> On May 23, 2026, at 1:21 PM, Mikael Abrahamsson > <[email protected]> wrote: > > On Sat, 23 May 2026, Robert Raszuk wrote: > >> But what about BGP Attributes which should never be sent interdomain ? As >> you can see from csv there are lots of them and the list keeps growing. > > I think this "never be sent interdomain" registry is a good suggestion, but > we need a knob to tell what is "interdomain" and not, on peer level, if > that's where the filtering is going. > > I have EBGP peers that are to other ISPs, and I have EBGP peers that are > internal. Some EBGP peers need my VXLAN nexthops (the internal ones), other > EBGP peers definitely don't.
The way this was typically handled in the past was the idea of BGP confederations and you would configure a list of internal vs external ASNs. This has also meant things like internal ASNs in private ASN ranges, through commands like remove-private and such. Some implementations required explicit configuration of send-community, and in these others we have varying levels of scrubs that may be required. The implementation of large communities originally required sending transitive attributes across until implementations caught up and parsed them. This was a big gap in the AS4 transition. We are regularly finding gaps in policies where our communities are leaking out to the internet and have to later clean them up. This is largely why we have had to move to standardized templates on the network devices and eventually can deploy clean configurations on devices that are not regularly touched. People need to be aware of what they are leaking and it’s easy to look at RIS/RIS Live and route-views dumps to determine what might be going out. It’s also important that networks share/publish that information. I’ve also been surprised that not all implementations dump/expose these well known attributes so this requires updates and changes as well to detect what is exported. The network is always a bit wilder than what we expect. - Jared _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
