On Thu, Jun 07, 2018 at 10:20:17AM +0100, Stuart Henderson wrote: > On 2018/06/07 10:26, Claudio Jeker wrote: > > On Wed, Jun 06, 2018 at 11:04:56PM +0200, Claudio Jeker wrote: > > > So the announce keyword in bgpd is massivly overloaded. > > > It is one of the most common things new bgpd users are unsure about. > > > These are all possible announce options: > > > > > > announce (IPv4|IPv6) (none|unicast|vpn) > > > announce as-4byte (yes|no) > > > announce capabilities (yes|no) > > > announce refresh (yes|no) > > > announce restart (yes|no) > > > and > > > announce (all|none|self|default-route) > > > > > > Especially the last one is a bit confusing because it influences the way > > > the filter work. This was good in the beginning of bgpd but now I think > > > the time is right to move on. Filtering in general got more important and > > > using large-communities as a method to tag prefixes so that they can be > > > matched against those later is important. > > > People are easily confused by `announce IPv4 unicast` vs `announce all` > > > and so on. > > > > > > The following diff does a few things. > > > a) it removes the `announce (all|none|self|default-route)` version > > > b) `announce none` is now `export none` > > > c) `announce default-route` is now `export default-route` > > > d) the examples file is adjusted accordingly and also the network > > > statements are no setting a large-community which is used by the > > > filters. > > > e) the filters are split in input and output and to a lesser extent > > > ibgp vs ebgp. > > > f) since anounce self is gone the filters will now default deny (which is > > > not a big thing and has the benefit that at start all routes show up in > > > Adj-RIB-In first). > > > > > > In general people using `announce all` can just remove the line. When > > > using `annouce self` more care is needed since the filters may need extra > > > adjustment. `announce none` and `announce default-route` are simple > > > renames, every thing else remains the same. > > > > > > > To be more precise what needs to be changed in your config. > > > > - neighbors using 'announce none' just rename it to 'export none' > > - neighbors using 'announce default-route' just rename it to 'export > > default-route' > > > > For all other cases 'announce self' and 'announce all' needs to be removed > > and filters need to be put in place instead. A good example is in > > /etc/example/bgpd.conf. In short you want to permit ibgp in and out and > > for ebgp you want to only allow reasonable things in and only your > > announcements out. How is this done best is by tagging announcements with > > a community. I use large-community here because they are more expressive. > > > > # tag announcements with a community > > network 10.0.1.0/24 set large-community $ASN:1:1 > > > > ... neighbor configs ... > > > > # first inbound > > allow from ibgp > > # the example filters out a lot of bad prefixes here which is good > > # In general you don't trust the outside world so this is where you should > > # filter the most. > > allow from ebgp inet prefixlen 8 - 24 > > allow from ebgp inet6 prefixlen 16 - 48 > > # scrub our community range from ebgp > > match from ebgp set large-community delete $ASN:*:* > > > > # now outbound filters > > # again ibgp is generally allowed > > allow to ibgp > > # for ebgp make sure to not leak any unintended networks so best is to > > # just allow the networks we tagged. > > allow to ebgp large-community $ASN:1:1 > > # another option is to go eplicit by network > > allow to ebgp prefix 10.0.1.0/24 > > > > For a pure ibgp router the basic rules can be simplified to: > > allow from ibgp > > allow to ibgp > > > > While most configs probably have inbound filters they may lack outbound > > filters. It is possible to check the effect of this change by adding > > deny from any > > deny to any > > at the start of your filters. `bgpctl show rib out nei myPeerName` is a > > great way to see what is announced before and after. > > > > See this as an oportunity to bring your bgpd filter up to current > > standards. > > -- > > :wq Claudio > > > > It would be helpful during upgrades if it's possible to write some > configurations that work the same on both the old and new versions. > That way the configuration can be changed to a version which will > still work before you get to the point where you can't simply revert > to the old config file). I think if the new version would accept > but ignore "announce all", that would be enough.
Yes, I can add a dummy "announce *" handler. In general people should be already able to write filters that work before and after the change. Happy to add a bit of code to ease the change but it also comes with a price that users may not adjust their configs because they don't fail to load. > Remember that "announce self" is implicit for ebgp neighbours unless > there's another "announce" keyword, so people might be using it without > realising. It would not be very good if those people (who are probably > not dealing with BGP often) started redistributing all their transit > routes to peers ;) I know, this is why there is also the change to default deny. Now if somebody uses implicit announce self with a ruleset that has allow to any in it then this will blow up badly. Should not be the common case but I guess there is always one or two specialists out there. I spent some time thinking on ways to catch that but I did not find a solution that has no other major drawbacks. The only way forward is that people start fixing their configs now and then when they upgrade there is no surprises. -- :wq Claudio