• Author : Josh pfosi

 
 

BGP Labeled Unicast / Segment Routing Multi-agent Support

Description This feature implements RFC3107 that allows carrying a label stack with BGP route updates, using multi-protocol BGP. It also implements segment routing extensions that allow accepting and carrying the transitive segment-index (SID) attribute in LU route updates. This implementation is for multi-agent mode. BGP LU for ribd mode is supported since 4.17.0F, see details at the following location: https://eos.arista.com/eos-4-17-0f/bgplu/ The following BGP LU features are supported as of release 4.20.5F: Basic IP{v4,v6} BGP LU, (i.e. receiving, re-advertising, and originating LU updates) iBGP and eBGP peering for LU peers Using ISIS-SR (or other MPLS tunnels) as the underlay for LU...
Continue reading →

Support for CPU traffic policy

Description This feature adds support for CPU traffic policy capable of matching and acting on IP traffic which would otherwise hit the CPU. This policy is capable of permitting traffic from trusted sources, while rejecting untrusted traffic. It supports matching on a variety of IP packet header information such as DSCP, L4 port values, fragmentation bits, etc. as well as a number of actions such as permit, deny, and police. To prevent a malicious source from overloading the CPU, this traffic policy will take effect in the switching hardware, before the traffic is processed by the kernel. This feature provides...
Continue reading →

Respect ‘set community’ clause order between route-map sequences

Introduction NOTE: The entire contents of this TOI apply equally to standard communities as well as extended communities. For brevity, the term “community” is used to mean either one. This feature adds support for “sequential” processing of route-map ‘set ext/community’ clauses. This feature is enabled via a configuration knob and there is no change in behavior without enabling this knob. The default route-map processing behavior can be summarized as “add then delete”. ip community-list expanded cl1 permit 1:.* route-map RMAP permit 5 set community 1:10 1:20 route-map RMAP permit 10 set community community-list cl1 delete route-map RMAP permit 15 set...
Continue reading →

BGP IPv6 link-local peering support (RFE 60498)

Introduction This feature adds support for BGP peering over IPv6 link-local addresses. As defined in RFC 4007, IPv6 addresses have multiple possible scopes . The prefix range fe80::/10 is reserved for uniquely identifying interfaces on a single link, or of link-local scope. Previous EOS versions supported BGP sessions with IPv4 or IPv6 peer addresses, as in: router bgp 64496 router-id 0.0.1.1 neighbor 192.0.2.1 remote-as 64497 neighbor 192.0.2.1 maximum-routes 12000 ! However, attempting to peer using the designated IPv6 link-local address prefix range was prohibited. neighbor fe80::1 remote-as 64496 % Link-local address is not allowed The BGP IPv6 link-local peering support...
Continue reading →

BGP route-map match on route type

Introduction This feature adds support for a ‘match route-type’ route-map match clause in release 4.20.1F. This clause allows filtering routes based on the peer from which the route was learned. Specifically, the user can match on ‘external’, ‘internal’, ‘local’, or ‘confederation-external’ which match on EBGP, IBGP, locally originating (e.g. aggregate), or confed-EBGP routes, respectively. This clause has a wide range of potential use cases. One use case is to add specific communities to all externally (EBGP) routes prior to propagating them into a customer’s network. Configuration In order to configure this feature, the following command is configured in the route-map...
Continue reading →

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: