Tag :: BGP

This new feature explains the use of the BGP Domain PATH (D-PATH) attribute that can be used to identify the EVPN domain(s) through which the EVPN MAC-IP routes have passed. EOS DCI Gateway provides new mechanisms for users to specify the EVPN Domain Identifier for its local and remote domains.   DCI Gateways sharing the same redundancy group should share the same local domain identifier and same remote domain identifier.

Multihoming in EVPN allows a single customer edge (CE) to connect to multiple provider edges (PE or tunnel endpoint). In any multihoming EVPN instance (EVI), for each ethernet segment a designated forwarder is elected using EVPN type 4 Ethernet Segment (ES) routes sent through BGP. In single-active mode, the designated forwarder (DF) is responsible for sending and receiving all traffic. In all-active mode, the DF is only used to determine whether broadcast, unknown

EVPN MPLS VPWS (RFC 8214) provides the ability to forward customer traffic to / from a given attachment circuit (AC) without any MAC lookup / learning. The basic advantage of VPWS over an L2 EVPN is the reduced control plane signalling due to not exchanging MAC address information. In contrast to LDP pseudowires, EVPN MPLS VPWS uses BGP for signalling. Port based and VLAN based services are supported.

Multihoming in EVPN allows a single customer edge (CE) to connect to multiple provider edges (PE or tunnel endpoint).

Flexible cross-connect service is an extension of EVPN MPLS Virtual Private Wire Service (VPWS) (RFC 8214). It allows for multiplexing multiple attachment circuits across different Ethernet Segments and physical interfaces into a single EVPN VPWS service tunnel while still providing single-active and all-active multi-homing.

Starting with EOS release 4.22.0F, the EVPN VXLAN L3 Gateway using EVPN IRB supports routing traffic from one IPV6

Starting with EOS release 4.22.0F, the EVPN VXLAN L3 Gateway using EVPN IRB supports routing traffic from IPV6 host to

Starting with EOS release 4.22.0F, the EVPN VXLAN L3 Gateway using EVPN IRB supports routing traffic from one IPV6

A forwarding equivalence class (FEC) entry is the data structure that holds all reachable vias where the packets should be sent to, for certain routes. Before this feature, a FEC could not contain both IPv4 next hop vias and IPv6 next hop vias. This feature starts supporting FECs that have both IPv4 next hop vias and IPv6 next hop vias. In an Equal Cost Multi-Path (ECMP) FEC, some of the vias may have IPv4 next hop and others may have IPv6 next hop. 

The General Router ID configuration provides the ability to configure a common Router ID for all routing protocols

This feature involves the use of packet’s Time to Live (TTL) (IPv4) or Hop Limit (IPv6) attributes to protect

This feature involves the use of packet’s Time to Live (TTL) (IPv4) or Hop Limit (IPv6) attributes to protect

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.

This feature introduces the ability to match on 1) any BGP aggregate contributor or 2) a specific BGP aggregate’s

This feature enables the user to configure a list or range of BGP attributes to be ignored by the router on receipt of a BGP update message. The BGP attributes are discarded from the BGP update message, and unless the action of discarding an attribute causes the update message to trigger error handling, then the update message is parsed as normal.

Currently, the 'maximum routes' knob allows one to set an upper bound on the number of routes that can be received from a

The "set metric" clause in a route map sequence has been enhanced with the addition of the "igp nexthop cost" keyword.

MPLS over GUE (Generic UDP Encapsulation) is a tunneling mechanism for encapsulating MPLS IP traffic in a UDP header. This feature adds support for MPLS over GUE encapsulation for BGP VPN routes resolving over IPv4 next hops. 

The Multicast Source Discovery Protocol (MSDP) provides a mechanism to connect together multiple PIM Sparse Mode

EOS supported two routing protocol implementations: multi-agent and ribd. The ribd routing protocol model is removed starting from the EOS-4.32.0F release. Multi-agent will be the only routing protocol model. Both models largely work the same way though there are subtle differences.

Add support for dynamic prefix list based matching in multi agent model. Please refer the TOI for rib

The PIM routing protocol builds multicast routing state based on control packets and multicast data events. In our

This feature allows a compatible SSH client to authenticate to EOS via a FIDO2-anchored SSH key via the “This email address is being protected from spambots. You need JavaScript enabled to view it.” or “This email address is being protected from spambots. You need JavaScript enabled to view it.” key types. In OpenSSH this was introduced in version 8.2p1. This feature is not compatible with the Federal Information Processing Standards (FIPS)restrictions mode in EOS; if both are configured, this feature will take precedence.

Prior to EOS 4.23.2F, BGP missing policy action configuration is a global BGP configuration that, when set to deny,

This document describes a new CLI command to help debug how and why policy permits and denies paths. The aim of this CLI command is for the user to debug a route map or RCF (Routing Control Functions) function by specifying as input a prefix for which BGP has reachability for, either via a BGP peer or a redistribute source.

This feature supports generation of non host routes for the IPv6 neighbor entries learnt on an SVI interface. These

This feature allows redistribution of bgp unicast routes into multicast address families. Specifically it allows redistribution of ipv4 unicast routes into the ipv4 multicast address family and ipv6 unicast routes into the ipv6 multicast address family.

This feature allows routes that were leaked from one VRF (the source VRF) into another VRF (the destination VRF) using

In the BGP Update message’s AS_PATH, routers have the capability to perform route aggregation and combine the ASes an update has traversed, merging the discrete entries into an  AS_SET. Routers can also do this within the local confederation with member AS numbers, using an AS_CONFED_SET. Route aggregation can be problematic as it blurs the semantics of what it means to originate a route. RFC 6472 recommends not using AS_SET or AS_CONFED_SET in BGP, and further justifies reasoning as to why, as well as provides a recommended way to handle updates with these messages.

This feature provides support for advertising IPv4 unicast Network Layer Reachability Information (NLRI) with

This feature provides support for advertising IPv4 unicast Network Layer Reachability Information (NLRI) with

This is an extension to BGP MPLS VPNs that allows us to use iBGP as the PE CE protocol. This feature also provides a way to

RIB Route Control is a collection of mechanisms for controlling how IP routing table entries get used. Next hop

This feature adds support for ‘match interface’ clause under route map config for Bgp policy application in

This feature adds support for ‘match ip(v6) resolved next hop’ clause under route map config for BGP policy

This document describes a new CLI command to help debug how and why route maps permit and deny paths. The aim of this CLI

In a Service Provider (SP) network, a Provider Edge (PE) device learns virtual private network (VPN) paths from remote PEs and uses the Route Target (RT) extended communities carried by those paths to determine which customer Virtual Routing and Forwarding (VRF) the paths should be imported into (from where they can be subsequently advertised to Customer Edge (CE) devices).

Routing control functions (RCF) is a language that can be used to express route filtering and attribute modification logic in a powerful and programmatic fashion.

Routing Control Functions (RCF) is a language that can express route filtering and attribute modification logic in a powerful and programmatic fashion.The document covers: Configurations of a RCF function for BGP points of application

Routing Control Functions (RCF) is a language that can be used to express route filtering and attribute modification logic in a powerful and programmatic fashion.

Routing Control Functions (RCF) is a language that can be used to express route filtering and attribute modification logic in a powerful and programmatic fashion.

Segment Routing Traffic Engineering Policy (SR TE) aka SR Policy makes use of Segment Routing (SR) to allow a headend

Segment Routing Traffic Engineering Policy (SR TE) aka SR Policy makes use of Segment Routing (SR) to allow a headend

This feature enables the BGP additional-path send configuration only for routes whose prefixes match a prefix list. The goal is to advertise multiple paths for a specific set of routes.

A new configuration command label local-termination explicit-null under BGP LU address family allows BGP LU speakers to send explicit-null labels for prefixes for which the router is a terminating LSP node. The prefix is expected to be originating locally (via network command).

In EOS, BGP creates different update groups based on the outbound configuration. Different route maps or Routing

This command stores and displays a list of failed BGP connection attempts for each peer. This may be particularly

Support for negotiating and receiving IPv6 unicast and IPv6 labeled unicast (6PE) updates from a BGP peer.

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.

BGP address aggregation was previously only supported for IPv4 and IPv6 unicast address families. Equivalent BGP