• Author : Lavanya

 
 

Nexthop-group match in PBR policy

Nexthop-group match in PBR policy enables the user to match incoming packets being routed to a specified nexthop-group and provide alternate action in the PBR policy to override the routing decision provided by the FIB route. Specifying the nexthop-group in the PBR policy helps improve the scale since this eliminates the need to add rules to match each destination IP. The default TCAM hardware profile doesn’t support matching nexthop-group. User needs to select TCAM hardware profile pbr-match-nexthop-group to enable this feature as shown below. Platform compatibility DCS-7500E DCS-7280E Configuration Selecting TCAM hardware profile switch(config)# hardware tcam profile pbr-match-nexthop-group Example 1...
Continue reading →

RFC 3107 – BGP Labeled Unicast and Recursive route resolution of IPV4 BGP Routes using tunnels

The BGP labeled-unicast (LU) RFC is used to advertise BGP routes with a stack of MPLS labels, thereby allowing distribution of MPLS tunnel paths through BGP.  The BGP peers that have negotiated labeled unicast capability can carry one or more labels as part of the network layer reachability information (NLRI) in the route advertisement. Recursive route resolution of IPv4 BGP routes using tunnels allows for BGP route nexthops to be resolved through tunnel paths received from BGP or other protocols. Platform Compatibility DCS-7500R series DCS-7500E series Configuration The following configuration commands have been added to supported this functionality. Configuration for labeled-unicast capability The following command submode...
Continue reading →

Support for bandwidth percentage

The guaranteed bandwidth feature ensures minimum bandwidth for outgoing lower priority traffic from a specific queue of an egress interface to prevent starvation from high-priority traffic. The guaranteed bandwidth percentage is an extension to this existing feature wherein guaranteed bandwidth can now be configured in percentage in addition to the absolute value in kbps or pps. This percentage is applied to the port speed of the egress interface. Operators may now have the flexibility to express bandwidth in percent rather than in explicit digits, which automatically adjusts based on the configured speed of the interface. As an example, if the required guaranteed bandwidth on a 40G...
Continue reading →

VxLAN VTEP counters

The VxLAN VTEP counters feature allows the device to count VxLAN packets received and sent by the device on a per VTEP basis. Specifically, it enables the device to count bytes and packets  that are getting encapsulated and decapsulated as they are passing through. The counters are logically split up in the two VxLAN directions:  “encap” counters count packets coming from the edge, encapsulated on the device and directed to the core, while “decap” counters count packets coming from the core, decapsulated on the device and heading towards the edge. To be able to count VxLAN packets the device has to support VxLAN and have a VxLAN interface...
Continue reading →

L3 Interface Ingress Counters

L3 interface ingress counters can be used to count routable traffic coming into the box on sub-interfaces and vlan interfaces with L3 address (IPv4 and/or IPv6 address) configured. Such traffic will get accounted irrespective of routing decision. L3 interface counters are not supported on routed ports. Platform compatibility DCS-7050X DCS-7250X DCS-7300X series Configuration L3 interface ingress counters for subinterfaces can be enabled using the following configuration: 7050(config)#[no] hardware counter feature subinterface in L3 interface ingress counters for vlan-interfaces can be enabled using the following configuration: 7050(config)#[no] hardware counter feature vlan-interface in Note that L3 interface ingress counters are not enabled...
Continue reading →

eBGP IP next-hop unchanged

The eBgp “ip next-hop unchanged” feature allows a router to send routes to its eBgp peers without changing their next-hops to its own peering address. By default a Bgp router, as defined in RFC 4271, changes the next-hop attribute of a route to its own address before sending it out to its eBgp peer. The router uses third party address as next-hop when the eBgp peers are within the same subnet as the source of the prefixes. Users may need further flexibility for multihop eBgp peer other than the above cases. If the command proposed by this feature is configured,...
Continue reading →

eBGP IP next-hop unchanged

The eBgp “ip next-hop unchanged” feature allows a router to send routes to its eBgp peers without changing their next-hops to its own peering address. By default a Bgp router, as defined in RFC 4271, changes the next-hop attribute of a route to its own address before sending it out to its eBgp peer. The router uses third party address as next-hop when the eBgp peers are within the same subnet as the source of the prefixes. Users may need further flexibility for multihop eBgp peer other than the above cases. If the command proposed by this feature is configured,...
Continue reading →

Arista EOS 4.17.0F Release – Transfer of Information

Arista Platform Independent Features IS-IS over GRE tunnels IS-IS adjacency uptime CLI command to explain BGP best-path eBGP IP next-hop unchanged Maximum number of accepted routes in BGP BGP Policy config enhancements IPv4 Addressless Forwarding on IPv6 addressed Interfaces for BGP RFC5549 support RFC 5549 support for BGP OSPFv3 BFD RFC 5838 support for OSPFv3 (AF support) LDP IS-IS Segment Routing QoS Profiles MapReduce tracer support for MR2 BFD enhancements MLAG heartbeat timeout enhancements Port-Channel member-status logging Event Manager on-logging handler Event Manager TCollector counters Event Manager custom bash counters CloudVision eXchange Bug Alerts Arista 7010/7050X/7250X/7300X Specific Features L3 interface ingress...
Continue reading →

Follow

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

Join other followers: