주니퍼 용 BGP 원격 트리거 블랙홀 (RTBH) 필터

고객으로부터받은 경로에 RTBH 필터 를 구현하는 가장 우아한 방법을 찾으려고합니다 .

필터는 다음과 같아야합니다.

1. 접두사 목록에서 고객 소유의 접두사 만 수락하십시오.
2. / 32 접두사 만 허용
3. 블랙홀 커뮤니티 접두사 만
4. 다음 홉을 RTBH 다음 홉으로 설정 (192.0.2.1)

먼저 주니퍼의 " 라우팅 정책 조건에서 일치 조건 구성 "문서를 살펴 보았습니다 .

먼저 prefix-list-filter고객 접두사 목록의 경로 만 일치 route-filter하도록 허용하고 접두사를 / 32로 제한 하기 위해 a 를 결합하는 방법 을 생각했습니다 .

from {
    as-path customer;
    community blackhole;
    prefix-list-filter customer-prefixes orlonger;
    route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}

그러나 나는이 정보에 대해 문서에서 우연히 발견했다.

경로 필터, 접두사 목록 및 소스 주소 필터의 일부 조합을 포함하는 정책을 구성하면 논리 OR 연산 또는 가장 긴 경로 일치 조회에 따라 평가됩니다.

나는 이것을 이해 (나는 그것을 분명 조금 찾기) 내가 사용하는 경우로서 prefix-list-filter, route-filter및 / 또는 source-address-filter같은 용어에는 가장 긴 경기와 OR이 방법을 만드는 그들 모두 사이에 평가 될 것입니다 사용할 .

내가 생각해 낸 것은 다음 필터입니다. 이 hostroutes-only용어는 / 32보다 짧은 모든 접두사를 다음 정책으로 바꿉니다. 그 후 prefixes/ 32가 고객 범위 내에 있으면 해당 경로가 일치하고 블랙홀 커뮤니티가 설정됩니다.

term hostroutes-only {
    from {
        route-filter 0.0.0.0/0 prefix-length-range /0-/31;
    }
    then next policy;
}
term prefixes {
    from {
        as-path customer;
        community blackhole;
        prefix-list-filter customer-prefixes orlonger;
    }
    then {
        next-hop 192.0.2.1;
        accept;
    }
}

그래서, 이것이 이것을 처리하는 가장 우아한 방법입니까? 다른 솔루션?

고객을 블랙홀 만 / 32로 제한 할 이유가 없습니다.

이 같은:

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            prefix-list-filter AS42 orlonger;
        }
        then {
            community add NO-EXPORT;
            next-hop 192.0.2.1;
            accept;
        }
    }
    term advertise {
        from {
            prefix-list AS42;
        }
        then {
            community add ADVERTISE;
            next-hop peer-address;
            accept;
        }
    }
    term reject {
        then reject;
    }
}

다음 홉이 링크 주소 이외의 것으로 변경 될 수 있도록 BGP 설정에서 'accept-remote-nexthop'을 설정해야합니다.

또한 제공자가 단순한 '전체 블랙홀'과 다른 블랙홀 커뮤니티를 지원하기 시작한다는 것을 강력하게지지합니다. 특히 여러 국가에서 사업을하는 경우 일반적으로 공격이 대중 교통에서 비롯된 경우가 많으며 종종 고객이 실제로 국내 피어링에 액세스하려고하므로 여러 수준의 블랙홀을 구현하는 것이 유용합니다.

1. 완전한
2. 현지 국가 외부 (로컬 IXP, 전체 AS + 고객 확인)
3. 해당 지역 외부 (해당되는 경우 'Nordics'일 수 있음)
4. 블랙홀에 특정 피어링 라우터 포함 / 제외

피어링 라우터가 JNPR 인 경우 JNPR DCU / SCU를 사용하여 이와 같은 것을 구현하는 방법에 대한 예제를 제공하게되어 기쁩니다.하지만 커뮤니티 만 있으면 더 어색합니다.

고객의 옵션을 절대적으로 제한하려면 다음을 추가하십시오.

policy-statement /32 {
    term /32 {
        from {
            route-filter 0.0.0.0/0 prefix-length-range /32-/32;
        }
        then accept;
    }
    term reject {
        then reject;
    }
}

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            policy /32;
            prefix-list-filter AS42 orlonger;
        }
..
}

이런 식으로 논리적 AND 여야합니다. 그러나 나는 표현의 표현성을 줄이기 위해 복잡성을 만드는 데 가치가 있다고 생각하지 않습니다.