TOI Author :: Gary McCarthy

Currently, EOS supports the receiving and transmitting of BGP Flowspec rules. Rules received can be installed locally as ACLs and/or transmitted to other BGP peers/route reflectors. EOS relies on external controllers to inject these flowspec rules. The feature will allow flowspec rules to be defined via CLI in a similar fashion as traffic-policies is currently done. These policies would then be redistributed into BGP. Once redistributed, the rules can be advertised to other BGP peers and optionally installed locally on the configured system.

VRF redirection often requires matching packets’ source addresses against one or more sets of IP prefixes.  This can become difficult to manage when the prefix sets need to be consistently maintained on several devices and either change too frequently or are very large.  When the prefixes for the prefix sets are learned by BGP, this feature provides an alternative to maintaining unwieldy sets of statically configured IP prefixes.

Prior to release EOS 4.29.1, a statically configured BGP neighbor, listen range or interface peer could reference a single peer group for inheriting configuration parameters. EOS 4.29.1 adds the ability for that peer group to inherit configuration from up to 8 additional “ancestor” peer groups. The term “leaf peer group” is given to the peer group which is directly referenced by the BGP neighbor, listen range or interface peer.

Prior to EOS 4.24.1F, per-destination steering into an SR Policy was only supported for IP unicast BGP routes in the default VRF. Support for additional AFI/SAFIs were added as follows: EOS 4.24.2F: L2 EVPN — EOS 4.27.2F: BGP Labeled Unicast

BGP out delay is an existing feature in EOS where an optional delay could be applied prior to advertising a route. The

The aggregate address advertise only feature adds the capability of NOT installing the Null0 route in the FIB/kernel

The default policy behavior is to permit/accept all routes when a BGP neighbor or peer group is configured with a route