nlnog / bgpfilterguide Goto Github PK

Document this concept http://www.us.ntt.net/support/policy/routing.cfm#bgp_nexthop

As in ISP you're the only one advertising your PA space (and maybe single home PI space customers). On any peering you shouldn't see your own IP space being announced.

Hi All,

in the bogon_prefixes guide 2002::/16 is considered a bogon with remarks towards RFC7526, however Section 4 of the RFC clearly states that this does not deprecate 2002::/16:

   The basic unicast 6to4 mechanism defined in [RFC3056] and the
   associated 6to4 IPv6 prefix 2002::/16 are not deprecated.  

By looking at our Tier1 Transits we see 2002::/16 from Telia but not from NTT, which makes sense since @job announced NTTs removal in the RIPE routing WG.

I couldn't find any official deprecation of 2002::/16 and the remarks to RFC7526 in the filter guide seem to be misleading.

Is there any document deprecating 2002::/16? I do not have any personal opinion on this prefix or 6to4 in general, however we are receiving customer complaints due to our implementation of the filter guide .

Every once in a while some network operator makes a mistake and starts announcing a peering subnet like 80.249.208.0/21 (Ams-ix) or 193.239.116.0/22 (Nl-ix). In some of these cases even more specifics. You don't want to accept these routes.

Hello, the OpenBGPD example is different from the other two. Is there a reason for that? Which one is correct?
I have highlighted the difference in pseudo code below.

BIRD, Junos, Arista

if ( ( bgp_community.length + bgp_ext_community.length + bgp_large_community.length ) >= 100 ) {
    bgp_community.delete_all();
    bgp_ext_community.delete_all();
    bgp_large_community.delete_all();
}

OpenBGPD:

if ( bgp_community.length >= 100 ) {
    bgp_community.delete_all();
}
if ( bgp_ext_community.length >= 100 ) {
    bgp_community.delete_all();
}
if ( bgp_large_community.length >= 100 ) {
    bgp_community.delete_all();
}

Ping on maintainers: @job @rodecker

It would be awesome to have some examples on how to implement RFC7999 (BLACKHOLE BGP Community) with the several platforms

For both

• the announcing part (e.g. how to announce to blackhole an IP address)
• and for filtering (e.g. how to check received announcements for certain communities and thus deny to accept them).

https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml contains a lot of prefixes that should never be seen in the global BGP routing table. These should be filtered out.