Intermediate System-to-Intermediate System (IS-IS) intra-domain routing information exchange protocol is designed by the International Organization for Standardization to support connectionless networking. This protocol is a dynamic routing protocol.
IS-IS is a link-state protocol, which uses the Shortest Path First (SPF) algorithm.
IS-IS and the OSPF protocol are similar in many aspects. As an Interior Gateway Protocol
(IGP), IS-IS runs inside an Autonomous System (AS).
To enable IS-IS, you must instantiate an IS-IS routing instance and assign it to an interface. Arista IS-IS support includes IS-IS segment routing and IS-IS graceful restart.
IS-IS Segment Routing
Segment Routing (SR) provides a mechanism to simplify the definition of end-to-end paths
within IGP topologies by encoding paths as sequences of topological sub-paths, called
segments. The IS-IS protocol advertises these segments in four different ways: node
segments, prefix segments, proxy-node segments, and adjacency segments.
Node-SID - Represents a node in an IGP topology. Uses an index or label associated with an Ipv4 or IPv6 address on
a loopback interface of a router.
Proxy Node-SID - Associated with an IP(v6) address received from a router that does not support IS-IS SR.
Prefix-SID - Represents an ECMP-aware shortest path to a prefix (or a node), as per
the state of the IGP topology.
Adjacency Segments - Represents a hop over a specific adjacency between two nodes in IGP.
Segment Routing Using IPv6
SRv6 provides the segment routing using IP v6 Data plane and encodes the segment ID
as an IPv6 address. The Micro-Segment extension to SRv6 uses the representation of
SIDs to enable compressing multiple of them into a single IPv6 address.
IS-IS support for SRv6 involves advertising the prefix and adjacency segments in the
LSP advertisements and computing reachability related to the same. The Locator uses
the prefix encompassing node SIDs,uN, and adjacency SIDs, uA. IS-IS also
advertises this Locator along with the SIDs. SRv6 computes the reachability to SIDs
using the Locator advertisement. EOS supports default-algorithms and FlexAlgo
SIDs.
Multiple node SIDs can be advertised from a node and each node SID can be associated
with a flex algorithm. The other nodes in the network install an IPv6 route and a
SRv6 tunnel either using the shortest IGP path for algo 0 locators or according to
the constraint specified in the Flex algorithm definition for the FlexAlgo
locators.
TI-LFA FRR using IS-IS Segment-Routing
Topology Independent Fast Reroute, or TI-LFA, uses IS-IS SR to build loop-free alternate paths along the post-convergence path. These loop-free alternates provide fast convergence in the range of sub-50 ms.
This section describes TI-LFA FRR using II-IS SR, including configuration instructions and command descriptions. Topics covered by this chapter include:
The (Point of Local Repair (PLR)- the router where TI-LFA is configured) PLR switches to
these loop-free alternate backup paths in the event of a link down (link-protection) or
BFD neighbor down (node-protection) event, protecting traffic destined to IS-IS SR node
segments, adjacency segments, and anycast segments while the IGP converges and the
post-convergence paths are computed. Anycast segment protection is restricted to those
segments which are attached to prefixes with host mask (/32
for V4 address and /128 for v6 address).
Note: Unlike node segments, anycast segments do not have the ‘N’ flag set described in
section 2.1.1.2 of RFC8667.
The following enhancements are available by release:
EOS Release 4.22.1F adds support for TI-LFA backup paths that protect IS-IS SR labeled traffic corresponding to a node segment or adjacency segment on a transit router.
EOS Release 4.23.1F adds support for TI-LFA backup paths that protect IS-IS SR tunnels.
EOS Release 4.24.1 adds support for protecting IS-IS SR labeled traffic corresponding to anycast segments.
EOS Release 4.24.2F adds support for calculating TI-LFA
backup paths that exclude the SRLG configured on the failing link.
Backup paths are only installed for IS-IS SR labeled routes and tunnels corresponding to node segments, adjacency segments, and anycast segments. When requesting node-protection, and no node-protecting LFAs are available, a link-protecting LFA is computed instead. TI-LFA FRR using IS-IS Segment-Routing is available with the multi-agent routing protocol model and the ribd routing protocol model.
Other traffic that resolves over IS-IS SR tunnels, such as LDP pseudowires, BGP LU tunnels, BGP IP routes, L2 EVPN, MPLS L3 VPN, and so on, are also protected by the TI-LFA tunnel that protects the resolving IS-IS SR tunnel.
TI-LFA FRR using IS-IS Segment-Routing Configuration
The following configuration tasks can be performed by Topology Independent Fast Reroute
(TI-LFA FRR) using IS-IS Segment-Routing.
Backup paths are not computed for prefix segments that do not have a host mask
(/32 for v4 and /128
for v6).
When TI-LFA is configured, the number of anycast segments generated by a node
cannot exceed 10.
Computing TI-LFA backup paths for proxy node segments is not supported.
Backup paths are not computed for node segments corresponding to multi-homed
prefixes. The multi-homing could be the result of them being anycast node
segments, loopback interfaces on different routers advertising SIDs for the same
prefix, node segments leaked between levels, and thus being seen as originated
from multiple L1-L2 routers.
Backup paths are only computed for segments that are non-ECMP.
Only IS-IS interfaces that are using the point-to-point network type are
eligible for protection.
Link/node protection is only supported in the default VRF owing to the lack of
non-default VRF support for IS-IS segment-routing.
Backup paths are computed in the same IS-IS level topology as the primary
path.
Even with IS-IS GR configured, SSU, SSO, agent restart are not hitless events
for IS-IS SR LFIB routes or tunnels being protected by backup paths.
IS-IS Graceful Restart
IS-IS Graceful Restart (GR) provides a mechanism to prevent routing protocol
re-convergence during a processor switchover or device downtime. Normally, when a router
restarts, all the neighboring routers associated with that router detect that the device
went down and remove routes from that neighbor. When the router restarts, the session
re-establishes, and data transfer continues. During the restart, the removal and
re-insertion of routes cause data loss. Prevent data loss by configuring Graceful
Restart on the device.
When using IS-IS as the Interior Gateway Protocol (IGP), the following EOS features require
nonstop forwarding (NSF) and support for the Graceful Restart from IS-IS:
Smart Software Upgrade (SSU).
A planned Stateful SwitchOver (SSO) for maintenance reasons or an unplanned SSO
due to failures on the active supervisor.
RIB agent restart due to software failures.
With IS-IS Graceful Restart (GR) configured, a redundancy switchover from an active to a standby
supervisor, or SSU, or restart of the IS-IS software, the RIB agent, should be a hitless
event if the GR completes successfully. Neighboring routers continue to forward traffic
to the restarting router, and traffic forwarding through the restarting router continues
without loss. When GR successfully completes, the failure of a router should be
completely transparent to network applications.
ISIS Graceful Restart (GR) is compatible with the following platforms:
IS-IS GR with unplanned software restart supported on all platforms.
IS-IS GR with SSO supported on modular dual-supervisor platforms.
IS-IS GR with SSU supported on platforms that support SSU.
IS-IS Dynamic Flooding
Dynamic Flooding allows IS-IS to scale to large, dense topologies such as Leaf-Spine
topologies. In such topologies, legacy IS-IS can exhibit a congestive collapse due to the
control plane load created by excessively redundant flooding.
The concept in Dynamic Flooding is to dynamically compute a restricted topology for
flooding (the flooding topology). Since this can be much smaller than the full
physical topology, this can reduce the redundancy seen by each node, thereby reducing
the control plane load and avoiding a congestive collapse.
To do this, first select one node within the IS-IS area as the area leader.
Leverage the Designated Intermediate System (DIS) election algorithm for this, except
instead of applying it to the neighbors on an interface, compute it across all of the
nodes within the area.
The area leader is responsible for computing the flooding topology. This is distributed
to the other nodes in the area through the Area System IDs TLV and the Flooding Path
TLV.
All nodes within the area then flood only on the flooding topology.
Figure 1. Flooding Topology
A flooding topology on a dense graph. The flooding topology is shown by the solid lines.
Dotted lines indicate non-flooding links.
In a dense topology, this can reduce the amount of flooding by an order of magnitude or
more, with a resulting increase in scalability.
Dynamic Link Delay using TWAMP Light
Overview of Link Delay using Two-Way Active Measurement Protocol (TWAMP)
EOS provides TWAMP support as a protocol used for active network performance
monitoring. It measures the end-to-end performance of a network path by sending and
receiving packets between two network devices. Previously, you could statically
configure the minimum and maximum link delay, but with the addition of TWAMP, EOS
supports dynamic measurement of link delay as described in RFC8186 and provides it to the IS-IS FlexAlgo
dynamically.
TWAMP Light provides two modes:
Active - The device initiates sending probe packets and receives
reflected packets with a timestamp to compute link-delay.
Reflector - The device receives the probe packet, adds the timestamps,
and sends it back.
The two modes operate independently, and the same interface can be in Active mode
and Reflector mode simultaneously. To avoid conflict, configure different UDP ports
for each mode.
IS-IS advertises the unidirectional link delay (the average delay), unidirectional min-max delay, and unidirectional delay variation measured by TWAMP
Light. Only the unidirectional min-max delay advertises in Application Specific Link Attributes Sub-TLV (ASLA).
This feature only supports IPv4 probe packets, but EOS utilizes the measured
link-delay values for IPv4 and IPv6 topologies in IS-IS multi-topology deployments.
Platform Support
EOS supports this feature on the following platforms:
7500R3X
7800R3X
DCS-7280XR3X
The platforms must have at least one Femtocell Access Point (FAP) with the Revision of Q2c2TX. To verify the FAP revision, use the
following command:
switch# show platform fap
Switches currently in the system
Name Type Device Revision
---------- -------------- --------------- --------------
Fap0 Jericho2 Jericho2c Q2c2tA1
IS-IS Configuration
These sections describe IS-IS configuration tasks:
Enabling IS-IS Globally and
Specifying an IS-IS Instance
The switch supports only one
IS-IS routing instance per VRF. The routing instance uniquely identifies
the switch to other devices. IS-IS configuration commands apply globally
to the IS-IS instance.
The switch must be in router IS-IS configuration mode to run IS-IS configuration commands. The
router isis command places the switch in router IS-IS
configuration mode.
Example
These commands create an IS-IS routing instance named Osiris in the default VRF and place
the switch in IS-IS configuration mode for that
instance.
After creating an IS-IS routing instance, configure the Network Entity Title (NET) with the net command. The NET defines the IS-IS area address and the system ID
of the device.
Example
These commands configure the NET by specifying the IS-IS area address and the system ID
of the device.
switch(config)# router isis Osiris
switch(config-router-isis)# net 49.0001.1010.1040.1030.00
Setting the Address Family
Configuration
The address-family command enables the address families that IS-IS will route
and places the switch in the configuration mode for that address
family. The address families supported are IPv4 unicast and IPv6
unicast.
Example
These commands enable and enter the address family mode for IPv4
unicast.
Configuring Redistribution of Connected or Static Non-ISIS Routes into Level-1 or
Level-2
Non-ISIS routes can be exported into Level-1, Level-2, or both using a route map. By default, the
routes are exported only to Level-2; to export to Level-1 or to both levels,
configure the route map using the set isis level command. The
Level-1 or Level-2 routes can also be filtered using the route maps match statement.
The route map is then used when redistributing routes in ISIS with the redistribute (IS-IS) command.
Use the show isis database detail command to make sure that the route
shows up in the exported level.
Examples
The following commands configure a route map called
rm to set the IS-IS level to Level-1, then
use it to redistribute connected routes.
The following command displays IS-IS database information and confirms that
the level has been set to Level-1.
switch# show isis database detail
ISIS Instance: inst1 VRF: default
ISIS Level 1 Link State Database
LSPID Seq Num Cksum Life IS Flags
1111.1111.1001.00-00 10 63306 751 L2 <>
NLPID: 0xCC(IPv4) 0x8E(IPv6)
Area address: 49.0001
<-------OUTPUT OMITTED FROM EXAMPLE-------->
Configuring Redistribution
of BGP Routes into ISIS
The redistribute bgp route-map command redistributes the BGP
routes from the specified route map into IS-IS. Only one route map can be specified;
reissuing the command overrides any previous configuration.
The no redistribute bgp and default
redistribute bgp commands disable BGP route redistribution
from the specified domain by removing the redistribute bgp
statement from running-config.
The command is available in both router IS-IS configuration mode and
the address-family submode. The command is rejected if configured in
both modes at the same time. Issuing the no or default command in
router IS-IS configuration mode has no effect on
redistribution configured in the address-family submode.
Note: If the command is configured in an address-family submode, it only
redistributes routes from that address family. If it is configured in router-ISIS
mode, it applies to all enabled address families.
Examples
These commands redistribute IPv4 BGP routes from the route map called
bgp-to-isis-v4 into the ISIS
domain.
The overload bit is set in link state packets (LSPs) to signal that the switch is not available
for forwarding transit traffic (for instance, during startup or when the
switch is being taken down for maintenance). To set the overload bit
manually, use the set-overload-bit command without the
on-startup option. To configure the switch to set
the overload bit after a reboot, allowing routing protocols to converge
before the switch is used for forwarding traffic, use the
set-overload-bit command with the
on-startup option. The overload bit will remain set
for the interval specified after startup.
Note: When using the on-startup option, the
overload bit will remain set in LSPs until the IS-IS agent has been up for
the configured interval. If the configured on-startup time
is less than the actual IS-IS agent uptime, the command will be applied
immediately.
In scenarios when Border Gateway Protocol
(BGP) routes are resolved using an Interior Gateway Protocol (IGP), if
the transit router reboots and becomes available again, the IGP will
consider the transit router as an optimal path again. After rebooting,
the transit router will blackhole traffic until the transit router learns
the external destination reachability information via BGP.
Examples
These commands configure the switch to set the overload
bit in LSPs sent for 120
seconds after startup.
These commands configure the overload bit until BGP converges.
If BGP fails to converge within the set timeout default
period, then the overload bit gets
cleared.
To configure authentication for the IS-IS instance causing LSPs, CSNPs, and PSNPs to be
authenticated, use the authentication mode and authentication key commands. To configure authentication on the
interface, causing IS-IS Hellos to be authenticated, use the isis authentication mode and isis authentication key commands on the interface.
Two forms of authentication are supported
by the IS-IS routing protocol: Clear-text authentication and MD5 authentication.
The difference between the two forms of authentication is in the level
of security provided. In the case of clear-text authentication, the password
is specified as text in the authentication TLV, making it possible for
an attacker to break authentication by sniffing and capturing IS-IS PDUs
on the network. Arista recommends using the MD5 authentication.
HMAC MD5 authentication provides much
stronger authentication by computing the message digest (on the IS-IS
PDU contents) using the secret key to produce a hashed message authentication
code (HMAC). Different modes of authentication can be specified on the
interface, which authenticates IIH PDUs (IS-IS hello PDUs), and globally
in the router IS-IS mode, in which the LSPs, CSNPs and PSNPs are authenticated.
Area-wide and domain-wide authentication can be specified for L1 and
L2 routers respectively.
Examples
These commands configure authentication for the IS-IS instance causing LSPs,
CSNPs, and PSNPs to be
authenticated.
To maximize interoperability, Arista recommends using the same key in both interface mode
and in the router isis mode.
Setting the SPF Interval
The SPF timer interval defines the maximum interval between two successive SPF calculations.
IS-IS runs SPF calculations following a change in the network topology or
the link-state database. The spf-interval command defines
the following intervals:
Maximum wait interval: The maximum time a switch will
wait before running an SPF after a topology change.
Initial wait interval: In a network that has been stable
throughout the hold interval, this interval defines the
initial wait time of a switch for performing an SPF
calculation after a topology change. As several link-state
updates must be sent after a topology change, the initial
wait interval allows the network to settle before a switch
computes an SPF. If the topology changes during an initial
wait interval, an SPF is calculated after the initial wait
interval expires and no further changes are made to throttle
timers.
Hold time: This interval delays SPF calculations during
network instability. If the topology changes during a hold
time, an SPF is computed when the hold time expires.
Subsequent hold intervals are doubled up to the configured
maximum wait interval for continuous topology changes. If
the next topology change occurs after the hold interval
expires, the hold interval is reset to its configured value
and the SPF is computed after the initial wait
interval.
Note: EOS does
not support configuring topology-specific SPF timers
in multi-topology deployments and IS-IS
level-specific SPF timers.
Example
This command configures maximum wait interval, initial wait interval, and hold
time to 10 seconds, 2000
ms, and 1000 ms respectively.
Configuring IS-IS Segment Routing
Global Adjacency-SID
IS-IS Segment Routing (SR)
supports global adjacency SIDs for point-to-point interfaces. The adjacency
SID is configured as an index using the adjacency-segment command.
Global adjacency segments are represented using an index instead of actual MPLS labels. The index
is an offset into the Segment Routing Global Block (SRGB) advertised by a router, resulting in
an MPLS label. The default value of SRGB in EOS is Base: 900000 and
Size: 65536.
The same index may be used to configure
multiple interfaces so that MPLS forms an ECMP group, and the same index
may be applied to IPv4 and IPv6 adjacencies.
Example
In this example, the global adjacency is configured on a point-to-point interface
ethernet Et1, with an index value
10.
switch(config-if-Et1)# adjacency-segment ipv4 p2p index 10 global
Displaying Adjacency SID Information
The command show isis segment-routing adjacency-segments displays the
global adjacency SID value and other related information.
Examples
In this example an interface is configured as follows:
switch(config)# interface ethernet 1/1
switch(config-if-Et1/1)# ip address 1.1.1.1/24
switch(config-if-Et1/1)# ipv6 address 1000::1/64
switch(config-if-Et1/1)# isis enable isis1
switch(config-if-Et1/1)# isis network point-to-point
switch(config-if-Et1/1)# adjacency-segment ipv4 p2p index 1 global
switch(config-if-Et1/1)# adjacency-segment ipv6 p2p index 2 global
The show output for the above interface
configuration:
switch# show isis segment-routing adjacency-segments
System ID: 1000.0000.0002 Instance: isis1
SR supported Data-plane: MPLS SR Router ID: 1.1.1.4
Adj-SID allocation mode: SR-adjacencies
Adj-SID allocation pool: Base: 100000 Size: 16384
Adjacency Segment Count: 2
Flag Descriptions: F: Ipv6 address family, B: Backup, V: Value
L: Local, S: Set
Segment Status codes: L1 - Level-1 adjacency, L2 - Level-2 adjacency, P2P -
Point-to-Point adjacency, LAN - Broadcast adjacency
Locally Originated Adjacency Segments
Adj IP Address Local Intf SID SID Source Flags Type
----------------- ---------- ------ ----------- --------------- -------
1.1.1.2 Et1 1 Configured F:0 B:0 V:0 L:0 S:0 P2P L1
fe80::1:ff:fe65:0 Et1 2 Configured F:1 B:0 V:0 L:0 S:0 P2P L1
Received Global Adjacency Segments
SID Originator Neighbor Flags
--------- -------------------- ---------------- ---------
0 rtrmpls1 1000.0000.0002 F:0 B:0 V:0 L:0 S:0
Enabling Logging for Peer Changes
The log-adjacency-changes (IS-IS) command configures the switch to send
syslog messages when it detects IS-IS neighbor adjacency state changes.
Example
These commands configure the switch to send a Syslog message when a neighbor goes up or
down.
The is-hostname command configures the use of a human-readable string to
represent the symbolic name of an IS-IS router. It also changes the output
of IS-IS show commands, to show the IS-IS hostname in place of system IDs if
the corresponding IS-IS hostname is known. However, Syslogs still use IS-IS
system IDs and not the IS-IS hostname.
By default if there's a hostname configured on the switch, it is used as the IS-IS hostname. It
is also possible to de-configure an assigned hostname for IS-IS using the
no is-hostname command. When the
IS-IS hostname is removed, the switch goes back to using the switch's
hostname as the IS-IS hostname.
Examples
These commands configure the IS-IS hostname to the symbolic name
ishost1 for the IS-IS
router.
These commands unconfigure the IS-IS hostname of the symbolic name
ishost1 for the IS-IS
router.
switch(config)# router isis inst1
switch(config-router-isis)# no is-hostname ishost1
switch(config-router-isis)#
Configuring IS-IS Multi-Topology
The multi-topology command configures IS-IS Multi-Topology (MT) support
(disabled by default), enabling an IS-IS router to compute a separate topology for IPv4
and IPv6 links in the network. With MT configured, not all the links in a network need
to support both IPv4 and IPv6. Some can support IPv4 or IPv6 individually. The IPv4 SPF
will install IPv4 routes using the IPv4 topology, and similarly, the IPv6 SPF will
install IPv6 routes using the IPv6 topology. Without MT support, all links in an IS-IS
network need to support the same set of address families.
When MT is enabled, and each link has
a separate IPv4 metric and IPv6 metric.
The isis multi-topology command configures the IPv4 or IPv6 address family
individually on an interface with both IPv4 and IPv6 addresses.
The address families that are enabled
on an interface are based on the global address families enabled in router
IS-IS configuration mode, and the addresses configured on the interface.
To enable a particular address family on an interface, it needs to have
an address configured in that address family. In the case where both
IPv4 and IPv6 address families are enabled in router IS-IS configuration
mode, then if an interface has IPv4 and IPv6 addresses, both IPv4 and
IPv6 address families are enabled on that interface. In the case of an
interface with only an IPv4 address family, the IPv4 address family is
enabled on that interface. Where an interface only has an IPv6 address
family, the IPv6 address family is enabled on that interface. Finally,
where only the IPv6 address family is enabled in router IS-IS config
mode and MT is enabled, then the IPv6 address family is enabled on all
interfaces which have an IPv6 address configured.
Configuring the Hello Multiplier
for the Interface
The switch maintains the adjacency
by sending/receiving hello packets. When receiving no hello packets from
the peer within a time interval, the local switch considers the neighbors
invalid.
The isis priority command determines which device will be the Designated
Intermediate System (DIS). The device with the highest priority on the LAN will become
the DIS.
Example
These commands configure a device priority of 60 on interface
interface ethernet
5.
A passive IS-IS interface does not send or receive IS-IS packets and will not form adjacencies,
but is still included in LSP advertisements, making its IP address visible to the IS-IS
domain. To configure an IS-IS interface as passive, use the isis passive command in interface configuration mode or the passive (IS-IS) command in router IS-IS configuration mode.
Examples
These commands configure interface ethernet 10 as a
passive interface.
The isis bfd and bfd
all-interfaces commands configure Bidirectional Forwarding Detection (BFD).
BFD is supported for both IS-IS IPv4 and IPv6 routes.
Examples
These commands enable BFD (for the IPv4 address family) for all the interfaces
on which IS-IS is enabled. By default, BFD is disabled on all
interfaces.
IS-IS BFD Damping prevents a switch from establishing IS-IS adjacency on a link that
experiences frequent BFD flapping. This feature mitigates SPF churn and reduces the
computational load on the system by ensuring link stability before forming a
neighbor relationship.
When BFD signals a DOWN state, IS-IS immediately removes the
adjacency, and recurring IP forwarding failures on a link result in adjacency flaps
on IS-IS. After enabling BFD Damping, IS-IS requires BFD to remain stable in the
UP state for a specified duration before attempting
to form an adjacency with the neighboring device.
BFD Damping has three distinct intervals to calculate the damping period:
Initial Interval - Applies to the state when an adjacency forms for
the first time, and has no prior BFD session monitored by the peer. Use the
recommended value of 0 for the initial interval.
Hold Interval - Applies to the state when an adjacency re-establishes
after encountering the first BFD flap.
Max Interval - Defines the upper limit for damping after encountering
multiple BFD flaps in quick succession.
Configure all intervals in seconds, and ensure that the initial and hold interval values
do not exceed the maximum damping interval. EOS disables the feature by default and
supports only Point-to-Point (P2P) interfaces.
Note: Configure this feature with IPv4 or IPv6 address families.
For the feature to work as intended, switches at both link endpoints must have BFD
Damping enabled with the same set of damping intervals. The following describes the
behavior with the initial, hold, and max intervals:
IS-IS begins the damping timer when the BFD state changes to
UP, and expects BFD to remain stable in the
UP state for the duration of the timer
before forming an adjacency.
If IS-IS attempts to establish adjacency for the first time without
a prior BFD session monitored by the peer, the damping timer starts
for the initial interval.
If IS-IS attempts to establish adjacency after experiencing a BFD
flap for the first time, the damping timer starts for the hold
interval.
If IS-IS experiences another BDS flap after the damping timer
begins, the current damping timer doubles when attempting to
establish an adjacency the next time, until it reaches the maximum
damping interval.
After BFD has stayed in the UP state through the
damping timer and finally establishes adjacency, the next BFD flap restarts
the damping timer for the hold interval.
BFD IPv4 and IPv6 flaps can be monitored by configuring BFD Damping for both address
families. In this case, the damping timers run independently for IPv4 and IPv6.
Adjacency occurs only if the BFD state remains stable corresponding to the
configured set of damping intervals, and neither damping timer has started.
If the adjacency currently has an UP status and BFD Damping needs
to be enabled, first configure IS-IS BFD, and wait for BFD to become active. Then,
configure BFD Damping for both address families.
If you need to configure new damping intervals while the corresponding damping timer runs, IS-IS immediately stops the damping timer.
The new intervals apply to the subsequent BFD flaps.
When enabling BFD Damping on an interface, BFD-enabled TLV (Type 148) advertise in the
IS-IS Hello PDUs (IIH). Even though IS-IS exchanges IIH packets with the link, IS-IS
does not form the adjacency if the link does not have a BFD session with an
UP status.
When IS-IS undergoes a graceful restart, EOS establishes the adjacencies regardless of
the BFD state, and damping timers do not initiate. After exiting the graceful
restart, IS-IS monitors the BFD flaps and applies BFD Damping if configured.
Use the following commands to enable BFD Damping for IS-IS isis-4, ipv4
address-family, with a damping interval of initial 0, hold 3, and max
15:
switch(config)# router isis isis-4
switch(config-router-isis)# address-family ipv4
switch(config-router-af)# bfd all-interfaces wait-for-up damping-interval initial 0
hold 3 max 15
To disable BFD Damping, use the no version of the command:
switch(config-router-af)# no bfd all-interfaces
Apply BFD Damping to specific IS-IS interfaces using the following commands:
switch(config)# interface Ethernet1
switch(config-if-Et1)# isis bfd wait-for-up damping-interface initial 0 hold 3 max 15
To disable BFD Damping on an interface, use the following commands:
switch(config)# interface Ethernet1
switch(config-if-Et1)# no isis bfd
The interface IS-IS BFD Damping feature configuration overrides the corresponding global address-family configuration. However,
if you set the interface configuration as default isis bfd, then the global address family configuration applies.
Displaying the BFD Damping Configuration
The show isis interface command displays the configured BFD Damping intervals for each address family on
an IS-IS interface.
The show isis neighbors detail displays detailed information about the state of BFD Damping such
as the following:
IS-IS waits for BFD to remain stable by staying in the UP
state in order to form the adjacency.
The duration, in seconds, that IS-IS expects BFD to stay UP
before establishing the adjacency.
switch# show isis neighbors detail
Instance VRF System Id Type Interface SNPA State Hold time Circuit Id
1 default ip2 L2 Ethernet1 P2P INIT 28 0A
...
BFD IPv4 wait-for-up is enabled
BFD IPv6 wait-for-up is enabled
Neighbor BFD IPv4 wait-for-up is enabled
Neighbor BFD IPv6 wait-for-up is enabled
BFD IPv4 damping is active Adjacency is waiting for BFD IPv4 to remain up
Damping timer: expires in 7 s at 2025-6-29 21:58:30
BFD IPv6 damping is active
Adjacency is waiting for BFD IPv6 to remain up
Damping timer: expires in 2 s at 2025-6-29 21:58:25
While IS-IS waits for BFD to remain in the UP state, the
adjacency state on the local and neighbor device displays
INIT. After BFD becomes active, the adjacency state on
both IS-IS devices transitions to UP status.
Configuring IS-IS LSP Out Delay
EOS implements IS-IS LSP Out Delay to mitigate transient micro-loops that may occur
during topology changes. By strategically delaying the flooding of routing updates, the
switch ensures that all nodes in the network converge in a predictable sequence.
When topology changes occur, such as a link state or metric change, different routers in
the network receive and process the updated Link State PDUs (LSPs) at slightly different
times which leads to a transient state on the network. Some routers update the
Forwarding Information Base (FIB) based on new LSPs, and other routers do not update the
FIB, which causes traffic to forward incorrectly and form micro-loops.
Configuring the LSP Out Delay feature forces a router to pause before flooding
self-originated LSPs after a link or metric decrease event. By delaying the
advertisement, the local router completes the Shortest Path First (SPF) calculation and
FIB update before the peer routers receive the LSP and recalculate the paths.
Use the following commands to configure the LSP Out Delay feature on switch, ISIS-4,
5000 milliseconds:
Configure the same out-delay value for each end of a link (peers).
For a link-up event, the out-delay timer starts only after establishing adjacency with the
peer.
For a metric decrease, the out-delay timer starts immediately after the metric change and defers the
advertisement with the updated metric.
Configuring Multiple Router Capability TLVs
The IS-IS Multiple Router Capability TLVs Advertisement feature addresses a critical
scalability bottleneck in segment-routed networks. It enables EOS to generate,
advertise, and process multiple Router Capability TLVs (Type 242) within IS-IS Link
State PDUs (LSPs).
To enable the feature on the router, remoteloc, use the following
commands:
Global IS-IS Segment Routing (IS-IS SR) commands are accessed in Segment-Routing MPLS mode, under the router IS-IS configuration mode. Interface-specific IS-IS SR commands are accessed in interface configuration mode.
Starting the MPLS Agent
The Routing Information Base (RIB) or IS-IS agent provides IS-IS segment routing, but the actual
installation of LFIB entries pertaining to SR information provided by IS-IS
is handled by the MPLS agent in EOS, which is disabled by default. To enable
the MPLS agent, use the following commands.
Note: IP(v6) routing must be enabled as a prerequisite.
Example
The following commands enable IP routing and the MPLS agent on the
switch.
switch(config)# ip routing
switch(config)# mpls ip
switch(config)#
Enabling IS-IS SR
By default, IS-IS SR is disabled. You must enable it explicitly by issuing the no form of
the shutdown (IS-IS SR)
command in Segment-Routing MPLS configuration mode.
To administratively disable IS-IS SR, issue the shutdown (IS-IS SR)
command in Segment-Routing MPLS configuration mode. To disable isis sr and
delete all isis sr configuration, issue the segment-routing mpls command in router isis
configuration mode.
Examples
The following commands administratively disable router
isis.
The following commands disable router isis and delete
all router isis
configuration.
switch(config)# router isis instance1
switch(config-router-isis)# no segment-routing mpls
switch(config-router-isis)#
SRGB (Segment Routing Global Range)
The global segments such as Prefix-SID, Node-SID, Proxy-node-SID are represented using
indices of actual MPLS labels. These indices are offset on the SRGB advertised by a
router to derive the respective MPLS label. The default value of SRGB in EOS is Base:
900000, Size: 65536. In
other words, the labels that any global segment could represent is between
900000-965535. The MPLS
label range is categorized and reserved into pools based on the applications using these
labels. The default values of label ranges in these pools are:
Dynamic Global Range--(100000)
(262144)
IS-IS SR Global Range -- (900000)
(65536)
Static Global Range -- (16)
(99984)
Note: SRGB can be configured to fit in different MPLS ranges as long as it does not fall
under an MPLS range already assigned for usage by other applications.
Example
switch(config)# mpls label range isis-sr 900000 65536
IS-IS Maximum LSP Size
The IS-IS maximum LSP size provides the ability to configure the maximum LSP size that
the IS-IS protocol accepts and sends. The default value of LSP size is
9000. The lsp size maximum
command configures maximum size of an LSP that is sent or received. The default LSP
maximum size is 9000. The minimum value is
512.
Example
switch(config)# lsp size maximum 400
The no lsp size maximum and default lsp size
maximum commands remove the specified lsp size
maximum command from
running-config.
switch(config)# no lsp size maximum
switch(config)# default lsp size maximum
Configuring the Node-SID
Node segments are indices associated with routers within an IS-IS SR domain by
associating node segments with prefix mask length /32 (IPV4)
or /128 (IPV6) addresses. Node segments are carried as
sub-TLVs (type-length-value) in IP reachability TLVs for the prefixes with the
associated segments. Node segments can also be represented by an absolute label and
validated against the default or user-specific SRGV advertised by a router. An Absolute
Node-SID has a label range of 16 - 1048575.
A node segment label or Absolute Node SID represents a global segment validated based on
the ISIS-SR global block, such as an SRGB range configured with the mpls
label range isis-srbaserange. Node segment label or Absolute Node SID advertise as an
index and bases the in-label on the local SRGB range and the out-label on the peer SRGB
range.
Configure node segments on IS-IS enabled Loop-back interface(s) as shown in the
example.
Note: Multiple node segments can be configured, but
each must have a unique index number.
Examples
Use the following commands to associate a node-segment with an IPv4 address.
switch(config)# int loopback 1
switch(config-if-Lo1)# ip address 21.1.1.1/32
switch(config-if-Lo1)# node-segment ipv4 index 5
Use the following commands to associate a node-segment with an IPv6
address.
switch(config)# int loopback 1
switch(config-if-Lo1)# ipv6 add 2000::24/128
switch(config-if-Lo1)# node-segment ipv6 index 6
The following example displays a warning in the CLI when no configured
/32 or /128 address
on the
interface.
switch(config)# int loopback 1
switch(config-if-Lo1)# ip address 21.1.1.1/24
switch(config-if-Lo1)# node-segment ipv4 index 1
! /32 IPv4 address is not configured on the interface
The following command configures an absolute label for a node-segment.
The following example displays a Node-SID with an absolute label.
switch(config-if-Lo1)# show node-segment ipv4 label 900123
The following command removes the node-segment from IS-IS SR from an
interface.
switch(config-if-Lo1)# no node-segment ipv4 index 1
Node segments can be configured with either an explicit-null or
no-php flag as well as a specific algorithm. The
following example shows how to add the two flag parameters:
switch(config-if-Lo1)# node-segment ipv4 index 1 ?
explicit-null Set Explicit Null flag
flex-algo Flexible algorithm
no-php Set No-PHP flag
switch(config-if-Lo1)# node-segment ipv4 index 1 explicit-null
switch(config-if-Lo1)# node-segment ipv6 index 2 no-php
switch(config-if-Lo1)# node-segment ipv4 index 3 flex-algo Algo-128
switch(config-if-Lo1)# show active
interface Loopback1
ip address 31.1.1.1/32
ipv6 address 2000::24/128
node-segment ipv4 index 1 explicit-null
node-segment ipv4 index 3 flex-algo Algo-128
node-segment ipv6 index 2 no-php
Note: A node segment configured with flex-algo only becomes active
when you enable Traffic Engineering and the IS-IS segment participates in the specified
flex-algo.
The CLI returns a warning if no /32 or /128 IPv4 addresses exist on the interface, but
accepts the configuration anyway.
switch(config-if-Lo2)# ip address 33.2.2.1/24
switch(config-if-Lo2)# node-segment ipv4 index 33
! /32 IPv4 address is not configured on the interface
switch(config-if-Lo2)# show active
interface Loopback2
ip address 33.2.2.1/24
node-segment ipv4 index 33
switch(config-if-Lo2)# node-segment ipv6 index 34
! /128 IPv6 address is not configured on the interface
switch(config-if-Lo2)# show active
interface Loopback2
ip address 33.2.2.1/24
node-segment ipv4 index 33
node-segment ipv6 index 34
switch(config-if-Lo2)# ip address 33.2.2.1/24
switch(config-if-Lo2)# node-segment ipv4 label 96123
! /32 IPv4 address is not configured on the interface
switch(config-if-Lo2)# show active
interface Loopback2
ip address 33.2.2.1/24
node-segment ipv4 label 61234
switch(config-if-Lo2)# node-segment ipv6 label 64321
! /128 IPv6 address is not configured on the interface
switch(config-if-Lo2)# show active
interface Loopback2
ip address 33.2.2.1/24
node-segment ipv4 index 33
node-segment ipv6 index 34
Remove node segments from IS-IS using the no parameter under the node-segment parameter for an interface.
switch(config-if-Lo2)# no node-segment ipv4 index 33
switch(config-if-Lo2)# no node-segment ipv4 label 900123
Configuring Prefix-SIDs
A router originating an IP reachability TLV associates Prefix segments with any IS-IS. These
segments are carried as sub-TLVs in IP Reachability TLVs of the
prefixes with which these segments are associated. Prefix segments are
configured under segment-routing MPLS configuration mode in IS-IS.
Note: The configured prefix segment becomes effective, only if, the prefix for which a prefix-SID
configured becomes a part of IS-IS by enabling IS-IS on interfaces, or
by redistribution from other protocols etc.
Example
Use the following commands to associate a prefix segment with an IPv4 address
with index value of
50.
Node segments represent a device (node) by attaching a segment (index) with a
/32, /128 prefix which generally is configured on a loopback
interface. For routers that do not support segment routing, you must assign node
identifiers on such routers. In this instance, a router that
supports IS-IS SR to proxy by configuring a proxy-node-SID for
an IS-IS prefix originating from the router that does not support IS-IS
SR.
Example
A proxy-node SID associates a /32 or a
/128 route with an SID.
In general, configure a proxy node segment on a
router without the prefix that you want to
associate with the proxy-node SID. You can also configure one
for self-originated prefixes.
Configuring proxy-node-SIDs enables a router to send out a Binding-SID TLV
with details pertaining to the prefix and SID.
Note: A Binding-SID can carry a range of prefixes and an associated range of
SIDs, but at present the EOS does not support the configuration of such ranges with one
binding segment TLV in IS-IS SR. However, EOS does process ranges of prefixes and SIDs, if
received from devices that support such configurations.
Attaching Flags to the Segmented Route
The default hop behavior of an Arista switch removes the top label if a neighbor node
advertises reachability. Change this behavior for Proxy-Node segments using the
attached parameter.
When routes redistribute from other domains into an IS-IS SR domain on a node, other nodes
assume the prefixes directly connect to the node advertising reachability. This may not be
the case and causes incorrect penultimate hop popping (PHP) behavior.
Using the attached flag corrects the behavior, and setting the flag on a proxy-node
segment directly connected to the node advertising reachability. Verify the attached
flag configuration using the show isis segment-routing
prefix-segments command.
switch(config-router-isis-sr-mpls)# show isis segment-routing prefix-segments
System ID: 0000.0000.5555 Instance: 'inst1'
SR supported Data-plane: MPLS SR Router ID: 5.5.5.5
Node: 5 Proxy-Node: 3 Prefix: 0 Total Segments: 8
Flag Descriptions: R: Re-advertised, N: Node Segment, P: no-PHP
E: Explicit-NULL, `V: Value, L: Local
Segment status codes: * - Self originated Prefix, L1 - level 1, L2 - level 2, ! - SR-unreachable,
# - Some IS-IS next-hops are SR-unreachable
Prefix SID Type Flags System ID Level Protection Algorithm
------------------- ----- ---------- --------------------------- --------------- ----- ----------- ----------
* 5.5.5.5/32 5 Proxy-Node R:0 N:0 P:0 E:0 V:0 L:0 A:0 0000.0000.5555 L2 unprotected SPF
* 6.6.6.6/32 6 Proxy-Node R:0 N:0 P:0 E:0 V:0 L:0 A:0 0000.0000.5555 L2 unprotected SPF
* 44.44.44.44/32 44 Proxy-Node R:0 N:0 P:0 E:0 V:0 L:0 A:1 0000.0000.5555 L2 unprotected SPF
Configure
a second parameter, attached-flag inspect and enable it on all
nodes. When set, the behavior defaults to no-php, the penultimate hop swaps or forwards the
label, for all proxy node segments without the attached
set.
The
resulting configuration has the following behavior:
pop action for 44.44.44.44/32 on penultimate node
R3.
swap action for 5.5.5.5/32 and
6.6.6.6/32 without the attached flag on R3.
pop action for 4.4.4.4/32 on R4 as the penultimate LDP
hop.
Configuration Considerations for the Attached Flag
Use when configuring proxy node segments for prefixes advertised by any node in the
IS-IS SR domain.
Use when configuring a proxy node segment for a prefix residing on an IS-IS domain
without SR.
Do not use when configuring proxy node segments on a node not in the IS-IS
domain.
Handling Conflicts between Proxy-Node Segments and Other Types of Segments
By default, EOS does not allow conflicts between proxy-node segments and other types of segments such as Node or Prefix. To ignore
conflicts, use the conflict ignore keyword when configuring proxy-nodes.
Example
The following configuration uses the conflict ignore keyword:
switch(config-router-isis-sr-mpls)#proxy-node-segment 1.0.14.1/32 index 200 range 10 conflict ignore
Configuring Anycast-SID
An Anycast-SID is a prefix segment that identifies a set of routers and not a specific
router. It enforces the ECMP-aware shortest-path forwarding towards the closest node of
the anycast set.
An example of such an anycast group could be a set of routers A1, A2, A3, and A4 where at
least one router of A1, A2, A3, and A4 advertises the prefix SID corresponding to the
anycast address (which can be a prefix originating on all of A1, A2, A3 and A4 a
loop-back address, maybe).
In general use case, all the routers of the anycast group would have the same prefix-SID
configured for the anycast IP address present on them.
Note: That for Anycast-SID to work as expected, the SRGB on the members of the anycast group
should be same.
Configuring router-ID
A router that support IS-IS
SR need to advertise its SR data-plane capability and the range of MPLS
label values it uses for segment routing, this is advertised by inserting
SR-Capability sub-TLV in the Router Capabilities TLV.
A Router Capability TLV is now sent in
IS-IS LSPs when Segment routing is enabled and it is necessary for a
Router Capability TLV to carry a router-ID. This router-ID could be configured
in EOS under the segment routing MPLS configuration mode. If no router-ID
is configured, the router automatically picks up the highest IPv4 address
configured on the router for an router-ID.
Configuring IS-IS Static Adjacency SID
Adjacency segments for IS-IS
adjacencies are statically configured on the switch, so that these values
are preserved even when the switch restarts. Static adjacency segments
are configured per address family on any interface (including Port-Channel,
VLANs and SVIs). They are configured and advertised as labels.
These are the few points to be considered while configuring the static adjacency SIDs:
The same label can be configured on multiple interfaces so that
MPLS can form ECMP, the same value can be applied to IPv4
and IPv6 adjacency.
Static adjacency SID is applied only to p2p interface, and has
local scope. When interface type changes to LAN, then
dynamic adjacency SID is assigned.
When Static adjacency SIDs are configured, then simply replace
dynamic adjacency SIDs which are advertised to other routers
and installed in the local LFIB.
Static adjacency SID is applied regardless of Adjacency Segment
Allocation Mode.
When Static adjacency SID is disabled, then normal rules for
dynamic adjacency SID is applied (it automatically applies a
value based on Adjacency Segment Allocation Mode as
described in IS-IS Segment Routing TOI document).
Example
switch(config-if-Et1)# adjacency-segment ipv4 p2p index 50 global
They can be a label (local) or index (global) and we can assign multiple
adjacency segments per link.
Where label-value must be within the SR Local Block (SRLB) that can be found in
the output of show mpls label range command as
shown.
Adjacency Segments are MPLS
labels assigned to IS-IS adjacencies.These labels are shared with other
routers in the domain by adding them in adjacency-SID sub-TLVs which
are inserted in neighbor Reachability TLVs in IS-IS.
The MPLS labels (adjacency segments) are incrementally allocated to adjacencies, as the
transition to Up state, from a adjacent set of MPLS labels pre-allocated by
MPLS agent. This label range extends from 100000
to 116383 (base: 100000,
size: 16384) by default. This could be changed by
the following configuration:
Example
switch(config)# mpls label range dynamic 200000 131072
The dynamic label pool is shared between LDP and IS-IS SR Adjacency Segments.
Configuring Adjacency Segment Allocation Mode
Adjacency Segments are allocated to all IS-IS adjacencies based on the IS-IS routers that have
advertised IS-IS SR capability or to none of the adjacencies. The command
adjacency-segment allocation is used to configure this under the
segment-routing mpls configuration mode.
The default behavior is to allocate adjacency
segments to adjacencies of SR supporting devices.
Adjacency segments are allocated to IS-IS adjacencies based on configured adjacency segment allocation mode mentioned above.
If an adjacency that has been allocated label L goes down, L is reserved for this adjacency for
a duration of 3600 seconds from the time of the adjacency down
event. Only the adjacency that owned this label before going down could reclaim label L
in this duration.
Troubleshooting IS-IS Segment Routing
The show tech-support ribd command has a
section starting with the string SR Book Keeper which has extensive
information on state of IS-IS SR on the router.
In-case, if IS-IS SR is configured but SR related TLVs/sub, but, TLVs
are not being sent in IS-IS LSPs.
Ensure that MPLS has been enabled (MPLD IP)
enabled.
Check if segment routing is administratively shut
down.
A segment might have been configured for a prefix not
yet being advertised in IS-IS.
In case, if Adjacency Segments are not being advertised.
Check if the adjacency segment mode is correctly
set.
Adjacency Mode is set to all SR supported interfaces
(default setting) and the peer does not support
SR.
Generally, it is good to not have same prefix with different indices or
same index with different prefixes. There are CLI prohibitions that
ensure that a router is not sending out conflicting sets of prefixes
and associated SIDs. As there is possibility of receiving
conflicting prefix-segments from other devices, there are ways to
resolve the following three types of conflicts: prefix+SID conflict,
SID conflict and prefix conflict.
Prefix+SID Conflict: When there are two prefix segments
which have both the prefix and SID have same values,
the one from the higher system ID is chosen for LFIB
processing.
Prefix Conflict: If the two prefix segments which have
same Prefix are from two different system than the
one from higher system ID is chosen. If they are
originated from same system ID than we choose the
prefix segment of smaller SID.
SID Conflict: If the two prefix segments which have same
SID are from two different system than the one from
higher system ID is chosen. If they are originated
from same system than the one which is of smaller
prefix length is chosen. If prefix length is also
same than the one with smaller address is
chosen.
For a given prefix, if both a proxy-node segment
and prefix-SID are received, the prefix-SID advertised is preferred while
the proxy-node segment is ignored.
The show tech-support ribd displays detail information about
IS-IS SRs internal state, and more information on conflicts and chosen
active segments could be found under the SR Book Keeper section of
show tech-support ribd command as
shown.
Received Prefix Segments:
------------------------------------------------------------------
Prefix | Value | Index/Label | Type | SystemID | spfgen
* - Active, # - Duplicate pfx, + - duplicate SID
-------------------------------------------------------------------
*1.0.3.0/24 3 Index Prefix 1111.1111.1002 0
*1.0.5.1/32 0 Index Node 1111.1111.1002 0
*1.0.6.1/32 2 Index Node 1111.1111.1003 39
*1.0.7.1/32 14 Index Node 1111.1111.1001 39
#1.0.7.1/32
10 Index Proxy 1111.1111.1003
39
Configuring SRv6 for IS-IS
Note: The following platforms support this feature:
One or more nodes must advertise the flex-algo constraints in the IS-IS domain. To
advertise the Flex-Algo definition, use the following commands to configure IS-IS
instance_1, network entity
49.0001.1111.1111.111.00. and Flex-Algo
algoRed
:
For configuring a locator, LOC1 with an appropriate
domain block, and usid value, add the domain
and locator parameters in the VRF Default Configuration Mode in the Segment-Routing
Configuration Mode. The Flex-Algo name, for example ,algoRed
associates a locator with a flex algorithm using the following
commands:
To advertise the locally configured Node Adjacency uSIDs in IS-IS Link State Packets
(LSPs), enable the locator in the SRV6 Configuration Mode of IS-IS.
Algorithm 0 locators additionally advertise as Extended IPv6 Reachability TLVs, in
addition to the SRv6 Locator TLV, ensuring that a route installs in the FIB, even on
non-SRv6-capable routers. Use the following commands to configure the SRv6 Locator
in
IS-IS:
EOS computes Flex-Algo paths based on the advertised constraints for the algorithm.
Use the show isis flex-algo path command to display the
computed
paths:
switch# show isis flex-algo path
Flex algo paths for IPv6 address family
Topology ID: Level-1
Destination Algorithm Next Hop Interface
-------------------- --------------- -------------------------- ---------
fc00:42:1::/48 SPF fe80::200:3ff:fe02:0 Ethernet1
fc00:80:1::/48 algoRed fe80::200:3ff:fe02:0 Ethernet1
Adding the parameter details displays more information about the computed paths:
switch# show isis flex-algo path detail
Destination: fc00:42:1::/48
Path ID: 4480
Path constraints: algo SPF
metric type TE
administrative-group exclude Red(1)
Request sequence number: 0
Response sequence number: 0
Number of times path updated: 3
Last updated: 7 days, 2:06:28 ago
Metric: 20
Next Hop Interface
-------------------- ---------
fe80::200:3ff:fe02:0 Ethernet1
Displaying Installed Paths in the Forwarding Information Database (FIB)
Other routers in the IS-IS also have routes installed for the locator prefix. Use the
show ipv6
route command:
switch# show ipv6 route
I L1 fc00:42:1::/48 [115/30]
via fe80::200:3ff:fe02:0, Ethernet1
I L1 fc00:80:1::/48 [115/30]
via fe80::200:3ff:fe02:0, Ethernet1
Displaying SRv6 Tunnel Information
IS-IS creates an SRv6 tunnel for each locator and adds it to the Routing Information
Database (RIB). The system tunnel RIB provides information to BGP routes and resolves the
next hop for them. To view the contents of the System Tunnel RIB, use the show tunnel rib
brief
command:
The output indicates that for BGP routes with the next hop fc00:42:1:: the resolved route contains the IS-IS SRv6 tunnel with index 2
similar to the Flex-Algo route.
To check the next hop and interface details for the tunnel, use the show
tunnel fib isis srv6index command. Based on the tunnel information, add the index
2 to the
command:
switch# show tunnel fib isis srv6 2
Type 'IS-IS SRv6', index 2, endpoint fc00:42:1::/128, algorithm algo128, forwarding None
via fe80::200:3ff:fe02:0, 'Ethernet1' SRv6, source 2001:db8:200::8, SRv6 sid-list fc00:42:1::
Configuring Redistribution of DHCP for IS-IS Agent (IPv6)
The redistribute dhcp command redistributes DHCPv6 routes
in IS-IS when using multi-agent routing protocol mode.
The redistribute dhcp command enables DHCP route
redistribution in IS-IS when using the multi-agent routing protocol mode.
These commands redistribute IPv6 DHCP routes into the ISIS
domain.
The noisis enable command disables IS-IS on an
interface.
Example
These commands disable IS-IS on interface interface ethernet
4.
switch(config-router-isis)# interface ethernet 4
switch(config-if-Eth4)# no isis enable
Configuring IS-IS Graceful
Restart (GR)
By default, IS-IS graceful
restart is disabled. Use the graceful-restart command to configure graceful
restart on an IS-IS router. By default IS-IS graceful-restart-helper
functionality is enabled, and to disable it use no graceful-restart-helper
command.
Examples
In this example IS-IS graceful restart is configured with t2 wait time of
30 seconds for
level-1
routes.
t2 is the maximum wait time for the LSP database to
synchronize (SPF computation is not done while t2 is running). t2 can
be configured for either Level-1 or Level-2 through the CLI. The
default value is 30 seconds, and the allowed
configuration range is 5 to
300 seconds.
Example
In this example an ISIS graceful restart is configured with restart-hold-time
of 50
seconds.
In case of a planned restart, the hold time advertised by
the IS-IS router prior to restart should be
greater than the time for which the router is
expected to be offline. Otherwise, neighboring
routers will bring down the adjacency before the
restarting router has a chance to send a restart
request in its hello packet, which may result in
traffic loss.
In case of ASU2, the IS-IS router instance will advertise
a hello hold time of restart-hold-time on
those interfaces for which the configured hold time is less than
restart-hold-time. This
is done just before the router restarts.
Note: Once the router has restarted, the routers advertised
hello hold time will depend on the hello-interval and hello-multiplier
configuration on each interface as before. By default, the
restart-hold-time is
disabled.
For Graceful Restart to be successful, the hold
time advertised by the router should be greater than the
time it takes for Graceful Restart to complete. If the
restarting router is DIS, hold time advertised is 1/3rd of
the configured value (default is 9s). We recommend
increasing the hold time for the DIS to a higher value
before a planned restart; otherwise, it may result in
traffic loss.
IS-IS Advertisement and Reachability of Interface Addresses
EOS advertises IS-IS passive and active interfaces, but in some cases, you want to
control the Time-to-Liveadvertisement of interface addresses on the switch. Configure
IS-IS to advertise only passive interfaces and control the LSP size by stopping the
advertisement of active interfaces and reduce the IS-IS convergence time in complex
networks.
EOS supports advertise ip-reachability passive-only to
control the advertisement of IP Reachability TLVs. When enabled, IS-IS advertises IP
Reachability for passive interfaces only.
Configuring IS-IS Interface Advertisement and Reachability
Use the following command to advertise TLVs from only passive interfaces on IS-IS instance,
inst1:
To implement minimum-delay and maximum-delay in the IS-IS FlexAlgo, configure a TWAMP
sender profile, and select it when adding a traffic engineering configuration.
In addition to the basic IS-IS configuration, perform these additional tasks:
Configure the IS-IS FlexoAlgo to use minimum-delay metrics.
Bind the algorithm to the IS-IS configuration.
Enable IS-IS and traffic engineering on the interfaces.
Configuring TWAMP
To initiate TWAMP reflection on the network, use the following command to enter TWAMP
or TWAMP Light configuration
mode:
Configure the sender profile parameters as follows:
measurement interval - The sender sends probe packets during the configured interval window in seconds.
samples -The number of packets sent during an
interval window.
significance and offset - The variables used to
calculate normalized minimum delay in microseconds.
To actively send TWAMP Light probes, configure a sender profile with a measurement
interval, 10 seconds, measurement samples 5,
and significance 10 microseconds offset 5 microseconds using the
following
command:
Note: The maximum effective sampling rate contains one (1) packet per second. The significance value must be larger than the offset value.
The ceiling function computes the ceiling values by adding the offset value to multiples of the significance value starting from a multiple of 0. For
example, if you specify a significance of ten (10) and the offset as three (3), then the ceiling values compute as 3, 13, 23, 33, etc. The measured delay
rounds up to the nearest ceiling value greater than the measure delay.
Configuring UDP Ports for TWAMP
Configure the UDP ports for sending and reflecting TWAMP probes by setting the listen port, source port, and destination port. The reflector uses
the listen port to listen for incoming packets. The sender uses the source port and destination port in probe packets.
Configure the ports using the following commands:
switch(config-twamp-light)#reflector defaults
switch(config-twamp-light-reflector-defaults)#listen port 51201
switch(config-twamp-light-reflector-defaults)#exit
switch(config-twamp-light)#sender defaults
switch(config-twamp-light-sender-defaults)#destination port 51201
switch(config-twamp-light-sender-defaults)#source port 51200
Configuring Traffic Engineering for TWAMP
Configure traffic engineering for IGP (IS-IS) to use the dynamic unidirectional delay of the point-to-point links as measured by the TWAMP
Light sender profile.
Global Configuration
Activate the TWAMP sender profile globally using the following commands:
Configuring Measured Values for Traffic Engineering
Activate TWAMP measurements and use measured values for traffic engineering on an interface using the following command:
switch(config-if-Et3)#traffic-engineering min-delay dynamic twamp-light fallback value microseconds/milliseconds
A fallback value must be configured on all IS-IS interfaces using dynamic delay measurement. IS-IS advertises this fallback value
if TWAMP Light fails to compute the dynamic unidirectional minimum delay metric of a link.
Displaying TWAMP Information
The show monitor
twamp-light command displays the calculated one way
and two way minimum delay. Be default, all information displays for all peer IP
addresses configured on the remote end of the IS-IS point-to-point links. You can
also filter for a specific IP address.
switch#show monitor twamp-light
Unit: microseconds
IP Address Interface One Way Two Way
Minimum Delay Minimum Delay
------------ ------------ --------------- ---------------
1.0.0.2 Ethernet17/1 2742 5482
1.0.0.3 Ethernet18/1 2772 5544
switch#show monitor twamp-light ip 1.0.0.2
Unit: microseconds
IP Address Interface One Way Two Way
Minimum Delay Minimum Delay
------------ ------------ --------------- ---------------
1.0.0.2 Ethernet17/1 2742 5482
Use the show monitor twamp-light detail to display detailed information about calculated results. By default, it displays
information for all IP addresses configured on the remote end of the IS-IS point-to-point links or filter on a specific IP address.
switch#show monitor twamp-light detail ip 1.0.0.2 detail
IP address: 1.0.0.2
Interface: Ethernet17/1
Description: Interface Ethernet17/1
Sender profile name: defaultSender
Effective sampling rate: 1 packet every 1.0 second
Packets sent: 178
Packets received: 21
Unit: microseconds
Measurement Min Max Avg Variance
------------- ---- ------ ----- ----------
One-way delay 2742 236072 19822 4294967295
Two-way delay 5482 472132 39642 4294967295
TI-LFA FRR using IS-IS Segment-Routing Configuration
The following configuration tasks can be performed by Topology Independent Fast Reroute
(TI-LFA FRR) using IS-IS Segment-Routing.
Configuring Link or Node Protection on a Specific Interface
To enable link or node protection for node segments and Adjacency segments learned on a specific IS-IS interface, use the following command in the interface configuration mode.
The interface TI-LFA configuration inherits the address-family sub-mode configuration by default.
On an L1-L2 router, the
[level-1|level-2] optional
keyword in both the router IS-IS address-family sub-mode and interface configuration
mode CLIs is used to restrict protection to node segments and Adjacency segments learned
through either Level-1 or Level-2 topologies only.
Configuring a Local LFIB Convergence Delay for Protected Node or Adjacency Segments
The Point of Local Repair (PLR) switches to the TI-LFA backup path on link failure or BFD
neighbor failure but switches back to the post-convergence path once the PLR computes
SPF and updates its LFIB. This sequence of events can lead to micro-loops in the
topology if the PLR converges faster than other routers along the post-convergence path.
So a configuration option is provided to apply a delay, after which the LFIB route being
protected by the TI-LFA loop-free repair path will be replaced by the post-convergence
LFIB route.
To configure a convergence delay only to LFIB routes that are being protected, the
following command is used either in the router IS-IS mode or the router isis
address-family sub-mode. A default of 10
seconds is used when using the command without an explicitly specified delay.
Making Locally-originated Adjacency Segments Backup Eligible
The PLR computes backup paths for an adjacency segment only if the Adjacency SID sub-TLV has the B-flag (backup flag) set.
To set the B-flag in originated Adjacency SID sub-TLVs corresponding to adjacency
segments dynamically allocated on the router, the following command is used in the
segment-routing mpls sub-mode in the router isis
mode.
To set the B-flag in originated Adjacency SID sub-TLVs corresponding to adjacency
segments statically configured on the router, the following command is used in the
interface configuration
mode.
backup-eligible is the newly introduced optional keyword in both the CLIs mentioned above that controls the setting of the B-flag in the Adjacency SID sub-TLV.
Enabling SRLG Protection
To enable SRLG protection on all interfaces, use the fast-reroute ti-lfa
srlg command. This command is used in addition to configuring
link-protection or node-protection. If SRLG protection is enabled, the backup paths are
computed after excluding all the links that share the same SRLG with the active link
that is being used by all prefix segments and adjacency segments.
fast-reroute ti-lfa srlg
[strict]
If the optional argument strict is configured, the backup path
is only programmed if a backup path that excludes all the SRLGs configured on the
primary interface. If the keyword is not provided and an SRLG excluding path is not
available, TI-LFA programs the backup path that excluded the maximum number of SRLGs
possible.
To selectively disable SRLG protection on an interface, use the isis
[ipv4|ipv6] fast-reroute ti-lfa srlg disabled command. This is
useful if SRLG protection is enabled globally for all interfaces but needs to be
selectively disabled for a specific
interface.
The above topology is used to demonstrate the configuration and show command output. You
will see the backup paths that the PLR computes to protect the node segments of R1 and
R2, the global adjacency segment on R2, and the local adjacency segment on the
vlan 2387 on the PLR.
Here is a snippet of the configuration on the PLR.
The protection of anycast segments does not need any new configuration. The above
configuration enables protection of anycast segments.
To demonstrate the protection of anycast segments consider the following topology.
Figure 3. Topology Number 2
R1 and R4 are originators of the host prefix 10.10.10.1/32 and
advertise prefix segment 900010. This must be configured as a
prefix segment and not a node segment.
R1 and R4’s configuration should look similar to the following:
The prefix in the prefix-segment command must belong to an interface enabled with IS-IS
or must be an active route in the RIB of another protocol redistributed into IS-IS.
When the link or node protection is configured on the PLR, then the primary path to the
segment 900010 is PLR - R1 and the backup path is PLR - R2 -
R3 - R4. In other words, the destination in the backup path is the segment originated by
R4 as the segment originated by R1 and is not reachable when link PLR-R1 or the node R1
goes down.
show ip route
When services like LDP pseudowires, BGP LU, L2 EVPN, or L3 MPLS VPN use IS-IS SR tunnels as an underlay, these services are automatically protected by TI-LFA tunnels that protect the IS-IS SR tunnels. The show ip route command displays the hierarchy of the overlay-underlay-TI-LFA tunnels.
switch# show ip route
B 2001:db8:3::/48 [200/0]
via 2002::b00:301/128, IS-IS SR tunnel index 3, label 122697
via TI-LFA tunnel index 5, label imp-null(3)
via fe80::200:76ff:fe03:0, Ethernet26/1, label imp-null(3)
backup via fe80::200:76ff:fe01:0, Ethernet30/1, label 900002 900003
IS-IS Dynamic Flooding Configuration
Configure Dynamic flooding using the lsp flooding dynamic
command under the router config mode. For
example:
On a sparse topology, Dynamic Flooding is not effective and only adds overhead. Leaf-spine and Clos networks are appropriate dense topologies.
Configuring IS-IS Fast Flooding
In Arista EOS, IS-IS Fast Flooding accelerates the convergence of the Link State Database
(LSDB) in large or dense networks. Standard IS-IS flooding rates use static intervals
between Link State PDUs (LSPs) which can be too slow for high-performance networks with
thousands of nodes or adjacencies.
IS-IS Fast Flooding allows a router to flood LSPs at much higher rates by negotiating
flooding capabilities with neighbors. The feature uses Sub-TLVs, Burst Size and
Transmission Interval, signaled in IS-IS Hello packets to inform neighbors exactly how
many LSPs the switch can process in a burst and the minimum delay required between those
bursts.
EOS supports the following functionalities to achieve faster LSP flooding:
Signaling of flooding parameters within IS-IS hello messages.
Faster LSP acknowledgement processing at the receiver.
Implementing flow control mechanisms at the sender.
You must enable fast flooding on the local and peer link of the IS-IS adjacency to
activate it. Once enabled, IS-IS Hello packets exchange EOS flooding parameters, and
fast flooding activates on the adjacency.
Note: Only Point-to-Point (P2P) links support this feature.
Use the following commands to configure a fast flooding profile, FF_receiver1, the
following parameters:
LSP burst size 30
LSP receiver window size 50
LSP transmit interval 20
Partial Sequence Number Protocol Data Unit (PSNP) transmit interval 100
Use the show isis interface command to display if fast
flooding is enabled or disabled in Ethernet1.
switch# show isis interface Ethernet3
IS-IS Instance: inst1 VRF: default
Interface Ethernet3:
Index: 20 SNPA: P2P
MTU: 1497 Type: point-to-point
Supported address families: IPv4
Area proxy boundary is disabled
Speed: 10000 mbps
BFD IPv4 is disabled
BFD IPv6 is disabled
Hello padding is enabled
Local fast flooding is enabled
Level 2:
Metric: 10, Number of adjacencies: 1
Link-ID: 14
Authentication mode: None
TI-LFA protection is disabled for IPv4
TI-LFA protection is disabled for IPv6
Relax Address-Family Check for IS-IS Adjacency
Address-Family Check for IS-IS creates the adjacency between
devices with different address families. For example, a router supporting IPv4 and IPv6 is
connected to a IPv4 only router, Address-Family Check is verified by
comparing the NLPID TLV ( Type #129 ) advertised in IIH hellos exchanged between peers. It is
useful in following scenarios.
Incrementally Enable IPv6 in an Existing IPv4 Network
Relaxing the Address-Family Check is useful to gradually add IPv6
support in an IPv4 network, without disturbing the IPv4 connectivity.
IPv4 Controller Peering IPv4/v6 Dual Stack Router
A controller forms an IS-IS adjacency with a router and uses the IS-IS database for
topology discovery. If the controller only supports IPv4 IS-IS or only IPv4 tunnels, to
relax the Address-Family Check on the dual stack IPv4/v6 router
for adjacency is useful in establishment.
Disabling the Address-family Check
Under IS-IS instance, configure the following to disable the Address-Family
Check during IIH processing.
switch(config-router-isis)# ?
adjacency Configure parameters for adjacency formation
switch(config-router-isis)# adjacency?
address-family Configure address-family related parameters for adjacency formation
switch(config-router-isis)# adjacency address-family?
match Configure address-family match check related parameters for adjacency formation
switch(config-router-isis)# adjacency address-family match?
disabled Relax address-family match check for bringing up adjacency
switch(config-router-isis)# adjacency address-family match disabled?
Show Command
The show isis neighbor detail command displays address family
details at each end of the
adjacency.
switch# show isis neighbor detail
Instance VRF System Id Type Interface SNPA State Hold time Circuit Id
inst1 default 1111.1111.1002 L2 Vlan2116 P2P UP 24 06
Area Address(es): 49.0001
SNPA: P2P
Router ID: 1.0.0.2
Advertised Hold Time: 30
State Changed: 00:04:18 ago at 2020-11-01 22:28:35
IPv4 Interface Address: 1.0.0.2
IPv6 Interface Address: none
Interface name: Vlan2116
Graceful Restart: Supported
Segment Routing Enabled
SRGB Base: 900000 Range: 65536
Adjacency Label IPv4: 149152
Supported Address Families: IPv4, IPv6
Neighbor Supported Address Families: IPv4
The show isis interface detail command shows the details of
supported protocols on the interface and the neighbors connected to it. The state of
Address-Family match check is also
displayed.
switch(config-router-isis)# show isis interface detail
IS-IS Instance: inst1 VRF: default
Interface Vlan2116:
Index: 35 SNPA: P2P
MTU: 1497 Type: point-to-point
Supported Address Families: IPv4, IPv4
Area Proxy Boundary is Disabled
BFD IPv4 is Disabled
BFD IPv6 is Disabled
Hello Padding is Enabled
Level 2:
Metric: 10, Number of adjacencies: 1
Link-ID: 23
Authentication mode: None
TI-LFA link protection is enabled for the following IPv4 segments: node segments, adjacency segments
TI-LFA protection is disabled for IPv6
Adjacency 1111.1111.1002:
State: UP, Level: 2 Type: Level 2 IS
Advertised Hold Time: 30
Neighbor Supported Address Families: IPv4Address Family Match: Disabled
IPv4 Interface Address: 1.0.0.2
Areas:
49.0001
Usage Guidelines
For IPv6 network upgrade, ensure the knob is incrementally configured on a contiguous
section of the network, at any point the choice of routers for upgrade should not bisect the
upgraded (supporting IPv4/v6) part of the network. All the routers bordering the upgraded
network should always have the knob enabled.
When a proper set of router is established, the following steps are carried on each
router.
Enable the CLI knob.
Enable IPv6 address family in the IS-IS instance.
Configure IPv6 on all the IS-IS interfaces.
Configuring Event Monitor Tracking for IS-IS Route Convergence
EOS stores changes to IS-IS routes into a SQL database to assist with troubleshooting convergence issues and understanding the impact
changes have on a switch. When an IS-IS route changes due to a IS-IS SPF calculation, Event Monitoring stores the changes and tracks the time of
the changes.
The SQL database stores the following information for each event:
Timestamp
IPv4 or IPv6 prefix
Add_Or_Update or Delete messages
The layer of the route pipeline such as follows
Rib - Specifies the time for a candidate route to update as computed by IS-IS.
SwFib - Specifies the time for the computed winning route in software to update.
HwFib - Specifies the time that the route sends to the forwarding hardware.
VRF name
All platforms support the Rib and SwFib layers.
The following platforms support HwFib:
7280R3A
7500R3
7800R3
DCS-7130LBR
DCS-7280CR3
DCS-7280DR3
DCS-7280PR3
DCS-7280SR3
DCS-7280TR3
Use the following commands to configure Event Monitoring for IS-IS:
In the example output, the IP addresses, 1.0.1.0/24 and
2000:0:0:41::/64, move through three layers in rapid succession.
Then deletes IP address 1.0.1.0/24.
Displaying IS-IS Information
The following sections describe display and verification of IS-IS settings and of peer and
connection configuration:
To display general information for IS-IS neighbors that the device sees, use show isis neighbors.
Example
This command displays information for IS-IS neighbors that the device
sees.
switch# show isis neighbor
Inst Id System Id Type Interface SNPA State Hold time
10 2222.2222.2222 L2 Vlan20 2:1:0:c:0:0 UP 30
10 1212.1212.1212 L2 Vlan20 2:1:0:d:0:0 UP 9
10 3030.3030.3030 L2 Ethernet30 2:1:0:b:0:0 UP 9
switch>
Displaying IS-IS Instance Information
To display the system ID, Type, Interface, IP address, State and Hold information for IS-IS
instances, use the show isis summary command. The command is also used
to verify the configured maximum wait interval, initial wait interval, and hold time of SPF
timers in IS-IS instances. This command also displays values of the current SPF interval, last
Level-1 SPF run, and last Level-2 SPF run.
Example
This command displays general information about IS-IS
instances.
switch# show isis summary
ISIS Instance: Osiris
System ID: 1010.1040.1030, administratively enabled, attached
Internal Preference: Level 1: 115, Level 2: 115
External Preference: Level 1: 115, Level 2: 115
IS-Type: Level 2, Number active interfaces: 1
Routes IPv4 only
Last Level 2 SPF run 2:32 minutes ago
Area Addresses:
10.0001
level 2: number dis interfaces: 1, LSDB size: 1
switch>
This command displays the SPF interval information about IS-IS
instances.
switch(config-router-isis-af)# show isis summary
IS-IS Instance: 1 VRF: default
System ID: 0000.0000.0001, administratively enabled
Multi Topology disabled, not attached
IPv4 Preference: Level 1: 115, Level 2: 115
IPv6 Preference: Level 1: 115, Level 2: 115
IS-Type: Level 1 and 2, Number active interfaces: 0
Routes both IPv4 and IPv6
Max wait(s) Initial wait(ms) Hold interval(ms)
LSP Generation Interval: 5 50 50
SPF Interval: 2 1000 1000
Current SPF hold interval(ms): Level 1: 1000, Level 2: 1000
Last Level 1 SPF run 1 seconds ago
Last Level 2 SPF run 1 seconds ago
Authentication mode: Level 1: None, Level 2: None
Graceful Restart: Disabled, Graceful Restart Helper: Enabled
Area Addresses:
49.0001
level 1: number dis interfaces: 0, LSDB size: 1
level 2: number dis interfaces: 0, LSDB size: 1
Displaying IS-IS Segment Routing
Information
Displaying IS-IS Database Detail
Use the show isis database
detail command to view the
LSPDB of different devices in the IS-IS domain. The output displays
the TLVs and sub-TLVs that are being self-originated or the ones
that have been received from other routers.
Example
switch# show isis database detail
ISIS Instance: inst1 VRF: default
ISIS Level 2 Link State Database
LSPID Seq Num Cksum Life IS Flags
1111.1111.1001.00-00 10 63306 751 L2 <>
NLPID: 0xCC(IPv4) 0x8E(IPv6)
Area address: 49.0001
Interface address: 1.0.7.1
Interface address: 1.0.0.1
Interface address: 2000:0:0:47::1
Interface address: 2000:0:0:40::1
IS Neighbor : lf319.53 Metric: 10
LAN-Adj-sid: 100000 flags: [ L V ] weight: 0 system ID: 1111.1111.1002
IS Neighbor (MT-IPv6): lf319.53 Metric: 10
LAN-Adj-sid: 100001 flags: [ L V F ] weight: 0 system ID: 1111.1111.1002
Reachability : 1.0.11.0/24 Metric: 1 Type: 1 Up
SR Prefix-SID: 10 Flags: [ R ] Algorithm: 0
Reachability : 1.0.3.0/24 Metric: 1 Type: 1 Up
Reachability : 1.0.7.1/32 Metric: 10 Type: 1 Up
SR Prefix-SID: 2 Flags: [ N ] Algorithm: 0
Reachability : 1.0.0.0/24 Metric: 10 Type: 1 Up
Reachability (MT-IPv6): 2000:0:0:4b::/64 Metric: 1 Type: 1 Up
SR Prefix-SID: 11 Flags: [ R ] Algorithm: 0
Reachability (MT-IPv6): 2000:0:0:43::/64 Metric: 1 Type: 1 Up
Reachability (MT-IPv6): 2000:0:0:47::1/128 Metric: 10 Type: 1 Up
SR Prefix-SID: 3 Flags: [ N ] Algorithm: 0
Reachability (MT-IPv6): 2000:0:0:40::/64 Metric: 10 Type: 1 Up
Router Capabilities: 252.252.1.252 Flags: [ ]
SR Capability: Flags: [ I V ]
SRGB Base: 900000 Range: 65536
Segment Binding: Flags: [ F ] Weight: 0 Range: 1 Pfx 2000:0:0:4f::1/128
SR Prefix-SID: 19 Flags: [ ] Algorithm: 0
Segment Binding: Flags: [ ] Weight: 0 Range: 1 Pfx 1.0.15.1/32
SR Prefix-SID: 18 Flags: [ ] Algorithm: 0
switch(config)# show isis segment-routing
System ID: 1111.1111.1002 Instance: inst1
SR supported Data-plane: MPLS SR Router ID: 252.252.2.252
SR Global Block( SRGB ): Base: 900000 Size: 65536
Adj-SID allocation mode: SR-adjacencies
Adj-SID allocation pool: Base: 100000 Size: 16384
All Prefix Segments have : P:0 E:0 V:0 L:0
All Adjacency Segments have : F:0 B:0 V:1 L:1 S:0
ISIS Reachability Algorithm : SPF (0)
Number of ISIS segment routing capable peers: 3
Self-Originated Segment Statistics:
Node-Segments : 2
Prefix-Segments : 2
Proxy-Node-Segments : 0
Adjacency Segments :
About the Output
The first line of the output displays the IS-IS system ID of this device
and the name of the instance with IS-IS configured.
The supported data plane is shown against the SR supported Data-plane
field whereas the Router ID being advertised in the Router
Capability is mentioned in the SR Router ID Field.
The SRGB in use and the MPLS label pool being used for adjacency segment
allocation are mentioned in this output. The current adjacency
allocation mode which refers to allocating adjacency segments to all
IS-IS adjacencies or only those adjacencies which support SR or None
of the adjacencies is shown in the Adj-SID allocation mode
field.
Flag contents of All Prefix Segments originated on this router, Flag
contents of All Adjacency Segments originated on this router and
supported IS-IS Reachability Algorithm have been provided through
this command output and they carry the meaning as per the IS-IS SR
IETF draft.
This show command provides a statistics related to IS-IS SR in terms of
various counters ranging from number of IS-IS SR enabled peers,
number of Node-SIDs, prefix-SIDs, proxy-node-segments and adjacency
segments being originated on this router in IS-IS.
The show isis segment-routing command also
provides information if segment routing has been administratively
disabled as shown.
switch(config-router-isis-sr-mpls)# show isis segment-routing
! IS-IS (Instance: inst1) Segment Routing has been administratively shutdown
Displaying IS-IS Segment Routing Global Blocks
Use the show isis
segment-routing global-blocks
command to list the SRGBs in use by all SR supporting devices in
IS-IS domain including the SRGB in use by IS-IS SR on this
device.
Example
switch# show isis segment-routing global-blocks
System ID: 1111.1111.1002 Instance: inst1
SR supported Data-plane: MPLS SR Router ID: 252.252.2.252
SR Global Block( SRGB ): Base: 900000 Size: 65536
Number of ISIS segment routing capable peers: 3
SystemId Base Size
-------------------- ------------ -----
1111.1111.1002 900000 65536
1111.1111.1001 900000 65536
Displaying IS-IS Segment Routing Prefix Segments
Use the show isis
segment-routing
prefix-segments command to provide the
details of all prefix segments being originated as well the segments
received from IS-IS SR speakers in the domain.
After the usual output header that represents the system ID, instance
name, etc and parameters of a router, there is a line depicting
prefix segment counters. Each field in this line relates to the
number of segments that are present in this routers IS-IS instance.
For example, the above example shows that this device has 2 Node
Segments, self-originated as well as the ones received from other
IS-IS SR devices.
The main section of this show commands output lists all the prefix
segments and related information like prefix, SID, type of segment
(Prefix, Node, Proxy-Node), the flag values being carried in the
sub-TLVs of these prefix segments and the system ID of the
originating router. The Type field will be useful on a IS type
level-1-2 router. It shows whether the installed prefix segment is
from a level-1 prefix or a level-2 prefix.
It consists allocation mode, MPLS label pool from which labels would be
allocated to adjacencies, total count of adjacency segments
allocated so far and the default flag values carried in all adj-SID
sub-TLVs originating from this device.
The main section of the output lists all the adjacency segments allocated
so far in six columns each pertaining to Adjacency IP address, local
interface name, MPLS label value, SID source, flags in the sub-TLV
and the type of adj-SID respectively. The type of the adjacency
segments depends on the IS-IS type of adjacency and the IS
level.
Displaying MPLS Label Ranges
Use the show mpls label
ranges command to display the
MPLS label range available on a router categorized into different
pools that cater to different applications running on the
router.
The isis-sr refers to the SRGB use-case in IS-IS, and isis
(dynamic) refers to the label pool used
for dynamic allocation of adjacency segments in IS-IS.
Use the show mpls
segment-routing bindings
command to display the local label bindings and label bindings on
the peer routers for each prefix with a segment advertised. Peer ID
here represents the IS-IS system ID of the peer.
Use the show mpls lfib
route command to display the
LFIB. Each LFIB entry has In-Label, Out-Label, metric, payload type,
next-hop information, etc. fields. The source column depicts the
MPLS control plane protocol responsible for the label binding that
resulted in this LFIB route.
Example
switch# show mpls lfib route
MPLS forwarding table (Label [metric] Vias) - 7 routes
MPLS next-hop resolution allow default route: False
Via Type Codes:
M - Mpls Via, P - Pseudowire Via,
I - IP Lookup Via, V - Vlan Via,
VA - EVPN Vlan Aware Via, ES - EVPN Ethernet Segment Via,
VF - EVPN Vlan Flood Via, AF - EVPN Vlan Aware Flood Via,
NG - Nexthop Group Via
Source Codes:
S - Static MPLS Route, B2 - BGP L2 EVPN,
B3 - BGP L3 VPN, R - RSVP,
P - Pseudowire, L - LDP,
IP - IS-IS SR Prefix Segment, IA - IS-IS SR Adjacency Segment,
IL - IS-IS SR Segment to LDP, LI - LDP to IS-IS SR Segment,
BL - BGP LU, ST - SR TE Policy,
DE - Debug LFIB
IA 100000 [1]
via M, 1.0.1.2, pop
payload autoDecide, ttlMode uniform, apply egress-acl
interface Vlan2930
IA 100001 [1]
via M, fe80::200:eff:fe02:0, pop
payload autoDecide, ttlMode uniform, apply egress-acl
interface Vlan2930
IP 900008 [1]
via M, 1.0.1.2, swap 900008
payload autoDecide, ttlMode uniform, apply egress-acl
interface Vlan2930
IP 900009 [1]
via M, fe80::200:eff:fe02:0, swap 900009
payload autoDecide, ttlMode uniform, apply egress-acl
interface Vlan2930
Displaying MPLS LFIB Route Label Value
Use the show mpls lfib route <label
value> command to provide
information relevant to the label value passed as an extension to
the show command.
Example
switch# show mpls lfib route 900008
MPLS forwarding table (Label [metric] Vias) - 7 routes
MPLS next-hop resolution allow default route: False
Via Type Codes:
M - Mpls Via, P - Pseudowire Via,
I - IP Lookup Via, V - Vlan Via,
VA - EVPN Vlan Aware Via, ES - EVPN Ethernet Segment Via,
VF - EVPN Vlan Flood Via, AF - EVPN Vlan Aware Flood Via,
NG - Nexthop Group Via
Source Codes:
S - Static MPLS Route, B2 - BGP L2 EVPN,
B3 - BGP L3 VPN, R - RSVP,
P - Pseudowire, L - LDP,
IP - IS-IS SR Prefix Segment, IA - IS-IS SR Adjacency Segment,
IL - IS-IS SR Segment to LDP, LI - LDP to IS-IS SR Segment,
BL - BGP LU, ST - SR TE Policy,
DE - Debug LFIB
IP 900008 [1]
via M, 1.0.1.2, swap 900008
payload autoDecide, ttlMode uniform, apply egress-acl
interface Vlan2930
Displaying show isis local-convergence-delay
The show isis local-convergence-delay command shows the current or last attempt at delaying the convergence of protected routes on a link down/BFD neighbor down event. If the timer aborts for some reason (such as a topology change causing a new SPF), the attempt fails.
switch# show isis local-convergence-delay
IS-IS Instance: inst1 VRF: default
System ID: 1111.1111.1001
IPv4 local convergence delay configured, 5000 msecs
IPv6 local convergence delay configured, 5000 msecs
Level 1 attempts 0, failures 0
Level 2 attempts 3, failures 1
Level 2 in progress due to LINK DOWN on Vlan2138
TI-LFA node protection is enabled for IPv4
IPv4 Routes delayed: 0
Delay timer started at: 2019-07-25 23:16:33
Delay timer expires in 2 secs
TI-LFA protection is disabled for IPv6
Level 2 last attempt due to LINK DOWN on Vlan2138, Succeeded
TI-LFA node protection is enabled for IPv4
IPv4 Routes delayed: 3
Delay timer started at: 2019-07-25 23:14:51
Delay timer stopped at: 2019-07-25 23:14:56
TI-LFA protection is disabled for IPv6
The detail keyword also lists all the routes that have been delayed.
switch# show isis local-convergence-delay detail
...
Level 2 last attempt due to LINK DOWN on Vlan2138, Succeeded
TI-LFA node protection is enabled for IPv4
IPv4 Routes delayed: 3
Delay timer started at: 2019-07-25 23:14:51
Delay timer stopped at: 2019-07-25 23:14:56
Delayed routes:
10.0.7.1/32
10.0.9.1/32
10.0.10.1/32
TI-LFA protection is disabled for IPv6
Verifying IS-IS Graceful Restart
(GR) Information
GR State can be one of the following:
Last Start/Restart was completed successfully.
Last Start/Restart exited after t2 (level-1/level-2) expiry.
Last Restart exited after t3 expiry.
Start/Restart in progress.
Graceful Restart was disabled during startup.
The following show commands are used to display the IS-IS graceful restart information.
The show isis graceful-restart vrf [vrf-name] command displays
the GR configuration and graceful-restart related state of the IS-IS instance as well as
its
neighbors.
Example
switch# show isis graceful-restart vrf default
IS-IS Instance: 1 VRF: default
System ID: 0000.0000.0001
Graceful Restart: Enabled, Graceful Restart Helper: Enabled
State: Last Start exited after T2 (level-1) expiry
T1 : 3s
T2 (level-1) : 30s/20s remaining
T2 (level-2) : 30s/not running
T3 : not running
System ID Type Interface Restart Capable Status
is-hostname-1 L1L2 Ethernet1 Yes Running
is-hostname-2 L1 Ethernet2 Yes Restarting
The show isis summary vrf [vrf-name] command displays the
graceful restart state and helper
configuration.
The show isis neighbors detail vrf [vrf-name] command displays
the helpers view of a restarting
router.
Example
switch# show isis neighbors detail vrf default
Instance VRF System Id Type Interface SNPA State Hold time Circuit Id
1 default OT1 L1 Ethernet1 2:1:0:b 4:0:0 UP 29839 OT3.05
Area Address(es): 49.0001
SNPA: 2:1:0:b4:0:0
....
Graceful Restart: Supported, Status: Restarting (RR rcvd, RA sent, CSNP sent)
The show isis interface detail vrf [vrf-name] command displays
the graceful restart related stats for that
interface.
The address-family command places the switch in
address-family configuration mode.
Address-family configuration mode is not a group change mode;
running-config is changed immediately after commands are
executed. The exit command does not affect the
configuration.
The switch supports these address families:
ipv4-unicast
ipv6-unicast
The no address-family and default
address-family commands delete the specified address-family
from running-config by removing all commands previously configured in
the corresponding address-family mode.
The exit command returns the switch to the
isis configuration mode.
Command Mode
Router-IS-IS Configuration
Command Syntax
address-family [ipv4 |
ipv6][MODE]
no address-family [ipv4 |
ipv6][MODE]
default address-family [ipv4 |
ipv6][MODE]
Parameters
address_family Options include:
ipv4 IPv4 unicast.
ipv6 IPv6 unicast.
MODE Options include:
no parameter Defaults to unicast.
unicast All IPv4 or IPv6
addresses are active.
Examples
These commands enter the address family mode for IPv4
unicast.
Use the adjacency-segment command in the interface
configuration mode to have the PLR computes backup paths for an adjacency segment only
if the Adjacency SID sub-TLV has the B-flag (backup flag) set.
labellabel Label value to be assigned as Adj-SID for
adjacency on this interface. label range
16 -1048575.
indexindex Prefix segment identifier.
index range
0-65535.
backup-eligible Eligible for protection.
adjacency-segment (allocation)
The adjacency-segment command allocates adjacency segments
to all IS-IS adjacencies, or only those adjacencies which are to IS-IS routers that
have advertised IS-IS SR capability, or to none of the adjacencies.
The adjacency-segment command configures IS-IS adjacencies
statically on the switch, so that these values are preserved even when the switch
restarts. The no and the default form of the command places the switch back to the
global configuration mode.
ipv4 IS-IS SR adjacency segment IPv4
interface configuration.
ipv6 IS-IS SR adjacency segment IPv6
interface configuration.
labellabel-value Label value to be assigned as Adj-SID for
adjacency on this interface. Value ranges from 16 to
1048575.
indexlabel-value Index to be assigned as Adj-SID for adjacency on
this interface. Value ranges from 0 to
65535.
global global adjacency SID.
Example
This command allocates the adjacency segment to an IPv4 p2p interface with a index
value 50.
switch(config-if-Et1)# adjacency-segment ipv4 p2p index 50 global
advertise interface-address passive-only
The advertise interface-address passive-only command configures IS-IS to advertise interface addresses for passive interfaces.
The no disables the configuration.
Configuration Mode
Router IS-IS Configuration
Command Syntax
advertise interface-address passive-only
Example
Use the following command to advertise TLVs from only passive interfaces on IS-IS
instance,
inst1:
The advertise ip-reachability passive-only allows the configuration of advertising IS-IS IP reachability TLVs for passive
and nonpassive interfaces. This reduces the size of the LSP by stopping the advertisement of IP reachability addresses for active interfaces and reduce IS-IS
convergence time in complex networks. The no version of the command disables the feature.
Configuration Mode
Router IS-IS Configuration
Command Syntax
advertise ip-reachability passive-only
Example
Use the following command to advertise TLVs from only passive interfaces on IS-IS
instance,
inst1:
The clear isis database command clears a specific LSP with
a predefined LSP ID, or LSPs at a given level, or all LSPs in the database.
Additionally, the command sends purge LSPs throughout the network to clear LSPs from
all devices.
Note: Exercise caution while using this command since it can
be disruptive to the network.
The clear isis neighbor command clears IS-IS adjacencies
that exist on an interface, or at a specific level, or the adjacencies formed with a
given neighbor (either with a system ID or a hostname).
This command clears Level 1-2 point-to-point adjacencies
only.
switch# clear isis neighbor all level-1-2
0 neighbors cleared on instance 1
switch#
event-monitor convergence
The event-monitor convergence command enters the Event Monitor Convergence Configuration Mode and
allows sending IS-IS convergence events to a database.
The [no | default] versions of the command disables the configuration and removes it from the running-config.
The fast-flooding profile command in the Router IS-IS Configuration Mode enables Fast Flooding
on Point-2-Point (P2P) links and enables faster network convergence for a consistent Link State Database (LSDB) for Link State
Interior Gateway Protocols (IGPs). Configure fast flooding profiles and apply them to IS-IS instances or interfaces.
The [no] version of the command disables fast flooding on the
switch.
all-interfaces - Enable fast flooding on all interfaces of an IS-IS instance.
profileprofile_name - Create a fast flooding profile for an
IS-IS instance.
lsp burst sizesize_value - Configure the maximum number of LSPs
that a node can receive without a delay between LSP transmissions. Use a value
between 5 and 50 with a default value of5.
lsp receiver window sizesize_value - Configure the maximum of unacknowledged
LSPs received on a node for an IS-IS adjacency. Specify a value between 30 to
200 with a default value of 60.
lsp tx interval - Configure the minimum interval in microseconds between LSPs on the receiving interface. Specify a value between 1
and 300 milliseconds with a default of 33 milliseconds.
psnp lpp countvalue - Configure the number of received LSPs that immediately triggers sending a PSPN acknowledgement. Specify
a value between 5 and 90 with a default value of 15.
psnp tx intervalmilliseconds - Configure the interval in milliseconds between periodic transmissions of the PSNP. Configure
a value between 50 and 500 milliseconds with a default value of 200 milliseconds.
Examples
Use the following commands to configure a fast flooding profile, FF_receiver1, with the
following parameters:
LSP burst size 30
LSP receiver window size 50
LSP transmit interval 20
Partial Sequence Number Protocol Data Unit (PSNP) transmit interval 100
Use the show isis
interface command to display information about IS-IS
fast flooding on an interface.
fast-reroute ti-lfa mode
Use the fast-reroute ti-lfa mode to enable link or node
protection for node segments and adjacency segments of a specific address-family learned
on all IS-IS interfaces.
Command Mode
address-family sub-mode of the router isis mode (config-router-isis-af)
link-protection Protects against the failure of the
link.
node-protection Protects against the failure of the
neighbor mode.
level-1 Protects prefixes only in level-1.
level-2 Protects prefixes on in level-2. Disables the
fast-reroute TI-LFA mode.
Guidelines
FRR using TI-LFA is disabled globally by default in the router IS-IS address-family
sub-modes.
The interface TI-LFA configuration inherits the address-family sub-mode configuration by
default.
fast-reroute ti-lfa srlg
Use the fast reroute ti-lfa srlg command to enable SRLG
protection on all interfaces. This command is used in addition to configuring
link-protection or node-protection. When SRLG protection is enabled, the backup paths
are computed after excluding all the links that share the same SRLG with the active link
that is being used by all prefix segments and adjacency segments.
Command Mode
IS-IS router address-family configuration mode
Command Syntax
fast-reroute ti-lfa srlg [strict]
Parameters
strict The backup path is only programmed if a backup path that
excludes all the SRLGs configured on the primary interface.
graceful-restart (IS-IS)
The graceful-restart command configures IS-IS
graceful-restart. The command provides options to configure the t2 time or the
restart-hold-time.
t2 is the maximum wait time for the LSP database to synchronize (SPF computation is
not done while t2 is running). t2 can be configured for either Level-1 or Level-2
routes.
restart-hold-time is the hold time advertised
by the router to its neighbors before undergoing ASU2 fast reboot.
The no graceful-restart and default
graceful-restart commands disables the IS-IS graceful-restart
configuration from running-config.
The is-hostname command configures the use of a
human-readable string to represent the symbolic name of an IS-IS router. It also
changes the output of IS-IS show commands, to show the IS-IS hostname in place of
system IDs if the corresponding IS-IS hostname is known. However, syslogs still use
IS-IS system IDs and not the IS-IS hostname.
By default, if a hostname is configured on the switch, it is used as the IS-IS
hostname. It is also possible to unconfigure an assigned hostname for IS-IS using
the no is-hostname command. When the IS-IS hostname is
removed, the switch goes back to using the switch's hostname as the IS-IS
hostname.
Command Mode
Router-IS-IS Configuration
Command Syntax
is-hostnamestring
no
is-hostname
Examples
These commands configure the IS-IS hostname to the symbolic name
ishost1 for the IS-IS
router.
The isis bfd command in the Interface Ethernet
Configuration mode attaches Bidirectional Forwarding Detection (BFD) to an interface
running IS-IS routing protocol. By default, EOS does not enable IS-IS routing
instance on an interface.
BFD acts as a lightweight, low overhead protocol designed to provide sub-second
forwarding path failure detection. When enabled on an interface, EOS configures the
following features:
The IS-IS protocol registers the established neighbor adjacency with the EOS
BFD engine.
Builds a BFD session between the direct neighbors.
If a physical or hidden data-plane link failure occurs, BFD drops instantly
and immediately signals the IS-IS agent.
IS-IS tears down the routing adjacency without waiting for IS-IS hello
timers to expire and accelerates the reconvergence of the global network
IGP.
The no isis enable and default isis
enable commands disable IS-IS BFD on the interface by removing
the corresponding isis enable command from
running-config.
The isis enable command activates the corresponding IS-IS
routing instance on the configuration mode interface. By default, the IS-IS routing
instance is not enabled on an interface.
The no isis enable and default isis
enable commands disable IS-IS on the configuration mode
interface by removing the corresponding isis enable command from
running-config.
Command Mode
Interface-Ethernet Configuration
Interface-Loopback Configuration
Interface-Port-channel Configuration
Interface-VLAN Configuration
Command Syntax
isis enableinstance_id
no isis enable
default isis enable
Parameters
instance_id IS-IS instance name.
Examples
These commands enable the IS-IS protocol on the interface
ethernet
4.
These commands disable the IS-IS protocol on the interface
ethernet
4.
switch(config)# interface ethernet 4
switch(config-if-Eth4)# no isis enable
isis fast-reroute ti-lfa mode
Use the isis fast-reroute ti-lfa mode command to enable link or
node protection for node segments and adjacency segments learned on a specific IS-IS
interface. By default, the interface TI-LFA configuration inherits the address-family
sub-mode configuration.
The no isis fast-reroute ti-lfa and default
isis fast-reroute ti-lfa mode commands disable link or node
protection for node segments and adjacency segments learned on a specific IS-IS
interface.
level-1 - Optional parameter in the Router Is-Is
Address-family Configuration Mode - Restricts protection to node
segments and adjacency segments learned through either Level-1 topologies
only.
level-2 - Optional parameter in both the Router
Is-Is Address-family Configuration Mode that restricts
protection to node segments and adjacency segments learned through Level-2
topologies only.
Example
Use the following command to enable link protection on node segments for all interfaces
on IS-IS, network1 with an instance ID, 24 and
address family
IPv4:
The isis hello-interval command sends Hello packets from
applicable interfaces to maintain the adjacency through the transmitting and
receiving of Hello packets. The Hello packet interval can be modified.
The no isis hello-interval and default isis
hello-interval commands restore the default hello interval of
10 seconds on the configuration mode interface by
removing the isis hello-interval command from
running-config.
Command Mode
Interface-Ethernet Configuration
Interface-Loopback Configuration
Interface-Port-channel Configuration
Interface-VLAN Configuration
Command Syntax
isis hello-intervaltime
no isis hello-interval
default isis hello-interval
Parameters
time Values range from 1 to
300; default is 10.
Examples
These commands configure a hello interval of 45
seconds for vlan
200.
These commands remove the configured hello interval of
60 seconds from interface
ethernet
5.
switch(config)# interface ethernet 5
switch(config-if-Et5)# no isis hello-interval
switch(config-if-Et5)#
isis hello-multiplier
The isis hello-multiplier command specifies the number of
IS-IS hello packets missed by a neighbor before the adjacency is considered
down.
The no isis hello-multiplier and default isis
hello-multiplier commands restore the default hello interval
of 3 on the configuration mode interface by removing the
isis hello-multiplier command from
running-config.
Command Mode
Interface-Ethernet Configuration
Interface-Loopback Configuration
Interface-Port-channel Configuration
Interface-VLAN Configuration
Command Syntax
isis hello-multiplierfactor
no isis hello-multiplier
default isis hello-multiplier
Parameters
factor Values range from 3 to
100; default is 3.
Examples
These commands configure a hello multiplier of 4
for vlan
200.
These commands remove the configured hello multiplier of
45 from interface ethernet
5.
switch(config)# interface ethernet 5
switch(config-if-Et5)# no isis hello-multiplier
switch(config-if-Et5)#
isis address-family fast-reroute ti-lfa srlg
Use the isis address-family fast-reroute ti-lfa srlg command to
enable protection selectively on a specific interface. This command only enables Shared
Risk Link Groups (SRLG) protection for prefix segments and adjacency segments enabled on
the interface.
mode [disabled | link-protection | node-protection] - Specify one of the following modes:
disabled - Disable protection over the link.
link-protection - Protect against failure of the link.
node-protection - Protect against the failure of the
neighbor node.
strict - The backup path is only programmed only if a
backup path that excludes all the SRLGs configured on the primary interface. If
strict is not provided and an SRLG excluding
path is not available, TI-LFA programs the backup path that excluded the maximum
number of SRLGs possible.
disabled - Use to selectively disable SRLG protection on
an interface. This is useful when SRLG protection is enabled globally for all
interfaces but needs to be selectively disabled for a specific interface.
Example
Use the following command to enable SRLG in strict
mode:
The isis lsp tx interval command sets the interval at which
IS-IS sends link-state information on the interface.
The no isis lsp tx interval and default isis
lsp tx interval commands restores the default setting of
33 ms. by removing the isis lsp tx
interval command from running-config.
Command Mode
Interface-Ethernet Configuration
Interface-Loopback Configuration
Interface-Port-channel Configuration
Interface-VLAN Configuration
Command Syntax
isis lsp tx intervalperiod
no isis lsp tx interval
default isis lsp tx interval
Parameters
period Value ranges from 1
through 3000. Default interval is
33 ms.
Examples
This command sets the LSP interval on interface interface
ethernet 5 to 600
milliseconds.
The isis metric command sets cost for sending information
over an interface.
The no isis metric and default isis
metric commands restore the metric to its default value of
10 by removing the isis
metric command from running-config.
Command Mode
Interface-Ethernet Configuration
Interface-Loopback Configuration
Interface-Port-channel Configuration
Interface-VLAN Configuration
Command Syntax
isis metricmetric_cost
no isis metric
default isis metric
Parameters
metric_cost Values range from 1 to
1677214. Default value is
10.
Examples
These commands configure a metric cost of 30 for
sending information over interface ethernet
5.
The isis network command sets the configuration mode
interface as a point-to-point link. By default, interfaces are configured as
broadcast links.
The no isis network and default isis
network commands set the configuration mode interface as a
broadcast link by removing the corresponding isis network
command from running-config.
Command Mode
Interface-Ethernet Configuration
Interface-Loopback Configuration
Interface-Port-Channel Configuration
Interface-VLAN Configuration
Command Syntax
isis network point-to-point
no isis network
default isis network
Examples
These commands configure interface ethernet 10 as
a point-to-point
link.
This command restores interface ethernet 10 as a
broadcast
link.
switch(config-if-Etl0)# no isis network
switch(config-if-Etl0)#
isis passive
The isis passive command configures the configuration-mode
interface as passive. The switch will continue to advertise the IP address in the
LSP, but the interface will not send or receive IS-IS control packets.
The no isis passive command removes the passive
configuration, allowing the interface to send and receive IS-IS control packets. The
default isis passive command sets the interface to
the default interface activity setting by removing the corresponding
isis passive or no isis
passive statement from running-config.
Command Mode
Interface-Ethernet Configuration
Interface-Loopback Configuration
Interface-Port-Channel Configuration
Interface-VLAN Configuration
Command Syntax
isis passive
no isis passive
default isis passive
Examples
These commands configure interface ethernet 10 as
a passive
interface.
These commands restore interface ethernet 10 as an
active
interface.
switch(config)# interface ethernet 10
switch(config-if-Etl0)# no isis passive
switch(config-if-Etl0)#
isis priority
The isis priority command sets the IS-IS priority for the
interface.
The default priority is 64. The network device with the
highest priority will be elected as the designated intermediate router to send
link-state advertisements for that network.
The no isis priority and default isis
priority commands restore the default priority
(64) on the configuration mode interface.
Command Mode
Interface-Ethernet Configuration
Interface-Loopback Configuration
Interface-Port-channel Configuration
Interface-VLAN Configuration
Command Syntax
isis prioritypriority_level
no isis priority
default isis priority
Parameter
priority_level Value ranges from
0 to 127. Default value is
64.
Examples
These commands configure a IS-IS priority of 60 on
interface ethernet
5.
These command restores the default IS-IS priority of
64 for
64.
switch(config)# interface vlan 7
switch(config-if-Vl7)# no isis priority
switch(config-if-Vl7)#
is-type
The is-type command configures the routing level for an
IS-IS instance.
An IS-IS router can be configured as Level-1-2
which can form adjacencies and exchange routing information with both
Level-1 and Level-2 routers. A Level-1-2 router can be configured to
transfer routing information from Level-1 to Level-2 areas and vice versa
(via route leaking). By default, all routes from Level-1 area are always
leaked into Level-2 network.
The log-adjacency-changes command sets the switch to send
Syslog messages when it detects link state changes or when it detects that a
neighbor state has changed.
The default option is active when running-config does not contain any
form of the command. Entering the command in any form replaces the previous command
state in running-config.
Command Mode
Router-IS-IS Configuration
Command Syntax
log-adjacency-changes
no log-adjacency-changes
default log-adjacency-changes
Examples
These commands configure the switch to send a Syslog message when a neighbor
state
changes.
These commands configure not to log the peer
changes.
switch(config)# router isis Osiris
switch(config-router-isis)# no log-adjacency-changes
switch(config-router-isis)#
lsp dynamic flooding
Use the lsp flooding dynamic command to configure dynamic
flooding. Dynamic flooding must be enabled on all routers in the area. The
no form of the command removes LSP dynamic flooding.
LSP flooding dynamic is disabled by default.
The match isis level command configures a route map to
match on ISIS level. It filters the Level-1 or Level-2 routes by using route maps
match statement.
The no match isis level and default match isis
level commands disables the match ISIS level configuration
from running-config.
Command Mode
Route-map Configuration
Command Syntax
match isis level [level-1 |
level-2]
no match isis level [level-1 |
level-2]
default match isis level [level-1 |
level-2]
Parameters
level-1 IS-IS level 1.
level-2 IS-IS level 2.
Example
These commands place the switch in route-map mode, and configures a
route map to match isis level to Level-1.
switch(config)# route-map Test
switch(config-route-map-test)# match isis level level-1
monitor twamp
The monitor twamp twamp-light command enters the TWAMP configuration mode and allows the configuration of TWAMP profiles
to initiate TWAMP reflection on an IS-IS network. The no twamp-light command disables the feature.
Command Mode
TWAMP Configuration Mode
Command Syntax
monitor twamptwamp-light
Parameters
twamp-light - Enter TWAMP configuration mode and
configure TWAMP Light.
Example
Use the following command to enter the TWAMP configuration
mode:
The mpls label range command derives the indices of the
actual MPLS label on the SRGB advertised by the router. The default value of SRGB in
EOS is Base: 900000, Size:
65536. In other words, the labels that any global segment
could represent is between
900000-965535.
Command Mode
Global Configuration
Command Syntax
mpls label rangevalue
Parameters
value Specifies the Segment Routing global range.
dynamic Specifies labels reserved for dynamic assignment.
Default value is (100000)
(262144).
IS-IS-sr Specifies labels reserved for IS-IS SR
global segment identifiers (SIDs). Default value is
(900000)
(65536).
static Specifies labels reserved for static MPLS
routes. Default value is (16)
(99984).
Example
The following command configures an IS-IS SR global range with a value of
(900000)-- starting label range,
(65536)--Numbers of labels to reserve.
switch(config)# mpls label range isis-sr 900000 65536
multi-topology
The multi-topology command configures IS-IS Multi-Topology
(MT) support (disabled by default), enabling an IS-IS router to compute a separate
topology for IPv4 and IPv6 links in the network. With MT configured, not all the
links in a network need to support both IPv4 and IPv6. Some can support IPv4 or IPv6
individually. The IPv4 SPF will install IPv4 routes using the IPv4 topology, and
similarly the IPv6 SPF will install IPv6 routes using the IPv6 topology. Without MT
support, all links in an IS-IS network need to support the same set of address
families. When MT is enabled, and each link has a separate IPv4 metric and IPv6
metric.
The no multi-topology and default
multi-topology commands restores the default interface to both
IPv4 and IPv6 address families.
The net command configures the Network Entity Title of the
IS-IS instance. By default, no NET is defined.
The no net and default net
commands removes the NET from running-config.
Command Mode
Router-IS-IS Configuration
Command Syntax
netmask_hex
no net
default net
Parameter
maxk_hex Mask value. Format is
hh.hhhh.hhhh.hhhh.hhhh.hhhh.hhhh.hhhh.hhhh.hhhh.00.
Examples
These commands specify the NET as
49.0001.1010.1040.1030.00, in which the
system ID is 1010.1040.1030, area ID is
49.0001.
switch(config)# router isis Osiris
switch(config-router-isis)# net 49.0001.1010.1040.1030.00
switch(config-router-isis)#
These commands remove NET
49.0001.1010.1040.1030.00 from
running-config.
switch(config)# router isis Osiris
switch(config-router-isis)# no net 49.0001.1010.1040.1030.00
switch(config-router-isis)#
node-segment
The node-segment command associates the node segments with
prefix mask length /32 (IPV4) or
/128 (IPV6) addresses. The
node-segment command must be issued on an
IS-IS-enabled loop back interface.
Command Mode
Loop-back Interface Configuration
Command Syntax
node-segment [ipv4 | ipv6]
indexvalue
Parameters
ipv4 Specifies the IPv4 node
configuration.
ipv6 Specifies the IPv6 node
configuration.
index Node segment identifier.
label Absolute node segment label. A value between 16-1048575
value Index to be mapped with IP
prefix. Value ranges from
0-65535.
Examples
The following commands are used to associate a node-segment with an IPv4
address.
switch(config)# int loopback 1
switch(config-if-Lo1)# ip address 21.1.1.1/32
switch(config-if-Lo1)# node-segment ipv4 index 5
The following commands are used to associate a node-segment with an IPv6
address.
switch(config)# int loopback 1
switch(config-if-Lo1)# ipv6 add 2000::24/128
switch(config-if-Lo1)# node-segment ipv6 index 5
The following example shows a warning thrown at the CLI when a
/32 or /128
address is not configured on the
interface.
switch(config)# int loopback 1
switch(config-if-Lo1)# ip address 21.1.1.1/24
switch(config-if-Lo1)# node-segment ipv4 index 1
! /32 IPv4 address is not configured on the interface
The following command adds an absolute label, 900123, to a node segment.
The following command removes the node-segment from IS-IS SR from an
interface.
switch(config-if-Lo1)# no node-segment ipv4 index 1
passive (IS-IS)
The passive command configures the specified IS-IS
interface as passive. The switch will continue to advertise the IP address in the
LSP, but the interface will not send or receive IS-IS control packets.s
The no passive command removes the passive configuration,
allowing the interface to send and receive IS-IS control packets. The
default passive command sets the interface to the
default interface activity setting by removing the corresponding
passive or no passive
statement from running-config.
Command Mode
Router-IS-IS Configuration
Command Syntax
passiveINTERFACE_NAME
no passiveINTERFACE_NAME
default passiveINTERFACE_NAME
Parameters
INTERFACE_NAME Options include:
ethernete_range Ethernet interface list.
loopbackl_range loopback interface list.
port-channelp_range channel group interface list.
vlanv_range VLAN interface list.
Valid e_range, l_range,
p_range, and v_range
formats include number, range, or comma-delimited list of numbers and ranges.
Examples
These commands configure interface ethernet 10 as
a passive
interface.
ip-address It can be IP address, or IP address
with prefix, or an IPv6 address prefix.
index Node segment identifier.
value Index to be mapped with IP prefix. Value
ranges from
0-65535.
conflict ignore - Ignore conflicts between proxy-node segments and other segments.
Example
A proxy-node-segment associates a /32 or a
/128 route with an SID as shown
below.
switch(config)#router isis instance1
switch(config-router-isis)#segment-routing mpls
switch(config-router-isis-sr-mpls)#proxy-node-segment 1.1.1.0/32 index 50
proxy-node-segment mpls
The proxy-node-segment mpls command allows the configuration of
an MPLS route to forward traffic to the IGP next-hop for the loopback.
Command Mode
Segment-Routing MPLS Configuration
Command Syntax
proxy-node-segment mpls [fallback |
pop | forward]
Parameters
fallback - Specify the fallback entry if Segment Routing
reachability becomes unavailable.
pop - Specify to pop the top label.
forward - Specify to forward the packet based on the IGP
best path.
Example
Configure the proxy-node segment to forward MPLS
traffic.
switch(config)# router general
switch(config-router-general)# segment-routing
switch(config-router-general-sr)# proxy-node-segment mpls fallback pop forward
redistribute (IS-IS)
The redistribute command redistributes the specified types
of routes into IS-IS.
The no redistribute and default
redistribute commands disable route redistribution from the
specified domain by removing the corresponding
redistribute statement from
running-config.
Command Mode
Router-IS-IS Configuration
Command Syntax
redistributeROUTE_TYPE
no redistributeROUTE_TYPE
default redistributeROUTE_TYPE
Parameters
ROUTE_TYPE The route type for which routes are redistributed. These
are the option to include.
bgpredistribute BGP routes
connectedredistribute connected routes
ospfredistribute OSPF routes
ospfv3redistribute OSPFv3 routes
staticredistribute static routes
Examples
These commands redistribute connected routes into the IS-IS domain.
switch(config)# router isis Test
switch(config-router-isis)# redistribute connected
These commands redistribute static routes into the IS-IS domain.
switch(config)# router isis Test
switch(config-router-isis)# redistribute static
These commands redistribute the BGP routes into ISIS domain in the
address-family
mode.
The redistribute bgp route-map command redistributes the
BGP routes from the specified route map into IS-IS. Only one route map can be
specified; reissuing the command overrides any previous configuration.
The no redistribute bgp and default
redistribute bgpcommands disable BGP route redistribution from
the specified domain by removing the redistribute bgp statement from
running-config.
The command is available in both router isis configuration mode and the
address-family submode. The command is rejected if configured
in both modes at the same time. Issuing the no or default command in
router isis configuration mode has no effect on redistribution
configured in the address-family submode.
Note: If the command is configured in an address-family submode, it only
redistributes routes from that address family. If it is configured in
router-isis mode, it applies to all enabled address
families.
Command Mode
Router-IS-IS Configuration
Router-IS-IS Address-Family Configuration
Command Syntax
redistribute bgp route-mapmap_name
no redistribute bgp
default redistributeROUTE_TYPE
Parameter
map_name Route map to be used for redistribution of BGP
routes.
Examples
These commands redistribute IPv4 BGP routes from the route map called
bgp-to-isis-v4 into the ISIS
domain.
The router isis command places the switch in router ISIS
configuration mode.
Router ISIS configuration mode is not a group change mode;
running-config is changed immediately after commands are executed.
The exit command does not affect the configuration.
The no router isis command deletes the IS-IS instance.
The exit command returns the switch to global
configuration mode.
Command Mode
Global Configuration
Command Syntax
router isisinstance_name [VRF_INSTANCE]
no router isisinstance_name
default router isisinstance_name
Parameters
instance_name routing instance.
VRF_INSTANCE
no parameter
vrfvrf_name
Examples
These commands places the switch in the router isis mode and
creates an IS-IS routing instance named
Osiris.
This command attempts to open an instance with a different routing instance
name from that of the existing instance. The switch displays an error and
stays in global configuration
mode.
switch(config)# router isis Osiris
% More than 1 ISIS instance is not supported
switch(config)#
This command deletes the IS-IS
instance.
switch(config)# no router isis Osiris
switch(config)#
segment-routing mpls
The segment-routing mpls command places the switch in the
segment-routing mpls configuration mode.
The no segment-routing mpls and default
segment-routing mpls commands disable IS-IS SR and delete all
IS-IS SR configurations.
Command Mode
Router IS-IS Configuration
Command Syntax
segment-routing mpls
no segment-routing mpls
default segment-routing mpls
Example
The following commands place the switch in segment-routing mpls
configuration
mode.
The set isis level command configures a route map to set
ISIS level.
The no set isis level and default set isis
level commands disables the set ISIS level configuration from
running-config.
Command Mode
Route-map Configuration
Command Syntax
set isis level [level-1 |
level-2 | level-1-2]
no set isis level [level-1 |
level-2 | level-1-2]
default set isis level [level-1 |
level-2 | level-1-2]
Parameters
level-1 IS-IS level 1.
level-2 IS-IS level 2.
level-1-2 IS-IS level 1 and level 2.
Example
These commands place the switch in the route-map mode, and configures a
route map to set isis level to level-1.
switch(config)# route-map Test
switch(config-route-map-test)# set isis level level-1
set-overload-bit
The set-overload-bit command sets the overload bit in link
state packets (LSPs) to signal that the switch is not available for forwarding
transit traffic (for instance, during startup or when the switch is being taken down
for maintenance). To configure the switch to set the overload bit for a specified
period after a reboot, use the on-startup option.
The no set-overload-bit and default
set-overload-bit commands remove the corresponding
set-overload-bit command from
running-config.
Note: When using the on-startup option, the
overload bit will remain set in LSPs until the IS-IS agent has been up for the
configured interval.
Command Mode
Router-IS-IS Configuration
Command Syntax
set-overload-bit [on-startupinterval]
no set-overload-bit
default set-overload-bit
Parameters
on-startup Configures the switch to set the overload
bit in LSPs for a period of interval seconds after
startup.
interval The period in seconds for which the overload
bit remains set after startup.
Examples
These commands configure the switch to sets the overload bit for
120 seconds after
startup.
The show isis graceful-restart vrf command displays the GR
configuration and graceful-restart related state of the IS-IS instance as well as
its neighbors.
Command Mode
EXEC
Command Syntax
show isis graceful-restart vrfvrf-name
Example
In this example the show isis graceful-restart command
displays the output for the default vrf
instance.
switch# show isis graceful-restart vrf default
IS-IS Instance: 1 VRF: default
System ID: 0000.0000.0001
Graceful Restart: Enabled, Graceful Restart Helper: Enabled
State: Last Start exited after T2 (level-1) expiry
T1 : 3s
T2 (level-1) : 30s/20s remaining
T2 (level-2) : 30s/not running
T3 : not running
System ID Type Interface Restart Capable Status
is-hostname-1 L1L2 Ethernet1 Yes Running
is-hostname-2 L1 Ethernet2 Yes Restarting
show isis hostname
The show isis hostname command displays mapping between the
System ID and IS-IS hostname.
Command Mode
EXEC
Command Syntax
show isis hostname
Example
This command mapping between the System ID and IS-IS hostnames
host1 and
host2.
switch# show isis hostname
ISIS Instance: 1 VRF: default
Level System ID Hostname
L1 1111.1111.1001 host1
L1 1111.1111.1002 host2
show isis interface
The show isis interface command displays interface
information for the IS-IS instance.
Command Mode
EXEC
Command Syntax
show isis interface
[INSTANCES][INTERFACE_NAME][INFO_LEVEL]
show isis interface [INTERFACE_NAME]
[INFO_LEVEL][VRF_INSTANCE]
Parameters
INSTANCES Options include:
no parameter
instance_name
INTERFACE_NAME Values include:
no parameter All interfaces.
ethernete_num Ethernet interface specified by
e_num.
loopbackl_num Loopback interface specified by
l_num.
managementm_num Management interface specified by
m_num.
port-channelp_num Port channel interface specified by
p_num.
vlanv_num VLAN interface specified by
v_num.
VXLANvx_num VXLAN interface specified by
vx_num.
INFO_LEVEL Options include:
no parameter
detail
VRF_INSTANCE specifies the VRF instance.
no parameter
vrfvrf_name
Display Values
ISIS Instance
System ID
Index
MTU
Metric
LAN-ID
DIS
Type
Interface
SNPA
State
Hold time
Examples
This command displays general IS-IS information for instance
Osiris.
This example displays the state of TI-LFA protection for IPv4/IPV6 prefixes learned on
that IS-IS
interface.
switch# show isis interface Vlan2387
IS-IS Instance: inst1 VRF: default
Interface Vlan2387:
Index: 36 SNPA: P2P
MTU: 1497 Type: point-to-point
BFD IPv4 is Disabled
BFD IPv6 is Disabled
Hello Padding is Enabled
Level 2:
Metric: 10, Number of adjacencies: 1
Link-ID: 24
Authentication mode: None
TI-LFA node protection with SRLG loose protection is enabled for the following IPv4 segments: node segments, adjacency segments
TI-LFA protection is disabled for IPv6
show isis local-convergence-delay
The show isis local-convergence-delay command shows the current or last attempt at delaying the convergence of protected routes on a link down/BFD neighbor down event. If the timer aborts for some reason (such as a topology change causing a new SPF), the attempt fails.
Examples
switch# show isis local-convergence-delay
IS-IS Instance: inst1 VRF: default
System ID: 1111.1111.1001
IPv4 local convergence delay configured, 5000 msecs
IPv6 local convergence delay configured, 5000 msecs
Level 1 attempts 0, failures 0
Level 2 attempts 3, failures 1
Level 2 in progress due to LINK DOWN on Vlan2138
TI-LFA node protection is enabled for IPv4
IPv4 Routes delayed: 0
Delay timer started at: 2019-07-25 23:16:33
Delay timer expires in 2 secs
TI-LFA protection is disabled for IPv6
Level 2 last attempt due to LINK DOWN on Vlan2138, Succeeded
TI-LFA node protection is enabled for IPv4
IPv4 Routes delayed: 3
Delay timer started at: 2019-07-25 23:14:51
Delay timer stopped at: 2019-07-25 23:14:56
TI-LFA protection is disabled for IPv6
The detail keyword also lists all the routes that have been delayed.
switch# show isis local-convergence-delay detail
...
Level 2 last attempt due to LINK DOWN on Vlan2138, Succeeded
TI-LFA node protection is enabled for IPv4
IPv4 Routes delayed: 3
Delay timer started at: 2019-07-25 23:14:51
Delay timer stopped at: 2019-07-25 23:14:56
Delayed routes:
10.0.7.1/32
10.0.9.1/32
10.0.10.1/32
TI-LFA protection is disabled for IPv6
show isis neighbors
The show isis neighbors command displays IS-IS neighbor
information.
Command Mode
EXEC
Command Syntax
show isis neighbors [INSTANCES]
[INFO_LEVEL]
show isis neighbor [INFO_LEVEL]
[VRF_INSTANCE]
Parameters
INSTANCES Options include:
no parameter
instance_name
INFO_LEVEL Options include:
no parameter
detail
VRF_INSTANCE Specifies the VRF instance.
no parameter
vrfvrf_name
Display Values
Inst. ID
System ID
Type
Interface
SNPA
State
Hold time
Area Address
Example
This command displays general information about the IS-IS
neighbors.
switch(config)# show isis neighbors
Inst Id System Id Type Interface SNPA State Hold time
10 2222.2222.2222 L2 Vlan20 2:1:0:c:0:0 UP 30
10 1212.1212.1212 L2 Vlan20 2:1:0:d:0:0 UP 9
10 3030.3030.3030 L2 Ethernet30 2:1:0:b:0:0 UP 9
switch(config)#
show isis network topology
The show isis network topology command displays a list of
all IS-IS devices that are reachable in the network.
Command Mode
EXEC
Command Syntax
show isis network topology
show isis INSTANCESnetwork topology
show isis network topologyVRF_INSTANCE
Parameters
INSTANCES Options include:
no parameter
instance_name
VRF_INSTANCE Specifies the VRF instance.
no parameter
vrfvrf_name
Display Values
System Id
Metric
Next-Hop
Interface
SNPA
Example
This command displays the list of all devices reachable in the
network.
switch# show isis network topology
IS-IS Instance: Osiris VRF: default
IS-IS paths to level-2 routers
System Id Metric IA Metric Next-Hop Interface SNPA
2222.2222.2222 10 0 2222.2222.2222 Ethernet1 P2P
switch>
show isis segment-routing
adjacency-segments
The show isis segment-routing adjacency-segments command
displays the global adjacency SID value and other related information.
Command Mode
EXEC
Command Syntax
show isis segment-routing adjacency-segments
Examples
In this example the show isis segment-routing
adjacency-segments command displays the output for the
interface configured like this:
switch# interface Ethernet1
ip address 1.1.1.1/24
ipv6 address 1000::1/64
isis enable isis1
isis network point-to-point
adjacency-segment ipv4 p2p index 1 global
adjacency-segment ipv6 p2p index 2 global
The show output for the above interface configuration:
switch# show isis segment-routing adjacency-segments
System ID: 1000.0000.0002 Instance: isis1
SR supported Data-plane: MPLS SR Router ID: 1.1.1.4
Adj-SID allocation mode: SR-adjacencies
Adj-SID allocation pool: Base: 100000 Size: 16384
Adjacency Segment Count: 2
Flag Descriptions: F: Ipv6 address family, B: Backup, V: Value
L: Local, S: Set
Segment Status codes: L1 - Level-1 adjacency, L2 - Level-2 adjacency, P2P -
Point-to-Point adjacency, LAN - Broadcast adjacency
Locally Originated Adjacency Segments
Adj IP Address Local Intf SID SID Source Flags Type
---------------- ---------- ------ ------------- ------------------- -------
1.1.1.2 Et1 1 Configured F:0 B:0 V:0 L:0 S:0 P2P L1
fe80::1:ff:fe65:0 Et1 2 Configured F:1 B:0 V:0 L:0 S:0 P2P L1
Received Global Adjacency Segments
SID Originator Neighbor Flags
--------- -------------------- ---------------- --------------------
0 rtrmpls1 1000.0000.0002 F:0 B:0 V:0 L:0 S:0
The following is the C-API output for the show isis
segment-routing adjacency-segments command.
The show isis segment-routing global-blocks command lists
the SRGBs in use by all SR supporting devices in IS-IS domain including the SRGB in
use by IS-IS SR on this device.
Command Mode
EXEC
Command Syntax
show isis segment-routing global-blocks
Example
switch# show isis segment-routing global-blocks
System ID: 1111.1111.1002 Instance: inst1
SR supported Data-plane: MPLS SR Router ID: 252.252.2.252
SR Global Block( SRGB ): Base: 900000 Size: 65536
Number of ISIS segment routing capable peers: 3
SystemId Base Size
-------------------- ------------ -----
1111.1111.1002 900000 65536
1111.1111.1001 900000 65536
show isis segment-routing
prefix-segments
The show isis segment-routing prefix-segments command
provides the details of all prefix segments being originated as well the segments
received from IS-IS SR speakers in the domain.
switch# show isis segment-routing prefix-segments
...
Prefix SID Type System ID Level Protection
------------- ----- ------ ... --------------- ------ -----------
* 10.1.1.1/32 0 Node ... 1111.1111.1001 L2 unprotected
10.1.1.2/32 1 Node ... 1111.1111.1002 L2 node with SRLG loose
10.1.1.3/32 4 Node ... 1111.1111.1005 L2 node with SRLG strict
10.1.1.4/32 10 Prefix ... 1111.1111.1004 L1 node
About the Output
After the usual output header that represents
the system ID, instance name, etc and parameters of a router, there is
a line depicting prefix segment counters. Each field in this line relates
to the number of segments that are present in this routers IS-IS instance.
For example, the above example shows that this device has 2 Node Segments
(Self originated as well as the ones received from other IS-IS SR devices).
The main section of this show commands
output is the section that lists all the prefix segments and related
information like prefix, SID, type of segment (Prefix, Node, Proxy-Node),
the flag values being carried in the sub-TLVs of these prefix segments
and the system ID of the originating router. The Type field will be useful
on a IS type level-1-2 router. It shows whether the installed prefix
segment is from a level-1 prefix or a level-2 prefix.
show isis segment-routing
The show isis segment-routing command displays the summary
information on IS-IS SR status.
Command Mode
EXEC
Command Syntax
show isis
segment-routing
Example
The command output
displays the summary information on IS-IS SR
status.
switch(config)# show isis segment-routing
System ID: 1111.1111.1002 Instance: inst1
SR supported Data-plane: MPLS SR Router ID: 252.252.2.252
SR Global Block( SRGB ): Base: 900000 Size: 65536
Adj-SID allocation mode: SR-adjacencies
Adj-SID allocation pool: Base: 100000 Size: 16384
All Prefix Segments have : P:0 E:0 V:0 L:0
All Adjacency Segments have : F:0 B:0 V:1 L:1 S:0
ISIS Reachability Algorithm : SPF (0)
Number of ISIS segment routing capable peers: 3
Self-Originated Segment Statistics:
Node-Segments : 2
Prefix-Segments : 2
Proxy-Node-Segments : 0
Adjacency Segments :
About the Output
The first line of the output shows the IS-IS system ID of this device and the name of
the instance with which IS-IS is configured.
The supported data plane is shown
against the SR supported Data-plane field, while the router ID being advertised in
the Router Capability is mentioned in the SR Router ID field.
The SRGB in use
and the MPLS label pool being used for adjacency segment allocation are mentioned in
this output. The current adjacency allocation mode which refers to whether we are
allocating adjacency segments to all IS-IS adjacencies or only those adjacencies
which support SR or None of the adjacencies is shown in the Adj-SID allocation mode
field.
Flag contents of All Prefix Segments originated on this router, Flag
contents of All Adjacency Segments originated on this router and supported IS-IS
Reachability Algorithm have been provided through this command output and they carry
the meaning as per the IS-IS SR IETF draft.
This show command provides a
statistics related to IS-IS SR in terms of various counters ranging from number of
IS-IS SR enabled peers, number of Node-SIDs, prefix-SIDs, proxy-node-segments and
adjacency segments being originated on this router in IS-IS.
The
show isis segment-routing command also provides
information if segment routing has been administratively disabled as
shown.
switch(config-router-isis-sr-mpls)# show isis segment-routing
! IS-IS (Instance: inst1) Segment Routing has been administratively shutdown.
show isis segment-routing tunnel
The show isis segment-routing tunnel command displays all the
IS-IS SR tunnels. The field TI-LFA tunnel index
displays the index of the TI-LFA tunnel protecting the SR tunnel. The same TI-LFA tunnel
that protects the LFIB route also protects the corresponding IS-IS SR tunnel.
Example
switch# show isis segment-routing tunnel 10.0.10.1/32
Index Endpoint Nexthop Interface Labels TI-LFA
tunnel index
------ --------------- ----------- ----------- ---------- -------------
4 10.0.10.1/32 10.0.0.2 Vlan2387 [900004] 0
show isis summary
The show isis summary command displays information about
the configured IS-IS instances.
Command Mode
EXEC
Command Syntax
show isis summary
show isis [INSTANCES]
summary
show isis summaryVRF_INSTANCE
Parameters
INSTANCES Options include:
no parameter
instance_name
VRF_INSTANCE Specifies the VRF instance.
no parameter
vrfvrf_name
Display Values
System ID
IPv4 Preference
IPv6 Preference
IS-Types
LSP Generation interval
SPF Interval
Current SPF Hold Interval
IS-Types Run Time
Area Addresses
Designated Intermediate Systems (DIS)
Interfaces
Link State DataBase (LSDB) size
Display Status
Multi Topology
Authentication Mode
Graceful Restart
Graceful Restart Helper
Example
This command displays general information about the configured IS-IS
instances.
switch(config-router-isis-af)# show isis summary
IS-IS Instance: 1 VRF: default
System ID: 0000.0000.0001, administratively enabled
Multi Topology disabled, not attached
IPv4 Preference: Level 1: 115, Level 2: 115
IPv6 Preference: Level 1: 115, Level 2: 115
IS-Type: Level 1 and 2, Number active interfaces: 0
Routes both IPv4 and IPv6
LSP size maximum: Level 1: 9000, Level 2: 9000
Max wait(s) Initial wait(ms) Hold interval(ms)
LSP Generation Interval: 5 50 50
SPF Interval: 2 1000 1000
Current SPF hold interval(ms): Level 1: 1000, Level 2: 1000
Last Level 1 SPF run 1 seconds ago
Last Level 2 SPF run 1 seconds ago
Authentication mode: Level 1: None, Level 2: None
Graceful Restart: Disabled, Graceful Restart Helper: Enabled
Area Addresses:
49.0001
level 1: number dis interfaces: 0, LSDB size: 1
level 2: number dis interfaces: 0, LSDB size: 1
show isis ti-lfa path
The show isis ti-lfa path command displays the repair path with the list of all the system IDs from the P-node to the Q-node for every destination/constraint tuple. You will see that even though node protection is configured, a link protecting LFA is computed too. This is to fallback to link protecting LFAs if the node protecting LFA becomes unavailable.
Examples
switch# show isis ti-lfa path 1111.1111.1005
TI-LFA paths for IPv4 address family
Topo-id: Level-2
Destination Constraint Path
1111.1111.1005 exclude node 1111.1111.1002 1111.1111.1003
1111.1111.1004
exclude Vlan2387 1111.1111.1002
SRLG strict
The TI-LFA repair tunnels are just internal constructs that are shared by multiple LFIB routes that compute similar repair paths. The show isis ti-lfa tunnel command displays TI-LFA repair tunnels with the primary and backup via information.
Example
switch#show isis ti-lfa tunnel 1
Tunnel Index 1
via 10.0.1.2, 'Vlan2968'
label stack 3
backup via 10.0.0.2, 'Vlan2387'
label stack 900004 900002
show monitor twamp-light
The show monitor twamp-light displays calculated one way and two way minimum delay. By default, information displays for all peer
IP addresses configured on the remote end of the IS-IS point-to-point links. The output can be filtered for a specific IP address.
Command Mode
EXEC
Command Syntax
show monitor twamp-light [ipip_address] detail
Parameters
ipip_address - Specify an IP address to filter the
output to an IP address.
detail - Displays details about the TWAMP
configuration.
Examples
Use the show monitor twamp command to display TWAMP
information.
switch#show monitor twamp-light
Unit: microseconds
IP Address Interface One Way Two Way
Minimum Delay Minimum Delay
------------ ------------ --------------- ---------------
1.0.0.2 Ethernet17/1 2742 5482
1.0.0.3 Ethernet18/1 2772 5544
Add an IP address to filter the TWAMP output to a specific IP
address.
switch#show monitor twamp-light ip 1.0.0.2
Unit: microseconds
IP Address Interface One Way Two Way
Minimum Delay Minimum Delay
------------ ------------ --------------- ---------------
1.0.0.2 Ethernet17/1 2742 5482
Use the show monitor twamp-light detail command to
display all information about the TWAMP configuration on IP address
1.0.0.2.
switch#show monitor twamp-light ip 1.0.0.2 detail
IP address: 1.0.0.2
Interface: Ethernet17/1
Description: Interface Ethernet17/1
Sender profile name: defaultSender
Effective sampling rate: 1 packet every 1.0 second
Packets sent: 178
Packets received: 21
Unit: microseconds
Measurement Min Max Avg Variance
------------- ---- ------ ----- ----------
One-way delay 2742 236072 19822 4294967295
Two-way delay 5482 472132 39642 4294967295
show monitor twamp-light counters
The show monitor twamp-light counters displays packet counters for TWAMP reflection on the IS-IS network. The
clear monitor twamp-light counters command clears the TWAMP packet counters.
Command Mode
EXEC
Command Syntax
show monitor twamp-light counters [sender |
reflector | drop]
detail
Parameters
sender
reflector
detail
Examples
Use the show monitor twamp-light counters to display
all
counters.
The show monitor twamp-light raw displays probe packet information for TWAMP reflection on the IS-IS network. The probe packet
information includes the packet received time, sequence number, and the delay calculated on this packet.
By default, the output displays statistics for all received packets but can be limited with the parameter, raw count.
Command Mode
EXEC
Command Syntax
show monitor twamp-light [ip |
interface] raw countnumber
Parameters
ipip_address - Specify an IP address to display probe
packet information.
interfaceinterface_name - Specify an interface to display
probe packet information.
raw countnumber - Specify the number of probe packets to display in the output.
Example
Use the show monitor twamp-light ip 1.0.0.2 raw count 5 command
to display five (5) probe packets on IP address,
1.0.0.2.
switch# show monitor twamp-light ip 1.0.0.2 raw count 5
Address: 1.0.0.2
Last RX interface: Ethernet17/1
Two-way delays (in microseconds):
Rx time Seqnum Delay
---------------------------- ---------- ------------
2024-05-15 01:44:45.814785 19 10120.5
2024-05-15 01:44:44.824825 18 21474.2
2024-05-15 01:44:43.828435 17 25934.5
2024-05-15 01:44:42.828052 16 26654.2
2024-05-15 01:44:41.811446 15 11387.4
show mpls label ranges
The show mpls label ranges command displays the MPLS label
range available on a router is categorized into different pools which cater to
different applications running on the router.
The show mpls lfib route command displays the LFIB
information for a specified route or for all routes. The source column depicts the
MPLS control plane protocol that is responsible for the label binding that resulted
in this LFIB route.
Command Mode
EXEC
Command Syntax
show mpls lfib route [label_num]
Parameter
label_num Displays only the LFIB information for
the specified route. If no label number is specified, the command displays
information for all LFIB routes.
Examples
This command displays LFIB information for all
routes.
switch# show mpls lfib route
MPLS forwarding table (Label [metric] Vias) - 7 routes
MPLS next-hop resolution allow default route: False
Via Type Codes:
M - Mpls Via, P - Pseudowire Via,
I - IP Lookup Via, V - Vlan Via,
VA - EVPN Vlan Aware Via, ES - EVPN Ethernet Segment Via,
VF - EVPN Vlan Flood Via, AF - EVPN Vlan Aware Flood Via,
NG - Nexthop Group Via
Source Codes:
S - Static MPLS Route, B2 - BGP L2 EVPN,
B3 - BGP L3 VPN, R - RSVP,
P - Pseudowire, L - LDP,
IP - IS-IS SR Prefix Segment, IA - IS-IS SR Adjacency Segment,
IL - IS-IS SR Segment to LDP, LI - LDP to IS-IS SR Segment,
BL - BGP LU, ST - SR TE Policy,
DE - Debug LFIB
IA 100000 [1]
via M, 1.0.1.2, pop
payload autoDecide, ttlMode uniform, apply egress-acl
interface Vlan2930
IA 100001 [1]
via M, fe80::200:eff:fe02:0, pop
payload autoDecide, ttlMode uniform, apply egress-acl
interface Vlan2930
IP 900008 [1]
via M, 1.0.1.2, swap 900008
payload autoDecide, ttlMode uniform, apply egress-acl
interface Vlan2930
IP 900009 [1]
via M, fe80::200:eff:fe02:0, swap 900009
payload autoDecide, ttlMode uniform, apply egress-acl
interface Vlan2930
switch#
This command displays LFIB information only for the route labeled
900008.
switch# show mpls lfib route 900008
MPLS forwarding table (Label [metric] Vias) - 7 routes
MPLS next-hop resolution allow default route: False
Via Type Codes:
M - Mpls Via, P - Pseudowire Via,
I - IP Lookup Via, V - Vlan Via,
VA - EVPN Vlan Aware Via, ES - EVPN Ethernet Segment Via,
VF - EVPN Vlan Flood Via, AF - EVPN Vlan Aware Flood Via,
NG - Nexthop Group Via
Source Codes:
S - Static MPLS Route, B2 - BGP L2 EVPN,
B3 - BGP L3 VPN, R - RSVP,
P - Pseudowire, L - LDP,
IP - IS-IS SR Prefix Segment, IA - IS-IS SR Adjacency Segment,
IL - IS-IS SR Segment to LDP, LI - LDP to IS-IS SR Segment,
BL - BGP LU, ST - SR TE Policy,
DE - Debug LFIB
IP 900008 [1]
via M, 1.0.1.2, swap 900008
payload autoDecide, ttlMode uniform, apply egress-acl
interface Vlan2930
switch#
show mpls segment-routing
bindings
The show mpls segment-routing bindings command displays the
local label bindings and label bindings on the peer routers for each prefix that has
a segment advertised. Peer ID here represents the IS-IS system ID of the peer.
The show tunnel fib command that displays tunnels programmed in the tunnel FIB also includes the TI-LFA tunnels along with protected IS-IS SR tunnels.
Examples
switch# show tunnel fib ti-lfa 1
Type 'TI-LFA', index 1, forwarding None
via 10.0.1.2, 'Vlan2968'
label stack 3
backup via 10.0.0.2, 'Vlan2387'
label stack 900004 900002
switch# show tunnel fib isis segment-routing
Type 'IS-IS SR', index 1, endpoint 2002::b00:201/128, forwarding Primary
via TI-LFA tunnel index 3 label 3
via fe80::200:76ff:fe01:0, 'Ethernet30/1' label 900002
backup via fe80::200:76ff:fe03:0, 'Ethernet26/1' label 132769
Type 'IS-IS SR', index 2, endpoint 2002::b00:101/128, forwarding Primary
via TI-LFA tunnel index 4 label 3
via fe80::200:76ff:fe01:0, 'Ethernet30/1' label 3
backup via fe80::200:76ff:fe03:0, 'Ethernet26/1' label 132769 900001
shutdown (IS-IS)
The shutdown command disables IS-IS on the switch without
modifying the IS-IS configuration.
The no shutdown and default
shutdown commands enable the IS-IS instance by removing the
shutdown command from
running-config.
The spf-interval command sets the Shortest Path First (SPF)
timer that defines the interval between IS-IS path calculations. The default value
is two seconds.
This command also configures the maximum
wait interval between any two SPF runs, initial wait interval before
executing the first SPF computation, and the hold time between the first
and second SPF runs.
The no spf-interval and default
spf-interval commands restore the default maximum IS-IS path
calculation interval to two seconds by removing the
spf-interval command from
running-config.
{max-waitseconds | max-waitmilliseconds} - Value ranges from 1 through
300 seconds or from
1 to 300000
milliseconds. Default maximum wait interval is 2
seconds.
initial-waitmilliseconds - Value ranges from 1 through
300000 ms. Default initial wait interval
is 1000 milliseconds.
hold-timemilliseconds - Value ranges from
1 through 300000
ms. Default hold interval is 1000
milliseconds.
Guidelines
EOS does not support configuring topology-specific
SPF timers in multi-topology deployments and IS-IS level-specific SPF
timers.
Examples
This command configures the SPF maximum wait interval to
50
seconds.
This command configures maximum wait interval, initial wait interval, and hold
time to 20000 milliseconds,
10000 milliseconds, and
5000 milliseconds
respectively.
This command reverts the SPF interval configuration to its default
value.
switch(config)# router isis Osiris
switch(config-router-isis)# no spf-interval
timers local-convergence-delay
The Point of Local Repair (PLR) switches to the TI-LFA backup path on link failure or BFD
neighbor failure but switches back to the post-convergence path once the PLR computes
SPF and updates its LFIB. This sequence of events can lead to micro-loops in the
topology if the PLR converges faster than other routers along the post-convergence path.
So a configuration option is provided to apply a delay, after which the LFIB route being
protected by the TI-LFA loop-free repair path will be replaced by the post-convergence
LFIB route.
delay_in_seconds The convergence delay, in seconds. A
default of 10 seconds is used when the command is used without an explicitly
specified delay.
protected-prefixes The prefix which the LFIB route
being protected by the TI-LFA loop-free repair path will be replaced by the
post-convergence LFIB route.
timers lsp out-delay
The timers lsp out-delay command in the IS-IS Router Configuration Mode forces a
router to pause before flooding self-originated LSPs after a link or metric decrease event and prevents
micro-loops from forming on the network.
The [no | default] versions of the command disables the configuration and
removes it from the running-config.
Command Mode
IS-IS Router Configuration
Command Syntax
timers lsp out-delaytransmit_delay
no timers lsp out-delay
default timers lsp out-delay
Parameters
out-delaytransmit_delay - Specify the number of
milliseconds, from 1 to 65000, to delay transmitting LSPs after an event.
Example
Use the following commands to configure the LSP Out Delay feature on the switch, ISIS-4,
5000 milliseconds:
Routing Information Protocol (RIP) is a routing protocol typically used as an Interior Gateway
Protocol (IGP). RIP uses hop counts only to determine the shortest path to a
destination. To avoid loops, RIP limits its paths to a maximum of
15 hops, making it an ineffective protocol for large
networks. RIP Version 2 supports Classless Inter-Domain Routing (CIDR) and uses IP
multicast at address 224.0.0.9 to share the routing table with
adjacent routers.
RIP sends updates whenever there is a change in the network topology and periodic updates when
there are no changes. Receiving switches update their routing table whenever the update
includes topology changes. Because RIP transmits the entire routing table every
30 seconds, RIP updates can generate heavy traffic
loads in large or complicated networks.
Each switch also sends a list of distance-vectors to each of its neighbors periodically. The
distance-vector is the metric RIP uses to express the cost of a route, and it describes
the number of hops required to reach a destination. Each hop is typically assigned a hop
count value of 1, and the router adds
1 to the metric when it receives a routing update and adds
the network to its routing table.
To remove dead routes from its routing
table, RIP marks a route for deletion if the router does not receive
an advertisement for it within the expiration interval, then removes
it from the routing table after the deletion interval.
Running RIP on the Switch
Accessing RIP Configuration Mode and Enabling
RIP
RIP Configuration Mode
The router rip command places the switch in router-RIP
configuration mode to configure Routing Information Protocol
(RIP) routing.
Example
This command places the switch in router-RIP configuration
mode.
Using the router rip command puts the switch in router-RIP
configuration mode but does not enable RIP on the switch.
Enabling RIP
Routing Information Protocol (RIP) is disabled by default on the switch. The noshutdown (RIP) command in router-RIP
configuration mode will enable RIP.
Example
This command enables RIP on the
switch.
switch(config-router-rip)# no shutdown
switch(config-router-rip)#
Issuing this command enables RIP, but to send and receive RIP route updates and route packets via
RIP, you must also use the network (RIP) command
to specify interfaces on which RIP will run.
Disabling RIP
You can disable RIP in two ways. The shutdown (RIP)
command disables RIP on the switch but maintains all user-entered router-RIP
configuration statements in the running-config. The norouter rip command disables RIP and
removes all user-entered router-RIP configuration statements from the
running-config.
Examples
This command disables RIP on the switch and removes all
user-entered router-RIP
configurations.
switch(config)# no router rip
switch(config)#
This command disables RIP on the switch but preserves all
user-entered router-RIP
configurations.
Issuing the noshutdown (RIP) command in
router-RIP configuration mode enables RIP. However, to run RIP on an
interface, you must specify a RIP network using the network (RIP) command.
You can also configure the redistribution
of routes learned from other protocols, set the default metric and administrative
distance for redistributed routes, configure the timing of various RIP
events, and configure specific interfaces to send RIP update packets
by broadcast instead of multicast.
Specifying RIP Networks
The network (RIP) command identifies networks on which
RIP will run and specifies which routes RIP will accept into its routing table.
You can issue the network (RIP) command
multiple times to build up a list of RIP networks. No RIP networks are configured
by default, so in order to route packets and send and receive RIP updates, you
must specify one or more RIP networks.
Use the no network (RIP) command to disable RIP on a specific
network.
switch(config-router-rip)# no network 10.168.1.1/24
switch(config-router-rip)#
Redistributing Routes Learned from Other Protocols
into RIP
Use the redistribute (RIP) command to enable route
import from a specified protocol into RIP. Additionally, you can apply a
route map to the incoming routes to filter which routes are added to the RIP
routing table. All connected routes are redistributed into RIP by
default.
Example
This command redistributes all routes learned from OSPF into
RIP.
When RIP runs on the switch, it sends unsolicited route updates and deletes expired routes at
regular intervals. To configure the timing of those events, use the timers (RIP) command. The command takes three parameters:
the update interval, the route expiration time, and the route deletion time.
The update interval is the time in seconds that the switch waits between sending unsolicited RIP
route updates to its neighbors. The route expiration time is how long the switch waits before
marking an unadvertised route for deletion (the counter resets whenever an advertisement for
the route is received). And the route deletion time is how long the switch waits between
marking a route for deletion and removing it from the routing table. During the deletion
interval, the switch continues to forward packets on the route.
Example
This command sets the update interval to 60 seconds, the expiration
time to 90 seconds, and the deletion time to
150
seconds.
Configuring an Interface to Transmit Broadcast
RIP Updates
By default, the switch uses RIP version 2 and multicasts RIP update packets from all
participating interfaces. To reconfigure a specific
interface to send updates as broadcast packets, use
the rip v2 multicast disable command in the configuration mode for the
interface.
Example
The following commands configure RIP version 2 broadcasting on interface
ethernet5.
To see a listing of the RIP routes in the switch’s routing table, use the show ip rip
database command. (You can also display
similar information using the RIP option in the
show ip route
command.)
Examples
This command displays all active rip
routes.
switch> show ip rip database
10.168.11.0/24 directly connected, Et4
10.168.13.0/24
[1] via 10.168.14.2, 00:00:25, Et4
[2] via 10.168.15.2, 00:00:20, Et1
10.168.13.0/24
[1] via 10.168.14.2, 00:00:25, Et3
This command submits a query for RIP route information for a
network.
switch> show ip rip database 10.168.13.0/16
10.168.13.0/24
[1] via 10.168.14.2, 00:00:25, Et4
[2] via 10.168.15.2, 00:00:20, Et1
Displaying RIP Route Gateways
To see information about the switch’s RIP route gateways, use the show ip rip
neighbors command. The output displays the
IPv4 address, the last heard time of the gateway,
and characteristic flags applying to the
gateway.
Example
This command displays information about all the gateways of RIP
routes.
switch> show ip rip neighbors
Gateway Last-Heard Bad-Packets Bad-Routes Flags
10.2.12.33 00:00:15 SRC, TRSTED,
ACCPTED, RJCTED,
Q_RJCTED, AUTHFAIL
Configuring RIP on Multiple
VRFs
VRF support for Routing Information
Protocol (RIP) allows instances of RIP on multiple non-default VRFs on
the same router. By default, all interfaces belong to the default VRF
until VRF forwarding is executed.
The vrf instanceand vrf (Interface mode)
commands configure a non-default VRF, enable routing in it, and configure the network
command under the configuration router RIP for the prefix to which the interface
belongs.
The router rip vrf command places the switch in
router-RIP configuration mode to configure a RIP routing
instance in a non-default VRF.
Examples
These commands configure a non-default VRF and enable unicast routing in
it.
switch(config)# vrf instance test
switch(config-vrf-test)# exit
switch(config)# ip routing vrf test
switch(config)#
This command configures a RIP instance in a non-default
VRF.
switch(config)# router rip vrf test
switch(config-router-rip-router-rip-vrf-test)# no shutdown
switch(config-router-rip)# exit
switch(config)#
This command configures an interface as part of a non-default VRF by configuring the network
command under the configuration router RIP for the
prefix to which the interface
belongs.
switch(config)# interface Ethernet 3 / 1
switch(config-if-Et3/1)# no switchport
switch(config-if-Et3/1)# ip address 1.0.0.1/24
switch(config-if-Et3/1)# vrf test
switch(config-if-Et3/1)# network 1.0.0.1
switch(config-if-Et3/1)# exit
switch(config)#
The distance command assigns an administrative distance
to routes that the switch learns through RIP. Routers use administrative distances
to select a route when two protocols provide routing information to the same
destination. Distance values range from 1 to 255; lower
distance values correspond to higher reliability. The default RIP distance value is
120.
The no
distance and default distance commands
restore the administrative distance default value of 120
by removing the distance command from
running-config.
Command Mode
Router-RIP
Configuration
Command Syntax
distancedistance_value
no
distance
default
distance
Parameter
distance_value distance
assigned to RIP routes. Values range from 1 to
255.
Example
These commands assign
an administrative distance of 75 to RIP
routes.
The distribute-list command allows users to filter out
routes that are received or sent out. The distribute-list command influences which
routes the router installs into its routing table and advertises to its
neighbors.
Configuration Notes:
Only one inbound distribute-list is allowed per interface.
Only one outbound distribute-list is allowed per interface.
Only one globally-defined inbound distribute-list is allowed.
Only one globally-defined outbound distribute-list is allowed.
Not all match clauses in a route-map are supported using RIP routes
filtering. These match clauses for distribute-lists are supported:
match ip address access-list
match ip address prefix-list
The distribute-list command does not enforce the
specified route-map to contain only supported match clauses.
Permit or deny can be specified in both prefix/access list and route-map
configurations. The following rules apply when filtering routes:
Routes permitted by the prefix/access lists are treated as
matched.
Matched routes are filtered based on the permit or deny option
configured for the route-map clause.
Unmatched routes are further evaluated by the next route-map
clause.
If a route does not match any clause in a route-map, it is
denied.
If the route-map given in the
distribute-list command is not
configured, then all routes are permitted.
When multiple inbound (or outbound) distribute-lists are
configured, only the most specific one is applied.
The no distribute-list and default distribute-list commands remove the corresponding distribute-list command from running-config.
DIRECTION direction specifies if distribute-list
is applied on inbound or outbound traffic. Valid options include:
in specifies inbound as the direction
the distribute-list is applied.
out specifies outbound as the
direction the distribute-list is applied.
MAP specifies route map that assigns attribute
values to the network. Options include:
no parameter attributes are not assigned through a route
map.
route-mapmap_name attributes listed by
specified route map are assigned to the network.
INTF interface to be configured. Options
include:
ethernet e_num Ethernet interface.
loopback l_num Loopback interface.
port-channelp_num Port channel interface.
vlanv_num VLAN interface.
Examples
The following commands demonstrate that an
access-list or
prefix-list can be used within a
route-map for use in a
distribute-list.
switch(config)# ip prefix-list 8to24 seq 5 permit 0.0.0.0/0 ge 8 le 24
switch(config)# route-map myRouteMap permit 10
switch(config-route-map-myRouteMap)# match ip address prefix-list 8to24
switch(config-route-map-myRouteMap)# exit
switch(config)#
switch(config)# router rip
switch(config-router-rip)# distribute-list in route-map myRouteMap
switch(config-router-rip)#
These commands suppress routes advertised on a particular interface.
switch(config)# ip prefix-list 2 seq 10 deny 30.1.1.0/24
switch(config)# route-map myRmOut permit 10
switch(config-route-map-myRmOut)# match ip address prefix-list 2
switch(config-route-map-myRouteMap)# exit
switch(config)# router rip
switch(config-router-rip)# distribute-list out route-map myRmOut
metric default
The metric default command specifies the metric value
assigned to RIP routes learned from other protocols. All routes imported into RIP
receive the default metric unless a matching route-map exists for the route. The
route metric of 0 is assigned to redistributed connected
and static routes. The default metric values range from 0
to 16 with a default value of
1.
The no metric default and default metric
default commands remove the metric
default command from running-config and returns
the metric value to its default value of 1.
Command Mode
Router-RIP Configuration
Command Syntax
metric defaultmetric_value
no metric default
default metric default
Parameter
metric_value default metric value assigned. Values
range from 0 to 16; default is
1.
The network command specifies which network the switch runs
Routing Information Protocol (RIP), and also specifies which routes will be accepted
into the RIP routing table. Multiple network commands can be issued to create a
network list on which RIP runs.
The switch enables RIP on all interfaces
in the specified network.
The no network and default network commands disable RIP on the specified network by removing the corresponding network command from running-config.
Command Mode
Router-RIP Configuration
Command Syntax
networkNETWORK_ADDRESS
no networkNETWORK_ADDRESS
default networkNETWORK_ADDRESS
Parameters
NETWORK_ADDRESS network IP address. Entry formats include
the following:
ipv4_subnet IPv4 subnet (CIDR notation).
ipv4_addrmaskwildcard_mask IP address and
wildcard-mask.
The redistribute command enables the importing of routes
from a specified routing domain to RIP.
connected by default, RIP redistributes all
connected routes that are established when IP is enabled on an interface.
The route-map parameter facilitates the exclusion of connected routes from
redistribution by specifying a route map that denies the excluded
routes.
BGP, OSPF, and
IP static routes by default, routes are
not redistributed. The redistribute command
without the route-map parameter facilitates the redistribution of all routes
from the specified source.
The no redistribute and default redistribute commands reset the default route redistribution setting by removing the redistribute statement from running-config.
Command Mode
Router-RIP Configuration
Command Syntax
redistribute connectedROUTE_MAP
redistribute ROUTE_TYPE [ROUTE_MAP]
no redistribute connected ROUTE_MAP
no redistributeROUTE_TYPE
default redistribute connectedROUTE_MAP
default redistributeROUTE_TYPE
Parameters
ROUTE_TYPE source from which routes are
redistributed. Options include:
BGP routes from a BGP domain.
OSPF routes from an OSPF domain.
OSPF match external routes external to
RIP, but imported from OSPF.
OSPF match internal OSPF routes that are
internal to the AS.
static IP static routes.
ROUTE_MAP route map that determines the routes
that are redistributed. Options include:
no parameter all routes are redistributed.
route-mapmap_name only routes in the specified
route map are redistributed.
The rip v2 multicast disable command specifies the
transmission of Routing Information Protocol (RIP) Version 2 update packets from the
configuration mode interface as broadcast to
255.255.255.255.
The no rip v2 multicast disable and default rip
v2 multicast disable commands specify the transmission of
update packets as multicast to 224.0.0.9 if the
configuration mode interface is multicast capable. Updates are broadcast if the
interface is not multicast capable.
Command Mode
Interface-Ethernet Configuration
Interface-Port-Channel Configuration
Interface-VLAN Configuration
Command Syntax
rip v2 multicast disable
no rip v2 multicast disable
default rip v2 multicast disable
Example
The following example configures version 2 broadcasting on interface
ethernet 5.
The router rip command places the switch in router-RIP
configuration mode to configure an RIP routing instance in the non-default VRF.
The no router rip vrf and default router rip
vrf commands disable an RIP routing instance in the
non-default VRF, and remove all user-entered router-rip
configuration statements from running-config. To disable RIP without
removing configuration statements, use the shutdown (RIP) command.
The exit command returns the switch to global configuration
mode.
Command Mode
Global Configuration
Command Syntax
router rip vrf [RIP_INSTANCE]
no router rip vrf [RIP_INSTANCE]
default router rip vrf [RIP_INSTANCE]
Parameter
RIP_INSTANCE configure a RIP VRF instance in the
non-default VRF.
Examples
This command configures a RIP instance in the non-default
VRF.
switch(config)# router rip vrf test
switch(config-router-rip-router-rip-vrf-test)# no shutdown
switch(config-router-rip)# exit
switch(config)#
This command disables a RIP instance in the non-default
VRF.
switch(config)# no router rip vrf test
switch(config)#
router rip
The router rip command places the switch in
router-rip configuration mode to configure the Routing
Information Protocol (RIP) routing process. Router-rip configuration mode is not a
group change mode; running-config is changed immediately upon command
entry. The exit command does not affect
running-config.
The no router rip and default router
rip commands disable RIP and remove all user-entered
router-rip configuration statements from running-config. To
disable RIP without removing configuration statements, use the shutdown
(RIP) command.
The exit command returns the switch to the
global configuration mode.
Command Mode
Global Configuration
Command Syntax
router rip
no router rip
default router rip
Commands Available in router-rip Configuration Mode
The show ip rip database command displays information about
routes in the Routing Information Base. The default command displays active routes
and learned routes not used in deference to higher priority routes from other
protocols.
This command has the following forms:
default (no arguments): information about all RIP routes.
IPv4 address and mask: information about the referenced
addresses.
active: information about routes not superseded by routes from other
protocols.
Command Mode
EXEC
Command Syntax
show ip rip database [FILTER]
Parameters
FILTER routing table entries that the command displays.
Values include :.
no parameter displays all routing table entries.
active displays all active routing table
entries.
net_addr subnet address (CIDR or
address-mask). Command displays entries in this subnet.
Examples
This command displays all active rip
routes.
switch> show ip rip database active
10.168.11.0/24 directly connected, Et4
10.168.13.0/24
[1] via 10.168.14.2, 00:00:25, Et4
[2] via 10.168.15.2, 00:00:20, Et1
10.168.13.0/24
[1] via 10.168.14.2, 00:00:25, Et3
This command submits a query for RIP route information for a
network.
switch> show ip rip database 10.168.13.0/16
10.168.13.0/24
[1] via 10.168.14.2, 00:00:25, Et4
[2] via 10.168.15.2, 00:00:20, Et1
This command returns information for all RIP
routes.
switch> show ip rip database
10.1.0.0/255.255.255.0
[1] via 10.8.31.15, 00:00:21, Et2, holddown
10.2.0.0/255.255.255.0
[1] via 10.8.31.15, 00:00:21, Et2, holddown
10.3.0.0/255.255.255.0
[1] via 10.8.31.15, 00:00:21, Et2, inactive
10.212.0.0/255.255.255.0
[1] via 10.8.31.15, 00:00:21, Et2, active
10.214.0.0/255.255.255.0
[1] via 10.8.12.17, 00:00:30, Et4, active
show ip rip neighbors
The show ip rip neighbors command displays information
about all RIP route gateways. The output displays the IPv4 address, the last heard
time of the gateway, and characteristic flags applying to the gateway.
Command Mode
EXEC
Command Syntax
show ip rip neighbors
Example
The show ip rip neighbors command displays information
about all gateways of RIP routes.
switch> show ip rip neighbors
Gateway Last-Heard Bad-Packets Bad-Routes Flags
10.2.12.33 00:00:15 SRC, TRSTED,
ACCPTED, RJCTED,
Q_RJCTED, AUTHFAIL
shutdown (RIP)
The shutdown command disables RIP on the switch without
modifying the RIP configuration. RIP is disabled by default.
The no shutdown command enables RIP. The
default shutdown command disables RIP.
switch(config-router-rip)# no shutdown
switch(config-router-rip)#
timers (RIP)
The timers command configures the update interval, the
expiration time, and the deletion time for routes received and sent through RIP. The
command requires value declaration of all values.
The update time is the interval between unsolicited route responses.
The expiration time is initialized when a route is established and any time
an update is received for the route.
The deletion time is initialized when the expiration time elapses and the
route is invalid. It is retained in the routing table until deletion time
expiry.
The no timers and default timers commands return the timer values to their default values by removing the timers command from running-config.
Command Mode
Router-RIP Configuration
Command Syntax
timers [update_time | expire_time
|deletion_time]
no timers
default timers
Parameters
update_time Default is
30 seconds.
expire_time Default is
180 seconds.
deletion_time Default is
120 seconds.
Parameter values are in seconds and range from 5 to
2147483647.
Example
This command sets the update (60 seconds), expiration
(90 seconds), and deletion
(150 seconds) times.
CloudVision eXchange (CVX) provides a single access point for real-time provisioning, orchestration and integration with third-party controllers. CVX aggregates and distributes operational state information across a set of EOS switches to support applications that provide network services. See the CloudVision User Guide for additional information.
Upgrade CVX from a previous version to the current version by performing a few simple tasks. You can use the following procedure to upgrade any previous version of CVX to the current version.
Requirements
Make sure you follow these requirements during the upgrade process.
If you have CVP, CVX and client switches in your environment, make sure you upgrade each component in the following order:
Upgrade CVP first.
Upgrade the CVX cluster.
Upgrade the client switches. The reason for this is to ensure backward compatibility.
You must upgrade the CVX cluster before you upgrade the client switches.
If you have a three node CVX cluster, ensure that only one node of the cluster goes down at any one time during the upgrade process. The order of upgrading the nodes does not matter.
Prerequisites
Before you begin the upgrade, ensure the following:
Perform a backup to ensure that you can restore data if needed.
Login to the cluster to be upgraded. You can login to any node.
Upgrade the node. You must deploy a new image to perform the upgrade.
Wait for the upgraded node to rejoin the cluster. Once the node rejoins, go to the next step. The node automatically rejoins the cluster as a follower node.
Repeat steps 1 through 3 to upgrade the two remaining nodes one node at a time. The order of upgrading the nodes does not matter.
CVX Overview
A CVX deployment includes CVX and a set of CVX clients that CVX provides services. CVX has no part in the data plane, nor does it receive data-path traffic. All CVX components exist as agents that run on EOS instances.
The configuration has certain hardware and software requirements for using CloudVision eXchange in your CloudVision virtual appliance implementation.
CloudVision eXchange should be installed on a single system along with CloudVision Portal.
The following table lists the minimum hardware and software required to use CloudVision eXchange.
Required Hardware
The hardware required to use the CloudVision eXchange consists of the following:
CPU - A minimum of 4 cores but 8 cores recommended.
RAM - A minimum of4G but 8G recommended.
Disk - 4G
Required Software
The software required to use the CloudVision eXchange:
EOS switches: Recommend 4.34.2 or later
Note: It is a best practice and highly recommended that the version of CVX should match the version running on the switches.
CloudVision Portal - version 2025.2
The configuration requires CloudVision Portal software if you want to use it with CloudVision eXchange. If you plan to use only CloudVision eXchange, no CloudVision Portal software required.)
Note: CVX supports live vMotion.
CVX Infrastructure
CVX provides a single integration point into network-wide services running across CVX clients. Typically deployed as an EOS instance running on a VM (vEOS). The CVX infrastructure consists of a CVX instance functioning as a server and a set of CVX clients. The CVX server uses a heartbeat keepalive (KA) mechanism to maintain contact with its clients.
When de-configuring or shutting down CVX, client services should be shut down first.
CVX Features
CVX manages communications among the network CVX clients, and provides an integration point for services to those clients. CVX also discovers the physical network topology by aggregating topology information it receives from its client devices.
CVX Clients
CVX client provides the agent that allows a switch to interact with a CVX server to access CVX services. Enabling the CVX client includes providing the IP address or host name of the device running CVX. The CVX client can then access services enabled on the CVX server.
The CVX client must be enabled to access the CVX server and the offered services. Individual services may require additional configuration statements.
Services should be shut down or removed from clients before shutting down or removing CVX. CVX features on the switch may continue to run after shutting down CVX if not explicitly shut down or removed prior to shutting down CVX.
CVX Services
CVX services consists of applications that run on top of the CVX infrastructure, and accessed by CVX clients through the CVX server. All CVX services maintain by version level, and client switches negotiate the version when connecting to the server. This allows multiple switches that run different EOS versions to connect to the same CVX server.
The following sections briefly describe some of the services available to CVX clients through CVX:
The OpenStack service on CVX allows the networking component of an OpenStack deployment. also called Neutron, to share state with CVX.
When deployed, this integration allows CVX to send state about the logical networks created in the OpenStack cloud to the CVX clients that configure the network.
More information on OpenStack software can be found in its online documentation at http://docs.openstack.org/. .
VXLAN Control Service
The VXLAN control service allows hardware VXLAN Tunnel End Points (VTEPs) to share state with each other in order to establish VXLAN tunnels without the need for a multicast control plane. Requires configuration on the client switches and in CVX.
Hardware Switch Controller (HSC) Service
Traffic between virtual machines which share a physical host (or between virtual machines and the rest of the network) is forwarded by virtual switches. The management and configuration of virtual switches uses the Open VSwitch DataBase (OVSDB) management protocol, as described in RFC 7047.
The Hardware Switch Controller (HSC) service provides an integration point between OVSDB controllers and the VXLAN control service, allowing exchange of state information among virtual and hardware switches.
Network Topology Service
The network topology service gathers information from CVX clients to provide a view of the physical topology of the network. Aggregated information gathered by the network topology service is used by other CVX services, and can be viewed on the CVX server.
Static Topology Service
Static Topology addresses cases where the deployment infrastructure in an OpenStack setup that manages Virtual Machines and Bare Metal servers does not enable LLDP on interfaces connecting hosts to switches. As a result, the topology information does not appear on CVX.
An example of this case is some deployments of OpenStack that do not enable LLDP for DPDK interfaces. Even with the manual configuration of LLDP on hypervisors, the configuration does not persist after OpenStack redeployment.
Static Topology enables the topology configuration statically using the service topology command on CVX without running LLDP on the servers connected to switches.
To view the aggregated topology information, use the show network physical-topology command on the switch running the CVX server instance.
Deploying CVX
CloudVision Exchange (CVX) can be deployed on KVM and ESXi. The required EOS version and Aboot version vary depending on whether you are deploying CVX on KVM or ESXi.
Deploying CVX on Kernel-based Virtual Machine (KVM)
Complete the following steps to install CVX on Ubuntu/KVM. Once the installation is complete, you can begin the CVX configuration process.
Note: Ensure you select versions of EOS and Aboot that meet the minimum requirements for CVX. EOS supports the following versions:
EOS (version 4.34.2 or later).
Aboot-veos-serial-8.0.2.iso (located in the vEOS section of the download).
Pre-requisites
Before you begin the procedure, make sure that:
Install qemu-kvm, libvirt*, and all related dependencies using yum (RHEL7/CentOS7) and apt-get (Ubuntu).
Two bridges are configured for use by the KVM VM, and that you have the names of the bridges. The configuration includes the procedure to add bridges, if not already configured.
Note: The bridges must be configured to persistas brctl commands do not persist across reboots. You can use Network Manager or another application available to you to complete this configuration.
You have both the generateXmlForKvm.py and cvpTemplate.xml required to complete the procedure. You can find them in the CVP tarball for Ubuntu.
Use the following command to convert the vmdk file to qcow2: qemu-img convert EOS_4_34_8M.vmdk -O qcow2
EOS.qcow2.
Note: Step 6 and 7 are required if you do not already have 2 bridges defined in different subnets. If the bridges exist, go directly to step 8.
Use brctl to add bridges for the KVM VM to use (br1 and br2 can be any names you choose).
brctl addbr br1
brctl addbr br2
ifconfig can be used to identify Ethernet ports to be bridged. Once you identify the ports, add them to the bridges.
Example
brctl addif br1
enx803f5d086eae
Confirm that the bridges are up using brctl show.
Enter: ifconfig br1 up
And: ifconfig br2 up
Note: The following step uses a number of input parameters depending on the server setup. To ensure the command executes successfully, Arista recommends that you type it into a scratch pad and edit as needed before typing it into the Linux Terminal.
Use the following command to generate cvx.xml used to setup the CVX VM.
generateXmlForKvm.py
Example
python generateXmlForKvm.py -n cvx --device-bridge br1 --cluster-bridge br2 -e /usr/bin/kvm -i cvpTemplate.xml -c /home/myname/Downloads/Aboot-veos-serial-8.0.0.iso -x /home/myname/Downloads/EOS.qcow2 -b 8192 -p 2 -t
-n cvx: VM name.
--device-bridge br1: This is the name you gave the bridge - br1 or anything else.
--cluster-bridge br2: Cluster bridge if clustering servers.
-i cvpTemplate.xml: Path to XML file input template.
-k: VM ID number used by virsh. If not entered, a random number is assigned.
-b 8192: 8G of RAM.
-p 2: # of CPU cores.
-c: Path to Aboot file.
-x: Path to qcow2 file created in step 3.
-t: This parameter indicates the file defined by -x is for CVX.
-e ‘/usr/bin/kvm: Ubuntu path to KVM.
(for RHEL KVM this is: -e ‘usr/libexec/qemu-kvm)
-o: XML file used by virsh to define the KVM VM.
From the software download page, expand Active Releases > 4.34 > EOS-4.34.2F to download EOS-4.34.2F.ova.
Load the files you downloaded into a filestore location within the VMware vSphere environment.
Figure 1. Loading the Files into the VMware vSphere Environment
Right-click the filestore location you selected, and choose New Virtual Machine.
Figure 2. Selecting New Virtual Machine
The New Virtual Machine dialog appears.
Figure 3. New Virtual Machine Dialog
In the New Virtual Machine dialog, select Create a new virtual machine, then click Next.
The dialog refreshes and displaysdatasttore2 options for the new Virtual Machine.
Figure 4. Naming and Selecting the Location
The dialog refreshes and displays datastore options to select the datastore.
Enter a name for the new Virtual Machine.
Select a location for the new Virtual Machine, then click Next.
Figure 5. Selecting the Datastore
Select the datastore for the new Virtual Machine configuration files and all of the virtual disks. Click Next. The dialog refreshes anddisplays operating system selection options.
Click Next. The dialog refreshes and displays compatibility options.
Figure 6. Compatibility Options
Using the Compatible with menu, select the ESXi compatibility for the new Virtual Machine.
Note: When adding the VMDK to ESX6, it treats this as sparse by default, whereas in ESX 5 it is thick. Converting the vEOS VMDK file from thin to thick would allow it to boot properly in ESX6: vmkfstools -i vEOS-lab-4.18.5M.vmdk -d eagerzeroedthick vEOS-lab-4.18.5M-thick.vmdk.
Note: If the VM keeps rebooting and displaying the message, "This is not a bootable disk. Insert a bootable floppy and press any key to try again", then go to https://arista.my.site.com/AristaCommunity/s/ and refer to the Common Issues When Deploying CVX 4.18.2F on vCenter 6 or 6.5 topic.
Click Next. The dialog refreshes, showing operating system selection options.
Figure 7. New Virtual Machine Dialog (Operating System Options)
Using the Guest OS Family menu, choose Linux.
Using the Guest OS Version menu, choose Other Linux (64-Âbit).
Click Next.
The dialog refreshes, showing options for customizing hardware.
Figure 8. New Virtual Machine Dialog (Hardware Configuration Options)
Change the default settings for the following options:
CPU
Set to 4 (number of CPUs)
Memory
Set to 8 GB
New Hard Disk
Delete the current setting (leave this option empty).
New Network
Specify connection to Network LAN segment with connectivity to CVX client devices (the Management LAN). Choose VMXNET3 network adapter type. This connection is used for CVX client / server communications.
Existing Hard Disk
Specify the EOS-4.21.0F.vmdk you downloaded in step 3.
(Optional) Delete the floppy drive and SCSI controller.
Click Next. You are now ready to begin the CVX configuration (see CVX Configuration).
CVX Configuration
CVX, its clients, and its services, are independently configured. These sections describe configuration processes for each:
CVX cluster peer out-of-band connection: Port 50004.
Note: All of these connections are TCP.
CVX Server Configuration
Enabling CVX on the CVX Server
CVX parameters for the server infrastructure are configured in CVX configuration mode. CVX configuration mode is not a group-change mode; running-config is changed when commands are entered, and exiting the mode does not modify running-config. The cvx command places the switch in CVX configuration mode.
CVX is disabled by default. The no shutdown (CVX) command enables CVX on the switch.
Example
These commands enter CVX-configuration mode and enable CVX.
switch(config)# cvx
switch(config-cvx)# no shutdown
switch(config-cvx)#
CVX Heartbeat Configuration
CVX synchronizes with its client devices by exchanging heartbeat signals. The heartbeat transmission frequency and timeout period determine when a client's access to the server is disrupted.
The interval between heartbeat messages that the server transmits is specified by the heartbeat-interval (CVX) command. The CVX timeout period is specified by the heartbeat-timeout (CVX) command. When CVX does not receive a subsequent heartbeat message from a CVX client before the timeout expiry, the server discontinues CVX services to that client.
Best practices dictate that CVX and its client applications configure identical heartbeat interval and heartbeat timeout values.
Example
These commands configure a CVX heartbeat interval of 30 seconds and a server heartbeat timeout period of 90 seconds.
Note: Before disabling or de-configuring CVX on the CVX server, CVX client services should be explicitly disabled or shut down. Failure to disable or de-configure services prior to disabling or de-configuring CVS may result in CVX features continuing to run after CVX shutdown.
When disabling the CVX service, service VXLAN configuration may be retained or erased. Be sure to disable or shut down client services prior to disabling the CVX service.
Examples
These commands shut down the CVX service while retaining the CLI configuration for service VXLAN.
localhost(config)# cvx
localhost(config-cvx)# service VXLAN
localhost(config-cvx-VXLAN)# shutdown
These commands shut down the CVX service and also erase service VXLAN CLI configuration.
localhost(config-cvx-VXLAN)#
localhost(config)# cvx
localhost(config-cvx)# no service VXLAN
CVX Client Configuration
This section describes the CVX client configuration and commands that enable CVX services. Most commands for the configuration of the CVX client infrastructure are accessed in Management-CVX configuration mode.
Enabling CVX on the CVX Client
CVX client parameters are configured in Management-CVX configuration mode. Management-CVX configuration mode is not a group-change mode; running-config is changed when commands are entered, and exiting the mode does not modify running-config. The management cvx command places the switch in Management-CVX configuration mode.
CVX client is disabled by default. The no shutdown (Management-CVX) command enables CVX client on the switch.
For the CVX network topology service to create an inventory of all CVX clients, ensure that LLDP is enabled on each client switch using the lldp run command.
Example
These commands enter Management-CVX-configuration mode and enable the CVX client.
switch(config)# lldp run
switch(config)# management cvx
switch(config-mgmt-cvx)# no shutdown
switch(config-mgmt-cvx)#
CVX Client Heartbeat Configuration
A CVX client synchronizes and maintains contact with CVX by exchanging heartbeat signals. The heartbeat transmission frequency and timeout period define when communication with CVX will be considered down.
The interval between heartbeat messages that the CVX client transmits is configured by the heartbeat-interval (Management-CVX) command.
The CVX client timeout period is specified by the heartbeat-timeout (Management-CVX) command. When a CVX client does not receive a subsequent heartbeat message from CVX within this timeout period, the client assumes that services provided by CVX are no longer available.
Best practices dictate that a CVX client's heartbeat interval and heartbeat timeout values are identical to those of the CVX server to which it connects.
Example
This command configures a CVX client heartbeat interval of 30 seconds and client timeout period of 90 seconds.
The server host (Management-CVX) command identifies the location of the CVX server that the client accesses. The source-interface (Management-CVX) command specifies the interface from which the client derives the IP address it uses as the source in CVX packets that it transmits. And the no shutdown (Management-CVX) command enables CVX on the client switch.
Example
These commands configure the switch as a CVX client, connecting to a CVX server at IP address 10.1.1.14 and using IP address 10.24.24.1 as the source address for its outbound packets.
switch(config)# interface loopback 5
switch(config-if-Lo5)# ip address 10.24.24.1/24
switch(config-if-Lo5)# management cvx
switch(config-mgmt-cvx)# server host 10.1.1.14
switch(config-mgmt-cvx)# source-interface loopback 5
switch(config-mgmt-cvx)# no shutdown
switch(config-mgmt-cvx)#
CVX Client Services Configuration
Switches running EOS must be configured as CVX clients to access the network services running on CVX. Individual services may require additional configuration.
Refer to the following for information regarding the services available to a CVX client.
The OpenStack service is enabled from CVX-OpenStack configuration mode, which is accessed by the service openstack command. The no shutdown (CVX-OpenStack) command enables CVX OpenStack services on the CVX server. Additional configuration is necessary to deploy OpenStack (http://docs.openstack.org/).
Example
These commands enable the CVX-OpenStack service.
switch(config-cvx)# service openstack
switch(config-cvx-openstack)# no shutdown
switch(config-cvx-openstack)#
Configuring VXLAN Control Service
The VXLAN control service is enabled on CVX by the no shutdown (CVX-VXLAN) command and on the client switches by enabling CVX and configuring the VXLAN as a controller client. When VXLAN control service is enabled, CVX functions as a VXLAN controller for its clients.
For information about configuring VXLAN on the client switch, see the VXLAN chapter of the User Manual .
Examples
These commands enable VXLAN control service on the CVX server.
switch(config-cvx)# service VXLAN
switch(config-cvx-VXLAN)# no shutdown
switch(config-cvx-VXLAN)#
These commands enable VXLAN Control Service on the CVX client. (This example assumes that the VXLAN has already been configured on the client switch. For information about configuring VXLAN, see the VXLAN chapter of the User Manual).
Configuring Hardware Switch Controller Service (HSC)
Certificate Requirements for CVX Interoperability with VMware NSX 6.2.2 and Higher
The HSC service is enabled on the CVX server by the no shutdown (CVX-HSC) command.
The certificate type needs to be changed from MD5 to SHA512 for use with VMware NSX 6.2.2. Complete the following steps to make the change.
At the EOS prompt of CVX, use the following commands.
switch(config)# cvx
switch(config-cvx)# service hsc
switch(config-cvx-hsc)# shut
Acquire superuser privileges and edit the default.
switch(config)# bash
switch(config)# sudo su
switch(config)# vi /usr/bin/ovs-pki
Find and replace default_md with sha512 (from md5).
default_md =md5
default_md =sha512
Delete all files and folders from /persist/secure/openvswitch/.
cd /persist/secure/openvswitch/bash-4.1#sudo rm -r *
Generate the new certificate.
[admin@CVX ~]$ exit
logout
CVX(config-cvx-hsc)# no shutdown
CVX(config-cvx-hsc)# end
Verify the change using the command.
CVX# show nsx status
Example
These commands enable the CVX-HSC service.
switch(config)# cvx
switch(config-cvx)# no shutdown
switch(config-cvx)# service hsc
switch(config-cvx-hsc)# no shutdown
The HSC service sends flood lists to each VTEP through CVX. Some controllers (such as VMware NSX's Service Nodes) implement replication nodes for head-end replication of unknown packets. For these controllers, BUM packets should be sent to a single replication node (send-to-any replication), and the flood list sent by the HSC service is a list of replication nodes. Other controllers (such as Nuage VSP) require each VTEP to perform its own head-end replication. For these, BUM packets should be sent to every known VTEP, and the flood list sent by the HSC service is the list of VTEPs.
The default behavior is to use a send-to-any replication list of VTEPs. If the required behavior is send-to-all replication of, use the all option of the VTEP (CVX-HSC) command.
Example
This command configures the CVX-HSC service to connect to an OVSDB controller at IP address 192.168.2.5, using the default port 6632.
This command configures the CVX-HSC service to use send-to-any replication.
switch(config-cvx-hsc)# vtep flood list type all
switch(config-cvx-hsc)#
Having established a connection to the OVSDB controller, the HSC service will publish the inventory of switches managed by CVX to OVSDB. For the inventory to succeed, LLDP must be enabled on each CVX client switch with the lldp run command.
Note: HSC also makes use of the VXLAN control service; ensure that VXLAN control service is enabled and properly configured (see VXLAN Control Service for details).
Note: LLDP is enabled by default on Arista switches.
Example
This command enables LLDP.
switch(config)# lldp run
switch(config)#
Configuring Network Topology Service
A network topology agent runs on each Arista switch whether or not the switch is connected to a CVX server. It requires no configuration. The network topology service on the CVX server is also enabled by default and requires no configuration.
To view the aggregated topology information, use the show network physical-topology command on the switch running the CVX server instance.
Use the service topology command to configure the topology statically on CVX without running LLDP on the servers connected to switches. It is configured under CVX configuration mode.
Example
The following command configures topology statically on the switch.
switch# config
switch(config)# cvx
switch(config-cvx)# service topology
The topology information can be specified using the following command:
The format of the hostname in this command could depend on services running on the host. As an example, in OpenStack use cases, it should match the hostname used by OpenStack services, the neutron server and agent in an FQDN format. The hostname in the command is case sensitive.
Optional Parameter
The neighbor interface is an optional parameter in the configuration however setting it helps to understand the physical network connectivity between switches and hosts. It also helps in troubleshooting any issue that may arise in the network.
Limitations
To avoid misconfiguration in a topology consisting of a switch with a connected host, where LLDP is enabled and static topology is used to configure the physical topology it is recommended to use only one source of configuration, not both. As a mismatch in the configuration can cause wrong configuration on the switch by a feature consuming the topology information.
CVX Secure out-of-band Connection
This feature adds support for securing out-of-band connection between CVX server and CVX clients by SSL/TLS transport protocol. SSL/TLS is an application-layer protocol that provides secure transport between client and server through a combination of authentication, encryption and data integrity. SSL/TLS uses certificates and private-public key pairs to provide this security. We will use the term SSL to mean SSL/TLS.
By default, CVX server and CVX clients communicate over insecure transport (there is no authentication and encryption between CVX server and CVX clients). This poses the possibility of security risks, such as communicating with untrusted CVX server and CVX clients, or eavesdropping CVX server/client communications. This feature can be used to secure the out-of-band connection between CVX server and CVX clients.
Note: The CVX client-server out-of-band connection uses port 50003. The CVX cluster peer out-of-band connection uses port 50004. These are TCP ports.
This feature uses SSL certificate and key management infrastructure for managing certificates, keys and SSL profiles. For more information regarding this infrastructure see SSL Certificate and Key Management in the Arista User's Guide.
On CVX server, copy the server certificate and key and also the CA certificate to verify CVX clients.
switch(config)# !Copy the PEM encoded certificate and RSA key files for CVX server
switch(config)# !Lets call them server.crt and server.key
switch(config)# copy <url> certificate:server.crt
switch(config)# copy <url> sslkey:server.key
switch(config)# !Copy the PEM encoded CA certificate to verify the certificate of CVX clients.Lets call it ca.crt
switch(config)# copy <url> certificate:ca.crt
On CVX server, configure SSL profile with the certificates and key as below. Lets call the SSL profile as serverssl.
Note: If you are using intermediate certificates to build a 'Chain of Trust' (such as server.crt -> intermediate1.crt -> intermediate2.crt -> ca.crt), then you need to configure the intermediate certificates as part of the SSL profile using the following commands:
On CVX server, configure to use the serverssl SSL profile. With this configuration, the CVX server starts listening on a secure port. The CVX server will continue to listen on the default port. i.e., the CVX server will accept connections from CVX clients over both SSL and default non-SSL transports. During a SSL negotiation, the CVX server will authenticate itself to the CVX clients by presenting server.crt and it verifies the authenticity of the CVX client by checking if the CVX client certificate is signed by the trusted certificate ca.crt.
On CVX client, copy the client certificate and key and also the CA certificate to verify CVX server.
switch(config)# !Copy PEM encoded certificate and RSA key files for CVX client
switch(config)# !Lets call them client.crt and client.key
switch(config)# copy <url> certificate:client.crt
switch(config)# copy <url> sslkey:client.key
switch(config)# !Copy PEM encoded CA certificate used to verify the
switch(config)# !certificate of CVX server. Lets call it ca.crt
switch(config)# copy <url> certificate:ca.crt
Note: If you are using intermediate certificates to build a 'Chain of Trust' (such as client.crt -> intermediate1.crt -> intermediate2.crt -> ca.crt), then you need to configure the intermediate certificates as part of the SSL profile using the following commands:
On CVX client, configure to use the SSL profile clientssl. With this configuration, the CVX client will connect to the secure port of the CVX server over SSL transport. During SSL negotiation, the CVX client will authenticate itself to the CVX server by presenting client.crt and it verifies the authenticity of the CVX server by checking if the CVX server certificate is signed by the trusted certificate ca.crt.
For information regarding show commands of SSL certificate, key and profile, please refer to SSL Certificate and Key Management.
To show the SSL profile status on CVX server, use the show cvx command.
switch# show cvx
CVX Server
Status: Enabled
UUID: beb19142-dfaa-11e4-b996-001c73105347
Heartbeat interval: 20.0
Heartbeat timeout: 60.0
SSL profile: serverssl
Status: Enabled
The Enabled SSL status means that the SSL profile is enabled for CVX server and the CVX clients can connect to CVX server over SSL transport. If there are any errors, then the status will show Disabled and the reason will be listed. In Disabled state, the CVX clients wont be able to connect to CVX server over SSL transport.
To show the SSL connection status of CVX clients on CVX server, use the show cvx connections command.
switch# show cvx connections
Switch 00:1c:73:10:53:48
Hostname: sq302
Status: up
Last heartbeat sent: 0:00:04 ago
Last heartbeat received: 0:00:10 ago
Clock offset: -0.00201620385865
Out-of-band connection: SSL secured
In-band connection: Not secured (SSL not supported)
The out-of-band connection shows as SSL secured, which means that the CVX client has connected to CVX server over SSL transport. The in-band connection is another connection between CVX server and CVX client. The SSL is not yet supported for this connection and hence it shows as SSL not supported. There is already some level of protection for the in-band connection. The CVX server and CVX client opens up the access to in-band connection only if the out-of-band connection is successful. Since the out-of-band connection is configured to use SSL, the in-band connection access is granted only for authentic CVX client and CVX server.
To show SSL profile status and connection status on CVX client, use the show management cvx command.
switch# show management cvx
CVX Client
Status: Enabled
Last connected time: 2015-04-14 11:16:19
Connection status: Connected
Out-of-band connection: SSL secured
In-band connection: Not secured (SSL not supported)
Negotiated version: 2
Controller UUID: 0e7dee2e-e2cf-11e4-880f-001c73105347
Controller: 127.0.0.1
Last heartbeat sent: 0:00:00 ago
Last heartbeat received: never
Clock offset: 0.0
SSL profile: clientssl
Status: Enabled
The Enabled SSL status means that the SSL profile is enabled and the CVX client can connect to CVX server over SSL transport. If there are any errors, then the status will show as Disabled and the reason will be listed. In Disabled state, the CVX client wont be able to connect to the CVX server.
Similar to the CVX server, the out-of-band connection shows as SSL secured and the SSL is not yet supported for in-band connection.
The possible reasons for Disabled SSL status on CVX server and CVX client are:
SSL profile does not exist: If the SSL profile configured under CVX server/client is not configured under management security, you will see this message. Configure the SSL profile with required certificates and key under management security.
Invalid SSL profile: If the SSL profile configured under CVX server/client is in invalid state, you will see this message. Check show management security ssl profile <name> command to see the errors on the SSL profile and fix them.
Trusted certificates not configured in SSL profile: If the SSL profile configured under CVX server/client does not have trusted certificates configured, you will see this message. Configure trusted CA certificates in the SSL profile.
Certificate not configured in SSL profile: If the SSL profile configured under CVX server/client does not have certificate key pair configured, you will see this message. Please configure certificate and key pair in the SSL profile.
Diffie-Hellman parameters not yet ready: When EOS is booted, a Diffie-Hellman parameters file is auto generated by the system if one does not exist. This Diffie-Hellman parameters file is used for symmetric key exchange during SSL negotiation. Only the CVX server uses this file and hence this message can be seen only on show cvx command output. If the file is not yet generated, you will see this message. When the file is ready, this message automatically goes away and the SSL profile will become enabled.
CVX High Availability
CVX provides high availability by enabling you to use multiple (redundant) CVX Controllers in the same cluster. Each Controller in the cluster has its own dedicated machine so that if a Controller fails, the failure is isolated to a single machine.
Within a cluster, one of the Controllers is a primary (leader), and the other Controllers are backup (follower) Controllers. If the primary Controller fails, one of the backup Controllers automatically assumes the role of the primary Controller.
CVX high availability does not prevent or compromise the detection of software failures or link failures that may cause Controllers to be unreachable on the network.
The configuration that is required to ensure CVX is set up for high availability involves:
CVX clusters are sets of CVX Controllers (usually 3 Controllers). Within a cluster, each Controller runs on its own dedicated machine, and all of the Controllers run the same version of CVX. Each Controller in the cluster functions as either the primary (leader) Controller, or a backup (follower) Controller.
One of the CVX Controllers is elected by the group of Controllers to be the primary Controller. Once a Controller is elected to be the primary, the other Controllers in the cluster are automatically assigned the role of backup Controllers. Cluster members maintain an out-of-band connection amongst themselves, which is used for the leader election protocol.
CVX Controllers in a cluster that are not the primary Controller always function as backup Controllers. Within the same cluster, only one CVX Controller can assume the role of a primary at any time.
Required Number of Controllers to Support High Availability
A cluster must have enough Controllers so that in the case of a failure of the primary Controller, there are enough remaining Controllers for the election process to be completed. The election process is used by clusters to select a new primary Controller in the case of failure.
Note: The number of Controllers for a cluster is 3 (one primary and two backup Controllers).
Examples
In a cluster with only two Controllers (one primary and one backup), a simple majority of backup Controllers does not exist after a failure of the primary Controller. A simple majority of two backup Controllers is required for the leader election process.
Cluster Configuration Options
You can configure the cluster for high availability using either of the following modes:
Cold followers mode - Only the Controllerdb of the primary (leader) CVX Controller mounts from the client switches.
Warm followers mode - The Controllerdb of every (all) CVX Controllers in the cluster mount from the client switches.
Advantages and Disadvantages of the Modes
The advantage of the warm follower mode is that if the primary CVX Controller fails, the switchover to the new primary is faster than a switchover in cold follower mode. The reason for this is that the state of the new primary does not have to be rebuilt from scratch. The disadvantage of the warm follower mode is that serialization from the switch is slower compared to cold follower mode.
Handling of CVX Controller Failures
CVX Controllers can fail because of hardware or software faults. Because EOS agents are designed to be software fault-tolerant, an agent that fails is automatically restarted and resumes operation statefully. The most recent saved state in Sysdb for the agent is used to restore the state of the agent.
Unlike software failures, hardware failures are not handled by EOS. CVX handles hardware failures through the use of redundant backup (follower) CVX Controllers that run on their own dedicated machine. Within a cluster, any backup Controller can assume the role of the primary (leader) Controller.
Note: In the event of a network partition, the partition with a majority of the Controllers elects a leader from its Controllers, and the minority partition relinquishes any leadership it might have had.
CVX Support for EOS Failure Modes
CVX supports both EOS failure modes that apply when a CVX Controller fails. The EOS failure modes are:
Fail-stop
Fail-recover
Because CVX supports both EOS failure modes, a failed CVX Controller can rejoin the cluster if the following failures occur:
A crash of the agent or machine running CVX.
The CVX controller or dedicated machine it runs on is removed (partitioned) from the cluster.
Client Interaction
Client switches maintain an out-of-band connection to all members of the cluster. The connection is used to determine liveness and for communications. The connection is also used to signal a change in leadership (switchover) to the client switches. Switchovers that are changes in leadership within a cluster are executed similarly to CVX Graceful Reboot switchovers.
The ControllerClient agent on the switch is responsible for maintaining liveness with the Controllers and for exchanging metadata. The ControllerClient agent registers with all cluster members. Each Controller's ControllerStatus has an additional flag to record whether the Controller is a leader within the cluster.
If there is more than one leader, the switch automatically waits until only one Controller is designated as the leader in the cluster. Once a single Controller is designated as the leader, the switch executes a graceful switchover to the new leader Controller.
Service Agents Interaction
One change to Service Agents is required to support CVX high availability. Service Agents must be modified to include the leader flag (this flag identifies the leader CVX Controller in the cluster). On a leader switchover, Service Agents are deactivated on the old leader Controller and activated on the new leader Controller. The client switches will perform a graceful switchover to the new leader Controller.
Leader Election
Leader election is an internal, system-run process that is essential to CVX high availability. The leader election process is used to safely elect a new leader Controller within a cluster following the failure of the current leader Controller, or a network configuration change that results in the loss of the current leader Controller in the cluster.
The leader election process is designed to ensure stability of leader Controllers within clusters. The process is based on an algorithm that provides the mechanism for the backup (follower) Controllers to elect (by consensus), the new leader Controller in the cluster.
Configuring CVX Clusters for High Availability
Configuring CVX clusters for high availability is a simple process that involves pointing each cluster member to the other cluster members using the peer host command. The objective of this task is to successfully register each cluster member with the other cluster members. Successful registration of the cluster members with each other ensures that the members can communicate with each other to elect a new leader member if the original leader member fails.
Once you complete the process, the cluster members will be successfully registered with each other. In addition, the cluster members will automatically elect a leader member and assign the leader to that member. The non-leader members are automatically assigned the role of follower.
Requirements
The requirements for setting up clusters for high availability are:
The number of CVX Controllers in a cluster is 3.
An odd number of CVX instances (CVX Controllers) are required to form a cluster.
Note: If an even number of CVX Controllers are configured in a cluster, a CVX instance will automatically refuse to participate in the cluster.
All cluster members must point to each other. This is essential for clusters to operate normally. (The steps required to complete this task are included in the following procedure.)
Procedure
Note: This procedure provides configuration examples for each step. The example cluster used throughout the procedure contains 3 cluster members (named cvs1, cvs2, and cvs3). The IP addresses of the cluster members are:
cvs1 (10.0.0.1)
cvs2 (10.0.0.2)
cvs3 (10.0.0.3).
Complete the following steps to configure clusters for high availability.
Using the peer host command, configure one of the cluster members to point to every other cluster member. This example shows the configuration of cluster member cvs1 to point to the other cluster members (cvs2 and cvs3).
cvs1(config-cvx)# peer host 10.0.0.2 (connects cvs1 to cvs2)
cvs1(config-cvx)# peer host 10.0.0.3 (connects cvs1 to cvs3)
Use the show cvx command to check the Mode and Peer registration state status values for cluster member cvs1. The status values should be:
Mode = Cluster
Peer registration state = Connecting
Note:Mode automatically changes from Standalone to Cluster when configuring a CVX cluster. This is because the presence of multiple CVX peers causes the Mode to change to Cluster. Peer registration state remains in Connecting status after you configure the first cluster member. This is because the two peers must register with each other for the registration of the two members to be successful.
Using the peer host command, configure peer cluster member cvs2 to point to every other cluster member. This example shows the configuration of cluster member cvs2 to point to the other cluster members (cvs1 and cvs3).
cvs2(config-cvx)# peer host 10.0.0.1 (connects cvs2 to cvs1)
cvs2(config-cvx)# peer host 10.0.0.3 (connects cvs2 to cvs3)
Use the show cvx command to check the Peer registration state settings for cvs1. This is done to verify that peers cvs1 and cvs2 are successfully registered with each other.
cvs1(config-cvx)# show cvx
Example
This example shows the output of the show cvx command for cvs1. The Peer registration state setting of Registration Complete for peer cvs2 indicates a successful registration between cvs1 and cvs2.
cvs1(config-cvx)# show cvx
CVX Server
Status: Enabled
UUID: 6c208fba-7324-11e5-8fef-1d98cdd3b27a
Mode: Cluster
Heartbeat interval: 20.0
Heartbeat timeout: 60.0
Cluster Status
Name: default
Role: Standby
Leader: 10.0.0.2
Peer timeout: 10.0
Last leader switchover timestamp: 0:00:03 ago
Peer Status for 10.0.0.3
Peer registration state: Connecting
Peer service version compatibility : Version mismatch
Peer Status for 10.0.0.2
Peer Id : 02-01-63-02-00-00
Peer registration state: Registration complete
Peer service version compatibility : Version ok
Using the peer host command, configure peer cluster member cvs3 to point to every other cluster member. This example shows the configuration of cluster member cvs3 to point to the other cluster members (cvs1 and cvs2).
cvs3(config-cvx)# peer host 10.0.0.1 (connects cvs3 to cvs1)
cvs3(config-cvx)# peer host 10.0.0.2 (connects cvs3 to cvs2)
Use the show cvx command to check the Peer registration state settings for cvs1. This is done to verify that peers cvs1 and cvs3 are successfully registered with each other.
cvs1(config-cvx)# show cvx
Example
This example shows the output of the show cvx command for cvs1. The Peer registration state setting of Registration Complete for peer cvs3indicates a successful registration betweencvs1 and cvs3.
cvs1(config-cvx)# show cvx
CVX Server
Status: Enabled
UUID: 6c208fba-7324-11e5-8fef-1d98cdd3b27a
Mode: Cluster
Heartbeat interval: 20.0
Heartbeat timeout: 60.0
Cluster Status
Name: default
Role: Standby
Leader: 10.0.0.2
Peer timeout: 10.0
Last leader switchover timestamp: 0:05:37 ago
Peer Status for 10.0.0.3
Peer Id : 02-01-63-03-00-00
Peer registration state: Registration complete
Peer service version compatibility : Version ok
Peer Status for 10.0.0.2
Peer Id : 02-01-63-02-00-00
Peer registration state: Registration complete
Peer service version compatibility : Version ok
Configuring CVX clients for high availability is a simple process that involves pointing each CVX client to every CVX cluster member using the server host command. The objective of this task is to successfully establish connections between each CVX client and every CVX cluster member. The connections are essential to ensure that the CVX clients are aware of the current status of each cluster member.
Note: If a CVX client is not pointing to every cluster member, or if it is pointing to a CVX instance (Controller) that is not part of the cluster, the client may not be aware of leadership changes in the cluster, or may become confused about which cluster member is currently the leader. Either of these scenarios can result in unexpected errors.
Once you complete the process, the CVX clients will have established connections with each cluster member (the Connection status for each Controller should be Established). In addition, the clients will be aware of which CVX instance (Controller) is currently the leader in the cluster.
Procedure
Note: This procedure provides configuration examples for each step. The example CVX client used throughout the procedure is named cvc1. The IP addresses of the cluster members are: 10.0.0.1 (cvs1), 10.0.0.2 (cvs2), and 10.0.0.3 (cvs3).
Complete the following steps to configure CVX clients for high availability.
Using the server host command, configure each of the CVX clients to point to every cluster member. This example shows the configuration of client cvc1 to point to all of the cluster members (the addresses of the cluster members are 10.0.0.1, 10.0.0.2, and 10.0.0.3).
cvc1(config-mgmt-cvx)# server host 10.0.0.1 (connects cvc1 to cluster member 10.0.0.1)
cvc1(config-mgmt-cvx)# server host 10.0.0.2 (connects cvc1 to cluster member 10.0.0.2)
cvc1(config-mgmt-cvx)# server host 10.0.0.3 (connects cvc1 to cluster member 10.0.0.3)
Use the show man cvx command to check the status of client cvc1. The Connection status for each cluster member should be Established. In addition, the client is also aware that cluster member 10.0.0.3 is the current Master.
cvc1(config-mgmt-cvx)# show man cvx
CVX Client
Status: Enabled
Source interface: Inactive (Not configured)
Controller cluster name: default
Controller status for 10.0.0.1
Connection status: established
Out-of-band connection: Not secured
In-band connection: Not secured (SSL not supported)
Negotiated version: 2
Controller UUID: 6c208fba-7324-11e5-8fef-1d98cdd3b27a
Last heartbeat sent: 0:00:07 ago
Last heartbeat received: 0:00:07 ago
Controller status for 10.0.0.3
Master since 0:03:34 ago
Connection status: established
Out-of-band connection: Not secured
In-band connection: Not secured (SSL not supported)
Negotiated version: 2
Controller UUID: c64954b8-7324-11e5-9f33-51f8b016cae8
Last heartbeat sent: 0:00:14 ago
Last heartbeat received: 0:00:14 ago
Controller status for 10.0.0.2
Connection status: established
Out-of-band connection: Not secured
In-band connection: Not secured (SSL not supported)
Negotiated version: 2
Controller UUID: 6a0dbf2c-7324-11e5-94f3-ff17a8a1cdc8
Last heartbeat sent: 0:00:05 ago
Last heartbeat received: 0:00:05 ago
CVX VIP
CVX VIP provides the virtual IP address that actively follows the master controller of the CVX cluster.
The virtual IP address of the CVX HA Cluster is configured on a macvlan interface setup on top of a physical management interface of the master controller. The virtual IP and virtual MAC needs to be provided by the customer as part of the controller configuration. This information is available to all controllers as each cluster member has to be configured manually by the user on all controllers.
The macvlan interface created should be designated as `Management0.` `Management0` is currently used for the ManagementActive interface on modular switches. Without explicit configuration of VIP and VMAC, CVX VIP functionality will not work in the CVX HA cluster.
Customers can pick the VMAC from a pool of MAC addresses reserved for use with CVX clusters. The OUI pool, 00:1C:73:00:00:AA “ 00:1C:73:00:00:FF has been reserved for this purpose.
The macvlan interface is setup if all of the following conditions are met:
VMAC is configured by the user
The controller instance is a leader
There are more than one controller instances
The controller is not being run on a modular system
All CLI commands applicable to the management interface of the controller will be allowed onManagement0, with the exception of Layer 1 / phy level commands. So auto-negotiation or flow control cannot be configured on the Management0 interface. Instead these commands can only be run on the physical management interfaces. This makes sense as the phy-level configuration really depends on what the interface is physically wire.
At EOS boot time, SSH host keys and Diffie-Hellman parameters are automatically generated and persistently stored on each controller. Multiple SSL profiles / keys / certificates might also be created and used by various agents on the controllers. Since these information contribute to the identity of the master, they will need to follow the master controller for all time.
In case of a controller switchover, the newly elected master controller will need to use the same SSH host keys & SSL profiles / keys / certificates to retain its identity and prevent any kind of network security alarms from being tripped. For example, if an SSH client notices that the host key has changed, it will normally flag an error warning the user of a possible man-in-the-middle type attack. Hence, this data will be replicated from the master to slaves.
SSH Host Key Tagging
SSH host keys are tagged with the chassis MAC address to deal with key regeneration issues when a supervisor module is moved from one chassis to another. This behavior will cause regeneration issues if we replicate the SSH host keys across the cluster resulting in the key fingerprint seen by management tools to be different.
To mitigate this, in addition to the chassis MAC address, the host keys would now be tagged with VMAC of the CVX HA cluster. If CVX VIP and VMAC are configured, SshHostKeysAgent will not regenerate keys if tagged VMAC and configured VMAC are the same, even if there is a mismatch between the chassis MAC and tagged MAC.
CVX (CloudVision eXtension) aggregates and shares status across a network of physical switches running EOS. CVX services provide visibility and coordinate activities across a network of switches that are configured as CVX clients.
The cvx command enters CVX configuration mode. CVX configuration mode is not a group-change mode; running-config is changed immediately upon entering commands. Exiting CVX configuration mode does not affect running-config. The exit command returns the switch to global configuration mode.
The no cvx and default cvx commands restore all CVX server defaults by deleting all CVX configuration mode statements from the running-config.
Command Mode
Global Configuration
Command Syntax
cvx
no cvx
default cvx
Commands Available in CVX Configuration Mode
port(CVX)
service openstack
service VXLAN
shutdown (CVX)
heartbeat-interval (CVX)
heartbeat-timeout (CVX)
Example
These commands enter the CVX-configuration mode and displays the CVX configuration.
switch(config)# cvx
switch(config-cvx)# show active all
cvx
shutdown
port 9979
heartbeat-interval 20
heartbeat-timeout 60
no service VXLAN
service openstack
shutdown
name-resolution interval 21600
switch(config-cvx)#
heartbeat-interval (CVX)
The heartbeat-interval command configures the interval between heartbeat messages that the switch sends as a CVX server. Heartbeat messages are part of the keepalive mechanism between CVX and the CVX clients to which it connects.
The no heartbeat-interval and default heartbeat-interval commands restore the heartbeat interval to the default setting by removing the heartbeat-interval command from running-config.
Command Mode
CVX Configuration
Command Syntax
heartbeat-intervalperiod
no heartbeat-interval
default heartbeat-interval
Parameters
period Interval duration (seconds). Value ranges from 5 through 60. Default value is 20.
Related Commands
cvx.
heartbeat-timeout (CVX)
Guidelines
Heartbeat messages flow independently in both directions between CVX and clients. When a client stops receiving heartbeat messages from the server within a specified period, the client assumes that the CVX server is no longer functioning.
Best practices dictate that CVX and its client applications configure identical heartbeat interval values.
Example
This command configures a CVX server heartbeat interval of 30 seconds:
The heartbeat-interval command configures the interval between heartbeat messages that the switch sends as a CVX client. Heartbeat messages are part of the keepalive mechanism between the CVX client and the CVX server to which it connects.
The no heartbeat-interval and default heartbeat-interval commands revert the heartbeat interval to the default setting by removing the heartbeat-interval command from running-config.
Command Mode
>Management CVX Configuration
Command Syntax
heartbeat-intervalperiod
no heartbeat-interval
default heartbeat-interval
Parameters
period: Interval duration (seconds). Value ranges from 5 through 60. Default value is 20.
Guidelines
Heartbeat messages flow independently in both directions between CVX and clients. When the server stops receiving heartbeat messages from a client within a specified period, the server assumes that the device it is no longer functioning as a CVX client.
Best practices dictate that the CVX client's heartbeat interval value is identical to that of its CVX server.
The heartbeat-timeout command specifies the CVX timeout period. When a CVX server does not receive consecutive heartbeat messages from a CVX client within the heartbeat timeout period, the server discontinues providing CVX services to the client device. The default timeout period is 60 seconds.
The no heartbeat-timeout and default heartbeat-timeout-timeout commands restore the heartbeat timeout to the default setting by removing the heartbeat-timeout command from running-config.
Command Mode
CVX Configuration
Command Syntax
heartbeat-timeoutperiod
no heartbeat-timeout
default heartbeat-timeout
Related Commands
cvx places the switch in CVX configuration mode.
heartbeat-interval (CVX) specifies the CVX heartbeat interval.
Parameters
period heartbeat timeout interval (seconds). Value ranges from 15 to 10800. Default value is 60.
Guidelines
Best practices dictate that CVX and its client applications configure identical heartbeat timeout values.
Examples
These commands set the CVX timeout period to 90 seconds.
The heartbeat-timeout command specifies the CVX client timeout period. When a CVX client does not receive consecutive heartbeat messages from a CVX server within the period specified by this command, the client assumes that its connection to CVX is disrupted. The default timeout period is 60 seconds.
The no heartbeat-timeout and default heartbeat-timeout commands restore the CVX client heartbeat timeout to the default setting by removing the heartbeat-timeout command from running-config.
Command Mode
Mgmt-CVX Configuration
Command Syntax
heartbeat-timeoutperiod
no heartbeat-timeout
default heartbeat-timeout
Parameter
period heartbeat timeout interval (seconds). Value ranges from 15 to 10800. Default value is 60.
Guidelines
Best practices dictate that the CVX client's heartbeat timeout value is identical to that of its CVX server.
The lldp run command enables LLDP on the Arista switch.
Command Mode
Global Configuration
Command Syntax
lldp run
no lldp run
default lldp run
Examples
This command enables LLDP globally on the Arista switch.
switch(config)# lldp run
switch(config)#
This command disables LLDP globally on the Arista switch.
switch(config)# no lldp run
switch(config)#
management cvx
The management cvx command places the switch in mgmt-CVX configuration mode to configure CVX client parameters.
Mgmt-CVX configuration mode is not a group-change mode; running-config is changed immediately upon entering commands. Exiting mgmt-CVX configuration mode does not affect the running-config. The exit command returns the switch to global configuration mode.
The no management cvx and default management cvx commands delete all mgmt-CVX configuration mode statements from the running-config.
Command Mode
Global Configuration
Command Syntax
management cvx
no management cvx
default management cvx
Commands Available in Mgmt-CVX Configuration Mode
heartbeat-interval (Management-CVX)
heartbeat-timeout (Management-CVX)
server host (Management-CVX)
source-interface (Management-CVX)
shutdown (Management-CVX)
Examples
This command places the switch in mgmt-CVX configuration mode.
This command returns the switch to global management mode:
switch(config-mgmt-cvx)# exit
switch(config)#
manager
The manager command configures the IP address of the OVSDB controller for the HSC service, allowing CVX to connect to the controller.
The no manager and default manager commands remove the HSC manager configuration from running-config.
Command Mode
CVX-HSC Configuration
Command Syntax
manager ip_address [port]
Parameters
ip_addressIP address of the HSC manager.
port connection port. Values range from 1 to 65535; default value is 6632.
Related Commands
service hsc places the switch in CVX-HSC configuration mode.
Example
These commands point the HSC service to a controller at IP address 192.168.2.5 using the default port 6632.
switch(config)# cvx
switch(config-cvx)# service hsc
switch(config-cvx-hsc)# manager 192.163.2.5
switch(config-cvx-hsc)#
name-resolution force (CVX-OpenStack)
The name-resolution force command initiates an OpenStack controller function that communicates with the OpenStack Keystone and Nova services to update names of VMs and tenants mapped by the local OpenStack instance.
The OpenStack controller accesses the Keystone and Nova services in response to various triggering events (such as the creation of a new tenant, network or VM), and also at a regular interval configured by the name-resolution interval (CVX-OpenStack) command (default interval 6 hours). The name-resolution force command is used to force an immediate update without waiting for a triggering event.
Command Mode
CVX-OpenStack Configuration
Command Syntax
name-resolution force
Related Commands
service openstack places the switch in CVX-OpenStack configuration mode.
name-resolution interval (CVX-OpenStack) sets the interval for automatic Keystone updates.
Example
These commands update the OpenStack instance immediately with data from the Keystone service.
switch(config)# cvx
switch(config-cvx)# service openstack
switch(config-cvx-openstack)# name-resolution force
switch(config-cvx-openstack)#
name-resolution interval (CVX-OpenStack)
The name-resolution interval command specifies the period between consecutive requests that the OpenStack controller sends to the Keystone service for VM and tenant name updates. Keystone is OpenStack’s authentication and authorization service.
The default period is 21600 seconds (six hours).
The name-resolution force (CVX-OpenStack) command performs an immediate update, as opposed to waiting for the periodic update.
Command Mode
CVX-OpenStack Configuration
Command Syntax
name-resolution intervalperiod
Parameters
periodKeystone identity service polling interval (seconds).
Related Command
service openstack places the switch in CVX-OpenStack configuration mode.
Example
These commands set the name resolution interval period at 18000 (five hours).
switch(config)# cvx
switch(config-cvx)# service openstack
switch(config-cvx-openstack)# name-resolution interval 18000
switch(config-cvx-openstack)#
ovsdb-shutdown
The ovsdb-shutdown command shuts down the OVSDB server.
The no ovsdb-shutdown and default ovsdb-shutdown commands enable the OVSDB server by removing the ovsdb-shutdown command from the running-config.
Command Mode
CVX-HSC Configuration
Command Syntax
ovsdb-shutdown
no ovsdb-shutdown
default ovsdb-shutdown
Related Command
The service hsc command places the switch in the CVX-HSC configuration mode.
Example
These commands shut down the OVSDB server used by the HSC service.
switch(config)# cvx
switch(config-cvx)# service hsc
switch(config-cvx-hsc)# ovsdb-shutdown
switch(config-cvx-hsc)#
port (CVX)
The port command specifies the TCP port number the CVX server listens on. The default port number is 9979.
The no port and default port commands restore the default port number by removing the port statement from running-config.
Command Mode
CVX Configuration
Command Syntax
portport_number
no port
default port
Parameter
port_number TCP port number. Value ranges from 1 to 65535.
Related Command
cvx places the switch in the CVX configuration mode.
Examples
These commands configure 9500 as the CVX server port.
switch# config
switch(config)# cvx
switch(config-cvx)# port 9500
switch(config-cvx)#
These commands restore the default port (9979) as the CVX server port.
switch(config-cvx)# no port
switch(config-cvx)#
resync-period
The resync-period command configures the grace period for completion of synchronization between the VXLAN control service and clients after a CVX restart. Arista recommends leaving the grace period set to its default of 300 seconds.
The no resync-period command disables VXLAN control service graceful restart. The default resync-period command resets the grace period to its default of 300 seconds.
Command Mode
CVX-VXLAN Configuration
Command Syntax
resync-periodseconds
no resync-period
default resync-period
Parameter
seconds synchronization grace period in seconds. Values range from 30 to 4800; default is 300.
Example
These commands reset the VXLAN control service synchronization grace period to 300 seconds.
switch(config)# cvx
switch(config-cvx)# service VXLAN
switch(config-cvx-VXLAN)# default resync-period
switch(config-cvx-VXLAN)#
server host (Management-CVX)
The server host command configures the IP address or host name of the CVX server to which the CVX client device connects. The configuration of this address is required for the switch to function as a CVX client. By default, no CVX host address is specified.
The no server host and default server host commands remove the CVX host address assignment by removing the server host statement from the running-config.
Command Mode
Mgmt-CVX Configuration
Command Syntax
server hosthost
no server host
default server host
Parameter
hostIPv4 address (in dotted decimal notation) or FQDN host name of the CVX server.
Example
This command specifies 10.1.1.14 as the address of the server to which the CVX client connects.
switch(config)# management cvx
switch(config-mgmt-cvx)# server host 10.1.1.14
switch(config-mgmt-cvx)#
service hsc
The service hsc command enters the CVX-HSC configuration mode where the HSC service is enabled and configured.
CVX-HSC configuration mode is not a group change mode; the running-config is changed immediately upon entering commands. Exiting the CVX-HSC configuration mode does not affect running-config. The exit command returns the switch to global configuration mode.
Command Mode
CVX Configuration
Command Syntax
service hsc
Commands Available in CVX-HSC Configuration Mode
manager
ovsdb-shutdown
shutdown (CVX-HSC)
Related Command
cvx places the switch into the CVX configuration mode.
Example
These commands enter the CVX-HSC configuration mode.
switch(config)# cvx
switch(config-cvx)# service hsc
switch(config-cvx-hsc)#
service openstack
The service openstack command places the switch in CVX-OpenStack configuration mode.
In order to integrate Arista switches into an OpenStack managed cloud network, OpenStack needs to interact with CVX to configure and maintain VLANs on appropriate physical switch ports that connect to hosts where the VMs reside.
CVX-OpenStack configuration mode is not a group change mode;the running-config is changed immediately upon entering commands. Exiting the CVX-OpenStack configuration mode does not affect the running-config. The exit command returns the switch to global configuration mode.
Command Mode
CVX Configuration
Command Syntax
service openstack
Commands Available in CVX-OpenStack Configuration Mode
name-resolution force (CVX-OpenStack)
name-resolution interval (CVX-OpenStack)
shutdown (CVX-OpenStack)
Related Command
cvx places the switch into the CVX configuration mode.
Example
These commands places the switch into the CVX-OpenStack configuration mode.
switch(config)# cvx
switch(config-cvx)# service openstack
switch(config-cvx-openstack)#
service topology
The service topology command configures the topology statically on CVX without running LLDP on the servers connected to switches.
The no service topology command removes the static topology configuration from the running-config.
Command Mode
CVX Configuration Mode
Command Syntax
service topology
no service topology
Example
The following command configures topology statically on the switch.
switch# config
switch(config)# cvx
switch(config-cvx)# service topology
switch(config-cvx-topology)#
service VXLAN
The service VXLAN command enters the CVX-VXLAN configuration mode where the VXLAN control service is enabled and configured.
The CVX-VXLAN configuration mode is not a group change mode; running-config is changed immediately upon entering commands. Exiting theCVX-VXLAN configuration mode does not affect the running-config. The exit command returns the switch to global configuration mode.
Command Mode
CVX Configuration
Command Syntax
service VXLAN
Commands Available in CVX-VXLAN Configuration Mode
resync-period
shutdown (CVX-VXLAN)
vtep (CVX-VXLAN)
Related Command
The cvx command places the switch into the CVX configuration mode.
Example
These commands enters the CVX-VXLAN configuration mode.
switch(config)# cvx
switch(config-cvx)# service VXLAN
switch(config-cvx-VXLAN)#
show cvx
The show cvx command displays the enable status and current configuration of CVX.
Command Mode
EXEC
Command Syntax
show cvx
Example
This command displays the status and configuration of CVX.
switch(config)# cvx
cvx
no shutdown
heartbeat-interval 30
heartbeat-timeout 90
switch(config-cvx)# dis
switch> show cvx
CVX Server
Status: Enabled
UUID: 75ce27ce-cc04-11e4-a404-233646319a2c
Heartbeat interval: 30.0
Heartbeat timeout: 90.0
show network physical-topology
The show network physical-topology command displays the network topology discovered through CVX.
Command Mode
EXEC
Command Syntax
show network physical-topology [hosts|neighbors]
Parameters
hostsDisplays all hosts visible in the topology.
neighbors Displays all connections in the network topology. Table is sorted by host name, and can be optionally filtered by host.
The shutdown command, in cvx mode, disables or enables the switch as a CVX server. By default, CVX is disabled on the switch.
The no shutdown command enables the switch as a CVX server. The shutdown and default shutdown commands disable the switch as a CVX server by removing the no shutdown command from running-config.
Note: Be sure to de-configure or shut down all CVX client services before disabling CVX; failure to do so may result in CVX client services continuing to run after CVX has been disabled.
Command Mode
CVX Configuration
Command Syntax
shutdown
no shutdown
default shutdown
Related Command
The cvx command places the switch in CVX configuration mode.
Examples
These commands enable the switch as a CVX server.
switch# config
switch(config)# cvx
switch(config-cvx)# no shutdown
switch(config-cvx)#
This command disables CVX on the switch.
switch(config-cvx)# shutdown
switch(config-cvx)#
shutdown (CVX-HSC)
The shutdown command, in CVX-HSC configuration mode, disables or enables the CVX service on the switch. HSC is disabled by default.
When a CVX server enables HSC, its clients (hardware VTEPs) are able to share state to establish VXLAN tunnels without the need for a multicast control plane. Configuration is also required on the client switches.
The no shutdown command enables the HSC service; the shutdown and default shutdown commands disable the HSC service.
Command Mode
CVX-VXLAN Configuration
Command Syntax
shutdown
no shutdown
default shutdown
Related Command
The service hsc command places the switch into the CVX-HSC configuration mode.
Examples
These commands enable the HSC service.
switch(config)# cvx
switch(config-cvx)# service hsx
switch(config-cvx-hsc)# no shutdown
switch(config-cvx-hsc)#
These commands disable the HSC service.
switch(config)# cvx
switch(config-cvx)# service hsx
switch(config-cvx-hsc)# shutdown
switch(config-cvx-hsc)#
shutdown (Management-CVX)
The shutdown command, in the mgmt-cvx mode, disables or enables CVX client services on the switch. CVX services are disabled by default.
The no shutdown command enables CVX client services. The shutdown and default shutdown commands disable CVX client services by removing the corresponding no shutdown command from the running-config.
Command Mode
Mgmt-CVX Configuration
Command Syntax
shutdown
no shutdown
default shutdown
Examples
These commands enable CVX client services.
switch(config)# management cvx
switch(config-mgmt-cvx)# no shutdown
switch(config-mgmt-cvx)#
The shutdown command, in the cvx-openstack configuration mode, disables or enables CVX-OpenStack on the switch. CVX-OpenStack is disabled by default.
When a CVX server enables OpenStack services, its clients are accessible to the OpenStack network controller (Neutron). Integrating Arista switches into an OpenStack-managed cloud network requires OpenStack to interact with CVX to configure and maintain VLANs on appropriate physical switch ports that connect to the hosts where the VMs reside.
The no shutdown command enables CVX-OpenStack. The shutdown and default shutdown commands disable CVX-OpenStack by removing the corresponding no shutdown command from the running-config.
Command Mode
CVX-OpenStack Configuration
Command Syntax
shutdown
no shutdown
default shutdown
Related Command
service openstack places the switch in CVX-OpenStack configuration mode.
Examples
These commands enable CVX-OpenStack.
switch(config)# cvx
switch(config-cvx)# service openstack
switch(config-cvx-openstack)# no shutdown
switch(config-cvx-openstack)#
The shutdown command, in CVX-VXLAN configuration mode, disables or enables the CVX VXLAN control service on the switch. VXLAN control service is disabled by default.
When a CVX server enables VXLAN control service, its clients (hardware VTEPs) are able to share state to establish VXLAN tunnels without the need for a multicast control plane. Configuration is also required on the client switches.
The no shutdown command enables the VXLAN control service. The shutdown and default shutdown commands disable the VXLAN control service.
Command Mode
CVX-VXLAN Configuration
Command Syntax
shutdown
no shutdown
default shutdown
Related Command
The service VXLAN command places the switch in CVX-VXLAN configuration mode.
Examples
These commands enable VXLAN control service.
switch(config)# cvx
switch(config-cvx)# service VXLAN
switch(config-cvx-VXLAN)# no shutdown
switch(config-cvx-VXLAN)#
These commands disable VXLAN control service.
switch(config)# cvx
switch(config-cvx)# service VXLAN
switch(config-cvx-VXLAN)# shutdown
switch(config-cvx-VXLAN)#
source-interface (Management-CVX)
The source-interface command specifies the interface from where the IPv4 address is derived for use as the source for outbound CVX packets that the switch sends as a CVX client. There is no default source interface assignment.
The no source-interface and default source-interface commands remove the source interface assignment for the CVX client by deleting the source-interface statement from the running-config.
Command Mode
Mgmt-CVX Configuration
Command Syntax
source-interface INT_NAME
no source-interface
default source-interface
Parameters
INT_NAME: Interface type and number. Options include:
ethernete_num: Ethernet interface specified by e_num.
loopbackl_num: Loopback interface specified by l_num.
managementm_num: Management interface specified by m_num.
port-channel p_num: Port-Channel Interface specified by p_num.
vlanv_num: VLAN interface specified by v_num.
Example
These commands configure the CVX client to use the IP address 10.24.24.1 as the source address for its outbound packets.
The HSC service sends flood lists to each VTEP through CVX. Some controllers (such as VMware NSX's Service Nodes) implement replication nodes for head-end replication of unknown packets. For these controllers, BUM packets should be sent to a single replication node (send-to-any replication), and the flood list sent by the HSC service is a list of replication nodes. Other controllers (such as Nuage VSP) require each VTEP to perform its own head-end replication. For these, BUM packets should be sent to every known VTEP, and the flood list sent by the HSC service is the list of VTEPs.
The default behavior is to use a send-to-any replication list of VTEPs. If the required behavior is send-to-all replication of, use the all option of the vtep command in the CVX-HSC configuration mode.
Command Mode
CVX-HSC Configuration
Command Syntax
vtepfloodlist typeall | any
no vtepfloodlist type
default vtepfloodlist type
Parameters
all: send-to-all replication; flood list is the list of VTEPs.
any: send-to-any replication; flood list is a list of replication nodes. This is the default setting.
Example
These commands configure the HSC to use send-to-all replication.
switch(config)# cvx
switch(config-cvx)# service hsc
switch(config-cvx-hsc)# vtep flood list type all
switch(config-cvx-hsc)#
vtep (CVX-VXLAN)
The OVSDB management protocol includes provisions for control-plane MAC learning, which allows MAC addresses to be distributed among VTEPs without using the data plane. Some controllers (such as VMware NSX) take advantage of this facility; others (such as Nuage VSP) do not. By default, CVX uses control-plane MAC learning.
To switch to data plane MAC learning, use the vtep command in the CVX-VXLAN configuration mode, as shown below.
Command Mode
CVX-VXLAN Configuration
Command Syntax
vtepmac-learning [control-plane|data-plane ]
Related Command
The service VXLAN command places the switch into the CVX-VXLAN configuration mode.
Example
These commands configure CVX to use data-plane MAC address learning.
switch(config)# cvx
switch(config-cvx)# service VXLAN
switch(config-cvx-VXLAN)# vtep mac-learning data-plane
switch(config-cvx)#
Open Shortest Path First (OSPF) is a link-state routing protocol that operates within a single
autonomous system. OSPF version 3 is defined by RFC 5340.
OSPFv3 is based on OSPFv2 and includes enhancements that utilize IPv6 features. However,
OSPFv3 is configured and operates independently of any implementation of OSPFv2 on the
switch. OSPFv2 features that OSPFv3 implements include:
Packet types
Neighbor discovery and adjacency formation mechanisms
LSA aging and flooding
SPF calculations
DR election procedure
Multiple area support
Router-ID (32 bits)
The following list describes the OSPFv3 differences and enhancements from OSPFv2:
IPv6 128-bit addresses
Use of link-local addresses
OSPFv3 runs over links instead of subnets
Support flood pacing
Arista switches support the following OSPFv3 functions:
A single OSPFv3 instance for each VRF
Intra- and inter-area routing
Type 1 and 2 external routing
Broadcast and P2P interfaces
Stub areas
Redistribution of static and connected routes into OSPFv3
OSPFv3 is a dynamic, link-state routing protocol in which links represent
routable paths. Dynamic routing protocols calculate the most
efficient path between locations based on bandwidth and device
status.
A Link State Advertisement (LSA) is an OSPFv3 packet communicating a
router's topology to other routers. The Link State Database
(LSDB) stores an area’s topology database and comprises LSAs
received from other routers. Routers update the LSDB by storing
LSAs from other routers.
Topology
An Autonomous System (AS) is the IP domain within which a dynamic protocol controls traffic
routing. In OSPFv3, an AS comprises areas that define the LSDB computation
boundaries—all routers in an area store identical LSDBs. Routers in different
areas exchange updates without storing the entire database, reducing information
maintenance on large, dynamic networks.
An AS shares internal routing information from its areas and external routing information from
other processes to inform routers outside the AS about routes the network can
access. Routers that advertise routes on other autonomous systems commit to
carrying data to the IP space on the route.
OSPFv3 defines these routers:
Internal Router (IR): a router with interfaces in a single area.
All IRs in an area maintain identical LSDBs.
Area Border Router (ABR): a router with interfaces in multiple
areas. ABRs maintain one LSDB for each connected area.
Autonomous System Boundary Router (ASBR): a gateway router
connecting the OSPFv3 domain to external routes, including static
routes and routes from other autonomous systems.
OSPFv3 areas are assigned a number between 0 and
4,294,967,295. Area numbers are often expressed in dotted
decimal notation, similar to IP addresses.
Each AS has a backbone area, designated area 0, that connects to all
other areas. The backbone receives routing information from all areas and
distributes it to the other areas as required.
OSPFv3 area types include:
Normal area accepts intra-area, inter-area, and external routes. The
backbone is a normal area.
Stub area does not receive router advertisements external to the AS.
Stub area routing is based on a default route.
Link Updates
Routers periodically send hello packets to advertise status and establish neighbors. A routers
hello packet includes IP addresses of other routers from which it received a hello packet
within the time specified by the router dead interval. Routers become neighbors when they
detect each other in their hello packets if they:
Share a common network segment.
Are in the same area.
Have the same hello interval, dead interval, and authentication parameters.
Neighbors form adjacencies to exchange LSDB
information. A neighbor group uses hello packets to elect a Designated
Router (DR) and Backup Designated Router (BDR). The DR and BDR become
adjacent to all other neighbors, including each other. Only adjacent
neighbors share database information.
The DR is the central contact for database
exchanges. Switches send database information to their DR, which relays
the information to the other neighbors. All routers in an area maintain
identical LSDBs. Switches also send database information to their BDR,
which stores this data without distributing it. If the DR fails, the
BDR distributes LSDB information to its neighbors.
OSPFv3 routers distribute LSAs by sending them on all of their active interfaces. The router does
not send hello packets from passive interfaces, preventing adjacencies. The router does not
process any OSPFv2 packets received on a passive interface.
When an LSA changes a router's LSDB, it sends the changes to the BDR and DR for distribution to
the other neighbors. Routing information is updated only when the topology changes.
Routing devices use Dijkstra's algorithm to calculate the shortest path to all known destinations
based on cumulative route cost. The cost of an interface indicates the transmission overhead
and is usually inversely proportional to its bandwidth.
OSPFv3 Security
The OSPFv3 protocol relies on the IPsec Authentication Header (AH) and Encapsulating Security
Payload (ESP) header to provide data integrity, authentication, and confidentiality.
Transport mode provides IPsec to OSPFv3 packets.
The IPsec SA has a Security Policy Index (SPI), HMAC algorithm, and a secret key as parameters.
These parameters are used to compute Integrity Check Value (ICV), that is used to
authenticate peers. When authentication is enabled, all corresponding peers must use
same SA parameters to clear OSPFv3 ICV verification. SA can be configured at both area
and interface levels.
Note: On the same area or interface, EOS allows security configuration with either AH or ESP but not
both. We can have one area or interface configured with AH and
another with ESP.
OSPFv3 Authentication
While sending OSPFv3 packets, the system inserts the HMAC-MD5 or SHA algorithm hash in
the IPsec header and sends the packet over the wire for peer authentication.
While receiving OSPFv3 packets, the system verifies the computed hash with the one in the
IPsec header and discards OSPFv3 packets if it fails.
OSPFv3 Encryption
ESP provides confidentiality to OSPFv3 packets. When confidentiality is enabled, ESP encrypts the
sent data and decrypts the received data. OSPFv3 packets that are not encapsulated with
a security payload are discarded.
OSPFv3 encryption uses the Triple Data Encryption Standard (3DES) and Advanced Encryption
Standard (AES) algorithms. 3DES uses a 192 bit key, whereas
the AES key length varies by 128,
192, and 256 bits.
Flood Pacing
OSPFv3 flood pacing allows configuring the minimum interval between the transmission of
consecutive Link State (LS) update packets in a network. Flood pacing provides the
following benefits:
Prevents the rapid drain of flood queue by sending consecutive LSU packets with
a delay.
It helps mitigate high CPU or socket buffer utilization issues that occur when a
switch instantly floods a large number of LSAs.
When LSDB is updated frequently, an incremented flood pacing interval scales
down LSA flooding.
Note: A high flood pacing interval may lead to convergence
delays in large OSPF LSDBs.
OSPFv3 BFD Sessions for Adjacencies in any State
BFD sessions are only established for OSPFv3 adjacencies that are in the FULL state. In a
LAN environment, this results in BFD sessions not being established for OSPFv3
adjacencies with DR Other neighbors.
This feature provides configuration that enables the establishment of BFD sessions for
OSPFv3 adjacencies that are in any state. This results in the BFD sessions being
established for OSPFv3 adjacencies with DR Other neighbors.
Support for OSPFv3 dn-bit-ignore
The OSPFv3 dn-bit-ignore command enables or disables the
inclusion of LSAs with a Down (DN) bit set in SPF calculations. The
DN Bit provides a loop prevention mechanism when configuring OSPF as a CE - PE IGP
protocol.
The IEEE RFC RFC6565 explains the DN-bit usage in OSPFv3. OSPFv3 honors the
DN-bit in type-3, type-5, or
type-7 LSAs in non-default VRFs. SPF calculations do
not include the LSAs and subsequently do not install them in the routing table. Using
the dn-bit-ignore command changes this behavior. Arista
Networks recommends understanding the entire topology before configuring the
dn-bit-ignore command, as it can lead to forwarding
loops on the network.
Configuring OSPFv3
These sections describe basic OSPFv3 configuration steps:
OSPFv3 configuration commands apply to the specified OSPFv3 instance. The switch must be in
router-OSPFv3 configuration mode to execute OSPFv3 configuration commands. The ipv6 router ospf
command places the switch in router-OSPFv3 configuration mode, creating an OSPFv3
instance if OSPFv3 was not previously instantiated on the switch. If no VRF is
specified, the OSPFv3 instance is in the default VRF. To instantiate or configure OSPFv3
on a non-default VRF, specify that VRF when using the ipv6 router
ospf command.
The process ID identifies the OSPFv3 instance
and is local to the router. Neighbor OSPFv3 routers can have different
process IDs. OSPFv3 instances configured in different VRFs on the switch
must have different process IDs.
The switch supports one OSPFv3 instance for each VRF. When an OSPFv3 instance already exists, the
ipv6 router
ospf command must specify its process ID (and VRF, if
not configured in the default VRF). Attempts to define additional instances in the same
VRF will generate errors. The show ipv6
ospf command displays information about OSPFv3
instances, including their process IDs.
Example
This command places the switch in router-OSPFv3 configuration mode for the default VRF.
If OSPFv3 was not previously instantiated in the default VRF, the command creates an
OSPFv3 instance with a process ID of
9.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# show active
ipv6 router ospf 9
switch(config-router-ospf3)#
Defining the Router ID
The router ID is a 32-bit number
assigned to a router running OSPFv3. This number uniquely labels the
router within an Autonomous System. Status commands identify the switch
through the router ID. When configuring OSPFv3 instances in multiple
VRFs, each should have a different router ID.
Note: A router ID is required to run OSPF and Arista recommends setting the router ID manually for
the following reasons:
If there are no IPv4 addresses configured on the switch, a manually configured
router ID is required.
The router ID also does not change if the interface status or IP address changes,
which can cause confusion if the ID is selected automatically.
The switch sets the router ID to the first available alternative in the following list:
The router-id command.
The loopback IPv4 address if a active loopback interface existson the switch.
The highest IPv4 address on the router.
Note: When configuring VXLAN on an MLAG,
always manually configure the OSPFv3 router ID to prevent the switch from using
the common VTEP IP address as the router ID.
The router-id (OSPFv3)
command configures the router ID for an OSPFv3 instance.
Example
This command assigns 15.1.1.1 as the OSPFv3 router
ID.
switch(config-router-ospf3)# router-id 15.1.1.1
switch(config-router-ospf3)# show active
ipv6 router ospf 9
router-id 15.1.1.1
switch(config-router-ospf3)#
Global OSPFv3 Parameters
These router-OSPFv3 configuration mode commands control the OSPFv3 instance's behavior.
Logging Adjacency Changes
The log-adjacency-changes
(OSPFv3) command configures the switch to log
OSPFv3 link-state changes and transitions of OSPFv3 neighbors into the up or down
state.
Examples
This command configures the switch to log transitions of OSPFv3 neighbors
into the up or down
state.
The distance ospf intra-area
(OSPFv3) command configures the administrative
distance for routes contained in a single OSPFv3 area. Administrative distances
compare dynamic routes configured by different protocols. The default administrative
distance for intra-area routes is 10.
Example
This command configures an administrative distance of 90
for OSPFv3 intra-area
routes.
switch(config-router-ospf3)# distance ospf intra-area 90
switch(config-router-ospf3)# show active
ipv6 router ospf 9
distance ospf intra-area 90
switch(config-router-ospf3)#
Passive Interfaces
The passive-interface
(OSPFv3) command prevents the transmission of hello
packets on the specified interface. Passive interfaces drop all adjacencies and do
not form new adjacencies. Although passive interfaces do not send or receive LSAs,
others may generate LSAs for the network segment. The router does not send OSPFv3
packets from a passive interface or process OSPFv3 packets received on a passive
interface. The router advertises the passive interface in the router LSA.
The no passive-interface command re-enables OSPFv3 processing on the
specified interface.
Examples
This command configures vlan 200 as a passive
interface.
switch(config-router-ospf3)# passive-interface vlan 200
switch(config-router-ospf3)# show active
ipv6 router ospf 9
passive-interface Vlan200
switch(config-router-ospf3)#
This command configures vlan 200 as an active
interface.
switch(config-router-ospf3)# no passive-interface vlan 200
switch(config-router-ospf3)# show active
ipv6 router ospf 9
switch(config-router-ospf3)#
Redistributing Connected Routes
Redistributing connected routes causes the OSPFv3 instance to advertise all connected routes on
the switch as external OSPFv3 routes. Connected routes are routes established when
enabling IPv6 on an interface.
Example
The redistribute
(OSPFv3)connected command converts connected routes to OSPFv3
external
routes.
switch(config-router-ospf3)# redistribute connected
switch(config-router-ospf3)# show active
ipv6 router ospf 9
redistribute connected
switch(config-router-ospf3)#
Redistributing Static Routes
Redistributing static routes causes the
OSPFv3 instance to advertise all static routes on the switch as external
OSPFv3 routes. The switch does not support redistributing individual
static routes.
Example
The redistribute
(OSPFv3)static command converts static routes to OSPFv3 external
routes.
switch(config-router-ospf3)# redistribute static
switch(config-router-ospf3)# show active
ipv6 router ospf 9
redistribute static
switch(config-router-ospf3)#
Configuring OSPFv3 Areas
Area commands configure OSPFv3 areas. The switch must be in router-OSPFv3 configuration mode to
run area commands, as described in Entering OSPFv3
Configuration Mode.
Areas are assigned a 32-bit number expressed in decimal or dotted-decimal notation. When an
OSPFv3 instance configuration contains multiple areas, the switch only
configures areas associated with its interfaces.
Configuring the Area Type
The no area (OSPFv3)
command specifies the area type. The switch supports two area types:
Normal area: Area that accepts intra-area, inter-area, and
external routes. The backbone area (area 0)
is a normal area.
Stub area: Area where external routes are not advertised.
External routes are reached through a default summary route
(::/0) inserted into stub areas.
Networks with no external routes do not require stub areas.
The default area type is normal.
Example
These commands configure area 200 as an NSSA area and
300 as a stub
area.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# area 200 nssa
switch(config-router-ospf3)# area 300 stub
switch(config-router-ospf3)# show active
ipv6 router ospf 9
area 0.0.0.200
area 0.0.1.44 stub
switch(config-router-ospf3)#
Configuring Area Parameters
These router-OSPFv3 configuration
mode commands define OSPFv3 behavior in a specified area.
Default Summary Route Cost
The area default-cost (OSPFv3) command specifies the cost of the default
summary route that ABRs send into a stub area or NSSA. Summary routes, also called
inter-area routes, originate in areas different than their destination. When the
area default-cost command is not configured for an
area, the default-cost of that area is set to 10.
Example
This command configures a cost of 25 for the default
summary route in area 0.0.1.194
(450).
switch(config-router-ospf3)# area 450 default-cost 25
switch(config-router-ospf3)# show active
ipv6 router ospf 9
area 0.0.1.194 default-cost 25
Area Stub
The area stub (OSPFv3) command configures the area type of an OSPFv3 area.
All routers in an AS must specify the same area type for identically numbered
areas.
Stub areas are areas in which external routes are not advertised. To reach these external routes,
the stub area uses a default summary route (::/0).
Networks without external routes do not require stub areas.
Areas are normal by default; area type configuration is required only for stub NSSA areas.
Area 0 is always a normal area and cannot be configured
through this command.
Examples
This command configures area 45 as a stub
area.
switch(config)# ipv6 router ospf 3
switch(config-router-ospf3)# area 45 stub
switch(config-router-ospf3)#
This command configures area 10.92.148.17 as a
stub
area.
switch(config-router-ospf3)# area 10.92.148.17 stub
switch(config-router-ospf3)#
Area Range
The area range (OSPFv3) command is used by OSPFv3 Area Border
Routers (ABRs) to consolidate or summarize routes, configure a cost setting for
those routes, and suppress summary route advertisements.
By default, an ABR creates a summary LSA for each route in an area and advertises that LSA to
adjacent areas. The area range (OSPFv3) command aggregates
routing information on area boundaries, allowing the ABR to use one summary LSA to
advertise multiple routes.
Examples
These commands consolidate and summarize routes at an area boundary
1.
switch(config)# ipv6 router ospf 1
switch(config-router-ospf3)# area 1 range 2001:0DB8:0:1::/64
switch(config-router-ospf3)#
These commands change the address range status to DoNotAdvertise. Neither
one of the individual intra-area routes falling under range or the ranged
prefix is advertised as summary
LSA.
switch(config)# ipv6 router ospf 1
switch(config-router-ospf3)# area 1 range 2001:0DB8:0:1::/64 not-advertise
switch(config-router-ospf3)#
Configuring Interfaces for
OSPFv3
OSPFv3 interface configuration commands enable OSPFv3 on an interface, assign the interface to an area, and specify transmission parameters for routed ports and SVIs that handle OSPFv3 packets.
Assigning an Interface to an Area
The ipv6 ospf area command enables OSPFv3 on the configuration mode
interface and associates the specified area to the interface. Each routed interface can be
associated with one OSPFv3 area; subsequent ipv6 ospf area
commands that designate a different area on an interface replace any existing command for
the interface.
Example
These commands enable OSPFv3 instance 9 on interface
vlan 200 and associate area 0 to the
interface.
switch(config)# interface vlan 200
switch(config-if-Vl200)# ipv6 ospf 9 area 0
switch(config-if-Vl200)# show active
interface Vlan200
ipv6 ospf 9 area 0.0.0.0
switch(config-if-Vl200)#
Configuring Intervals
Interval configuration commands determine the OSPFv3 packet transmission characteristics for a
specified VLAN interface. Interval configuration commands are entered in vlan-interface
configuration mode.
Hello Interval
The hello interval specifies the period between consecutive hello packet transmissions from an
interface. Each OSPFv3 neighbor should specify the same hello interval, which should
not be longer than any neighbor's dead interval.
The ospfv3 hello-interval command configures the hello interval for the
configuration mode interface. The default is 10
seconds.
Example
These commands configure a hello interval of 45 seconds for
vlan
200.
switch(config)# interface vlan 200
switch(config-if-Vl200)# ospfv3 hello-interval 45
switch(config-if-Vl200)# show active
interface Vlan200
ospfv3 hello-interval 45
switch(config-if-Vl200)#
Dead Interval
The dead interval specifies the period that an interface waits for an OSPFv3 packet from a
neighbor before it disables the adjacency under the assumption that the neighbor is
down. Configure identical dead intervals on all OSPFv3 neighbors. They must be
longer than the hello interval of any neighbor.
The ospfv3 dead-interval command configures the dead interval for the
configuration mode interface. The default is 40
seconds.
Example
This command configures a dead interval of 75 seconds for
vlan
200.
switch(config)# interface vlan 200
switch(config-if-Vl200)# ospfv3 dead-interval 75
switch(config-if-Vl200)# show active
interface Vlan200
ospfv3 dead-interval 75
switch(config-if-Vl200)#
Retransmission Interval
Routers that send OSPFv3 advertisements to an adjacent router expect to receive an acknowledgment
from that neighbor. If they do not receive an acknowledgment, they will retransmit
the advertisement. The retransmission interval specifies the period between
retransmissions.
The ospfv3 ipv6 retransmit-interval command configures the LSA
retransmission interval for the configuration mode interface. The default
retransmission interval is 5 seconds.
Example
This command configures a retransmission interval of 25
seconds for vlan
200.
switch(config)# interface vlan 200
switch(config-if-Vl200)# ospfv3 ipv6 retransmit-interval 25
switch(config-if-Vl200)# show active
interface Vlan200
ospfv3 ipv6 retransmit-interval 25
switch(config-if-Vl200)#
Transmission Delay
The transmission delay is an estimate of the time that an interface requires to transmit a
link-state update packet. OSPFv3 adds this delay to the age of outbound packets to
more accurately reflect the age of the LSA when received by a neighbor.
The ospfv3 transmit-delay command configures the transmission delay for the
configuration mode interface. The default transmission delay is one second.
Example
This command configures a transmission delay of 10 seconds
for vlan
200.
switch(config)# interface vlan 200
switch(config-if-Vl200)# ospfv3 transmit-delay 10
switch(config-if-Vl200)# show active
interface Vlan200
ospfv3 transmit-delay 10
switch(config-if-Vl200)#
Configuring Interface Parameters
Interface Cost
The OSPFv3 interface cost reflects the overhead of sending packets across the interface. The cost
is typically assigned to be inversely proportional to the interface's bandwidth. The
ospfv3 cost command configures the OSPFv3 cost for the
configuration mode interface. The default cost is 10.
Example
This command configures a cost of 50 for vlan
200.
switch(config)# interface vlan 200
switch(config-if-Vl200)# ospfv3 cost 50
switch(config-if-Vl200)# show active
interface Vlan200
ospfv3 cost 50
switch(config-if-Vl200)#
Router Priority
Router priority determines preference during Designated Router (DR) and Backup Designated Router
(BDR) elections. Routers with higher priority numbers have preference over other
routers. Routers with a priority of 0 cannot be elected as a
DR or BDR.
The ospfv3 priority command configures router priority for the configuration
mode interface. The default priority is 1.
Example
This command configures a router priority of 128 for
vlan
200.
switch(config)# interface vlan 200
switch(config-if-Vl200)# ospfv3 priority 128
switch(config-if-Vl200)# show active
interface Vlan200
ospfv3 priority 128
switch(config-if-Vl200)#
Enabling OSPFv3
IP Routing
OSPFv3 requires enabling IPv6 unicast routing on the switch. When IP routing is not enabled,
entering OSPFv3 configuration mode generates a message.
Examples
This message is displayed if, when entering
router-OSPFv3 configuration mode, IPv6 unicast
routing is not
enabled.
The shutdown (OSPFv3) disables OSPFv3 operations on the switch without
disrupting the OSPFv3 configuration. To disable OSPFv3 on an interface, remove the ipv6 ospf area statement for the corresponding interface.
The no shutdown command resumes OSPFv3 activity.
Examples
This command disables OSPFv3 activity on the
switch.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# shutdown
switch(config-router-ospf3)# show active
ipv6 router ospf 9
shutdown
switch(config-router-ospf3)#
This command resumes OSPFv3 activity on the
switch.
switch(config-router-ospf3)# no shutdown
switch(config-router-ospf3)# show active
ipv6 router ospf 9
switch(config-router-ospf3)#
Configuring OSPFv3 Security
You can configure OSPFv3 security for either an area, an interface, or both, using either an Authentication Header (AH) or an Encapsulating Security Payload (ESP).
When configuring OSPFv3 security on an area, the configured settings apply to all interfaces in that area. Interface-specific configuration overrides configuration on the area to which the interface belongs.
You can configure flood pacing for global OSPFv3 instances and address families. The
timers pacing flood command configures OSPFv3 flood pacing.
Examples
This command configures OSPFv3 flood pacing timer to 50 ms in
the global OSPFv3
instance.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# timers pacing flood 50
switch(config-router-ospf3)# show ipv6 ospf
Routing Process "ospfv3 9" with ID 13.13.13.13 and Instance 0 VRF default
FIPS mode disabled
It is not an autonomous system boundary router and is not an area border router
Minimum LSA arrival interval 1000 msecs
Initial LSA throttle delay 1000 msecs
Minimum hold time for LSA throttle 5000 msecs
Maximum wait time for LSA throttle 5000 msecs
Interface flood pacing timer 50 msecs
It has 0 fully adjacent neighbors
Number of areas in this router is 1. 1 normal, 0 stub, 0 nssa
Number of LSAs 1
Initial SPF schedule delay 0 msecs
Minimum hold time between two consecutive SPFs 5000 msecs
Current hold time between two consecutive SPFs 5000 msecs
Maximum wait time between two consecutive SPFs 5000 msecs
SPF algorithm last executed 21d19h ago
No scheduled SPF
Adjacency exchange-start threshold is 20
Maximum number of next-hops supported in ECMP is 32
Number of backbone neighbors is 0
Graceful-restart is not configured
Graceful-restart-helper mode is enabled
Area 0.0.0.0
Number of interface in this area is 0
It is a normal area
SPF algorithm executed 2 times
This command configures OSPFv3 flood pacing timer to 50 ms for
ipv4 address family.
switch(config)# router ospfv3
switch(config-router-ospfv3)# address-family ipv4
switch(config-router-ospfv3-af)# timers pacing flood 50
switch(config-router-ospfv3-af)# show ospfv3
OSPFv3 address-family ipv4
Routing Process "ospfv3" with ID 11.1.11.1 and Instance 64 VRF default
FIPS mode disabled
It is not an autonomous system boundary router and is not an area border router
Minimum LSA arrival interval 1000 msecs
Initial LSA throttle delay 1000 msecs
Minimum hold time for LSA throttle 5000 msecs
Maximum wait time for LSA throttle 5000 msecs
Interface flood pacing timer 50 msecs
It has 0 fully adjacent neighbors
Number of areas in this router is 1. 1 normal, 0 stub, 0 nssa
Number of LSAs 1
Initial SPF schedule delay 0 msecs
Minimum hold time between two consecutive SPFs 5000 msecs
Current hold time between two consecutive SPFs 5000 msecs
Maximum wait time between two consecutive SPFs 5000 msecs
SPF algorithm last executed 00:01:05 ago
No scheduled SPF
Adjacency exchange-start threshold is 20
Maximum number of next-hops supported in ECMP is 32
Number of backbone neighbors is 0
Graceful-restart is not configured
Graceful-restart-helper mode is enabled
Area 0.0.0.0
Number of interface in this area is 0
It is a normal area
SPF algorithm executed 2 times
Configuring OSPv3 dn-bit-ignore
OSPFv3
Use the command dn-bit-ignore to include
type-3/5/7 LSAs to set the DN-bit in the SPF calculation.
The commands dn-bit-ignore or default
dn-bit-ignore revert the behavior back to default. Use this
command in the ipv6 router ospf vrf configuration mode and the
router ospfv3 vrf configuration mode. The default VRF does not
support this command.
router ospfv3
The dn-bit-ignore command in the router
ospfv3 vrf configuration mode disables the dn-bit check for
Type-3/5/7 LSAs in non-default
VRFs.
switch(config)# router ospfv3 vrf red
switch(config-router-ospfv3-vrf-red)# dn-bit-ignore
ipv6 router ospf
The dn-bit-ignore command in the ipv6
router ospf vrf configuration mode disables the dn-bit check for
Type-3/5/7 LSAs in non-default
VRFs.
switch(config)# ipv6 router ospf 1 vrf red
switch(config-router-ospfv3-vrf-red)# dn-bit-ignore
Displaying OSPFv3 Status
This section describes OSPFv3 show commands that display OSPFv3 status. General switch methods that provide OSPFv3 information include pinging routes, viewing route status (show ip route command), and viewing the configuration (show running-config command).
OSPFv3 Summary
The show ipv6 ospf command displays general OSPFv3 configuration
information, operational statistics, and status for the OSPFv3 instance, followed by a brief
description of the areas configured on the switch.
Example
This command displays OSPFv3 routing process
information.
switch(config-router-ospf3)# show ipv6 ospf
Routing Process "ospfv3 1" with ID 1.1.1.1 and Instance 0 VRF default
It is not an autonomous system boundary router and is not an area border router
Minimum LSA arrival interval 1000 msecs
Initial LSA throttle delay 1000 msecs
Minimum hold time for LSA throttle 5000 msecs
Maximum wait time for LSA throttle 5000 msecs
Interface flood pacing timer 50 msecs
It has 0 fully adjacent neighbors
...
Graceful-restart is not configured
Graceful-restart-helper mode is enabled
Viewing OSPFv3 on the Interfaces
The show ipv6 ospf interface command displays OSPFv3
information for switch interfaces configured for OSPFv3. Different command options allow the
display of all interfaces or a specified interface. You can configure the command to display
complete information or a summary.
Example
This command displays OSPFv3 information for interfaces where OSPFv3 is
enabled.
switch# show ipv6 ospf interface
Ethernet17 is up
Interface Address fe80::48c:73ff:fe00:1319%Ethernet12, Area 0.0.0.0
Network Type Broadcast, Cost 10
Transmit Delay is 1 sec, State Backup DR, Priority 1
Designated Router is 10.37.0.37
Backup Designated Router is 10.37.0.23
Timer intervals configured, Hello 10, Dead 40, Retransmit 5
Neighbor Count is 1
Vlan31 is up
Interface Address fe80::48c:73ff:fe00:1319%Vlan31, Area 0.0.0.0
Network Type Broadcast, Cost 10
Transmit Delay is 1 sec, State Backup DR, Priority 1
Designated Router is 10.37.0.22
Backup Designated Router is 10.37.0.23
Timer intervals configured, Hello 10, Dead 40, Retransmit 5
Neighbor Count is 1
Vlan32 is up
Interface Address fe80::48c:73ff:fe00:1319%Vlan32, Area 0.0.0.0
Network Type Broadcast, Cost 10
Transmit Delay is 1 sec, State DR Other, Priority 1
Designated Router is 10.37.0.11
Backup Designated Router is 10.37.0.22
Timer intervals configured, Hello 10, Dead 40, Retransmit 5
Neighbor Count is 2
switch#
Viewing the OSPFv3 Database
The show ipv6 ospf database <link state list> command
displays the LSAs in the LSDB for the specified area. If no area is listed, the command
displays the database's contents for each area on the switch. The database command provides
options to display subsets of the LSDB database, a summary of database contents, and the link
states that comprise the database.
Example
This command displays the OSPFv3 database of Link State Advertisements
(LSAs).
switch# show ipv6 ospf database
Routing Process "ospf 9":
AS Scope LSDB
Type Link ID ADV Router Age Seq# Checksum
AEX 0.0.0.5 10.37.0.37 15 0x80000005 0x00be82
AEX 0.0.0.9 10.37.0.22 1747 0x8000002b 0x00df56
AEX 0.0.0.3 10.37.0.46 599 0x8000002d 0x00651d
Area 0.0.0.0 LSDB
Type Link ID ADV Router Age Seq# Checksum
RTR 0.0.0.0 10.37.0.32 234 0x80000031 0x00585a
NTW 0.0.0.26 10.37.0.32 271 0x80000005 0x005609
NAP 0.0.0.26 10.37.0.32 274 0x80000005 0x00964c
Interface vlan3911 LSDB
Type Link ID ADV Router Age Seq# Checksum
LNK 0.0.0.38 10.37.0.22 267 0x80000005 0x00a45a
LNK 0.0.0.23 10.37.0.23 270 0x8000002c 0x005b7e
Interface vlan3902 LSDB
Type Link ID ADV Router Age Seq# Checksum
LNK 0.0.0.17 10.37.0.11 1535 0x8000002b 0x007120
LNK 0.0.0.37 10.37.0.22 7 0x8000002b 0x00ce23
LNK 0.0.0.22 10.37.0.23 250 0x8000002d 0x00c350
switch#
Viewing OSPFv3 Neighbors
The show ipv6 ospf neighbor command displays information about
the routers that are neighbors to the switch. Command options allow the display of summary or
detailed information about the neighbors to all areas and interfaces on the switch. The
command also allows for the display of neighbors to individual interfaces or areas. The
adjacency-changes option displays the interface's adjacency
changes.
Example
This command displays the switch's
neighbors.
switch# show ipv6 ospf neighbor
Routing Process "ospf 9":
Neighbor 10.37.0.37 priority is 1, state is Full
In area 0.0.0.0 interface et12
DR is 10.37.0.37 BDR is 10.37.0.23
Options is 0
Dead timer is due in 37 seconds
Neighbor 10.37.0.22 priority is 1, state is Full
In area 0.0.0.0 interface vlan3911
DR is 10.37.0.22 BDR is 10.37.0.23
Options is 0
Dead timer is due in 31 seconds
Neighbor 10.37.0.22 priority is 1, state is Full
In area 0.0.0.0 interface vlan3902
DR is 10.37.0.11 BDR is 10.37.0.22
Options is 0
Dead timer is due in 31 seconds
Neighbor 10.37.0.22 priority is 1, state is Full
In area 0.0.0.0 interface vlan3908
DR is 10.37.0.22 BDR is 10.37.0.21
Options is 0
Dead timer is due in 39 seconds
switch#
Viewing OSPFv3 Routes
The show ipv6 routes command provides an OSPFv3 option.
Example
This command displays the switch's OSPFv3
routes.
switch# show ipv6 route ospf
IPv6 Routing Table - 43 entries
Codes: C - connected, S - static, K - kernel, O - OSPF, B - BGP, R - RIP, A -
Aggregate
O fd7a:3279:81a4:1112::/64 [150/11]
via fe80::21c:41ff:fe00:d120, Ethernet12
O fd7a:3279:81a4:1114::/64 [150/11]
via fe80::21c:41ff:fe00:d120, Ethernet12
O fd7a:3279:81a4:1124::/64 [10/20]
via fe80::21c:41ff:fe01:5fe1, Vlan3901
via fe80::21c:41ff:fe01:5fe1, Vlan3902
via fe80::21c:41ff:fe01:5fe1, Vlan3908
O fd7a:3279:81a4:1a00::25/128 [150/11]
via fe80::21c:41ff:fe00:d120, Ethernet12
O fd7a:3279:81a4:1a00::28/128 [150/11]
via fd7a:3279:81a4:fe40::5, Vlan3908
Viewing OSPFv3 dn-bit-ignore
The show running-config command verifies whether the
dn-bit-ignore command is configured.
OSPFv3 Configuration Examples
This section describes the commands required to configure three OSPFv3 topologies.
OSPFv3 Configuration Example 1
The AS in Example 1 contains two areas that are connected through two routers. The backbone area also contains an internal router that connects two links.
Example 1 Topology
OSPFv3 Example 1 displays the Example 1 topology.
Two ABRs, Router A and Router B, connect
Area 0 and Area 1 . Router
C is an internal router connecting two links in Area
0. Area 0 is normal; area
1 is stub.
Figure 3. OSPFv3 Example 1
Area 1 Configuration
Area 1 contains links to ABRs Router A
and Router B.
Router A is accessed through VLAN
301.
Router B is accessed through VLAN
401.
Designated Router (DR): Router A.
Backup Designated Router (BDR): Router B.
Each router defines an interface cost of 10.
Router priority is not specified for either router on area
1.
Area 0 ABR Configuration
Area 0 contains links to ABRs Router A and Router
B.
Router A is accessed through VLAN
302.
Router B is accessed through VLAN
402.
Designated Router (DR): Router B.
Backup Designated Router (BDR): Router A.
Each router defines an interface cost of 20.
Each router defines a retransmit-interval of 10.
Each router defines a transmit-delay of 2.
Router priority is specified such that Router B will be
elected as the Designated Router.
Area 0 IR Configuration
Area 0 contains two links to an internal router.
Router C is accessed through VLAN
501 and VLAN 502.
VLAN 501 is configured as follows:
Interface cost of 20.
Retransmit-interval of 10.
Transmit-delay of 2.
VLAN 502 is configured as follows:
Interface cost of 20.
Dead interval of 80 seconds.
Example 1 Code
This code configures the OSPFv3
instances on the three switches.
The AS in Example 2 contains three areas. Area 0 connects
to the other areas through different routers and contains an internal router connecting two
links. Area 0 is normal; the other areas are stub
areas.
Example 2 Topology
OSPFv3 Example 2 displays the Example 2 topology. One
ABR (Router B) connects area 0 and area
1; another ABR (Router C) connects
area 0 and area 2. Router
A is an internal router connecting two links in area
0.
Figure 4. OSPFv3 Example 2
Area 1 Configuration
Area 1 contains one link that is accessed by Router
B.
Router B is accessed
through VLAN 601.
The router defines a interface cost of
10.
Area 2 Configuration
Area 2 contains one link that is accessed by Router
C.
Router C is accessed
through VLAN 802.
The router defines a interface cost of
20.
Area 0 ABR Configuration
One ABR Router B link connects area 1 to area
0. One ABR
Router C link connects
area 0 to area
2.
Router
B is accessed through
VLAN 602
Router C is accessed
through VLAN 801.
Designated Router (DR): Router
B.
Backup Designated Router (BDR):
Router C.
Each router defines an interface cost of
20.
Each router defines a retransmit-interval of
10.
Each router defines a transmit-delay of
2.
Area 0 IR Configuration
Area 0 contains links connected by an internal router.
Router A is accessed through vlan
701 and vlan
702.
The AS in Example 3 contains two areas that connect through one ABR. Each area also contains an ASBR that connects static routes to the AS.
Example 3 Topology
OSPFv3 Example 3 displays the Example 3 topology. One
ABR connects area 0 and area 1.
Router C is an ABR connecting the areas. Router
A is an internal router connecting two links in area
1. Router D and Router
E are internal routers connecting links in area 0.
Router B and Router F are ASBRs that
connect static routes outside the AS to area 1 and area
0, respectively.
Figure 5. OSPFv3 Example 3
Area 0 ABR Configuration
ABR Router C connects one area 0 link to an
area 1 link.
Router C is accessed through VLAN
1302.
All interface OSPFv3 parameters are set to their default values.
Area 0 IR Configuration
Area 0 contains two internal routers, each of which connects two of the
three links in the area.
Router D is accessed through VLAN
1401 and VLAN 1402.
Router E is accessed through VLAN
1501 and VLAN 1502.
All interface OSPFv3 parameters are set to their default values.
Area 0 ASBR Configuration
ASBR Router F connects one area 0 link to an
external link.
Router F is accessed through VLAN
1601.
Router F connects to the external AS through
VLAN 1602.
All interface OSPFv3 parameters are set to their default values.
Area 1 ABR Configuration
ABR Router C connects one area 0 link to an
area 1 link.
Router C is accessed by area
1 through VLAN 1301.
Router C is accessed by area 0
through VLAN 1302.
All interface OSPFv3 parameters are set to their default values.
Area 1 IR Configuration
Area 1 contains one internal router that connects two links in the
area.
Router A is accessed through VLAN
1101 and VLAN 1102.
All interface OSPFv3 parameters are set to their default values.
Area 1 ASBR Configuration
ASBR Router B connects one area 1 link to an
external link.
Router B is access through VLAN
1201.
Router B connects to the external AS through
VLAN 1202.
All interface OSPFv3 parameters are set to their default values.
The adjacency exchange-start threshold command sets the
exchange-start options for an OSPF instance.
The no adjacency exchange-start threshold and
default adjacency exchange-start threshold command
resets the default by removing the corresponding adjacency
exchange-start threshold command from the
running-config.
Command Mode
Router-OSPFv3 Configuration
Command Syntax
adjacency exchange-start threshold peers
no adjacency exchange-start threshold
default adjacency exchange-start threshold
Parameter
peers Value ranges from 1 -
4294967295. Default value is 10.
Example
This command sets the adjacency exchange start threshold to
156923.
Passphrase and key value are exclusive. MD5
and SHA1 keys are derived from the configured passphrase.
Restriction
On the same area, EOS allows security configuration
with either AH or ESP but not both. We can have one area configured with
AH and another with ESP.
Examples
This command configures OSPFv3 authentication on an area with MD5 hash
algorithm.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# area 0.0.0.0 authentication ipsec spi 34 md5 0 8FD6158BFE81ADD961241D8E4169D411
switch(config-router-ospf3)# show active
ipv6 router ospf 9
area 0.0.0.0 authentication ipsec spi 34 md5 7 $1$cNpcrQl1czqdvKAzKLtYVr6I7+R3niuWouDKKYCFNs4/XOWG/Iap5Q==
switch(config-router-ospf3)#
This command configures OSPFv3 authentication on an area with SHA1
algorithm.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# area 0.0.0.0 authentication ipsec spi 5789 sha1 passphrase 7 $1$Ab754G0OHbGllIKqlCl7lyUKscUlpFTpvcQxQIhjJm1OUzGJDh4bLWxSdKHvWMo6
switch(config-router-ospf3)# show active
ipv6 router ospf 9
area 0.0.0.0 authentication ipsec spi 5789 sha1 passphrase 7
Ab754G0OHbGllIKqlCl7lyUKscUlpFTpvcQxQIhjJm1OUzGJDh4bLWxSdKHvWMo6
switch(config-router-ospf3)#
This command deletes the OSPFv3 authentication on an area.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# show active
ipv6 router ospf 9
area 1.1.1.1 authentication ipsec spi 2437 md5 7 cNpcrQl1czqdvKAzKLtYVr6I7+R3niuWouDKKYCFNs4/XOWG/Iap5Q==
area 0.0.0.0 authentication ipsec spi 5789 sha1 passphrase 7
Ab754G0OHbGllIKqlCl7lyUKscUlpFTpvcQxQIhjJm1OUzGJDh4bLWxSdKHvWMo6
switch(config-router-ospf3)#no area 0.0.0.0 authentication
switch(config-router-ospf3)#show active
ipv6 router ospf 9
area 1.1.1.1 authentication ipsec spi 2437 md5 7 cNpcrQl1czqdvKAzKLtYVr6I7+R3niuWouDKKYCFNs4/XOWG/Iap5Q==
switch(config-router-ospf3)#
area default-cost (OSPFv3)
The area default-cost command sets the cost for the default
summary routes sent into an area. When the area
default-cost command is not configured for an area, the
default-cost of that area is set to 10.
The no area default-cost and default area
default-cost command resets the default-cost value of the
specified area to 10 by removing the corresponding
area default-cost command from
running-config. The no area
(OSPFv3) command removes all area commands for the
specified area from running-config, including the area
default-cost command.
Command Mode
Router-OSPFv3 Configuration
Command Syntax
areaarea_iddefault-costdef_cost
no areaarea_iddefault-cost
default areaarea_iddefault-cost
Parameters
area_id area number. 0
to 4294967295 or 0.0.0.0
to 255.255.255.255. Running-config
stores value in dotted decimal notation.
def_cost Values range from 1 to
65535.
Example
These commands configure a cost of 15 for default summary
routes that an ABR sends into area
100.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# area 100 default 15
switch(config-router-ospf3)# show active
ipv6 router ospf 9
area 0.0.0.100 default-cost 15
switch(config-router-ospf3)#
area encryption ipsec
spi
The area encryption ipsec spi command configures OSPFv3
security on an area.
The default area encryption andno area
encryptioncommands delete the OSPFv3 security on an area.
Passphrase and key values are
exclusive. MD5 and SHA1 keys are
derived from the configured passphrase.
Restriction
On the same area, EOS allows security configuration
with either AH or ESP but not both. We can have one area configured with
AH and another with ESP.
Examples
This command configures OSPFv3 security on an area with 3DES-CBC encryption
and MD5 hash
algorithm.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# area 0.0.0.0 encryption ipsec spi 5678 esp 3des-cbc md5 passphrase 0
8FD6158BFE81ADD961241D8E4169D411
switch(config-router-ospf3)# show active
ipv6 router ospf 9
area 0.0.0.0 encryption ipsec spi 5678 esp 3des-cbc md5 passphrase 7
$1$cNpcrQl1czqdvKAzKLtYVr6I7+R3niuWouDKKYCFNs4/XOWG/Iap5Q==
switch (config-router-ospf3)#
This command deletes the OSPFv3 security on an area.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# show active
ipv6 router ospf 9
area 0.0.0.0 encryption ipsec spi 5678 esp 3des-cbc md5 passphrase 7
$1$cNpcrQl1czqdvKAzKLtYVr6I7+R3niuWouDKKYCFNs4/XOWG/Iap5Q==
switch(config-router-ospf3)# no area 0.0.0.0 encryption
switch(config-router-ospf3)# show active
ipv6 router ospf 9
switch(config-router-ospf3)#
area not-so-stubby lsa
type-7 convert type-5 (OSPFv3)
The area not-so-stubby lsa type-7 convert type-5 command
configures the switch to always translate Type-7 Link-State Advertisement (LSAs) to
Type-5 LSAs.
The no area not-so-stubby lsa type-7 convert type-5 and no area not-so-stubby lsa type-7 convert type-5
commands allow LSAs to be translated dynamically by removing the no area
not-so-stubby lsa type-7 convert type-5 command from the
running-config.
The area nssa command configures an OSPFv3 area as a
Not-So-Stubby Area (NSSA). All routers in an AS must specify the same area type for
identically numbered areas.
NSSA ASBRs advertise external LSAs that
are part of the area, but do not advertise external LSAs from other areas.
Areas are normal by default; area type configuration is required only for stub
NSSA areas. Area 0 is always a normal area and cannot be
configured through this command.
The no area nssa command configures the specified area as a
normal area by removing the specified area nssa command
from running-config.
Command Mode
Router-OSPFv3 Configuration
Command Syntax
areaarea_idnssa [TYPE]
no areaarea_idnssa [TYPE]
default areaarea_idnssa [TYPE]
Parameters
area_id
Valid formats: integer 1 to
4294967295 or dotted decimal
0.0.0.1 to
255.255.255.255.
Area 0 (or
0.0.0.0) is not configurable; it is
always normal.
The running-config stores value in dotted decimal
notation.
The area nssa default-information-originate command sets an
area as an NSSA and the generation of a type 7 default LSA is created if a default
route exists in the routing table.
The switch supports three area types:
Areas are normal by default; area type configuration is required only for stub
NSSA areas. Area 0 is always a normal area and cannot be
configured through this command.
The no areaand default area
commands remove the specified area from the OSPFv3 instance by deleting all
area commands from the
running-config for the specified area, including the area default-cost (OSPFv3) command.
The no area stub and default area
stub commands configure the specified area as a normal
area.
The default-metric command sets default metric value for
routes redistributed into the OSPFv3 domain.
The no default-metric and default
default-metric commands restores the default metric to its
default value of 10 by removing the
default-metric command from the
running-config.
Command Mode
Router-OSPFv3 Configuration
Command Syntax
default-metricdef_metric
no default-metric
default default-metric
Parameter
def_metric Values range from 1 to
65535. Default value is 10.
Example
These commands configure a default metric of 30 for routes
redistributed into
OSPFv3.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# default-metric 30
switch(config-router-ospf3)# show active
ipv6 router ospf 9
default-metric 30
switch(config-router-ospf3)#
distance ospf intra-area
(OSPFv3)
The distance ospf intra-area command sets the
administrative distance for routes in a single OSPFv3 area. The default is
110.
The no distance ospf intra-area and default
distance ospf intra-area commands remove the
distance ospf intra-area command from the
running-config, returning the OSPFv3 intra-area distance
setting to the default value of 110
Command Mode
Router-OSPFv3 Configuration
Command Syntax
distance ospf intra-areadistance
no distance ospf intra-area
default distance ospf intra-area
Parameter
distance Values range from 1 to 255. Default is
110.
Example
This command configures a distance of 90 for all OSPFv3
intra-area routes on the
switch.
The ipv6 ospf area command enables OSPFv3 on the interface
and associates the area to the interface.
OSPFv3 areas are configured in by no area (OSPFv3) commands in
router-OSPFv3 configuration mode.
The no ipv6 ospf area and default ipv6 ospf
area commands disable OSPFv3 on the configuration mode
interface by removing the corresponding ipv6 ospf area
command from the running-config.
Command Mode
Interface-Ethernet Configuration
Interface-Loopback Configuration
Interface-Port-Channel Configuration
Interface-VLAN Configuration
Command Syntax
ipv6 ospfprocess_id [areaarea_id]
no ipv6 ospfprocess_id [areaarea_id]
default ipv6 ospfprocess_id [areaarea_id]
Parameters
process_id Values range from 1 to
65535.
area_id.
Valid formats: integer 0 to
4294967295 or dotted decimal
0.0.0.0 to
255.255.255.255.
Running-config stores value in dotted decimal
notation.
Example
These commands enable OSPFv3 on VLAN interface 200 and
associates area 0 to the
interface.
switch(config)# interface vlan 200
switch(config-if-Vl200)# ipv6 ospf 9 area 0
switch(config-if-Vl200)# show active
interface Vlan200
ipv6 ospf 9 area 0.0.0.0
switch(config-if-Vl200)#
ipv6 router ospf
The ipv6 router ospf command places the switch in
router-OSPFv3 configuration mode and creates and OSPFv3 instance if one does not
already exist. Note that each OSPFv3 instance on the switch must have a unique
process ID. A router ID for the new instance will be created if one does not already
exist.
The show ipv6 ospf command displays the router ID of each
OSPFv3 instance configured on the switch.
The no ipv6 router ospf and default ipv6 router
ospf commands delete the OSPFv3 instance.
This command creates an OSPFv3 instance in the default VRF with process ID
9.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# show active
ipv6 router ospf 9
switch(config-router-ospf3)#
This command deletes the OSPFv3
instance.
switch(config)# no ipv6 router ospf 9
switch(config)#
log-adjacency-changes
(OSPFv3)
The log-adjacency-changes command enables syslog messages
to be sent when it detects OSPFv3 link state changes or when it detects that a
neighbor has gone up or down. Log message sending is enabled by default.
The default log-adjacency-changes command restores the
default state by removing the log-adjacency-changes
statement from the running-config.
The default option (sending a message only when a neighbor goes up or down) is active
when the running-config does not contain any form of the command.
Entering the command in any form replaces the previous command state in the
running-config.
The no log-adjacency-changes disables link state change
Syslog reporting.
The default log-adjacency-changes command restores the
default state by removing the log-adjacency-changes detail
or no log-adjacency-changes statement from the
running-config.
Command Mode
Router-OSPFv3 Configuration
Command Syntax
log-adjacency-changes [INFO_LEVELdetail]
no log-adjacency-changes
default log-adjacency-changes
Parameters
INFO_LEVEL Options include:
no parameter Sends messages when a neighbor goes up or down.
detail Sends messages for all neighbor state
changes.
Example
This command configures the switch to send a Syslog message when a neighbor state
changes.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# log-adjacency-changes
switch(config-router-ospf3)# show active
ipv6 router ospf 9
log-adjacency-changes
switch(config-router-ospf3)#
maximum-paths (OSPFv3)
The maximum-paths command sets the maximum number of
parallel routes that OSPFv3 supports on the switch.
The no maximum-paths command restores the maximum number of
parallel routes that OSPFv3 supports on the switch to the default value of
16 by removing the
maximum-paths command from
running-config.
Command Mode
Router-OSPFv3 Configuration
Command Syntax
maximum-pathspaths
no maximum-paths
default maximum-paths
Parameters
paths Value range is platform dependent:
Arad: Value ranges from 1 to 128. Default
value is 128.
FM6000: Value ranges from 1 to 32. Default
value is 32.
PetraA: Value ranges from 1 to 16. Default
value is 16.
Trident: Value ranges from 1 to 32. Default
value is 32.
Trident II: Value ranges from 1 to 128.
Default value is 128.
Example
This command configures the maximum number of OSPFv3 parallel paths to
12.
The max-metric router-lsa command configures OSPF to
include the maximum value in LSA metric fields to keep other network devices from
using the switch as a preferred intermediate SPF hop.
The no max-metric router-lsa and default
max-metric router-lsa commands disable the advertisement of a
maximum metric.
The no area command removes all area configuration
commands for the specified OSPFv3 area. Commands removed by the no
area command include:
area
nssa
range
stub
Area settings can be removed individually; refer to the command
description page of the desired command for details.
Command
Mode
Router-OSPFv3 Configuration
Command Syntax
no
areaarea_id [TYPE]
default
areaarea_id [TYPE]
Parameters
area_id area number.
Valid formats: integer 1 to
4294967295 or dotted decimal
0.0.0.1 to
255.255.255.255.
Area 0 (or
0.0.0.0) is not configurable; it is
always normal.
The running-config stores value in dotted decimal
notation.
TYPE area type. Values include:
nssa.
nssa translate type7 always.
stub.
stub no-summary.
Example
This command remove the area
1 stub
configuration.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# no area 1 stub
switch(config-router-ospf3)#
ospfv3 transmit-delay
Theospfv3 transmit-delay command configures the
transmission delay for OSPFv3 packets.
The no ospfv3
transmit-delay and default ospfv3
transmit-delay commands restore the default transmission delay
of 1 second on the configuration mode interface by
removing the corresponding ospfv3 transmit-delay command
from running-config.
Command
Mode
Interface-Ethernet Configuration
Interface-Loopback
Configuration
Interface-Port-Channel Configuration
Interface-VLAN
Configuration
Command Syntax
ospfv3 transmit-delaytrans
no ospfv3
transmit-delay
default ospfv3
transmit-delay
Parameter
trans Value ranges from 1 to
65535; default is
1.
Guideline
Arista devices also
support the legacy ipv6 ospf transmit-delay command in
certain software releases of the EOS.
Example
This command configures a
transmission delay of 10 seconds for VLAN
200.
switch(config)# interface vlan 200
switch(config-if-Vl200)# ospfv3 transmit-delay 10
switch(config-if-Vl200)# show active
interface Vlan200
ospfv3 transmit-delay 10
switch(config-if-Vl200)#
ospfv3 authentication
ipsec spi
The ospfv3 authentication ipsec spi command configures
OSPFv3 authentication on an interface.
The default ospfv3 authentication and no
ospfv3 authentication commands delete the OSPFv3
authentication on an interface.
Passphrase and key values are
exclusive. MD5 and SHA1 keys are
derived from the configured passphrase. Arista devices also support the legacy
ipv6 ospf authentication ipsec spi command in certain software releases of the EOS.
Restriction
On the same interface, EOS allows security
configuration with either AH or ESP but not both. We can have one interface
configured with AH and another with ESP.
Examples
This command configures OSPFv3 authentication on an interface with MD5 hash
algorithm.
switch(config)# interface ethernet 9
switch(config-if-Et9)# ospfv3 authentication ipsec spi 3456 md5 0 8FD6158BFE81ADD961241D8E4169D411
switch(config-if-Et9)# show active
interface Ethernet9
no switchport
ospfv3 authentication ipsec spi 3456 md5 7 $1$xtmcMSPzEn+Njp8Lb4qryVVOjKcjsrYuv6dx1O+nSwKQdaiRt2RPTQ==
switch(config-if-Et9)#
This command configures OSPFv3 authentication on an interface with SHA1
algorithm.
switch(config)# interface ethernet 9
switch(config-if-Et9)# ospfv3 authentication ipsec spi 987 sha1 7 $1$VmUkWk6IL2S343bR3BbH0RhgvxHhwBpfvB4VXKNOOQF7HJBp5VvXTfBaVYbgCkWU
switch(config-if-Et9)# show active
interface Ethernet9
no switchport
ospfv3 authentication ipsec spi 987 sha1 7
$1$VmUkWk6IL2S343bR3BbH0RhgvxHhwBpfvB4VXKNOOQF7HJBp5VvXTfBaVYbgCkWU
switch(config-if-Et9)#
This command deletes the OSPFv3 authentication on an interface.
switch(config)# interface ethernet 9
switch(config-if-Et9)# show active
interface Ethernet9
no switchport
ospfv3 authentication ipsec spi 3456 md5 7 $1$xtmcMSPzEn+Njp8Lb4qryVVOjKcjsrYuv6dx1O+nSwKQdaiRt2RPTQ==
switch(config-if-Et9)#no ospfv3 authentication
switch(config-if-Et9)#show active
interface Ethernet9
no switchport
switch(config-if-Et9)#
ospfv3 cost
The ospfv3 cost command sets the OSPFv3 cost for the
interface. The default OSPFv3 cost is 10.
The no ospfv3 cost and default ospfv3
cost commands restore the default cost of
10 for the configuration mode interface by
removing the corresponding ospfv3 cost command from the
running-config.
Command Mode
Interface-Ethernet Configuration
Interface-Loopback Configuration
Interface-Port-Channel Configuration
Interface-VLAN Configuration
Command Syntax
ospfv3 costinterface_cost
no ospfv3 cost
default ospfv3 cost
Parameters
interface_cost Value ranges from 1 to
65535; default is 10.
Guideline
Arista devices also support the legacy ipv6 ospf cost
command in certain software releases of the EOS.
Example
This command configures a cost of 50 for vlan
200.
switch(config)# interface vlan 200
switch(config-if-Vl200)# ospfv3 cost 50
switch(config-if-Vl200)# show active
interface Vlan200
ospfv3 cost 50
switch(config-if-Vl200)#
ospfv3 dead-interval
The ospfv3 dead-interval command sets the OSPFv3 dead
interval.
The no ospfv3 dead-interval and default ospfv3
dead-interval commands restore the default dead interval of
40 seconds on the configuration mode interface by
removing the corresponding ospfv3 dead-interval command
from the running-config.
Command Mode
Interface-Ethernet Configuration
Interface-Loopback Configuration
Interface-Port-Channel Configuration
Interface-VLAN Configuration
Command Syntax
ospfv3 dead-intervaltime
no ospfv3 dead-interval
default ospfv3 dead-interval
Parameter
time Value ranges from 1 to
65535; default is 40.
Guideline
Arista devices also support the legacy ipv6 ospf
dead-interval command in certain software releases of the EOS.
Example
This command configures a dead interval of 75 seconds for
vlan
200.
switch(config)# interface vlan 200
switch(config-if-Vl200)# ospfv3 dead-interval 75
switch(config-if-Vl200)# show active
interface Vlan200
ospfv3 dead-interval 75
switch(config-if-Vl200)#
ospfv3 encryption ipsec
spi
The ospfv3 encryption ipsec spi command configures OSPFv3
security on an interface.
The default ospf3 encryption and no ospfv3
encryption commands delete the OSPFv3 security on an
interface.
Passphrase and key value are exclusive. MD5 and SHA1 keys are derived from the
configured passphrase. Arista devices also support the legacy ipv6 ospf
encryption ipsec spi command in certain software releases of the EOS.
Restrictions
On the same interface, EOS allows security
configuration with either AH or ESP but not both. We can have one interface
configured with AH and another with ESP.
Examples
This command configures OSPFv3 security on an interface with 3DES-CBC
encryption and SHA1
algorithm.
This command deletes the OSPFv3 security on an interface.
switch(config)# interface ethernet 9
switch(config-if-Et9)# show active
interface Ethernet9
no switchport
ospfv3 encryption ipsec spi 3456 md5 7 $1$xtmcMSPzEn+Njp8Lb4qryVVOjKcjsrYuv6dx1O+nSwKQdaiRt2RPTQ==
switch(config-if-Et9)#no ospfv3 encryption
switch(config-if-Et9)#show active
interface Ethernet9
no switchport
switch(config-if-Et9)#
ospfv3 hello-interval
The ospfv3 hello-interval command sets the OSPFv3 hello
interval. The hello interval is the period between the transmission of consecutive
hello packets.
Each OSPFv3 neighbor should be the same
hello interval and should not be longer than any neighbors dead interval.
The no ospfv3 hello-interval and default ospfv3
hello-interval commands restore the default hello interval of
10 seconds on the configuration mode interface by
removing the ospfv3 hello-interval command from
running-config.
Command Mode
Interface-Ethernet Configuration
Interface-Loopback Configuration
Interface-Port-Channel Configuration
Interface-VLAN Configuration
Command Syntax
ospfv3 hello-intervaltime
no ospfv3 hello-interval
default ospfv3 hello-interval
Parameter
timeValues range from 1 to
65535; default is 10.
Guideline
Arista devices also support the legacy ipv6 ospf
hello-interval command in certain software releases of the
EOS.
Example
This command configures a hello interval of 45 seconds for
vlan
200.
switch(config)# interface vlan 200
switch(config-if-Vl200)# ospfv3 hello-interval 45
switch(config-if-Vl200)# show active
interface Vlan200
ospfv3 hello-interval 45
switch(config-if-Vl200)#
ospfv3 ipv6 retransmit-interval
The ospfv3 ipv6 retransmit-interval command configures the
link state advertisement retransmission interval.
The no ospfv3 ipv6 retransmit-interval and
default ospfv3 ipv6 retransmit-interval commands
restore the default retransmission interval of 5 seconds
on the configuration mode interface by removing the corresponding ospfv3
ipv6 retransmit-interval command from the running-config.
Command Mode
Interface-Ethernet Configuration
Interface-Loopback Configuration
Interface-Port-Channel Configuration
Interface-VLAN Configuration
Command Syntax
ospfv3 ipv6 retransmit-intervalperiod
no ospfv3 ipv6 retransmit-interval
default ospfv3 ipv6 retransmit-interval
Parameter
period Value ranges from 1 to
65535; default is 5.
Example
This command configures a retransmission interval of 25
seconds for vlan
200.
switch(config)# interface vlan 200
switch(config-if-Vl200)# ospfv3 ipv6 retransmit-interval 25
switch(config-if-Vl200)# show active
interface Vlan200
ospfv3 ipv6 retransmit-interval 25
switch(config-if-Vl200)#
ospfv3 network
The ospfv3 network command sets the configuration mode
interface as a point-to-point link. By default, interfaces are set as broadcast
links.
The no ospfv3 network and default ospfv3
network commands set the configuration mode interface as a
broadcast link by removing the corresponding ospfv3
network command from the running-config.
Command Mode
Interface-Ethernet Configuration
Interface-Loopback Configuration
Interface-Port-Channel Configuration
Interface-VLAN Configuration
Command Syntax
ospfv3 networkpoint-to-point
no ospfv3 network
default ospfv3 network
Guideline
Arista devices also support the legacy ipv6 ospf network
command in certain software releases of the EOS.
Examples
This command configures interface vlan 200 as a
point-to-point
link.
switch(config)# interface vlan 200
switch(config-if-Vl200)# ospfv3 network point-to-point
switch(config-if-Vl200)# show active
interface Vlan200
ospfv3 network point-to-point
switch(config-if-Vl200)#
This command restores interface ethernet 10 as a
broadcast
link.
switch(config)# interface vlan 200
switch(config-if-Vl200)# no ospfv3 network
switch(config-if-Vl200)# show active
interface Vlan200
switch(config-if-Vl200)#
ospfv3 priority
The ospfv3 priority command configures the OSPFv3 router
priority.
The no ospfv3 priority and default ospfv3
priority commands restore the default priority
(1) on the interface by removing the corresponding
ospfv3 priority command from the
running-config.
Command Mode
Interface-Ethernet Configuration
Interface-Loopback Configuration
Interface-Port-Channel Configuration
Interface-VLAN Configuration
Command Syntax
ospfv3 prioritypriority_level
no ospfv3 priority
default ospfv3 priority
Parameter
priority_level Settings range from 0 to
255.
Guideline
Arista devices also support the legacy ipv6 ospf
prioritycommand in certain software releases of the EOS.
Example
This command configures a router priority of 128 for
vlan
200.
switch(config)# interface vlan 200
switch(config-if-Vl200)# ospfv3 priority 128
switch(config-if-Vl200)# show active
interface Vlan200
ospfv3 priority 128
switch(config-if-Vl200)#
passive-interface (OSPFv3)
The passive-interface command disables OSPF on an interface
range. All interfaces are active by default.
The no passive-interface and default
passive-interface commands enable OSPFv3 on the specified
interface range by removing the corresponding
passive-interface statements from the
running-config.
Command Mode
Router-OSPFv3 Configuration
Command Syntax
passive-interfaceINTERFACE_NAME
no passive-interfaceINTERFACE_NAME
default passive-interfaceINTERFACE_NAME
Parameters
INTERFACE_NAME Options include:
ethernet e_range
loopback l_range
management m_range
port-channel p_range
vlan v_range
VXLAN vx_range
default
Valid e_range, l_range,
m_range, p_rangev_range, and vx_range formats
include number, range, or comma-delimited list of numbers and ranges.
Example
This command configures VLAN interfaces 101 through
103 as passive
interfaces.
The redistribute command enables the advertising of all
specified routes into the OSPFv3 domain as external routes.
The no redistribute and default
redistribute commands remove the corresponding
redistribute command from the
running-config, disabling route redistribution for the
specified route type.
Command Mode
Router-OSPFv3 Configuration
Command Syntax
redistributeROUTE_TYPEROUTE_MAP
no redistribute ROUTE_TYPE
default redistribute ROUTE_TYPE
Parameters
ROUTE_TYPE Options include:
BGP
connected
static
ROUTE_MAP Options include:
route-mapmap_name
Example
The redistribute static command starts the advertising of
static routes as OSPFv3 external
routes.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# redistribute static
switch(config-router-ospf3)# show active
ipv6 router ospf 9
redistribute connected
redistribute static
switch(config-router-ospf3)#
router-id (OSPFv3)
The router-id command assigns the router ID for an OSPFv3
instance. The switch sets the router ID to the first available alternative in the
following list:
The router-id command.
The loopback IPv4 address.
The highest IPv4 address present on the device.
Note: When configuring VXLAN
on an MLAG, always manually configure the OSPFv3 router ID to prevent the
switch from using the common VTEP IP address as the router
ID.
Note: You must configure the router ID on IPv6 switches or the OSPFv3 router does not
start.
The no router-id and default
router-id commands remove the router ID command from the
running-config.
Command Mode
Router-OSPFv3 Configuration
Command Syntax
router-ididentifier
no router-id
default router-id
Parameters
identifier Value ranges from 0.0.0.0 to
255.255.255.255 (dotted decimal notation).
Example
This command assigns 10.10.1.4 as the router ID for the
OSPFv3 instance.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# router-id 10.10.1.4
switch(config-router-ospf3)# show active
ipv6 router ospf 9
router-id 15.10.1.4
switch(config-router-ospf3)#
show ipv6 ospf border-routers
The show ipv6 ospf border-routers command displays the OSPF
routing table entries.
Command Mode
EXEC
Command Syntax
show ipv6 ospf border-routers
[VRF_INSTANCEvrfvrf_name]
Parameters
VRF_INSTANCE Values include:
no parameter Displays information for all
VRFs.
vrfvrf_name Displays information for the
specified VRF.
Example
This command displays the ABRs and ASBRs configured in the switch in all
VRFs.
switch# show ipv6 ospf border-routers
Routing Process "ospf 9", VRF default
Router 10.37.0.32 area 0.0.0.0 ASBR
Router 10.37.0.18 area 0.0.0.0 ASBR
Router 10.37.0.22 area 0.0.0.0 ASBR ABR
Router 10.37.0.31 area 0.0.0.0 ASBR ABR
Router 10.37.0.58 area 0.0.0.0 ASBR
Router 10.37.0.37 area 0.0.0.0 ASBR
Router 10.37.0.22 area 0.0.0.2 ASBR ABR
Router 10.37.0.31 area 0.0.0.2 ASBR ABR
show ipv6 ospf database
link if-name
The show ipv6 ospf database link command displays link
state advertisement details. The switch can return link state data about a single
area or for all areas on the switch.
Command Mode
EXEC
Command Syntax
show ipv6 ospfdatabase link if-name
[INTF_ID][LS_ID][ROUTER][DATA_LEVEL]
Parameters
INTF_ID Options include:
ethernete_range Ethernet interface list.
loopbackl_range Loopback interface list.
managementm_range Management interface list.
port-channelp_range Channel group interface list.
vlanv_range VLAN interface list.
VXLANvx_range VXLAN interface list.
Valid
range formats include number,
range, or comma-delimited list of numbers and
ranges.
LS_ID Options include:
no parameter
A.B.C.D
ROUTER Options include:
no parameter
adv-routera.b.c.d
self-originate
DATA_LEVEL Options include:
no parameter
detail
Example
This command displays information for ethernet 4/1 link
state advertisements.
switch# show ipv6 ospf database link if-name ethernet 4/1
Codes: AEX - AS External, GRC - Grace,
IAP - Inter Area Prefix, IAR - Inter Area Router,
LNK - Link, NAP - Intra Area Prefix,
NSA - Not So Stubby Area, NTW - Network,
RTR - Router
Routing Process "ospf 1":
show ipv6 ospf database
link if-type
The show ipv6 ospf database link command displays
information of the link state advertisements. The switch can return link state data
about a single area or for all areas on the switch.
Command Mode
EXEC
Command Syntax
show ipv6 ospfdatabase link if-type
[INTF_TYPE][LS_ID][ROUTER][DATA_LEVEL]
Parameters
INTF_TYPE
broadcast
nbma
p2mp
p2p
LS_ID Options include:
no parameter
A.B.C.D
ROUTER Options include:
no parameter
adv-routera.b.c.d
self-originate
DATA_LEVEL Options include:
no parameter
detail
Example
This command displays LSA information for the interfaces configured for broadcast
transmissions.
switch# show ipv6 ospf database link if-type broadcast
Codes: AEX - AS External, GRC - Grace,
IAP - Inter Area Prefix, IAR - Inter Area Router,
LNK - Link, NAP - Intra Area Prefix,
NSA - Not So Stubby Area, NTW - Network,
RTR - Router
Routing Process "ospf 1":
Interface et4 LSDB
Type Link ID ADV Router Age Seq# Checksum
LNK 0.0.0.61 10.26.0.49 1378 0x80000027 0x00f8b0
LNK 0.0.0.20 10.26.0.23 1371 0x80000027 0x005423
Interface et7 LSDB
Type Link ID ADV Router Age Seq# Checksum
LNK 0.0.0.61 10.26.0.50 1298 0x80000028 0x005e0d
LNK 0.0.0.38 10.26.0.23 1291 0x80000028 0x00ce8d
Interface vlan3901 LSDB
Type Link ID ADV Router Age Seq# Checksum
LNK 0.0.0.36 10.26.0.22 216 0x800000b0 0x00c2b1
LNK 0.0.0.19 10.26.0.23 231 0x800000b0 0x00cfca
show ipv6 ospf database
<link state list>
The show ipv6 ospf database command displays the OSPF link
state advertisements that originate on a switch.
Command Mode
EXEC
Command Syntax
show ipv6 ospfdatabase
[FILTER][LINKSTATE_ID][ROUTER][DATA_LEVEL]
Parameters
FILTER Filters the output of the command by
specifying areas. Options include:
no parameter
area A.B.C.D
area backbone
as
as external
LINKSTATE_ID Options include:
no parameter
A.B.C.D
ROUTER Options include:
no parameter
adv-routera.b.c.d
self-originate
DATA_LEVEL Options include:
no parameter
detail
Example
This command displays the OSPFv3 database of link state
advertisements.
switch# show ipv6 ospf database 10.26.0.23
Codes: AEX - AS External, GRC - Grace,
IAP - Inter Area Prefix, IAR - Inter Area Router,
LNK - Link, NAP - Intra Area Prefix,
NSA - Not So Stubby Area, NTW - Network,
RTR - Router
Routing Process "ospf 9":
AS Scope LSDB
Type Link ID ADV Router Age Seq# Checksum
AEX 0.0.0.5 10.37.0.37 15 0x80000005 0x00be82
AEX 0.0.0.9 10.37.0.22 1747 0x8000002b 0x00df56
AEX 0.0.0.3 10.37.0.46 599 0x8000002d 0x00651d
Area 0.0.0.0 LSDB
Type Link ID ADV Router Age Seq# Checksum
RTR 0.0.0.0 10.37.0.32 234 0x80000031 0x00585a
NTW 0.0.0.26 10.37.0.32 271 0x80000005 0x005609
NAP 0.0.0.26 10.37.0.32 274 0x80000005 0x00964c
Interface vlan3911 LSDB
Type Link ID ADV Router Age Seq# Checksum
LNK 0.0.0.38 10.37.0.22 267 0x80000005 0x00a45a
LNK 0.0.0.23 10.37.0.23 270 0x8000002c 0x005b7e
Interface vlan3902 LSDB
Type Link ID ADV Router Age Seq# Checksum
LNK 0.0.0.17 10.37.0.11 1535 0x8000002b 0x007120
LNK 0.0.0.37 10.37.0.22 7 0x8000002b 0x00ce23
LNK 0.0.0.22 10.37.0.23 250 0x8000002d 0x00c350
show ipv6 ospf database
link
The show ipv6 ospf database link command displays details
of the specified link state advertisements. The switch can return link state data
about a single area or for all areas on the switch.
Command Mode
EXEC
Command Syntax
show ipv6 ospf database link
[LINKSTATE_ID][ROUTER][DATA_LEVEL]
Parameters
LINKSTATE_ID Options include:
no parameter
A.B.C.D
ROUTER Options include:
no parameter
adv-routera.b.c.d
self-originate
DATA_LEVEL Options include:
no parameter
detail
Example
This command displays information about the Open Shortest Path First
(OSPF).
switch# show ipv6 ospf database link
Codes: AEX - AS External, GRC - Grace,
IAP - Inter Area Prefix, IAR - Inter Area Router,
LNK - Link, NAP - Intra Area Prefix,
NSA - Not So Stubby Area, NTW - Network,
RTR - Router
Routing Process "ospf 9":
show ipv6 ospf database
The show ipv6 ospf database command displays data from the
OSPF database. The switch can return link state data for a single VRF or for all
VRFs on the switch.
Command Mode
EXEC
Command Syntax
show ipv6 ospf database [VRF_INSTANCEvrfvrf_name]
Parameters
VRF_INSTANCE Values include:
no parameter Displays information for all VRFs.
vrfvrf_name Displays information for the
specified VRF.
Example
This command displays OSPF database information for VRF
blue.
switch# show ipv6 ospf database vrf blue
Codes: AEX - AS External, GRC - Grace,
IAP - Inter Area Prefix, IAR - Inter Area Router,
LNK - Link, NAP - Intra Area Prefix,
NSA - Not So Stubby Area, NTW - Network,
RTR - Router
Routing Process "ospf 9", VRF blue
AS Scope LSDB
show ipv6 ospf database <link-state details>
The show ipv6 ospf database <link-state details>
command displays detailed information about the specified link state advertisements.
The switch can return link state data about a single area or for all areas on the
switch.
Command Mode
EXEC
Command Syntax
show ipv6 ospf database
[FILTER][LINK_TYPE][LINKSTATE_ID][ROUTER][DATA_LEVEL]
Parameters
FILTER Filters the output of the command by
specifying areas. Options include:
areaA.B.C.D
area backbone
LINK_TYPE Parameter options include:
router
network
inter-area-prefix
inter-area-router
intra-area-prefix
nssa
LINKSTATE_ID Options include:
no parameter
A.B.C.D
ROUTER Options include:
no parameter
adv-routera.b.c.d
self-originate
DATA_LEVEL Options include:
no parameter
detail
Example
This command displays the OSPF database
summary.
switch# show ipv6 ospf database detail
Codes: AEX - AS External, GRC - Grace,
IAP - Inter Area Prefix, IAR - Inter Area Router,
LNK - Link, NAP - Intra Area Prefix,
NSA - Not So Stubby Area, NTW - Network,
RTR - Router
Routing Process "ospf 9":
AS Scope LSDB
LSA Type: AEX
Link State ID: 0.0.0.1
Advertising Router: 10.21.4.9
Age: 1123
Sequence Number: 0x80000001
Checksum: 0x009c89
Length: 40
Metric Type: 2
Metric: 1
External Route Tag: 0
Prefix
Prefix: fd7a:629f:52a4:1::
Length: 64
Options: (null)
Metric: 0
Area 0.0.1.44 LSDB
LSA Type: LNK
Link State ID: 0.0.0.14
Advertising Router: 10.26.0.11
Age: 1285
Sequence Number: 0x800000c1
Checksum: 0x00629b
Length: 56
Option Priority: 16777235
Link Local Addr: fe80::21c:73ff:fe0b:a80e
Number of Prefixes: 1
Prefix
Prefix: fd7a:629f:52a4:fe08::
Length: 64
Options: (null)
Metric: 0
LSA Type: LNK
Link State ID: 0.0.0.34
Advertising Router: 10.26.0.22
Age: 1042
Sequence Number: 0x800000c2
Checksum: 0x00bd9f
Length: 56
Option Priority: 16777235
Link Local Addr: fe80::21c:73ff:fe01:5fe1
Number of Prefixes: 1
Prefix
Prefix: fd7a:629f:52a4:fe08::
Length: 64
Options: (null)
Metric: 0
LSA Type: LNK
Link State ID: 0.0.0.15
Advertising Router: 10.26.0.23
Age: 1128
Sequence Number: 0x800000c7
Checksum: 0x00d4ab
Length: 56
Option Priority: 16777235
Link Local Addr: fe80::21c:73ff:fe00:1319
Number of Prefixes: 1
Prefix
Prefix: fd7a:629f:52a4:fe08::
Length: 64
Options: (null)
Metric: 0
Interface vlan3925 LSDB
LSA Type: LNK
Link State ID: 0.0.0.153
Advertising Router: 10.27.0.52
Age: 1186
Sequence Number: 0x800009b6
Checksum: 0x002f27
Length: 56
Option Priority: 16777235
Link Local Addr: fe80::21c:73ff:fe17:3906
Number of Prefixes: 1
Prefix
Prefix: fd7a:629f:52a4:fe67::
Length: 64
Options: (null)
Metric: 0
Interface lo0 LSDB
show ipv6 ospf interface
The show ipv6 ospf interface command displays OSPFv3
information on interfaces where OSPFv3 is enabled.
Command Mode
EXEC
Command Syntax
show ipv6 ospf interface [VRF_INSTANCE]
Parameters
VRF_INSTANCE Values include:
no parameter Displays information for all VRFs.
vrfvrf_name Displays information for the
specified VRF.
Example
This command displays OSPFv3 information for interfaces where OSPFv3 is
enabled.
switch# show ipv6 ospf interface
Ethernet17 is up
Interface Address fe80::48c:73ff:fe00:1319, VRF default, Area 0.0.0.0
Network Type Broadcast, Cost 10
Transmit Delay is 1 sec, State Backup DR, Priority 1
Designated Router is 10.37.0.37
Backup Designated Router is 10.37.0.23
Timer intervals configured, Hello 10, Dead 40, Retransmit 5
Neighbor Count is 1
Options are R E V6
Vlan31 is up
Interface Address fe80::48c:73ff:fe00:1319, VRF default, Area 0.0.0.0
Network Type Broadcast, Cost 10
Transmit Delay is 1 sec, State Backup DR, Priority 1
Designated Router is 10.37.0.22
Backup Designated Router is 10.37.0.23
Timer intervals configured, Hello 10, Dead 40, Retransmit 5
Neighbor Count is 1
Options are R E V6
Vlan32 is up
Interface Address fe80::48c:73ff:fe00:1319, VRF default, Area 0.0.0.0
Network Type Broadcast, Cost 10
Transmit Delay is 1 sec, State DR Other, Priority 1
Designated Router is 10.37.0.11
Backup Designated Router is 10.37.0.22
Timer intervals configured, Hello 10, Dead 40, Retransmit 5
Neighbor Count is 2
Options are R E V6
show ipv6 ospf lsa-log
The show ipv6 ospf lsa-log command displays log entries
when LSA update messages are sent or received for OSPFv3.
Command Mode
EXEC
Command Syntax
show ipv6 ospf [PROCESS_ID]
lsa-log [VRF_INSTANCE]
Parameters
PROCESS_ID OSPFv3 process ID. Values include:
no parameter Displays information for all process IDs.
1 to 65535 Displays information for the
specified process ID.
VRF_INSTANCE Values include:
no parameter Displays information for all VRFs.
vrfvrf_name Displays information for the
specified VRF.
Example
This command displays log entries when LSA update messages are sent or received for
OSPFv3.
switch# show ipv6 ospf lsa-log
OSPF3 Process 3.3.3.3, VRF default, LSA Throttling Log:
[04:21:09] type 1: 3.3.3.3/32 [3.3.3.3], event 1, backed off, new hold value 2000 msecs
[04:21:08] type 1: 3.3.3.3/32 [3.3.3.3], event 2, backoff restarted, new hold value 900 msecs
[04:21:00] type 1: 3.3.3.3/32 [3.3.3.3], event 1, backed off, new hold value 3000 msecs
[04:21:00] type 1: 3.3.3.3/32 [3.3.3.3], event 4, maxwait value changed, new hold value 3000
msecs
/* Here the maxwait value was changed to 3000 from earlier 32000, this is not part of the log */
[04:20:42] type 1: 3.3.3.3/32 [3.3.3.3], event 1, backed off, new hold value 32000 msecs
[04:20:10] type 1: 3.3.3.3/32 [3.3.3.3], event 1, backed off, new hold value 32000 msecs
[04:19:54] type 1: 3.3.3.3/32 [3.3.3.3], event 1, backed off, new hold value 16000 msecs
[04:19:46] type 1: 3.3.3.3/32 [3.3.3.3], event 1, backed off, new hold value 8000 msecs
[04:19:42] type 1: 3.3.3.3/32 [3.3.3.3], event 1, backed off, new hold value 4000 msecs
[04:19:40] type 1: 3.3.3.3/32 [3.3.3.3], event 1, backed off, new hold value 2000 msecs
[04:19:39] type 1: 3.3.3.3/32 [3.3.3.3], event 2, backoff restarted, new hold value 900 msecs
[04:19:22] type 1: 4.4.4.4/32 [4.4.4.4], event 3, discarded, was early by 995 msecs
[04:19:22] type 1: 3.3.3.3/32 [3.3.3.3], event 0, backoff started, new hold value 1000 msecs
show ipv6 ospf neighbor
state
The show ipv6 ospf neighbor state command displays the
state information on OSPF neighbors on a per-interface basis.
Command Mode
EXEC
Command Syntax
show ipv6 ospf neighbor stateSTATE_NAME [VRF_INSTANCE ]
Parameters
STATE_NAME Values
include:
2-ways
attempt
down
exch-start
exchange
full
restart
init
loading
VRF_INSTANCE Values include:
no parameter Displays information for all VRFs.
vrfvrf_name Displays information for the
specified VRF.
Example
This command displays OSPF information for neighboring devices that are
adjacent.
switch# show ipv6 ospf neighbor state full
Routing Process "ospf 3":
show ipv6 ospf neighbor
summary
The show ipv6 ospf neighbor summary command displays a
single line of state information for each OSPFv3 neighbor.
Command Mode
EXEC
Command Syntax
show ipv6 ospf neighbor summary
[VRF_INSTANCE]
Parameters
VRF_INSTANCE Values include:
no parameter Displays information for all VRFs.
vrfvrf_name Displays information for the specified
VRF.
Example
This command shows the summary information for the OSPFv3
neighbors.
switch# show ipv6 ospf neighbor summary
Routing Process "ospf 1":
3 neighbors are in state Down
3 neighbors are in state Full
5 neighbors are in state Init
0 neighbors are in state Loading
0 neighbors are in state Attempt
3 neighbors are in state Restarting
0 neighbors are in state Exchange
3 neighbors are in state 2 Ways
0 neighbors are in state Exch Start
show ipv6 ospf neighbor
The show ipv6 ospf neighbor command displays OSPFv3
neighbor information.
Command Mode
EXEC
Command Syntax
show ipv6 ospf neighbor [VRF_INSTANCE]
Parameters
VRF_INSTANCE Values include:
no parameter Displays information for all VRFs.
vrfvrf_name Displays information for the specified
VRF.
Example
This command displays the switch's
neighbors.
switch# show ipv6 ospf neighbor
Routing Process "ospf 9":
Neighbor 10.37.0.37 VRF default priority is 1, state is Full
In area 0.0.0.0 interface et12
DR is 10.37.0.37 BDR is 10.37.0.23
Options is 0
Dead timer is due in 37 seconds
Neighbor 10.37.0.22 VRF default priority is 1, state is Full
In area 0.0.0.0 interface vlan3911
DR is 10.37.0.22 BDR is 10.37.0.23
Options is 0
Dead timer is due in 31 seconds
Neighbor 10.37.0.11 VRF default priority is 1, state is Full
In area 0.0.0.0 interface vlan3902
DR is 10.37.0.11 BDR is 10.37.0.22
Options is 0
Dead timer is due in 33 seconds
Neighbor 10.37.0.22 VRF default priority is 1, state is Full
In area 0.0.0.0 interface vlan3902
DR is 10.37.0.11 BDR is 10.37.0.22
Options is 0
Dead timer is due in 31 seconds
Neighbor 10.37.0.22 VRF default priority is 1, state is Full
In area 0.0.0.0 interface vlan3923
DR is 10.37.0.22 BDR is 10.37.0.46
Options is 0
Dead timer is due in 31 seconds
Neighbor 10.37.0.22 VRF default priority is 1, state is Full
In area 0.0.0.0 interface vlan3908
DR is 10.37.0.22 BDR is 10.37.0.21
Options is 0
Dead timer is due in 39 seconds
Neighbor 10.37.0.22 VRF default priority is 1, state is Full
In area 0.0.0.2 interface vlan3992
DR is 10.37.0.22 BDR is 10.37.0.23
Options is 0
Dead timer is due in 39 seconds
show ipv6 ospf spf-log
The show ipv6 ospf spf-log command displays when and how
long the switch took to run a full SPF calculation for OSPFv3.
Command Mode
EXEC
Command Syntax
show ipv6 ospf [PROCESS_ID]
spf-log [VRF_INSTANCE]
Parameters
PROCESS_ID OSPFv3 process ID. Values include:
no parameter Displays information for all process IDs.
1 to 65535 Displays information for the
specified process ID.
VRF_INSTANCE Values include:
no parameter Displays information for all VRFs.
vrfvrf_name Displays information for the
specified VRF.
Example
This command displays the SPF information for OSPFv3 in all
VRFs.
switch# show ipv6 ospf spf-log
OSPF3 Process 172.26.0.22, VRF default
TIME EVENT REASON
04:54:52.070 SPF ran for 0.70 ms
04:54:52.070 Scheduled after 0 ms Router LSA generation
04:54:39.151 SPF ran for 0.71 ms
04:54:39.151 Scheduled after 0 ms Router LSA generation
04:54:12.071 SPF ran for 0.56 ms
04:54:12.070 Scheduled after 0 ms Router LSA generation
04:54:04.153 SPF ran for 0.29 ms
04:53:59.153 Scheduled after 4999 ms Router LSA generation
04:53:59.153 SPF ran for 0.25 ms
04:53:59.151 Scheduled after 0 ms Router LSA generation
04:53:33.081 SPF ran for 0.3 ms
04:53:33.081 Scheduled after 0 ms ECMP max nexthop cfg change
show ipv6 ospf
The show ipv6 ospf command displays information about
OSPFv3 routing.
Command Mode
EXEC
Command Syntax
show ipv6 ospf [access-list |
border-routers | database |
interface | lsa-log |
neighbor | request-list |
retransmission-list | spf-log |
vrf ] Process ID
Parameters
no parameters displays the complete configuration
of OSPFv3 address family and routing process.
access-list displays the information of configured
OSPFv3 access-list. Options include:
no parameters displays the information of all configured
OSPFv3 access lists.
WORD displays the information of the
specified access list.
summary displays the summary of all
configured access lists.
border-routers displays the information of
configured OSPFv3 border and boundary routers. Options include:
no parameters displays the information of all configured
OSPFv3 borders and boundary routers.
vrf displays the OSPFv3 borders and
boundary routers information of the specified Virtual Routing and
Forwarding (VRF).
database displays the summary of database. Options
include:
no parameters displays the complete summary of database.
ipv4 displays the database information of
link state ID.
adv-router displays the database
information of advertising router link states.
area displays the database information
filtered by area scope LSAs.
as displays the database information
filtered by AS scope LSAs.
database-summary displays the count of
LSAs in OSPFv3 database.
detail displays the detailed information
of LSA.
link displays the database information
filtered by link scoped LSAs.
self-originate displays the database
information of self-originated link states.
vrf displays the VRF information in OSPFV3
database.
interface displays the information of OSPFv3
interfaces. Options include:
no parameters displays the information of all OSPFv3
interfaces.
Etherneteth_num displays the information of the
specified Ethernet interface. The value ranges from 1 to
24.
Loopbacklb_num displays the information of the
specified loop back interface. The value ranges from 0
to 1000.
Port-Channelpc_num displays the interface or
sub-interface information of the specified port channel. The
interface and sub-interface values of port channel ranges from
1-1000 and
1-2000.
1-4094 respectively.
Tunnelt_num displays the information of the
specified tunnel. The value ranges from 0 to
255.
Vlanvlan_num displays the information of the
specified VLAN interface. The value ranges from 1 to
4094.
vrfvrf_name displays the information of the
specified VRF.
lsa-log displays the log entries of OSPFv3 LSA
updates.
neighbor displays the list of OSPFv3
neighbors.
request-list displays the list of all OSPFv3 LSAs
requested by a router.
retransmission-list displays the list of all
OSPFv3 LSAs waiting to be re-sent.
spf-log displays the start-time, duration of
completion, and reason of delay to calculate the OSPFv3 Sender Policy
Framework (SPF).
vrfvrf_name displays the information of specified
VRF.
Process ID displays the OSPFv3 configuration of
the specified process ID. The value ranges from 1 to
65535.
Examples
This command displays OSPFv3 routing information for all
VRFs.
switch# show ipv6 ospf
Routing Process "ospfv3 0" with ID 11.1.11.1 and Instance 0 VRF default
FIPS mode disabled
It is not an autonomous system boundary router and is not an area border router
Minimum LSA arrival interval 1000 msecs
Initial LSA throttle delay 1000 msecs
Minimum hold time for LSA throttle 5000 msecs
Maximum wait time for LSA throttle 5000 msecs
It has 0 fully adjacent neighbors
Number of areas in this router is 0. 0 normal, 0 stub, 0 nssa
Number of LSAs 0
Initial SPF schedule delay 0 msecs
Minimum hold time between two consecutive SPFs 5000 msecs
Current hold time between two consecutive SPFs 5000 msecs
Maximum wait time between two consecutive SPFs 5000 msecs
SPF algorithm last executed 00:07:13 ago
No scheduled SPF
Adjacency exchange-start threshold is 20
Maximum number of next-hops supported in ECMP is 32
Number of backbone neighbors is 0
Graceful-restart is not configured
Graceful-restart-helper mode is enabled
This command displays the log entries of OSPFv3 LSA
updates.
switch# show ipv6 ospf lsa-log
[22:11:02] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[21:31:02] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[20:56:22] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[20:18:12] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[19:47:22] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[19:13:22] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[18:39:32] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[18:06:32] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[17:26:42] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[16:48:42] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[16:13:12] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[15:36:52] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[15:03:32] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[14:27:52] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[13:52:02] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[13:15:02] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[12:39:42] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[12:00:02] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[11:27:22] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[10:53:22] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[10:17:12] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
[09:42:42] type RTR: 0.0.0.0 [13.13.13.13], event 2, backoff restarted, new hold value 1000 msecs
show ospfv3
The show ospfv3 command displays the OSPFv3 configuration
of OSPFv3 address family and routing process.
no parameters displays the complete configuration of OSPFv3 address
family and routing process.
access-list displays the information of configured
OSPFv3 access-list. Options include:
no parameters displays the information of all configured
OSPFv3 access lists.
WORD displays the information of the
specified access list.
summary displays the summary of all
configured access lists.
border-routers displays the information of
configured OSPFv3 border and boundary routers. Options include:
no parameters displays the information of all configured
OSPFv3 borders and boundary routers.
vrf displays the OSPFv3 borders and
boundary routers information of the specified Virtual Routing and
Forwarding (VRF).
database displays the summary of database. Options
include:
no parameters displays the complete summary of database.
ipv4 displays the database information of
link state ID.
adv-router displays the database
information of advertising router link states.
area displays the database information
filtered by area scope LSAs.
as displays the database information
filtered by AS scope LSAs.
database-summary displays the count of
LSAs in OSPFv3 database.
detail displays the detailed information
of LSA.
link displays the database information
filtered by link scoped LSAs.
self-originate displays the database
information of self-originated link states.
vrf displays the VRF information in OSPFV3
database.
interface displays the information of OSPFv3
interfaces. Options include:
no parameters displays the information of all OSPFv3
interfaces.
Etherneteth_num displays the information of the
specified Ethernet interface. The value ranges from 1 to
24.
Loopbacklb_num displays the information of the
specified loop back interface. The value ranges from 0
to 1000.
Port-Channelpc_num displays the interface or
sub-interface information of the specified port channel. The
interface and sub-interface values of port channel ranges from
1-1000 and
1-2000.
1-4094 respectively.
Tunnelt_num displays the information of the
specified tunnel. The value ranges from 0 to
255.
Vlanvlan_num displays the information of the
specified VLAN interface. The value ranges from 1 to
4094.
vrfvrf_name displays the information of the
specified VRF.
ipv4 displays the IPv4 address family
information.
ipv6 displays the IPv6 address family
information.
lsa-log displays the log entries of OSPFv3 LSA
updates.
neighbor displays the list of OSPFv3
neighbors.
request-list displays the list of all OSPFv3 LSAs
requested by a router.
retransmission-list displays the list of all
OSPFv3 LSAs waiting to be re-sent.
spf-log displays the start-time, duration of
completion, and reason of delay to calculate the OSPFv3 Sender Policy
Framework (SPF).
vrfvrf_name displays the information of specified
VRF.
Examples
This command displays the complete configuration of OSPFv3 address family
and routing process.
switch# show ospfv3
OSPFv3 address-family ipv6
Routing Process "ospfv3" with ID 13.13.13.13 and Instance 0 VRF default
FIPS mode disabled
It is not an autonomous system boundary router and is not an area border router
Minimum LSA arrival interval 1000 msecs
Initial LSA throttle delay 1000 msecs
Minimum hold time for LSA throttle 5000 msecs
Maximum wait time for LSA throttle 5000 msecs
Interface flood pacing timer 50 msecs
It has 0 fully adjacent neighbors
Number of areas in this router is 1. 1 normal, 0 stub, 0 nssa
Number of LSAs 1
Initial SPF schedule delay 0 msecs
Minimum hold time between two consecutive SPFs 5000 msecs
Current hold time between two consecutive SPFs 5000 msecs
Maximum wait time between two consecutive SPFs 5000 msecs
SPF algorithm last executed 3d23h ago
No scheduled SPF
Adjacency exchange-start threshold is 20
Maximum number of next-hops supported in ECMP is 32
Number of backbone neighbors is 0
Graceful-restart is not configured
Graceful-restart-helper mode is enabled
Area 0.0.0.0
Number of interface in this area is 0
It is a normal area
SPF algorithm executed 2 times
This command displays the count of LSAs in OSPFv3
database.
switch# show ospfv3 database database-summary
OSPFv3 address-family ipv4
Routing Process "ospfv3" Instance 64 VRF default
LSA Type Count
Router 1
Network 0
Inter Area Prefix 0
Inter Area Router 0
Summary Asex 0
Nssa 0
Link 0
Intra Area Prefix 0
Grace 0
Total 1
OSPFv3 address-family ipv6
Routing Process "ospfv3" Instance 0 VRF default
LSA Type Count
Router 0
Network 0
Inter Area Prefix 0
Inter Area Router 0
Summary Asex 0
Nssa 0
Link 0
Intra Area Prefix 0
Grace 0
Total 0
ro301.02:05:02(config-router-ospfv3-af)#
This command displays the start-time, duration of completion, and reason of
delay to calculate the OSPFv3
SPF.
switch# show ospfv3 spf-log
OSPFv3 address-family ipv4
Routing Process "ospfv3" with ID 11.1.11.1 and Instance 64, VRF default
TIME EVENT REASON
02:00:13.495 SPF ran for 0.064 ms
02:00:13.335 Scheduled after 0.000 ms Router LSA generation
01:59:55.499 SPF ran for 0.061 ms
01:59:54.604 Scheduled after 0.000 ms ECMP max nexthop cfg change
OSPFv3 address-family ipv6
Routing Process "ospfv3" with ID 11.1.11.1 and Instance 0, VRF default
TIME EVENT REASON
02:00:13.495 SPF ran for 0.064 ms
02:00:13.335 Scheduled after 0.000 ms OSPF3 re-initialisation
01:59:55.499 SPF ran for 0.089 ms
01:59:54.603 Scheduled after 0.000 ms ECMP max nexthop cfg change
ro301.02:04:06(config-router-ospfv3-af)#
shutdown (OSPFv3)
The shutdown command disables OSPFv3 on the switch.
OSPFv3 is disabled by default on individual interfaces and enabled through ipv6 ospf area commands.
The no shutdown and default
shutdown commands enable the OSPFv3 instance by removing the
shutdown statement from the OSPFv3 block in
running-config.
Command Mode
Router-OSPFv3 Configuration
Command Syntax
shutdown
no shutdown
default shutdown
Example
This command disables OSPFv3 activity on the
switch.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# shutdown
switch(config-router-ospf3)# show active
ipv6 router ospf 9
shutdown
switch(config-router-ospf3)#
timers lsa rx min interval
(OSPFv3)
The timers lsa rx min interval command sets the minimum
interval for accepting identical Link-State Advertisements (LSAs) from OSPFv3
neighbors.
The no timers lsa rx min interval and default
timers lsa rx min interval commands restore the minimum
interval to the default value of one second by removing the timers lsa
rx min interval command from the
running-config.
Command Mode
Router-OSPFv3 Configuration
Router-OSPFv3 Address-Family
IPv4/IPv6 Configuration
Command Syntax
timers lsa rx min intervallsa_time
no timers lsa rx min interval
default timers lsa rx min interval
Parameter
lsa_time Minimum time (in milliseconds) after which the
switch accepts an identical LSA from OSPFv3 neighbors. Value ranges from
0 to 600000 (ms). Default value is
1000 milliseconds (1
second).
Example
This command sets the minimum LSA arrival interval to 10
milliseconds.
The timers lsa tx delay initial command sets the
rate-limiting values for OSPFv3 Link-State Advertisement (LSA) generation.
The no timers lsa tx delay initial and default
timers lsa tx delay initial commands restore the default LSA
rate-limiting values by removing the timers lsa tx delay
initial command from the running-config.
initial_delay Initial delay in milliseconds to
generate the first instance of LSAs. Value ranges from 0 to
600000 (ms). The default value is
1000 ms.
min_hold Minimum hold interval availed in
milliseconds between the generation of same LSA. Value ranges from
1 to 600000 (ms). The default interval is
5000 ms.
max_wait Maximum hold interval availed in
milliseconds between the generation of same LSA. Value ranges from
1 to 600000 (ms). The default interval is
5000 ms.
Example
These commands set the LSA transmission timers
on the switch.
The purpose of SPF throttling is to delay Shortest Path First (SPF) calculations when
network topology is changing rapidly. The timers spf delay
initial command controls the intervals of SPF calculations in
a switch. The command sets three values:
Initial delay: Initial wait by a switch to calculate SPF after a
topology change in a network that has been stable throughout the hold
interval. Because a topology change often requires several link state
updates to be sent, the initial delay is configured to allow the network to
settle before the switch calculates SPF. If an additional topology change
occurs during the initial interval, the SPF calculation still takes place
after the initial delay period has expired and no other change is made to
the throttle timers.
Hold interval: This is an additional wait timer that reduces the
frequency of SPF calculations during periods of network instability. If a
network change occurs during the hold period, an SPF calculation is
scheduled to occur when the hold interval expires. Subsequent hold intervals
are doubled if further topology changes occur during a hold interval until
either the hold interval reaches its configured maximum or no topology
change occurs during the interval. If the next topology change occurs after
the hold interval expires, the hold interval is reset to its configured
value and the SPF calculation is scheduled to take place after the initial
delay.
Maximum interval: The maximum wait time of a switch after a topology
change before performing an SPF calculation.
The no timers spf delay initial and default
timers spf delay initial commands restore the default OSPFv3
SPF calculation intervals by removing the timers spf delay
initial command from running-config.
initial_delay Initial delay between a topology
change and SPF calculation. Value ranges from 0 to
65535000 (ms). The default value is
0 ms.
hold_interval Additional wait time after SPF
calculation to allow the network to settle. If a topology change occurs
during the hold interval, another SPF calculation is scheduled to occur
after the hold interval expires. The next hold interval is doubled if
topology changes occur during the hold interval. If doubling exceeds the
maximum value, the maximum value is used instead. Value ranges from
0 to 65535000 (ms). The default value is
5000 ms.
max_interval The maximum hold interval before a
switch calculates SPF. Value ranges from 0 to
65535000 (ms). The default value is
5000 ms.
lsa configures threshold for the retransmission of
LSA. Option includes:
arrival configures the OSPF LSA arrival
timer.
out-delay configures the delay to flood router LSA
in milliseconds. Option includes:
out-delay_time minimum interval in
milliseconds between accepting the same LSAs. The value ranges from
0 to 65000 milliseconds. The
default value is 0.
pacing configures the OSPF packet pacing. Option
includes:
lsa configures threshold for the
retransmission of LSA.
spf configures the time between SPF
calculations.
Examples
This command configures OSPFv3 flood pacing timer to
50 ms in the global OSPFv3
instance.
switch(config)# ipv6 router ospf 9
switch(config-router-ospf3)# timers pacing flood 50
switch(config-router-ospf3)# show ospfv3
Routing Process "ospfv3 9" with ID 13.13.13.13 and Instance 0 VRF default
FIPS mode disabled
It is not an autonomous system boundary router and is not an area border router
Minimum LSA arrival interval 1000 msecs
Initial LSA throttle delay 1000 msecs
Minimum hold time for LSA throttle 5000 msecs
Maximum wait time for LSA throttle 5000 msecs
Interface flood pacing timer 50 msecs
It has 0 fully adjacent neighbors
Number of areas in this router is 1. 1 normal, 0 stub, 0 nssa
Number of LSAs 1
Initial SPF schedule delay 0 msecs
Minimum hold time between two consecutive SPFs 5000 msecs
Current hold time between two consecutive SPFs 5000 msecs
Maximum wait time between two consecutive SPFs 5000 msecs
SPF algorithm last executed 21d19h ago
No scheduled SPF
Adjacency exchange-start threshold is 20
Maximum number of next-hops supported in ECMP is 32
Number of backbone neighbors is 0
Graceful-restart is not configured
Graceful-restart-helper mode is enabled
Area 0.0.0.0
Number of interface in this area is 0
It is a normal area
SPF algorithm executed 2 times
This command configures the OSPFv3 flood pacing timer to
50 ms in IPv4 address
family.
switch(config)# router ospfv3
switch(config-router-ospfv3)# address-family ipv4
switch(config-router-ospfv3-af)# timers pacing flood 50
switch(config-router-ospfv3-af)# show ospfv3
OSPFv3 address-family ipv4
Routing Process "ospfv3" with ID 11.1.11.1 and Instance 64 VRF default
FIPS mode disabled
It is not an autonomous system boundary router and is not an area border router
Minimum LSA arrival interval 1000 msecs
Initial LSA throttle delay 1000 msecs
Minimum hold time for LSA throttle 5000 msecs
Maximum wait time for LSA throttle 5000 msecs
Interface flood pacing timer 50 msecs
It has 0 fully adjacent neighbors
Number of areas in this router is 1. 1 normal, 0 stub, 0 nssa
Number of LSAs 1
Initial SPF schedule delay 0 msecs
Minimum hold time between two consecutive SPFs 5000 msecs
Current hold time between two consecutive SPFs 5000 msecs
Maximum wait time between two consecutive SPFs 5000 msecs
SPF algorithm last executed 00:10:38 ago
No scheduled SPF
Adjacency exchange-start threshold is 20
Maximum number of next-hops supported in ECMP is 32
Number of backbone neighbors is 0
Graceful-restart is not configured
Graceful-restart-helper mode is enabled
Area 0.0.0.0
Number of interface in this area is 0
It is a normal area
SPF algorithm executed 2 times
Border Gateway Protocol (BGP) exchanges routing information among neighboring routers in different Autonomous Systems (AS). Arista switches use BGP version 4+, incorporating the multiprotocol extensions defined by RFC 4760 so that BGP can carry both IPv4 and IPv6 routes simultaneously over a single BGP peering.
Simultaneous internal (iBGP) and external (eBGP) peering.
Multiprotocol BGP, including IPv4-mapped IPv6 address next hops for IPv6 labeled-unicast routes.
BGP Confederations.
BGP Selective Route Download.
BGP Route Reflection.
BGP Conceptual Overview
Using TCP sessions, the BGP protocol exchanges routing information among neighboring routers in different autonomous systems.
BGP neighbors (peers) communicate through a TCP session on port 179. They are established by manual configuration commands (static peers) or by creating a peer group listen range and accepting incoming peering requests in that range (dynamic peers). Internal BGP (iBGP) peers operate within a single Autonomous System (AS). External BGP (eBGP) peers operate between autonomous systems. Border routers are on AS boundaries and exchange information with other autonomous systems; the primary function of border routers is distributing routes. Internal routers do not distribute route updates that they receive.
BGP defines a state machine for establishing connections. BGP routers maintain a state variable for each peer-to-peer session to track connection status. The state machine consists of these states:
Idle: The router initializes BGP resources, refuses inbound BGP connection attempts, initiates a TCP connection to the peer, and then transitions to the Connect state.
Connect: The router waits for the TCP connection to complete, then sends an OPEN message to the peer and transitions to the OpenSent state if successful. If unsuccessful, it sets the ConnectRetry timer and transitions to the Active state upon expiry.
Active: The router sets the ConnectRetry timer to zero and returns to the Connect state.
OpenSent: The router waits for an OPEN message from the peer. After receiving a valid message, it transitions to the OpenConfirm state.
OpenConfirm: The router waits for a keepalive message from its peer. The router waits for a keepalive message from its peer. If the message is received before a timeout expires, the router transitions to the Established state. If the timeout expires or an error condition exists, the router transitions to the Idle state.
Established: Peers exchange UPDATE messages about routes they advertise. If an UPDATE message contains an error, the router sends a NOTIFICATION message and transitions to the Idle state.
During established BGP sessions, routers exchange UPDATE messages about the destinations to which they offer connectivity. The route description includes the destination prefix, prefix length, autonomous systems in the path, the next hop, and information that affects the receiving router's acceptance policy. UPDATE messages also list destinations to which the router no longer offers connectivity.
BGP detects and eliminates routing loops while making routing policy decisions by using the network topology as defined by AS paths and path attributes.
Multiprotocol BGP
Multiprotocol BGP facilitates the advertisement of network routes and switch capabilities to neighbors from multiple address families over a single BGP peering. The switch supports IPv4 unicast and IPv6 unicast address families.
Neighbors negotiate an address family when establishing a connection. This address family, which identifies the following, forms the basis of the peer session:
The set of network layer protocols to which the address carried in the Next Hop field must belong.
The encoding format of the next-hop address.
The semantics of Network Layer Reachability Information (NLRI).
BGP Confederations
BGP confederations divide an Autonomous System (AS) into subsystems (sub-ASs), each identified by a unique sub-AS number while appearing externally as a single AS.
QoS Control of Neighbor Discovery and ARP Packets
To prevent BGP sessions from being affected by dropped neighbor discovery and ARP packets, some Arista switches assign those packets to a higher-priority output queue when they are being software-forwarded. This action helps minimize hardware drops when competing with data plane packet traffic congestion.
Best-path Selection
Routing information received via the BGP protocol often contains multiple routes to the same destination. The BGP best-path selection algorithm determines which routes to install in the routing table.
BGP evaluates criteria in order. At each step, if a tie occurs for the best path BGP applies the next criterion. If a tie still exists at the end of the process, BGP installs the route it received from the peer with the lowest address.
When Equal Cost Multi-Path (ECMP) routing is enabled, the system may install multiple paths to a single destination in the IP routing table.
BGP supports convergence, which waits for all peers to join and receive all the routes from other peers.
Before declaring convergence, BGP waits for IGP protocols to converge so that all IBGP sessions are established and routes learned over IBGP sessions are resolved via the IGP routes. BGP declares convergence when it has received route updates from all its peers and End-Of-RIB (EOR) markers from all the expected peers and IGP protocols have converged. You can avoid hardware updates or route advertisement churn during a switch reload or a BGP instance start using BGP convergence.
BGP Communities
A BGP community is a group of subnet address prefixes that share a common identifying attribute. Communities simplify routing policies by consolidating IP network spaces into logical entities BGP speakers can address to accept, prefer, and distribute routing information. BGP communities are defined by setting the community value within route maps. Community lists then reference one or more communities as follows:
Standard community lists refer to communities by name or number.
Expanded community lists reference communities using regular expressions.
BGP Graceful Shutdown Community
Autonomous System Boundary Routers (ASBRs) do not update all paths received from external BGP sessions and routers. They hide inefficient alternate paths and update only best paths in the routing table. BGP route policies are applied to all internal BGP sessions of ASBRs that support the graceful shutdown procedure.
As a part of maintenance mode, these route policies perform the following functionalities on routing advertisements:
Match the graceful shutdown community with route map rules.
Set the local preference attribute value of the paths that are tagged with the graceful shutdown community as 0.
Refer to Maintenance Mode for detailed information on maintenance mode.
BGP Labeled-Unicast (LU) Path Nexthop Resolution over Tunnel RIB Entries
BGP Labeled-Unicast Protocol (BGP LU) path next-hop is enhanced to allow BGP in ribd mode to support resolution of BGP LU path next-hop over entries in the Tunnel RIB and fall-back to resolving over connected route when there is no entry in Tunnel RIB that provides a direct match for the BGP LU path next-hop. Previously, BGP in “ribd” mode allowed resolution of BGP Labeled-Unicast Protocol (BGP LU) path next-hop over only connected routes, resolution of the next-hop over IGP or static routes was not allowed since the next-hop router may not be in the MPLS forwarding path in which case the traffic will get dropped by the next-hop router (per IGP).
The following two use cases explain how BGP LU path next-hop resolution over tunnels would help in achieving desired or efficient traffic forwarding.
Egress Peer Engineering is a source-routing paradigm that provides ability to select an egress node/interface through which traffic goes out of an Autonomous System (AS). As shown in Figure 1 below R1, R2, ASBR1 & ASBR2 are in AS 1 and E1, E2, E3 & E4 are in different Ases. R1, R2, ASBR1 & ASBR2 could be connected each other directly or reachable to each other over an IGP (OSPF/ISIS) or MPLS tunnel. Let’s assume reachability of loop-back addresses 1.1.1.1, 2.2.2.2, 3.3.3.3 & 4.4.4.4 through LDP or Segment Routing (SR). There exists an iBGP Full Mesh between R1, R2, ASBR1 & ASBR2. eBGP session is present between ASBR1 & E1, ASBR1 & E2, ASBR2 & E3 and ASBR2 & E4. Consider following BGP updates are received on ASBR1:
Prefix 50.0.0.0/8 next-hop 10.0.0.2 as-path 2100 from E1.
Prefix 50.0.0.0/8 next-hop 11.0.0.2 as-path 3200300 from E2.
BGP path from E1 will be selected as best path due to shorter AS path length. ASBR1 advertises this prefix to both R1 & R2. Any traffic destined to prefix 50.0.0.0/8 from R1 will always be tunneled to ASBR1 and then it will always be sent on an interface connected to E1. Traditional Destination based routing enforced by BGP policy and best path selection on the ASBRs may route traffic to a single AS as exit when a case can be made that for some prefixes an exit via some other AS may be preferable. BGP LU can be used here to perform traffic engineering or selecting Egress peer through which traffic should be forwarded.
Figure 1.BGP Topology Example
A Centralized EPE Controller can be used to establish iBGP session with R1 and R2. Let’s assume Controller advertises BGP LU routes for E2, i.e., 11.0.0.2/32, with next-hop set to loop-back IP address of ASBR1, that is, 1.1.1.1 and a label 111 to R1 & R2.
switch# show ip bgp 11.0.0.2/32
BGP routing table information for VRF default
Router identifier 3.3.3.3, local AS number 1
BGP routing table entry for 11.0.0.2/32
Paths: 1 available
Local
1.1.1.1 labels [111] from 100.100.100.1 (100.100.100.1)
Origin IGP, metric 0, localpref 100, IGP metric 40, weight 0, received
21:07:07 ago, valid, external, not installed
Rx SAFI: Labels
Tunnel RIB eligible
BGP LU path next-hop will get resolved over an ISIS SR tunnel present on R1 and R2 to reach 1.1.1.1, loop-back IP address of ASBR1.
Controller or CLI can be used to install a static label route on ASBR1 such that ingress label 111 have a forwarding action of “POP and forward” to next-hop (11.0.0.2) in MPLS forwarding table.
switch# show mpls lfib route
MPLS forwarding table (Label [metric] Vias) - 20 routes
MPLS next-hop resolution allow default route: False
Via Type Codes:
M - Mpls Via, P - Pseudowire Via,
I - IP Lookup Via, V - Vlan Via,
VA - EVPN Vlan Aware Via, ES - EVPN Ethernet Segment Via,
VF - EVPN Vlan Flood Via, AF - EVPN Vlan Aware Flood Via,
NG - Nexthop Group Via
Source Codes:
S - Static MPLS Route, B2 - BGP L2 EVPN,
B3 - BGP L3 VPN, R - RSVP,
P - Pseudowire, L - LDP,
IP - IS-IS SR Prefix Segment, IA - IS-IS SR Adjacency Segment,
IL - IS-IS SR Segment to LDP, LI - LDP to IS-IS SR Segment,
BL - BGP LU, ST - SR TE Policy,
DE - Debug LFIB
S 111 [100]
via M, 11.0.0.2, pop
payload ipv4, apply egress-acl
interface Ethernet 4
For prefixes to which traffic should be sent over interface connected E2 controller will advertise a BGP route with next-hop being BGP LU prefix and higher local-preference compared to paths advertised by ASBR1 and ASBR2, so that path received from controller will be preferred over paths coming from ASBR1 and ASBR2.
switch# show ip bgp 50.0.0.0/8
BGP routing table information for VRF default
Router identifier 3.3.3.3, local AS number 1
BGP routing table entry for 50.0.0.0/8
Paths: 3 available
Local
11.0.0.2 from 100.100.100.1 (100.100.100.1)
Origin IGP, metric 0, localpref 200, IGP metric 0, weight 0, received 00:00:15
ago, valid, internal, best
Rx SAFI: Unicast
2 100
1.1.1.1 from 1.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, IGP metric 0, weight 0, received 00:04:49
ago, valid, internal
Rx SAFI: Unicast
2 200 300
2.2.2.2 from 2.2.2.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, IGP metric 0, weight 0, received 00:30:38
ago, valid, internal
Rx SAFI: Unicast
This results in pushing two labels on R1, top label is the label corresponding to ISIS SR tunnel to reach ASBR1 and bottom label is the label that corresponds to egress interface. Similarly LU route for12.0.0.0.2 or 13.0.0.2 can be advertised from controller to select egress peer between E3 and E4. This approach provides Egress peer selection on an ingress router R1/R2.
switch# show ip route 50.0.0.0/8
VRF: default
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service,
DH - DHCP client installed default route, M - Martian,
DP - Dynamic Policy Route
B I 50.0.0.0/8 [200/0] via 11.0.0.2/32, BGP LU tunnel index 1
via 6.6.6.6, Ethernet 5, label 900001 111
Inter-AS Option C
Inter-AS Option C is an efficient and scalable MPLS IP VPN solution to provide connectivity between two sites of a customer connected to Provider Edge (PE) routers in different ASes. Following diagram shows a typical topology.
Figure 2.BGP Tunnel Topology Example
PE1 and ASBR1 and PE2 and ASBR2 distribute loop-back addresses using an IBGP Labeled Unicast (LU) session. ASBR2 advertises system addresses in AS200 to ASBR1 with next-hop as itself over EBGP LU session between them and installing Label swap entry of label sent to ASBR1 (L2) to label received from PE2 (L1) in MPLS forwarding table. ASBR1 further propagates system addresses in AS200 learned from ASBR2 into AS100 or to PE1 using IBGP LU session with next-hop as itself and installing Label swap entry with label advertised to PE1 (L3) to Label received from ASBR2 (L2) in MPLS forwarding table. Similarly ASBR1 sends system addresses in AS100 to ASBR2 over EBGP LU session, ASBR2 forwards them into AS200 or to PE2 using IBGP LU session with itself as next-hop and this would trigger installing appropriate label swap actions into MPLS forwarding table. These advertisements results in the creation of a label switched path from PE1 to PE2.
PE1 and PE2 exchange VPN routes between each other using a Multi hop EBGP session with next-hop being their own loop-back/system addresses. This method eliminates the requirement of storing or sending/receiving VPN routes at ASBR routers. When PE and ASBR routers are non-adjacent, but in the same AS, then LDP or ISIS-SR can be used as a transport label signaling protocol and this would need resolving BGP LU path next-hop over LDP or ISIS-SR tunnel. An IP packet destined to an address in CE1 site 2 is received on PE1 from CE1 site 1PE1 would need to push 3 labels onto it. Bottom label corresponds to packet destination address in a particular VRF of CE1 site 2 advertised by PE2 to PE1 over Multi hop EBGP session, Middle label belongs to PE2 system address sent by ASBR1 and top label corresponding to ASBR1 system address assigned by transport label signaling protocol.
BGP Selective Route Download
BGP Selective Route Download allows the learning and advertising of BGP routes without installing them in hardware. The BGP routes are filtered before installation in hardware through the route map definition and routes that are filtered out are flagged as inactive in the Routing Information Base (RIB).
The route map used for filtering is applied only to BGP learned paths and not on locally originated routes, for example, BGP aggregate or redistributed routes. Also, because the BGP routes filtered by Selective Route Download are not active in the RIB, they are not used for recursive resolution, they are not redistributed into other protocols, and they do not contribute to BGP aggregates.
When BGP Selective Route Download is configured, the best path for peer advertisement is chosen based on the following aspects. If received BGP paths exist, then the best of them is advertised to BGP peers, else, the aggregate is preferred if configured and active. If neither BGP paths nor a BGP aggregate is available, then the RIB winner is advertised.
Note: The number of routes is limited based on the compute and memory resources available at runtime.
BGP Route Reflector
A BGP route reflector is a switch within an autonomous system that forwards route information learned from iBGP peers to other iBGP peers as an alternative to a full-mesh topology. When the switch is configured as a route reflector it can also be configured to preserve the BGP attributes of the reflected routes (next-hop, local preference, and metric) in its route advertisements regardless of outbound BGP policies.
BGP Nexthop Resolution RIBs: EVPN and IPV4/6 Labeled-Unicast Support
Adds the BGP Nexthop Resolution RIBs feature for EVPN and labeled-unicast address families.
BGP Nexthop Resolution RIBs: EVPN and IPV4/6 Labeled-Unicast Support adds support for user-configured BGP Nexthop Resolution RIB profiles for various BGP-based services such as IP unicast, L3 VPN, EVPN, etcetra. This feature allows an administrator to customize the next hop resolution semantics of BGP routes with an ordered list, or profile, of resolution RIB domains (for example, either tunnel or IP domain). This allows EOS to direct specific services over the specified RIB domains, overriding the default behavior. Further, this feature, through the use of user-defined tunnel RIBs, empowers an administrator to further select a subset of tunneling protocols for specific services.
Note: This feature is only available when running the multi-agent routing protocol model.
Support for Set Large Community List Limitations
Resolution of NLRI from (directly connected) eBGP Speakers
For IPv4 or IPv6 unicast NLRI received from eBGP, directly connected BGP sessions are resolved by only using connected routes, or system-connected, in the parlance of this feature. This feature does not change this behavior, nor will configuration of a non-default resolution profile affect this behavior.
Address Family Profile Restrictions
Certain BGP address families only support a subset of possible next-hop resolution profiles. This section documents such limitations.
Table 1.Limitations
Address family
Restriction
IPv4/IPv6 unicast (non 6PE)
None.
IPv6 unicast 6PE
Only supports tunnel domains*.
IPv4/IPv6 unicast (eBGP directly connected)
Only supports system-connected; Not configurable.
IPv4/IPv6 VPN
Only supports tunnel domains* and system-connected.
IPv4/IPv6 LU
Only supports tunnel domains* and system-connected.
EVPN (MPLS)
Only supports tunnel domains* and system-connected.
EVPN (VXLAN)
Only supports IP domains+.
* Tunnel domains refer to tunnel RIBs, e.g. system-colored-tunnel-rib, system-tunnel-rib, or user-defined tunnel RIBs.
+ IP domains are either of system-unicast-rib or system-connected.
BGP Logical OR of Multiple Community Lists in the Same Match Command
In the multi-agent routing protocol model, the BGP agent now supports matching community lists with a logical OR via the route map match community or-results command (same applies for extended and large communities with match extcommunity and match large-community).
Without the or-results portion of the command, the default is to compute the logical AND of all provided community lists. Before, one would need to merge existing community lists into one to do a logical OR:
Issue:
switch(config)# ip community-list COMMLIST1 permit 1:1
switch(config)# ip community-list COMMLIST2 permit 2:2
! No way to match "COMMLIST1" or "COMMLIST2" in a singel
! route-map sequence match community COMMLIST1 COMMLIST2
Workaround:
switch(config)# ip community-list standard mergedCommunityList permit 1:1
switch(config)# ip community-list standard mergedCommunityList permit 2:2
match community mergedCommunityList
Limitations
This feature is available only when configuring BGP in the multi-agent routing protocol model.
BGP Flowspec
The EOS Release 4.21.3F introduces support for BGP Flowspec, as defined in RFC5575 and RFC7674. The typical use case is to filter or redirect DDoS traffic on edge routers.
BGP Flowspec rules are disseminated using a new BGP address family. The rules include both matching criteria used to match traffic, and actions to perform on the matching traffic. The rules are programmed into TCAM resources and applied on the ingress ports for which flowspec is enabled.
Release Updates
EOS Release 4.x enhancements:
Added support for BGP Flowspec applied to SVI.
BGP Flowspec releases TCAM banks as they are no longer needed to store matches. Previously, once TCAM banks allocated to BGP Flowspec, they never released.
EOS Release 4.22.0 Enhancements:
Added support for redirect over MPLS or GRE Tunnels.
Added support for traffic-rate action.
EOS Release 4.22.1 Enhancements:
Added support for hitless rule updates. This enhancement ensures that persistent filtering rules remain active while other filtering rules update, for example, a BGP Peer publishes or withdraws rules.
EOS Release 4.23.1 Enhancements:
Added support for best-effort rule programming. When a switch receives more filtering rules from BGP neighbors than can fit within TCAM hardware, it programs the highest priority Flowspec rules up to the maximum TCAM available on a per-ASIC basis. The maximum TCAM available could either be the per-ASIC maximum free TCAM banks or the limit set by feature flow-spec bank maximum tcam in the hardware sub-configuration. (LIMITATION - the best-effort rule programming does not apply when Flowspec rules, after expansion into HW TCAM entries, occupy more than 24k 160b IPv4 or 320b IPv6 HW TCAM entries. In this case, programming fails, and no flowspec rules are programmed in hardware. This limitation is resolved in EOS Release 4.24.2).
Added support for traffic-marking action. To enable traffic-marking action, the feature flow-spec port (ipv4|ipv6) command of the active TCAM profile must include action set-dscp.
Added support for packet length (Type 10) component match on IPv4 packets. To enable matching on IPv4 packet length, the feature flow-spec port ipv4 command of the active TCAM profile must include keyword field ip-length.
EOS Release 4.23.2 Enhancements:
Added support for configuring BGP Flowspec in a non-default VRF. Only a single VRF is supported.
Added support for packet length (Type 10) component match on IPv6 packets. To enable matching on IPv6 packet length, the feature flow-spec port ipv6 command of the active TCAM profilemust include the keword field ipv6-length.
EOS Release 4.24.0 Enhancements:
Added support for configuring BGP Flowspec on subinterfaces. To enable subinterface support, the TCAM profile of the flow-spec feature must include port qualifier size 3 bits (see Flowspec TCAM Profile and Flowspec Policer TCAM Profile below).
EOS Release 4.24.1 Enhancements:
Added support for BGP Flowspec in the DCS-7500R3 and DCS-7280R3 series.
Added support for configuring BGP Flowspec in multiple VRFs.
EOS Release 4.24.2 Enhancements:
Removed EOS Release 4.23.1 limitation to best effort programming.
EOS Release 4.25.2 Enhancements:
Added support for BGP Flowspec applied to SVI.
BGP Flowspec releases TCAM banks when no longer needed to store matches. Previously, once TCAM banks allocated to BGP Flowspec, they never released.
EOS Release 4.30.0F Enhancements
Added support for below and above police counters.
EOS Release 4.30.1F Enhancements
Added support for the source VRF override the configuration and apply flowspec rules received in a different VRF.
EOS Release 4.30.2F Enhancements
Added support for displaying per-match byte counters in addition to packet counters in the output of show flow-spec.
EOS Release 4.31.1F Enhancements
Added support tor traffic-rate-packets policing action from RFC8955.
To redirect to a nexthop, IP RIB must have a route to resolve the specified nexthop. When redirecting to a VRF, a default route for the VRF must be configured and traffic sent to the nexthop for the default route in this VRF.
Prior to version EOS Release 4.22.0, to redirect to a nexthop or VRF, the resolving route cannot use the MPLS VPN or GRE tunnel, so the resolving route must have regular IP nexthop(s) for the redirect action. This limitation removed in EOS Release 4.22.0, except for the IPv6 GRE tunnels support for redirect action.
All matching components described in RFC 5575 supported, except for the following known caveats:
For TCP flags, the ECE, CWR, and NS flags not supported.
For fragment flags, only the Is a fragment (IsF) bit supported only for IPv4 packets. Combining source and destination ports and the Fragment flags in the same rule not supported.
When enabling support for BGP FlowSpec policer, EOS disables the BGP FlowSpec counter feature due to a hardware limitation.
Beginning with EOS Release 4.23.2, the BGP FlowSpec address family can be configured in a non-default VRF. However, only a single VRF (default or non-default) may be used on EOS Release 4.24.0 or earlier versions.
The additional BGP NLRI type (AFI=1, SAFI=134) which can be used to propagate traffic filtering information in a BGP/MPLS VPN environment not supported.
The validation procedure described in RFC 5575 not supported. Any received BGP FlowSpec rules considered valid.
EOS Release 4.32.0F introduced support for BGP FlowSpec counter telemetry. BGP FlowSpec couters update periodically based on a specified interval. Currently, EOS supports an interval between 30 and 300 seconds. To enable BGP FlowSpec counter telemetry, use the following command:
flow-spec
counters poll interval 30-300 seconds
BGP Limitations
EOS does not support BGP FlowSpec rules for ECMP. If BGP FlowSpec receives the same rule from two peers and ECMP configured, only the actions received from the ECMP head apply.
BGP Graceful Restart not supported.
Policies applied on the BGP FlowSpec NLRI not supported. This means that prefix-list matching rules in a route-map do not match against BGP FlowSpec rules.
BGP Additional Paths Send functionality not supported.
Platform Limitations
BGP FlowSpec rules can only be applied to traffic received on routed Ethernet and Port-Channel interfaces in the initial release. Beginning with EOS Release 4.24.0, support for L3 subinterfaces added. Beginning with EOS Release 4.25.0, support for SVIs added. L2 interfaces not supported.
Counters can either be reported for BGP FlowSpec or ACLs, but not both.
With EOS Release 4.24.1 and earlier versions, if the number of flow-spec rules exceed the available hardware TCAM resources, EOS removes all rules and logs a message.
Reinstalling the entire set of BGP FlowSpec rules removes all existing rules from the hardware.
Scaling Limits
that are supported in BGP FlowSpec depend on the match criteria of each rule. Assuming that BGP FlowSpec is the only TCAM feature enabled on the switch, it attempts to use all of the TCAM space available (24K entries per chip) in the forwarding chip. Simple BGP FlowSpec IPv4 rules map to one entry, allowing a max of 24K rules. Simple IPv6 rules each take two entries with a maximum of 12K rules.
Some types of rules expand into multiple entries in the TCAM, for example, port ranges. Combining source and destination port ranges in a single rule multiplies the number of entries necessary to cover all combinations, which can quickly consume all of the TCAM space.
The BGP FlowSpec and BGP FlowSpec Policer TCAM profiles support configuring the feature on up to seven VRFs starting with EOS Release 4.24.1. This scale can be adjusted with the number of bits in the feature's port qualifier size at the expense of removing other TCAM key fields.
EOS adds support to use large community lists in the set large community route map set clause.
The Support for Set Large Community List feature allows a large community list to be shared between a number of route maps. Changes to the large community list then affect all route-maps which use this list. This makes applying the same policy change to different inbound and outbound communication easier.
Properties of large communities and how to create large community lists are not be covered as those are described here.
Configuring Support for Set Large Community List
The following commands have been added to route map configuration:
set large-community large-community-listLIST1 [LIST2][additive | delete]
no set large-community large-community-listLIST1 [LIST2][additive | delete]
default set large-community large-community-listLIST1 [LIST2][additive | delete]
The following command replaces the large community value of the contents of the permit sequences of the specified large community list. It is possible to specify more than one large community list to the set clause. In this example, the community values in permit sequences in the lists are concatenated and applies in the set clause.
set large-community large-community-listLIST1 [LIST2]
no set large-community large-community-listLIST1 [LIST2]
default set large-community large-community-listLIST1 [LIST2]
The following command works similarly to the prior command, however, it does not replace communities already set on a route; it concatenates the community values with the values specified in the list. Duplicate communities are only shown once.
default set large-community large-community-listLIST1 [LIST2][additive]
set large-community large-community-listLIST1 [LIST2][additive]
no set large-community large-community-listLIST1 [LIST2][additive]
In the following command, the delete keyword is used. The delete keyword specifies that any large community values in the input matching any of the large community values (or large community value regular expressions) in the specified large community lists are removed.
default set large-community large-community-listLIST1 [LIST2][delete]
set large-community large-community-listLIST1 [LIST2][delete]
no set large-community large-community-listLIST1 [LIST2][delete
Apply the following command to the concerned neighbour which large communities are to be sent, otherwise they are not sent.
neighbourx.x.x.xsend-community large
Support for Set Large Community List Show Commands
Use the following command to show information about all of the configured route maps.
show route-map
This is an example output of the show route-map command.
switch# show route-map
route-map rm1 permit 10
Description:
Match clauses:
SubRouteMap:
Set clauses:
set large-community large-community-list lgl1 lgl2
Support for Set Large Community List Limitations
Resolution of NLRI from (directly connected) eBGP Speakers
For IPv4 or IPv6 unicast NLRI received from eBGP, directly connected BGP sessions are resolved by only using connected routes, or system-connected, in the parlance of this feature. This feature does not change this behavior, nor will configuration of a non-default resolution profile affect this behavior.
Address Family Profile Restrictions
Certain BGP address families only support a subset of possible next-hop resolution profiles. This section documents such limitations.
Table 2.Limitations
Address family
Restriction
IPv4/IPv6 unicast (non 6PE)
None.
IPv6 unicast 6PE
Only supports tunnel domains*.
IPv4/IPv6 unicast (eBGP directly connected)
Only supports system-connected; Not configurable.
IPv4/IPv6 VPN
Only supports tunnel domains* and system-connected.
IPv4/IPv6 LU
Only supports tunnel domains* and system-connected.
EVPN (MPLS)
Only supports tunnel domains* and system-connected.
EVPN (VXLAN)
Only supports IP domains+.
* Tunnel domains refer to tunnel RIBs, e.g. system-colored-tunnel-rib, system-tunnel-rib, or user-defined tunnel RIBs.
+ IP domains are either of system-unicast-rib or system-connected.
BGP Additional Paths Send Optimization
BGP Add-Path TX, or send, allows for a BGP speaker to advertise multiple paths (instead of a single best-path) for a prefix towards a peering BGP speaker. BGP Add-Path increases path diversity in a network. It restores fast traffic and has efficient link usage through multipathing. This can also be used as a monitoring solution for eligible paths to a monitoring or receiving Add-Path speaker.
Without Add-Path, a sending speaker only sends the best-path for a prefix and a receiving speaker collects all best-path announcements from its peers. The receiving speaker uses only the peer’s address to identify the path.
With Add-Path, the sending speaker can potentially send multiple paths using distinct path-id’s to a peer and the receiver can use to distinguish the multiple paths coming from the same sender.
Ordered Next Hops in FEC
In symmetric network topology, for the same Equal Cost Multi-Path (ECMP) route programmed at different devices in a switch layer, the various devices can program ECMP next-hops in the Forwarding Equivalence Class (FEC) for that route in varying orders. This could result in inconsistent hashing of traffic for those destination routes at the same layer of switches in the network and could be undesired behavior for certain classes of applications. Ordered FEC is an approach to order the next hops in the FEC of a route based on a network-wide device identifier for each next-hop resulting inconsistent ordering of next hops in the FEC for a route across all switches in a layer.
A BGP router-id can be used as a unique network-wide device identifier and BGP paths received from various peers for a BGP ECMP route can have their paths and subsequently, next-hops sorted based on the corresponding peer’s router-id. Ordered Next Hops in the FEC feature would use the BGP router-id to achieve a consistent ordering of next hops in the FEC for a route. This feature is available with multi-agent routing protocol models.
EOS supports mixed IPv4 and IPv6 next hops in a network. An ECMP FEC may have an IPv4 primary route with a secondary IPv6 next hop or an IPv6 route with a secondary IPv4 next hop.
Configuring Ordered Next Hops in FEC
Use the following configuration commands to implement Ordered FEC solution for BGP routes.
The BGP instance must be configured to order ECMP paths received for a BGP route deterministically using bgp bestpath tie-break router-id under router bgp configuration mode.
Note: Other tie-break options available under router bgp configuration mode is not supported for Ordered Next Hops in FEC solution.
The device must be configured to enforce ordering of next hops as determined by the protocol agents in the FEC programmed for the route using the rib fib fec ecmp ordered command under router general configuration mode.
switch(config)# router general
switch(config-router-general)# rib fib fec ecmp ordered
switch(config-router-general)#
Ordered FEC Show Commands
The show ip route fec command displays if the next-hops in the FEC of a route have been ordered. The output below indicate the show command output before enabling the Ordered FEC solution on the device, and after enabling it. The show ip bgp command output is also included to correlate next hop with corresponding router-id of the peer that the path was received from.
Example
switch# show ip bgp 1.0.16.0
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 1
BGP routing table entry for 1.0.16.0/24
Paths: 8 available
30
1.0.10.2 from 1.0.10.2 (10.0.1.1)
Origin EGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:01:53 ago, valid, external, ECMP head, ECMP, best, ECMP contributor
Rx SAFI: Unicast
10
1.0.8.2 from 1.0.8.2 (10.0.4.1)
Origin EGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:01:55 ago, valid, external, ECMP, ECMP contributor
Rx SAFI: Unicast
20
1.0.9.2 from 1.0.9.2 (10.0.3.1)
Origin EGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:01:54 ago, valid, external, ECMP, ECMP contributor
Rx SAFI: Unicast
40
1.0.11.2 from 1.0.11.2 (10.0.8.1)
Origin EGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:01:52 ago, valid, external, ECMP, ECMP contributor
Rx SAFI: Unicast
50
1.0.12.2 from 1.0.12.2 (10.0.2.1)
Origin EGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:01:52 ago, valid, external, ECMP, ECMP contributor
Rx SAFI: Unicast
60
1.0.13.2 from 1.0.13.2 (10.0.5.1)
Origin EGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:01:51 ago, valid, external, ECMP, ECMP contributor
Rx SAFI: Unicast
70
1.0.14.2 from 1.0.14.2 (10.0.6.1)
Origin EGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:01:50 ago, valid, external, ECMP, ECMP contributor
Rx SAFI: Unicast
80
1.0.15.2 from 1.0.15.2 (10.0.7.1)
Origin EGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:01:49 ago, valid, external, ECMP, ECMP contributor
Rx SAFI: Unicast
switch#
switch# show ip ro 1.0.16.0 fec
FEC ID 4294967334, used by 100 IPv4 prefixes and 0 IPv6 prefixes
Next hops:
via 1.0.8.2, Ethernet8
via 1.0.9.2, Ethernet9
via 1.0.10.2, Vlan2317
via 1.0.11.2, Vlan2836
via 1.0.12.2, Vlan2043
via 1.0.13.2, Ethernet4
via 1.0.14.2, Vlan2000
via 1.0.15.2, Vlan2191
switch#
switch(config)# router general
switch(config-router-general)# rib fib fec ecmp ordered
switch(config-router-general)# end
switch# show ip route 1.0.16.0 fec
FEC ID 4294967334, used by 100 IPv4 prefixes and 0 IPv6 prefixes
Next hops (ordered):
via 1.0.10.2, Vlan2317
via 1.0.12.2, Vlan2043
via 1.0.9.2, Ethernet9
via 1.0.8.2, Ethernet8
via 1.0.13.2, Ethernet4
via 1.0.14.2, Vlan2000
via 1.0.15.2, Vlan2191
via 1.0.11.2, Vlan2836
Limitations
Ordered FEC is supported only for IPv4 and IPv6 BGP ECMP routes received with directly connected next hops.
BGP IPv4-mapped IPv6 Address Next Hops for IPv6 Labeled-Unicast Routes
A BGP router in an IPv4 network may need to receive or send labeled-unicast routes to and from IPv6 networks. A receiving BGP router can be configured so that when it receives a next hop with an IPv4-mapped IPv6 address, the IPv4 address is used for resolving the next hop. Similarly, a sending BGP router can use the IPv4-mapped IPv6 address of its interface as the next hop. For example, this allows IPv6 labeled-unicast EPE bindings to be carried across an IPv4 MPLS network with a next hop corresponding to the border node's loopback IPv4-mapped IPv6 address. The iBGP peer receiving the IPv6 labeled-unicast EPE bindings resolves the IPv4-mapped IPv6 next hop over a IPv4 MPLS transport tunnel.
Example
In this example, a labeled-unicast path from a BGP router in one IPv6 network needs to cross an IPv4 MPLS network to a BGP router in another IPv6 network, as shown in the figure.
Figure 3.IPv4-mapped IPv6 address example
Customer edge router CE2 advertises an IPv6 labeled-unicast route to provider edge router PE2.
PE2 advertises to PE1 the IPv6 labeled-unicast route using the IPv4-mapped address of its loopback interface.
PE1 receives the IPv6 labeled-unicast route, and uses the IPv4 address of the IPv4-mapped IPv6 address in order to resolve the next hop. It resolves to PE2 with an IPv4 multiprotocol label switching (MPLS) tunnel.
PE1 advertises the IPv6 labeled-unicast route to CE1.
This allows a BGP speaker to send and receive IPv6 labeled-unicast paths with IPv4-mapped IPv6 next hops through the use of appropriate send-side policy and receive-side policy.
BGP Monitoring Protocol for a Multi-agent Model
BGP Monitoring Protocol (BMP) allows a monitoring station to connect to a router and collect all BGP announcements received from the BGP peers of the router. BGP sends announcements to the monitoring station as BMP Route Monitoring messages generated from path information in the BGP internal tables on the router. A BMP speaker may choose to send either Adj-Rib-In routes or Loc-Rib routes, or both.
The router sends unidirectional BMP messages to the monitoring station and does not send monitoring messages from the monitoring station to the router. The router configuration controls the information sent to a monitoring station.
In addition to sending Route Monitoring messages, BMP also sends the following messages:
Initiation - Sent at the beginning of a session and identifies the router.
Termination - An optional message sent at the end of a session that contains the reason for closing the session.
Peer Up - Indicates the BGP peer has an established state.
Peer Down - Indicates the BGP peer transitioned to an unestablished state.
Figure 4.BGP Monitoring Protocol Overview
Configuring BGP
These sections describe basic BGP configuration steps:
Creating an Instance and Entering BGP Configuration Mode
The switch supports one BGP instance, which is associated with a specified Autonomous System (AS). To other BGP peers, the AS number uniquely identifies the network to which the switch belongs. Arista switches support four-byte AS numbers as described in RFC 4893. Four-byte AS number capability is communicated to BGP peers in OPEN messages. When communicating with a BGP peer which does not support four-byte AS numbers, the switch will replace AS numbers greater than 65535 with the well-known two-byte AS number 23456 (also called AS_TRANS), and encode the actual four-byte AS numbers using the AS4_PATH attribute.
The switch must be in router-BGP configuration mode to run BGP configuration commands. The router bgp command places the switch in the router-BGP configuration mode for creating a BGP instance if one was not previously created. BGP configuration commands apply globally to the BGP instance.
Example
This command places the switch in router-BGP configuration mode. It also creates a BGP instance in AS 50 if an instance was not previously created.
When a BGP instance exists, the router bgp command must include its autonomous system. Any attempt to create a second instance results in an error message.
Example
This command attempts to open a BGP instance with a different AS number from that of the existing instance. The switch displays an error and stays in global configuration mode.
switch(config)# router bgp 100
% BGP is already running with AS number 50
switch(config)#
Configuring BGP in a VRF
IPv6 VRF support in EOS allows application of a BGP configuration to a single VRF instance, overriding global commands. To apply VRF-specific BGP configuration, use the vrf command within router-BGP configuration mode to enter BGP VRF configuration mode. IPv6 BGP VRF configuration is performed in the VRF submode of the router-BGP configuration mode. This submode is also where a Route Distinguisher (RD) is configured for a VRF on switches running Ethernet VPN (EVPN): use the rd (Router-BGP VRF and VNI Configuration Modes) command to configure an RD for a VRF.
Examples
These commands place the switch in BGP VRF configuration mode for VRF purple. Commands issued in this mode override the global BGP configuration for the specified VRF instance.
RCF functions support in EOS allows application of a BGP configuration to filter routes and update route attributes. RCF functions can be configured for inbound and outbound updates on BGP neighbors under the IPv4 unicast, IPv6 unicast, IPv4 labeled unicast, and IPv6 labeled unicast address families.
Examples
These commands configure the switch in RCF functions for IPv4 application.
switch(config)# router bgp 64500
switch(config-router-bgp)# address-family ipv4
switch(config-router-bgp-af)# neighbor 192.168.0.1 rcf in INBOUND_POLICY()
switch(config-router-bgp-af)# neighbor 192.168.0.1 rcf out OUTBOUND_POLICY()
These commands configure the switch in RCF functions for IPv6 unicast application.
switch(config)# router bgp 64500
switch(config-router-bgp)# address-family ipv6 labeled-unicast
switch(config-router-bgp-af-label)# neighbor 192.168.0.1 rcf in LU_INBOUND_POLICY()
switch(config-router-bgp-af-label)# neighbor 192.168.0.1 rcf out LU_OUTBOUND_POLICY()
These commands configure RCF function with the redistribute configuration statement for connected and static routes.
These commands configure RCF function on routes redistributed into BGP from IS-IS. Level 1, level 2, or both IS-IS level routes can be specified for RCF application.
BGP neighbors, or peers, are established by configuration commands that initiate a TCP connection. BGP supports two types of neighbors:
Internal neighbors are in the same autonomous system.
External neighbors are in different autonomous systems.
BGP neighbors can be either static or dynamic:
Static neighbors are established by manually configuring the connection.
Dynamic neighbors are established by creating a listen range and accepting incoming connections from neighbors in that address range.
Static neighbors may belong to a static peer group, allowing them to be configured as a group. Configuration applied to an individual member of a static peer group overrides the group configuration for that peer. Dynamic neighbors must belong to a dynamic peer group, and can only be configured as a group.
Static BGP Neighbors
The neighbor remote-as command connects the switch with a peer, establishing a static neighbor.
Once established, a static neighbor may be added to an existing peer group. Any configuration applied to the peer group then is inherited by the neighbor, unless a conflicting configuration has been entered for that peer. Settings applied to a member of the peer group override group settings.
Note: To establish a BGP session, there must be an IPv4 router ID configured in the same VRF or at least one L3 interface with an IPv4 address in the same VRF. If the VRF contains no L3 interfaces with IPv4 addresses (for example, in an IPv6-only environment), configure an appropriate router ID using the router-id (BGP) command.
Examples
These commands establish an internal BGP connection with the peer at 10.1.1.14.
The bgp listen range command specifies a range of IPv4 addresses from which the switch will accept incoming dynamic BGP peering requests, and creates the named dynamic peer group to which those peers belong. Dynamic BGP neighbors are peers which have not been manually established, but are accepted into a dynamic peer group when the switch receives a peering request from them.
Dynamic peers cannot be configured individually, but inherit any configuration that is applied to the peer group to which they belong. Peering relationships with dynamic peers are terminated if the peer group is deleted.
Example
These commands create a peer group called “brazil” which accepts dynamic peering requests from the 192.168.2.0/24 subnet.
switch(config)# router bgp 50
switch(config-router-bgp)# bgp listen range 192.168.2.0/24 peer-group brazil remote-as 50
switch(config-router-bgp)#
This command indicates the connection state with the peer at 192.168.2.5 is Estab (established). The peer is an external neighbor because it is in AS 100 and the local server is in AS 50.
switch# show ip bgp summary
BGP summary information for VRF default
BGP router identifier 192.168.104.2, local AS number 50
Neighbor Status Codes: m - Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc
192.168.2.5 4 100 198 281 0 0 03:11:31 Estab 12 12
switch#
Static BGP Peer Groups
A static BGP peer group is a collection of BGP neighbors which can be configured as a group. Once a static peer group is created, the group name can be used as a parameter in neighbor configuration commands, and the configuration will be applied to all members of the group. Neighbors added to the group will inherit any settings already created for the group. Static peer group members may also be configured individually, and the settings of an individual neighbor in the peer group override group settings for that neighbor.
When the default form of a BGP configuration command is entered for a member of a static peer group, the peer inherits that configuration from the peer group.
The neighbor peer group (create) command will delete a static peer group. When a peer group is deleted, the members of that group revert to their individual configurations, or to the system default for any attributes that have not been specifically configured for that peer.
Examples
These commands create a peer group named akron.
switch(config)# router bgp 50
switch(config-router-bgp)# neighbor akron peer group
switch(config-router-bgp)#
This command adds the neighbors at 1.1.1.1 and 2.2.2.2 to peer group akron.
switch(config-router-bgp)# neighbor 1.1.1.1 peer group akron
switch(config-router-bgp)# neighbor 2.2.2.2 peer group akron
switch(config-router-bgp)#
These commands configure the members of peer group akron, but cause the neighbor at 1.1.1.1 to use the system default value for out-delay.
A dynamic BGP peer group is a collection of BGP neighbors in a specified address range which makes a peer request to the switch. Members of dynamic peer group are configured in groups and not as individuals. A dynamic peer group name is used as a parameter to apply the configuration across all the members in the group. Neighbors joining the group inherit any settings already created for the group.
The bgp listen range command is used to create a dynamic peer group. This command identifies the BGP peering request from a range of IP address, and names the dynamic peer group to which those peers belong to. The bgp listen range command can be configured to accept a peering request from a single AS number or to accept peer request from the range of AS numbers. To accept the request from the range of AS numbers use the peer filter option in the command as shown. If the peer filter referred by the bgp listen range command does not exist, or if the filter exists but has no match commands, it will accept any AS number.
Note: When a listen range command is modified, any existing dynamic neighbor that is already established will get reset.
To delete a dynamic peer group, use the no or default form of the bgp listen range command. All peering relationships with group members are terminated when the dynamic peer group is deleted.
Examples
These commands create a dynamic peer group called brazil in a single AS, which accepts peering requests from the 192.0.2.0/24 subnet the single AS is 5.
switch(config)# router bgp 1
switch(config-router-bgp)# bgp listen range 192.0.2.0/24 peer-group brazil remote-as 5
switch(config-router-bgp)#
These commands create a dynamic peer group called brazil in a range of ASNs, which accepts peering requests from the 192.0.2.0/24 subnet. The range of AS numbers is defined by peer filter option.
switch(config)# router bgp 1
switch(config-router-bgp)# bgp listen range 192.0.2.0/24 peer-group brazil peer-filter group-1
switch(config-router-bgp)#
The show ip bgp peer-group command displays the source of a listen range’s remote AS number definition as shown.
switch(config-router-bgp)# show ip bgp peer-group
BGP peer-group is brazil
BGP version 4
Listen-range subnets:
VRF default:
192.0.2.0/24, remote AS 5
192.0.2.0/24, peer filter group1
switch(config-router-bgp)#
Peer Filter
A peer filter defines a set of rules to decide whether to accept or reject the incoming peer request based on the peer’s attributes. The peer filter is defined using a sequence number and a match statement, and supports one new match statement for matching against a range of BGP AS numbers. A peer filter is defined in peer filter configuration mode as shown. The peer filter command supports only matching AS ranges. Unlike route maps, peer filters do not support sets, continues or subroutines.
To delete a peer filter, use the no peer filter or default peer filter commands.
Examples
These commands define a peer filter that accepts any AS number.
switch(config)# peer-filter group1
switch(config-peer-filter-group1)# 10 match as-range 1-4294967295 result accept
switch(config-peer-filter-group1)#
These commands define a peer filter that accepts any AS number between 65000 and 65100 (inclusive) except 65008 and 65009.
switch(config)# peer-filter group2
switch(config-peer-filter-group2)# 10 match as-range 65008-65009 result reject
switch(config-peer-filter-group2)# 20 match as-range 65000-651000 result accept
switch(config-peer-filter-group2)#
These commands define a peer filter that accepts 3 specific remote AS numbers.
switch(config)# peer-filter group3
switch(config-peer-filter-group3)# 10 match as-range 65003 result accept
switch(config-peer-filter-group3)# 20 match as-range 65007 result accept
switch(config-peer-filter-group3)# 30 match as-range 65009 result accept
switch(config-peer-filter-group3)#
The show peer-filter command displays the peer filter definition.
switch(config)# show ip bgp peer-group3
peer-filter group3
10 match as-range 65003 result accept
20 match as-range 65007 result accept
30 match as-range 65009 result accept
switch(config)#
Special Considerations for IPv6
BGP predates the use of IPv6, and BGP configuration assumes IPv4 connections by default. The following additional steps are used to configure IPv6 BGP neighbors.
Note: To establish a BGP session, there must be an IPv4 router ID configured in the same VRF or at least one L3 interface with an IPv4 address in the same VRF. If the VRF contains no L3 interfaces with IPv4 addresses (e.g., in an IPv6-only environment), configure an appropriate router ID using the router-id (BGP) command.
Activating IPv6 Neighbors
By default, the switch does not negotiate or advertise IPv6 BGP routes. In order to establish a session with an IPv6 neighbor, it must be made active in the IPv6 address family. The ipv6-unicast option of the bgp default command causes the switch to send IPv6 capability messages and all network advertisements with IPv6 prefixes to all BGP neighbors. The neighbor activate command issued in IPv6 address family configuration mode does the same for a single BGP neighbor.
Examples
These commands make all BGP neighbors active in the IPv6 address family.
The switch supports the exchange of IPv4 NLRIs with IPv6 neighbors. To enable this feature for all IPv6 neighbors, use the ipv4-unicast transport ipv6 option of the bgp default command in the IPv4 address family configuration mode. To enable it for a single IPv6 neighbor, use the neighbor activate command for that neighbor in the IPv4 address family configuration mode.
To send IPv4 NLRIs to IPv6 neighbors, the IPv4 next-hop address must also be communicated. To explicitly configure an IPv4 next hop to send to a specific IPv6 neighbor, use the neighbor local-v4-addr command. In some network configurations, the switch can also be configured to automatically determine the best IPv4 next-hop address for an individual IPv6 neighbor or for all neighbors in the VRF using the neighbor auto-local-addr command.
Examples
These commands permit IPv4 NLRI transport over all IPv6 connections by making the IPv4 address family active on IPv6 BGP neighbors, then configure the switch to automatically select a local IPv4 address to be sent in NLRIs to the IPv6 neighbors in a peer group called indianapolis.
switch(config)# router bgp 11
switch(config-router-bgp)# address-family ipv4
switch(config-router-bgp-af)# bgp default ipv4-unicast transport ipv6
switch(config-router-bgp-af)# exit
switch(config-router-bgp)# neighbor indianapolis auto-local-addr
switch(config-router-bgp)#
These commands permit IPv4 NLRI transport with the IPv6 neighbor at 2001:0DB8:8c01::1 using a local IPv4 address of 10.7.5.11.
BGP neighbors maintain connections by exchanging KEEPALIVE, UPDATE, and NOTIFICATION messages. Neighbors that do not receive a message from a peer within a specified period (hold time) close the BGP session with that peer. Hold time is typically three times the period between scheduled KEEPALIVE messages. The default keepalive period is 60 seconds; default hold time is 180 seconds.
The timers bgp command configures the hold time and keepalive period. A peer retains its BGP connections indefinitely when its hold time is zero.
Example
This command sets the keepalive period to 15 seconds and the hold time to 45 seconds.
This command indicates the BGP hold time is 45 seconds.
switch# show ip bgp neighbors 10.100.100.2
BGP neighbor is 10.100.100.2, remote AS 100
BGP version 4, remote router ID 192.168.100.13, VRF default
Negotiated BGP version 4
Last read 00:00:05, last write 00:00:05
Hold time is 45, keepalive interval is 15 seconds <= hold time
Configured hold time is 45, keepalive interval is 15 seconds
Connect timer is inactive
Idle-restart timer is inactive
BGP state is Established, up for 04:44:05
Number of transitions to established: 11
Last state was OpenConfirm
Last event was RecvKeepAlive
Last sent notification:Cease/administrative reset, Last time 04:44:09
Last rcvd notification:Cease/peer de-configured, Last time 2d02h, First time 7d08h, Repeats 1
Neighbor Capabilities:
Multiprotocol IPv4 Unicast: advertised and received and negotiated
Four Octet ASN: advertised and received
<-------OUTPUT OMITTED FROM EXAMPLE------->
switch#
Neighbor Route Configuration
Maximum Routes
The neighbor maximum-routes command determines the number of BGP routes the switch accepts from a specified neighbor. The switch disables peering with the neighbor when this number is exceeded.
Example
This command configures the switch to accept 15,000 routes from the peer at 192.168.18.24.
Participating BGP routers within an AS communicate eBGP-learned routes to all of their peers; they do not re-advertise iBGP-learned routes within the AS to prevent routing loops. Although a fully meshed network topology ensures that all AS members share routing information, this topology can result in high volumes of iBGP messages when scaled. Alternatively, one or more routers can be configured as route reflectors in larger networks.
A route reflector re-advertises routes learned through iBGP to a group of BGP neighbors within the AS, replacing the function of a fully meshed topology. The neighbor route-reflector-client command configures the switch to act as a route reflector and configures the specified neighbor as a client. The bgp client-to-client reflection command enables client-to-client reflection.
Cluster IDs When using route reflectors, an AS is divided into clusters. A cluster contains at least one route reflector and a group of clients to which they re-advertise route information. A cluster may contain multiple route reflectors to provide redundancy protection. Each reflector has a cluster ID. When the cluster has a single route reflector, the cluster ID is its router ID. When a cluster has multiple route reflectors, a 4-byte cluster ID is assigned to all route reflectors in the cluster, allowing them to recognize updates from other cluster reflectors. The command configures the cluster ID in a cluster with multiple route reflectors.
Attribute Preservation Outbound BGP policies can rewrite the BGP attributes (next-hop, local preference and metric) of routes advertised by a route reflector. To configure the route reflector to preserve these attributes regardless of policy (unless those policies are included in a route map), use the bgp route-reflector preserve-attributes command. To include route attributes at all times (even contrary to policies included in route maps), use the always option of the command.
Client-to-client Reflection Usually the clients of a route reflector are not interconnected, and any routes learned by a client are mirrored to other clients and re-advertised within the AS by the route reflector. If the clients of a route reflector are fully meshed, routes received from a client do not need to be mirrored to other clients. In this case, client-to-client reflection should be disabled using the bgp client-to-client reflection command.
Examples
These commands configure the switch as a route reflector and the neighbor at 172.72.14.5 as one of its clients, set the cluster ID to 172.22.30.101, and configure the reflector to preserve all BGP attributes of re-advertised routes.
This command displays the global BGP status for the default VRF, including route reflector configuration.
Note: The value of the “Attributes of reflected routes” can be preserved (reflected routes maintain attributes unless they are removed by an outbound BGP policy map), always preserved (reflected routes maintain BGP attributes regardless of all policies), or not preserved (reflected routes do not maintain their BGP attributes).
switch# show bgp instance
BGP instance information for VRF default
BGP Local AS: 64512, Router ID: 1.1.4.1
Total peers: 14
Configured peers: 14
UnConfigured peers: 0
Disabled peers: 4
Established peers: 9
Graceful restart helper mode enabled
Attributes of reflected routes are preserved
End of rib timer timeout: 00:05:00
BGP Convergence timer is inactive
BGP Convergence information:
BGP has converged: yes, Time taken to converge: 00:05:44
Outstanding EORs: 0, Outstanding Keepalives: 0
Convergence timeout: 00:10:00
switch#
Route Preference
The primary function of external peers is to distribute routes they learn from their peers. Internal peers receive route updates without distributing them. External peers receive route updates, then distribute them to internal and external peers.
Local preference is a metric that iBGP sessions use to select an external route. Preferred routes have the highest local preference value. UPDATE packets include this metric in the LOCAL_PREF field.
The neighbor export-localpref command specifies the LOCAL_PREF that the switch sends to an internal peer. The command overrides previously assigned preferences and has no effect on external peers.
Example
This command configures the switch to enter 200 in the LOCAL_PREF field of UPDATE packets it sends to the peer at 10.1.1.45.
The neighbor import-localpref command assigns a local preference to routes received through UPDATE packets from an external peer. This command has no effect when the neighbor is an internal peer.
Examples
This command configures the switch to assign the local preference of 50 for routes advertised from the peer at 172.16.5.2.
The show ip bgp command displays the LOCAL_PREF value for all listed routes.
This command indicates the route to network 10.10.20.0/24 has a local preference of 400.
switch# show ip bgp
BGP routing table information for VRF default
Router identifier 192.168.100.23, local AS number 64512
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* >Ec 10.10.20.0/24 192.168.31.3 0 400 0 64521 i
switch#
Graceful Restart
Graceful BGP restart allows a BGP speaker with separate control plane and data plane processing to continue forwarding traffic during a BGP restart. Its neighbors (receiving speakers) may retain routing information from the restarting speaker while a BGP session with it is being re-established, reducing route flapping.
Arista switches can act as helpers (receiving speakers) for graceful BGP restart with neighbors that advertise graceful restart capability.
Graceful restart helper mode is enabled by default, but can be turned off globally with the graceful-restart-helper command. Per-peer configuration takes precedence over the global configuration.
Examples
This command disables graceful restart helper mode for all BGP peers.
switch(config-router-bgp)# no graceful-restart-helper
switch(config-router-bgp)#
This command disables graceful restart helper mode for the neighbor at 192.168.32.5 regardless of global configuration.
switch(config-router-bgp)# no neighbor 192.168.32.5 graceful-restart-helper
switch(config-router-bgp)#
Peers with graceful restart capability advertise a restart time value as an estimate of the time it will take them to restart a BGP session. When a BGP session with a restarting speaker goes down, the switch (receiving speaker) marks routes from that peer as stale and starts the restart timer. If the session with the peer is not re-established before the restart time runs out, the switch deletes the stale routes from that peer. If the session is re-established within that time, the stale path timer is started. If the stale paths are not updated by the restarting speaker before the stale path time runs out, they are deleted. The maximum time these stale paths are retained after the BGP session is re-established is 300 seconds by default, but can be configured using the graceful-restart stalepath-time command.
Example
This command configures BGP to discard stale paths from a restarting peer 500 seconds after the BGP session with that peer is re-established.
Route maps are used in BGP to directly filter IPv4 unicast routes. The neighbor route-map (BGP) command applies a route map to inbound or outbound BGP routes. To display the route maps associated with a specific BGP neighbor, use the show ip bgp neighbors command.
The redistribution of BGP unicast routes into multicast address families allows the network to take a different path for the multicast traffic. It allows redistribution of IPv4 unicast routes into the IPv4 multicast address family and IPv6 unicast routes into the IPv6 multicast address family.
The following command configures the redistribution of IPv4 unicast routes into IPv4 multicast address family in both default and non-default VRF.
The following commands shows the two BGP unicast routes that are received by bgprtr1.
bgprtr1(config-router-multicast)# show bgp ipv4 unicast
BGP routing table information for VRF default
Router identifier 1.1.1.1, local AS number 100
Route status codes: s - suppressed, * - valid, > - active, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI Origin Validation codes: V - valid, I - invalid, U - unknown
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric AIGP LocPref Weight Path
* > 10.10.10.1/32 1.1.1.2 0 - 100 0 200 i
* > 10.10.20.1/32 1.1.1.2 0 - 100 0 200 i
The following command shows BGP IPv4 multicast output, when a RCF function filters 10.10.20.1/32.
bgprtr1# show bgp ipv4 multicast
BGP routing table information for VRF default
Router identifier 1.1.1.1, local AS number 100
Route status codes: s - suppressed, * - valid, > - active, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric AIGP LocPref Weight Path
* > 10.10.20.1/32 1.1.1.2 - - - 0 ?
Filtering with BGP Communities
Community values are assigned to a set of subnet prefixes through route map set commands. Route map match commands subsequently use community values to filter routes. The switch uses the following ip community-list commands to filter community routes into a BGP domain:
ip community-list creates a community list by explicitly referencing one or more communities by name or number.
ip community-list regexp creates a community list by referencing one or more communities by regular expression.
ip extcommunity-list creates an extended community list to identify routes for VRFs or for Link BandWidth (LBW) by explicitly referencing extended communities by prefix and number.
ip extcommunity-list regexp creates an extended community list to identify routes for VRFs or for Link BandWidth (LBW) by regular expression.
The BGP community attribute is a 32 bit value formatted as follows:
an integer between 0 and 4294967040.
AA:NN, where AA is 65535 and NN specifies the community number (0-65535) within the AS.
These four community attribute values, and the associated BGP speaker actions, are predefined:
no-export: speaker does not advertise the routes beyond the BGP domain.
no-advertise: speaker does not advertise the routes to any BGP peers.
local-as: speaker does not advertise route to any external peers.
internet: speaker advertises the route to the Internet community. By default, this includes all prefixes.
Example
These commands assign two network subnets to a prefix list, assign a community number to the prefix list members, then utilize that community in an ip community-list command to permit the routes into the BGP domain.
Compose the IP prefix list.
switch(config)# ip prefix-list PL_1 permit 10.1.2.5/24
switch(config)# ip prefix-list PL_1 permit 10.2.5.1/28
switch(config)#
Create a route map that matches the IP prefix list and sets the community value.
switch(config)# route-map MAP_1 permit
switch(config-route-map-MAP_1)# match ip address prefix-list PL_1
switch(config-route-map-MAP_1)# set community 500
switch(config-route-map-MAP_1)# exit
switch(config)#
Create a community list that references the community.
switch(config)# ip community-list CL_1 permit 500
switch(config)#
BGP extended communities identify routes for VRFs or for Link BandWidth (LBW). Extended community clauses utilize Route Target (RTt) and Site of Origin Options (SOO):
route targets identify sites that may receive appropriately tagged routes.
site of origin identifies the site where the router learned the route.
Filtering with AS Path Access Lists
An AS path access list is a named list of permit and deny statements which use regular expressions to filter BGP routes based on their AS path attribute. AS path access lists are created using the ip as-path access-list command, and are applied using a route map match clause with the name of the access list as a parameter.
Example
These commands create an AS path access list identifying routes which pass through AS 3, create a route map which references the access list, assign the routes it filters to community 300, and apply the route map to the neighbor at 192.68.14.5 to assign a community value of 300 to inbound routes received from that neighbor.
Create the AS path access list.
switch(config)# ip as-path access-list as_list3 permit _3
Create a route map that matches the AS path access list and sets the community value.
switch(config)# route-map MAP_3 permit
switch(config-route-map-MAP_3)# match as-path as_list3
switch(config-route-map-MAP_3)# set community 300
switch(config-route-map-MAP_3)# exit
The Generalized TTL Security Mechanism (GTSM) uses a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect BGP peering sessions from Denial-of-Service (DoS) attacks based on forged protocol packets.
An IP packet received from a BGP peer is discarded when its current TTL value is less than (255-n) where n is the configured maximum number of hops to the peer. Use the neighbor ttl maximum-hops command to configure the maximum hop count.
Note: IP packets to GTSM enabled BGP peers are sent with the configured TTL value of 255.
Configuring Routes
Advertising Routes
A BGP neighbor advertises routes it can reach through UPDATE packets. The network (BGP) command specifies a prefix that the switch advertises as a route originating from its AS.
The configuration clears the host portion of addresses entered in network commands. For example, 192.0.2.4/24 is stored as 192.0.2.0/24.
Example
This command configures the switch to advertise the 10.5.8.0/24 network.
By default, BGP will advertise only those routes that are active in the switch’s RIB. This can contribute to dropped traffic. If a preferred route is available through another protocol (like OSPF), the BGP route will become inactive and not be advertised; if the preferred route is lost, there is no available route to the affected peers. Advertising inactive BGP routes minimizes traffic loss by providing alternative routes.
The bgp advertise-inactive command causes BGP to advertise inactive routes to BGP neighbors. Inactive route advertisement is configured globally, but the global setting can be overridden on a per-VRF basis.
Examples
This command configures the switch to advertise routes learned through BGP even if they are not active on the switch.
This command overrides inactive route advertisement for VRF purple.
switch(config-router-bgp)# vrf purple
switch(config-router-bgp-vrf-purple)# no bgp advertise-inactive
switch(config-router-bgp-vrf-purple)#
Advertising ISIS Routes into BGP Network
The redistribute (BGP) command advertises the routes learned through IS-IS routes into the BGP network. It also allows the user to selectively advertise some routes and modify route attributes before advertising using route maps.
The command is available in both address-family mode and router BGP mode, but the command is rejected if configured in both address-family mode and router mode at the same time.
While redistributing IS-IS routes into BGP, the Level-1 or Level-2 keyword can be used to selectively redistribute Level-1 routes or Level-2 routes into BGP. The keyword is optional, and defaults to Level-2 when not configured.
Use the show ipv6 bgp command to verify that routes are advertised with correct attributes.
Note: If the command is configured in router-af mode, it only redistributes routes with matching address family. If it is configured in router mode, it applies to all enabled address-families.
Examples
These commands redistribute IS-IS routes into BGP in the address-family mode.
Routes learned through the OSPF protocol can be redistributed into the BGP domain and advertised by BGP. To redistribute OSPF routes into BGP, use the redistribute (BGP) command. By default, redistribute ospf will redistribute only internal OSPF routes into BGP; the command must be issued separately with additional parameters for each type of OSPF route that is to be redistributed.
Examples
These commands redistribute internal OSPF routes into BGP.
Aggregation combines the characteristics of multiple routes into a single route for advertisement by the BGP speaker. Aggregation can reduce the amount of information that a BGP speaker is required to store and transmit when advertising routes to other BGP speakers. Aggregation options affect the attributes associated with the aggregated route, the advertisement of the contributor routes that comprise the aggregate, and which contributor routes are included.
Aggregate routes are created with the aggregate-address command, which takes an IP subnet as an argument; any routes configured on the switch that lie within that subnet then become contributors to the aggregate. Note that on Arista switches the BGP aggregate route becomes active if there are any available contributor routes on the switch, regardless of the originating protocol. This includes routes configured statically.
Note: This behavior is observed only when the single-agent routing model (ribd) is run on the switch.
BGP speakers display aggregate routes that they create as null routes (with one exception: if all the contributors to the aggregate have the same BGP path attributes, then the BGP aggregate copies those attributes and is no longer a null route). Aggregate routes are advertised into the BGP autonomous system and redistributed automatically, and their redistribution cannot be disabled. BGP neighbors display inbound aggregate routes as normal BGP routes. Null routes are displayed with the show ip route command. Display normal BGP routes (and null aggregate routes) with the show ip bgp and show ip route commands.
Aggregation Options
The aggregate-address command provides the following aggregate route options:
AS_PATH attribute inclusion: the as-set option controls the aggregate route’s AS_PATH and ATOMIC_AGGREGATE attribute contents. AS_PATH identifies the autonomous systems through which UPDATE message routing information passes. ATOMIC_AGGREGATE indicates that the route is an aggregate or summary of more specific routes.
When the command includes as-set, the aggregate route’s AS_SET attribute contains the AS numbers of contributor routes. This can help BGP neighbors to prevent loops by rejecting aggregate routes that include their AS number in the AS_SET.
When the command does not include as-set, the aggregate route’s ATOMIC_AGGREGATE attribute is set and the AS_PATH attribute does not include AS numbers of contributing routes.
Attribute assignment: the attribute-map option assigns attributes contained in set commands in a specified route map’s lowest sequence with any set command to the aggregated route, overriding the automatic determination of the aggregate route’s attributes by the switch.
Route suppression: the summary-only option suppresses the advertisement of the contributor routes that comprise the aggregate.
Contributor filtering: the match-map option uses a route map to filter out contributor routes that would otherwise be included in the aggregate.
Example
These commands create an aggregate route (10.16.48.0/20) from four contributor routes (10.16.48.0/23, 10.16.50.0/23, 10.16.52.0/23, and 10.16.54.0/23). The aggregate route includes the AS_PATH information from the contributor routes.
These commands create an aggregate route and use a route map to allow only those contributors that match a specified prefix list included in the aggregate route.
The match-map parameter in the aggregate-address command advertises the route(s) denied in match-map.
Note: The match-map parameter only takes effect when used with the summary-only parameter.
Identifying BGP Aggregate Contributors Match in Outbound Policy
When configured, this feature introduces the ability to match on the following parameters:
Any BGP aggregate contributor, in the outbound route maps.
A specific BGP aggregate contributor, in the outbound route maps.
The attributes that are currently supported for matching on BGP aggregate contributors are community, local-preference, prefix, next-hop,route-type.
Match Contributors to Any Aggregate
To match contributors to any BGP aggregate and set attributes (say communities) on said contributor, add an outbound policy with the clause:
switch(config-route-map-test)# match aggregate-role contributor
The match aggregate-role contributor clause only works with outbound policies.
Example
In this example, all the BGP contributor routes (to all aggregates) is assigned to the community 65536:100 as they are advertised to the neighbor 192.0.2.1.
switch(config)# ip community-list BLUE permit 65536:100
switch(config)# route-map OUTBOUND_POLICY permit 10
switch(config-route-map-OUTBOUND_POLICY)# match aggregate-role contributor
switch(config-route-map-OUTBOUND_POLICY)# set community community-list BLUE
!
switch(config)# route-map OUTBOUND_POLICY permit 20
switch(config-route-map-OUTBOUND_POLICY)# description “Permit the routes rejected by seq10"
!
switch(config)# router bgp 65536
switch(config-router-bgp)# aggregate-address 203.0.113.0/24
switch(config-router-bgp)# neighbor 192.0.2.1 route-map OUTBOUND_POLICY out
switch(config-router-bgp)#
Match Contributors to Specific Aggregates
To match contributors which contribute only to a BGP aggregate with specific attributes (say communities) and set attributes (say communities again) on said contributor, add an outbound policy with the clause:
switch(config-route-map-test)# match aggregate-role contributor aggregate-attributes MATCH_AGG_COLOR
Define the MATCH_AGG_COLOR as below:
switch(config)# route-map MATCH_AGG_COLOR
switch(config-route-map-MATCH_AGG_COLOR)# match community RED
Add an aggregate definition to explicitly set the desired attributes on the aggregate of interest:
switch(config)# route-map AGG_SET_COLOR
switch(config-route-map-AGG_SET_COLOR)# set community community-list RED
!
switch(config)# router bgp 65536
switch(config-router-bgp)# aggregate-address 203.0.113.0/24
switch(config-router-bgp)# aggregate-address 203.0.113.0/24 attribute-map AGG_SET_COLOR
The route map referenced by the match aggregate-role contributor aggregate-attributes clause discards all set operations.
Example
In this example the BGP contributor routes to the aggregate 203.0.113.0/24 (that has community 65536:200), to be assigned the community 65536:100 when they are advertised outbound to the neighbor 192.0.2.1.
switch(config)# ip community-list BLUE permit 65536:100
switch(config)# ip community-list RED permit 65536:200
!
switch(config)# route-map AGG_SET_COLOR
switch(config-route-map-AGG_SET_COLOR)# set community community-list RED
!
switch(config-route-map-AGG_SET_COLOR)# route-map MATCH_AGG_COLOR
switch(config-route-map-MATCH_AGG_COLOR)# match community RED
!
switch(config-route-map-MATCH_AGG_COLOR)# route-map OUTBOUND_POLICY permit 10
switch(config-route-map-OUTBOUND_POLICY)# match aggregate-role contributor aggregate-attributes MATCH_AGG_COLOR
switch(config-route-map-OUTBOUND_POLICY)# set community community-list BLUE
!
switch(config-route-map-OUTBOUND_POLICY)# route-map OUTBOUND_POLICY permit 20
switch(config-route-map-OUTBOUND_POLICY)# description “Permit the routes rejected by seq10”
!
switch(config-route-map-OUTBOUND_POLICY)# router bgp 65536
switch(config-router-bgp)# aggregate-address 203.0.113.0/24 attribute-map AGG_SET_COLOR
switch(config-router-bgp)# neighbor 192.0.2.1 route-map OUTBOUND_POLICY out
switch(config-router-bgp)#
Invert-result Support
This match clause supports the invert-result modifier. When applied, invert-result inverts the result of the match clause to which it is applied.
The results for the following command would be:
switch(config-route-map-test)# match invert-result aggregate-role contributor aggregate-attributes MATCH_AGG_COLOR
match all routes that are not contributors to any aggregate.
match all routes that are contributors to aggregates where the aggregate doesn’t match MATCH_AGG_COLOR (provided MATCH_AGG_COLOR is configured).
not match all routes that are contributors to aggregates where the aggregate matches MATCH_AGG_COLOR (provided MATCH_AGG_COLOR is configured).
not match all routes that are contributors to aggregates if MATCH_AGG_COLOR is not configured.
The BGP Replace AS-Path feature allows the user to customize the AS_PATH attribute for prefixes that are either received from a BGP neighbor or advertised to a BGP neighbor. To configure the BGP Replace AS-Path feature, use the set as-path match and set as-path prepend commands.
To replace the AS_PATH attribute of routes received from a BGP neighbor, configure a route map and attach the policy to the corresponding BGP neighbor statement in the inbound direction.
To replace the AS_PATH attribute of routes that are advertised to a neighbor, configure a route map and attach the policy to the corresponding BGP neighbor statement in the outbound direction.
The Replace AS-Path feature works in conjunction with the AS-Path Prepend feature which is also used to modify the AS_PATH attribute. However, if both features are configured within the same route map, then the replace AS-Path feature takes precedence over the AS-Path Prepend.
Note: The BGP Replace AS-Path feature supports both eBGP and iBGP neighbors. The locally configured AS number is always prefixed to the AS-Path of routes advertised to the eBGP neighbors. This RFC behavior is retained in Arista’s implementation of the Replace AS-Path feature as well.
BGP Replace AS-Path has the following limitations:
Replacing the AS-Path should be used cautiously since it may impact BGP loop prevention.
A few duplicated routes may be advertised and installed on a router after the original AS-Path of those routes are replaced. To fix this issue, it is always suggested to filter out such routes by prefix with BGP Community.
Example
This command replaces the AS-Path with the none option.
switch# show ip bgp neighbors 80.80.1.2 advertised-routes
BGP routing table information for VRF default
Router identifier 202.202.1.1, local AS number 200
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E
- ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast, q - Queued
for advertisement
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop -
Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 101.101.1.0/24 80.80.1.1 - - - 200 i
* > 102.102.1.0/24 80.80.1.1 - - - 200 i
* > 103.103.1.0/24 80.80.1.1 - - - 200 302 i
* > 202.202.1.0/24 80.80.1.1 - - - s200 i
switch# configuration terminal
switch(config)# route-map foo permit 10
switch(config-route-map-foo)# set as-path match all replacement none
switch(config-route-map-foo)# exit
switch(config)# router bgp 200
switch(config-router-bgp)# neighbor 80.80.1.2 route-map foo out
switch(config-router-bgp)# end
switch# show ip bgp neighbors 80.80.1.2 advertised-routes
BGP routing table information for VRF default
Router identifier 202.202.1.1, local AS number 200
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E
- ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast, q - Queued
for advertisement
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop -
Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 101.101.1.0/24 80.80.1.1 - - - 200 i
* > 102.102.1.0/24 80.80.1.1 - - - 200 i
* > 103.103.1.0/24 80.80.1.1 - - - 200 i
* > 202.202.1.0/24 80.80.1.1 - - - 200 i
switch#
The AS-Path of matching prefixes are replaced with an empty or a null AS-Path. AS 302 is removed from prefix 103.103.1.0/24 as shown in the above output.This command replaces the AS-Path with the auto option.
switch(config)# route-map foo permit 10
switch(config-route-map-foo)# set as-path match all replacement auto
switch(config-route-map-foo)# end
switch# show ip bgp neighbors 80.80.1.2 advertised-routes
BGP routing table information for VRF default
Router identifier 202.202.1.1, local AS number 200
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E
- ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast, q - Queued
for advertisement
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop -
Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 101.101.1.0/24 80.80.1.1 - - - 200 200 i
* > 102.102.1.0/24 80.80.1.1 - - - 200 200 i
* > 103.103.1.0/24 80.80.1.1 - - - 200 200 i
* > 202.202.1.0/24 80.80.1.1 - - - 200 200 i
switch#
The AS-path of matching prefixes are replaced with the locally configured AS 200.
Modifying the Local AS Value
The switch can replace its local AS number with a configured value when sending OPEN messages to a specified neighbor, allowing the switch to appear as a member of a different AS to that peer. In the case of a static peer, the neighbor must also be configured to recognize the modified AS in order for peering to occur. The additional configuration is unnecessary in the case of dynamic peers.
To configure a different local AS value for the switch, use the neighbor local-as command. To configure the peer to expect the altered ASN from the switch, use the neighbor remote-as command on the peer.
Example
These commands configure the switch to replace its local ASN in OPEN messages sent to the peer at 10.13.64.1 with ASN 64500, and configure the peer to expect that ASN in messages received from the switch.
By default, BGP rejects routes that contain the local Autonomous System Number (ASN). Sometimes a single autonomous system is divided geographically or otherwise with one or more provider ASs in between. In these cases, a valid route can sometimes be dropped by a customer edge router because the local ASN appears in the AS-path of route advertisements that have traveled through one or more provider networks. To ensure that these routes are not dropped, the provider edge router can be configured to replace the customer AS with its own, or the customer edge router can be configured to ignore its local AS number in received routes.
Replacing Remote ASN in Outbound Route Announcements
To replace a remote ASN with the local ASN in BGP route announcements sent to a specified router, use the neighbor as-path remote-as replace out command.
Example
These commands configure the switch to substitute its local ASN for the ASN of the BGP neighbor at 192.168.2.15 in BGP routes advertised to that neighbor.
Ignoring Local ASN in Incoming Route Announcements
To accept BGP routes that include the local ASN in their AS-path attribute, use the neighbor allowas-in command.
Example
These commands configure the switch to accept routes from the BGP neighbor at 192.168.1.30 which contain the switch’s ASN in their AS paths as many as 3 times.
The switch determines the network prefixes that peering sessions advertise and the BGP neighbor addresses that receive advertisements through address family activity configuration.
An address family is a data structure that defines route advertising status to BGP neighbor addresses. Each BGP neighbor address is assigned an activity level for each address family on the switch. The switch sends capability and network prefix advertisements to neighbor addresses that are active within specified address families:
IPv4 address family: switch advertises IPv4 capability and network commands with IPv4 prefixes to neighbor addresses configured as IPv4 address family active.
IPv6 address family: switch advertises IPv6 capability and network commands with IPv6 prefixes to neighbor addresses configured as IPv6 address family active.
Neighbor Address Family Configuration
Address family activity levels for neighbor addresses are configured through bgp default and neighbor activate commands.
The bgp default command specifies the default activity level of BGP neighbor addresses for a specified address family.
The neighbor activate command specifies deviations from default address family activity level for a specified BGP neighbor address.
Default Neighbor Activation
The bgp default command configures the default address family activity level of all configured BGP neighbor addresses. The switch advertises the following to address family active addresses:
IPv4 address family active: IPv4 capability and all network advertisements with IPv4 prefixes.
IPv6 address family active: IPv6 capability and all network advertisements with IPv6 prefixes.
These commands configure default address family activity levels for configured BGP neighbor addresses:
bgp default ipv4-unicast: all BGP neighbor addresses are IPv4 address family active (this is the switch default).
no bgp default ipv4-unicast: no BGP neighbor addresses are IPv4 address family active.
bgp default ipv6-unicast: all BGP neighbor addresses are IPv6 address family active.
no bgp default ipv6-unicast: no BGP neighbor addresses are IPv6 address family active (this is the switch default).
bgp default ipv4-unicast transport ipv6: all BGP neighbor addresses are IPv4 address family active and IPv6 neighbors can receive IPv4 NLRIs.
Note: If it is necessary to exchange IPv4 NLRIs over an IPv6 connection, the IPv4 address family must be activated on the IPv6 neighbor. To do this for all IPv6 neighbors, use the command bgp default. For an individual neighbor, use the neighbor activate command for the IPv6 neighbor in the IPv4 address-family configuration mode as described below.
Activating Individual Neighbor Addresses
The address-family command places the switch in address family mode to configure the address family activity level of individual BGP neighbor addresses. The switch supports these address families:
ipv4-unicast
ipv6-unicast
The running-config displays address family commands in sub-blocks of the BGP configuration. The neighbor activate command is available in each address family configuration mode and defines the configuration mode address family activity level of a specified configured BGP neighbor address. Addresses are assigned one of the following states by the activate command:
neighbor activate configures the address as active in the configuration mode address family.
no neighbor activate configures the address as not active in the configuration mode address family.
The switch sends the following announcements to addresses that are active in an address family:
IPv4 address family: IPv4 capability and all network routes with IPv4 prefixes.
IPv6 address family: IPv6 capability and all network routes with IPv6 prefixes.
The neighbor route-map (BGP) command applies a route map to inbound or outbound BGP routes. In address-family mode, the route map is applied to routes corresponding to the configuration-mode address family. When a route map is applied to outbound routes, the switch advertises only routes matching at least one section of the route map. One outbound and one inbound route map can be applied to a neighbor for each address family. Applying a route map to a route replaces the previous corresponding route map assignment.
Network Route Advertising in Address Families
The network (BGP) command specifies a network for advertisement through UPDATE packets to BGP peers. The command is available in Router-BGP and Router-BGP-Address-Family configuration modes; the mode in which the command is issued does not affect the command’s execution.
Commands with an IPv4 address are advertised to peers that are IPv4 address family-active.
Commands with an IPv6 address are advertised to peers that are IPv6 address family-active.
Examples
These commands instantiate BGP, configure three neighbors, and configure two network routes.
The default activity level for IPv4 and IPv6 address families is set to the default; all neighbor addresses are IPv4 address family active and IPv6 address family not active. IPv4 capability and network routes with IPv4 prefixes are advertised to all neighbor IPv4 addresses.
These commands instantiate BGP on the switch, set IPv4 default activity level (not active), set IPv6 default activity level (active), and configure three neighbor addresses and two network route prefixes.
IPv6 capability and network routes with IPv6 prefixes are advertised to all neighbor addresses.
These commands configure three neighbors, two network routes, and the default activity level for each address family (not active), and specify neighbor addresses for each address family that is active.
The best-path selection algorithm (described under Best-Path Selection) determines which of multiple paths to the same destination received by BGP will be added to the IP routing table. To shape route preferences and influence best-path selection, use the following commands in router-BGP configuration mode.
bgp always-compare-med configures the switch to always consider the Multi-Exit Discriminator (MED) value when comparing paths (disabled by default).
bgp bestpath as-path ignore configures the switch to ignore the length of the Autonomous System (AS) path when comparing routes (disabled by default).
bgp bestpath as-path multipath-relax used in Equal-Post Multi Path (ECMP configuration) and enabled by default; the no form of the command configures the switch to consider paths unequal if their AS paths have different contents.
bgp bestpath ecmp-fast the no form of this command causes the switch to ignore order of arrival in evaluating paths within an ECMP group.
bgp bestpath med confed causes comparison of Multi-Exit Discriminator (MED) values in routes originating within the same confederation as the switch and received from confederation peers (disabled by default).
bgp bestpath tie-break cluster-list-length configures the switch to prefer the multipath route with the shortest CLUSTER_LIST length in case of a tie in step 10 of the selection process (disabled by default).
bgp bestpath tie-break router-id configures the switch to prefer the multipath route with the lowest ROUTER_ID in case of a tie in step 10 (disabled by default).
Displaying Reasons for Best-path Selection
To see the reasons why certain routes were excluded by the best-path selection process, use the detail option of the show ip bgp command. Enter the prefix to which BGP has selected a best path, and the output will display all learned paths. Paths which were not selected as best will display the reason they were not selected after the label not best.
The reason will be listed as one of the following:
path weight
local preference
AS path length
origin
path MED
eBGP path preferred
IGP cost
AS path details
ECMP-Fast configured
router ID
originator ID
router ID tie-break configured
cluster list length
cluster list length tie-break configured
peer IP address
path ID
redistributed route exists
unknown
another route from the same AS is a better BGP route
peer not ready
unusable
Example
This command displays the reasons why three routes to 172.16.0.0/24 were rejected by the best-path algorithm. The reason for rejection is preceded by the label Not best:
switch# show ip bgp 172.16.0.0/24 detail
BGP routing table information for VRF default
Router identifier 192.168.100.18, local AS number 64524
Route status: [a.b.c.d] - Route is queued for advertisement to peer.
BGP routing table entry for 204.1.47.220/30
Paths: 4 available
64512 64550 65100
192.168.14.2 from 192.168.14.2 (192.168.100.21)
Origin IGP, metric 0, localpref 100, weight 0, received 19:15:29 ago, valid,
external, ECMP head, ECMP, best, ECMP contributor
Rx SAFI: Unicast
64512 64550 65100
192.168.24.2 from 192.168.24.2 (192.168.100.22)
Origin IGP, metric 0, localpref 100, weight 0, received 19:15:29 ago, valid,
external, ECMP, ECMP contributor
Rx SAFI: Unicast
Not best: ECMP-Fast configured
64512 64550 65100
192.168.34.2 from 192.168.34.2 (192.168.100.23)
Origin IGP, metric 0, localpref 100, weight 0, received 19:15:29 ago, valid,
external, ECMP, ECMP contributor
Rx SAFI: Unicast
Not best: Redistributed route exists
64512 64550 65100
192.168.44.2 from 192.168.44.2 (192.168.100.24)
Origin IGP, metric 0, localpref 100, weight 0, received 19:15:29 ago, valid,
external, ECMP, ECMP contributor
Rx SAFI: Unicast
Not best: eBGP path preferred
Not advertised to any peer
switch#
Configuring BGP Convergence
To avoid hardware updates and route advertisement churn during switch reload or BGP instance start, BGP enters into the convergence state where it waits for all peers to join and receive all routes from all the peers.
BGP Convergence is bound by an upper value of convergence time (default value is 5 minutes) and BGP declares convergence on expiry of convergence timer. At the end of convergence, BGP updates the routes in FIB and advertises to all the peers.
To configure BGP convergence and the different timeout features, use the following commands in router-BGP configuration mode.
bgp convergence slow-peer time configures the BGP convergence idle peer timeout value. The default timeout value is 90 seconds.
bgp convergence time configures the BGP convergence timeout value. The default timeout value is 300 seconds.
Different Cases for Convergence with Default Timeout Configuration
Convergence Time < 90 seconds after the first peer has joined: this is the best case when all the configured peers have joined and EORs have been received from all peers in less than 90 seconds after the first peer has joined.
Convergence Time = 90 seconds after the first peer has joined: this is the case when one or more BGP peers have joined within 90 seconds and EORs have been received from all peers within 90 seconds, but there are still some configured peers which have not joined yet. In this case, the convergence is declared after slow-peer timeout is reached.
Convergence Time > 90 seconds after the first peer has joined: this is the case when one or more BGP peers have joined after 90 seconds, but EORs have not been received from all peers. As soon as EORs are received from all peers which have joined during the first 90 seconds, the convergence is declared.
Convergence Time = 300 seconds after the first peer has joined: this is the case when EOR is not received till 300 seconds from some of the peers that have joined during 90 seconds after the first peer has joined.
Displaying BGP Convergence Status
Use the show bgp convergence command to view information about the BGP convergence status, and to know if the convergence timer has started or not. The examples below show the command output at different points in the convergence process.
No Peers Have Joined
This is the output when no peers have joined before convergence.
switch(config-router-bgp)# show bgp convergence
BGP Convergence information for VRF: default
Configured convergence timeout: 00:02:30
Configured convergence slow peer timeout: 00:00:55
Convergence based update synchronization is enabled
Last Bgp convergence event : None
Bgp convergence state : Not Initiated (Waiting for the first peer to join)
Convergence timer is not running
Convergence timeout in use: 00:02:30
Convergence slow peer timeout in use: 00:00:55
First peer is not up yet
All the expected peers are up: no
All IGP protocols have converged: yes
Outstanding EORs: 0, Outstanding Keepalives: 0
Pending Peers: 2
Total Peers: 2
Established Peers: 0
Disabled Peers: 0
Peers that have not converged yet:
IPv4 peers:
201.1.1.1 (Session : Connect)
202.1.1.1 (Session : Connect)
IPv6 peers:
None
switch(config-router-bgp)#
First Peer Has Joined
This is the output when the first peer has joined before convergence.
switch# show bgp convergence
BGP Convergence information for VRF: default
Configured convergence timeout: 00:02:30
Configured convergence slow peer timeout: 00:00:55
Convergence based update synchronization is enabled
Last Bgp convergence event 00:00:40 ago
Bgp convergence state : Pending (Waiting for EORs/Keepalives from peer(s) and IGP
convergence)
Convergence timer running, will expire in 00:01:50
Convergence timeout in use: 00:02:30
Convergence slow peer timeout in use: 00:00:55
First peer came up 00:00:13 ago
All the expected peers are up: no
All IGP protocols have converged: yes
Outstanding EORs: 0, Outstanding Keepalives: 0
Pending Peers: 1
Total Peers: 2
Established Peers: 1
Disabled Peers: 0
Peers that have not converged yet:
IPv4 peers:
201.1.1.1 (Session : Active)
IPv6 peers:
None
switch#
Convergence Timeout Reached
This is the output when the convergence timeout value is reached.
switch(config-router-bgp)# show bgp convergence
BGP Convergence information for VRF: default
Configured convergence timeout: 00:02:30
Configured convergence slow peer timeout: 00:00:55
Convergence based update synchronization is enabled
Last Bgp convergence event 00:02:44 ago
Bgp convergence state : Timeout reached
Time taken to converge 00:02:30
Pending Peers: 1
Total Peers: 2
Established Peers: 1
Disabled Peers: 0
Peers that did not converge before local bgp convergence:
IPv4 peers:
201.1.1.1 (Session : Active)
202.1.1.1 (Session : Established)
IPv6 peers:
None
switch(config-router-bgp)#
Converged State
This is the output during the converged state.
switch(config-router-bgp)# show bgp convergence
BGP Convergence information for VRF: default
Configured convergence timeout: 00:05:00
Configured convergence slow peer timeout: 00:01:30
Convergence based update synchronization is enabled
Last Bgp convergence event 00:00:05 ago
Bgp convergence state : Converged
Time taken to converge 00:00:02
First peer came up 00:00:05 ago
Pending Peers: 0
Total Peers: 3
Established Peers: 3
Disabled Peers: 0
Peers that did not converge before local bgp convergence:
IPv4 peers:
None
IPv6 peers:
None
switch(config-router-bgp)#
Configuring BGP Graceful Shutdown Community
Creating a Route-Map Entry That Sets the Community for Graceful Shutdown
The bgp route install-map command is used in the BGP configuration mode to enable BGP Selective Route Download. BGP Selective Route Download can also be configured in an address family or VRF instance as shown in the following examples.
The following examples show how to configure a prefix list and route map, then apply BGP Selective Route Download to the map.
Examples
These commands install BGP routes in the 10.0.0.0/24 and 20.0.0.0/24 ranges in the RIB (and thus in the hardware), but no other BGP routes.
switch(config)# ip prefix-list PFXL_ALLOW
switch(config-ip-pfx)# seq 1 permit 10.0.0.0/24 ge 24 le 32
switch(config-ip-pfx)# seq 2 permit 20.0.0.0/24 ge 24 le 32
switch(config-ip-pfx)# exit
switch(config-ip-pfx)#
These commands configure the permit and deny rules for BGP routes.
switch(config)# route-map BGP_INSTALL_MAP permit 10
switch(config-route-map-BGP_INSTALL_MAP)# match ip address prefix-list PFXL_ALLOW
switch(config-route-map-BGP_INSTALL_MAP)# exit
switch(config)# route-map BGP_INSTALL_MAP deny 20
switch(config)#
These commands configure Selective Route Download for the map BGP_INSTALL_MAP.
The following examples show how to configure prefix lists individually for the IPv4 and IPv6 address families, then apply BGP Selective Route Download for these address families.
Examples
These commands configure the IPv4 address family prefix list.
switch(config)# ip prefix-list V4_ALLOW
switch(config-ip-pfx)# route-map BGP_V4_MAP permit 10
switch(config-route-map-BGP_V4_MAP)# match ip address prefix-list V4_ALLOW
switch(config-route-map-BGP_V4_MAP)# route-map BGP_V4_MAP deny 20
switch(config-route-map-BGP_V4_MAP)# exit
switch(config-route-map-BGP_V4_MAP)#
These commands configure the IPv6 address family prefix list.
Displaying BGP Selective Route Download Information
The show ip bgp command displays BGP RIB winning paths that are not installed in the RIB.
Example
The following command displays BGP routing table information for VRF default, showing winning paths that are not installed in the RIB.
switch# show ip bgp
BGP routing table information for VRF default
Router identifier 1.0.0.2, local AS number 100
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E
- ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop -
Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 6.0.0.0/24 1.0.0.1 0 100 0 ?
* # 7.0.0.0/24 1.0.0.1 0 100 0 ?
switch#
The show ip bgp command with a specified prefix displays detailed information and the reason for the BGP RIB winning paths to that prefix not being installed in the RIB.
Example
The following command displays detailed information for the BGP routing table for VRF default.
switch# show ip bgp 7.0.0.0/24
BGP routing table information for VRF default
Router identifier 1.0.0.2, local AS number 100
BGP routing table entry for 7.0.0.0/24
Paths: 1 available
Local
1.0.0.1 from 1.0.0.1 (1.0.0.1)
Origin INCOMPLETE, metric 0, localpref 100, weight 0, valid, internal, not
installed (denied by install-map)
switch#
The show ip bgp installed command displays the list of installed routes in the BGP RIB.
Example
The following command displays the list of installed routes in BGP routing table for VRF defaults.
switch# show ip bgp installed
BGP routing table information for VRF default
Router identifier 1.0.0.2, local AS number 100
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E
- ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop -
Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 6.0.0.0/24 1.0.0.1 0 100 0 ?
switch#
The following command displays the list of non-installed routes in the BGP routing table for VRF default.
switch# show ip bgp not-installed
BGP routing table information for VRF default
Router identifier 1.0.0.2, local AS number 100
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E
- ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop -
Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* # 7.0.0.0/24 1.0.0.1 0 100 0 ?
switch#
Configuring Nexthop Resolution
The configuration model for this feature involves configuring and applying Nexthop Resolution RIB Profiles on a per-address family basis. There are two ways a profile can be applied: (1) across an entire address-family, or (2) a granular, route-map based mechanism for specific routes within an address family. The per-address-family configuration is the simplest. It enables specification of a unique profile for all the routes in a given address family, such as IPV4 unicast, or EVPN. In contrast, the route-map approach leverages the matching criteria of route-map statements to apply profiles to individual routes within an address family.
Note: Note the support for each configuration and submode were released in a phased manner.
The general configuration model for the CLI is a new command under the BGP address-family submode:
The PROFILE option is a list of up to three (3) resolution domains. The NAME option is the name of a route-map. Notice the PROFILE and route-map NAME options are mutually exclusive. That is, a resolution profile can be specified either explicitly at the address family level, or on a per-route basis via a route-map.
To enable setting a profile using a route-map, this feature adds support for a new set statement in the route-map submode:
switch(config-route-map-NAME)# set next-hop resolution ribs PROFILE
You ban combine this statement with existing match statements to select profiles based on the BGP path attributes of a route, or other properties.
As mentioned, the profile itself is a list of resolution domains:
PROFILE:=DOMAIN[DOMAIN[DOMAIN]]
Example configuration for EVPN MPLS, EVPN VXLAN and BGP Labeled-unicast:
The PRIMARY-RIB and FALLBACK-RIB refers to either tunnel domain or IP RIB domain. EVPN VXLAN only supports IP-RIB domain.
Configure the tunnel domain as:
tunnel-rib <tunnel-rib-name> where the <tunnel-rib-name> refers to either the system-tunnel-rib or the user defined tunnel rib.
The IP domain can be either:
system-unicast-rib
system-connected
The system-unicast-rib refers to complete IP RIB and the system-connected refers to just the connected routes.
Primary and secondary RIBs cannot come from the same domain (for example, both cannot be from the tunnel domain and both cannot be from the IP RIB domain). The FALLBACK-RIB is optional.
Nexthops will first attempt to resolve, using the primary rib. If the resolution fails, it attempts to resolve using the fallback rib (if that exists).
All the nexthops of the IPV4 labeled-unicast routes will first attempt to resolve, using the tunnel ribUSER_TR. If the resolution fails, the nexhops attempt to resolve using the complete unicastIP RIB.
Each DOMAIN can be either a system or user-defined tunnel RIB or a unicast RIB. The available resolution domains, and their corresponding tokens, are tabulated below:
Table 3.Domains
Domain
Token
Description
IP RIB
system-unicast-rib
The complete IP unicast RIB is available for next-hop resolution.
Connected routes (IP)
system-connected
Only connected routes are available for next-hop resolution.
System tunnel RIB
tunnel-rib system-tunnel-rib
All winning tunnels from all protocols are available for next-hop resolution.
System colored tunnel RIB
tunnel-rib colored system-colored-tunnel-rib
All winning, colored tunnels from all protocols are available for next-hop resolution. Only routes with an associated color can be resolved by the system colored tunnel RIB.
User-defined tunnel RIB
tunnel-rib NAME
All contributing tunnels to the tunnel RIB called NAME are available for next-hop resolution.
IP RIB of VPN Import VRF
vrf-unicast-rib
This token is limited to BGP L3VPNs.
Now the profile configuration is available under select BGP address family submodes. For example:
Note that a given address-family may restrict the possible profiles which can be configured, and may not support specifying a route-map. For example, the resolution profile for 6PE routes, configured via next-hop 6pe resolution ribs PROFILE, is constrained to only the tunnel domain. That is, the profile cannot specify either system-unicast-rib or system-connected. This is, of course, because it is meaningless to resolve a 6PE next-hop using either of those resolution domains.
Configuring BGP Attributes Ignore Received Lists
Configure BGP Attributes Ignore Received Lists using the router bgp command to enter the Router-BGP Configuration Mode. When adding the BGP attributes to the ignore list, EOS displays a warning message that in order to discard the BGP attributes from the existing BGP sessions, BGP must relearn the routes. Discard BGP attributes on an outbound route after applying inbound and outbound policies.
Adding BGP Attribute Ignore Received Lists
To add the feature to the default BGP configuration, use the following commands:
switch(config)#router bgp
switch(config-router-bgp)#neighbor default received attribute discard bgp_attributes
! To make this command effective for existing BGP sessions, clear all routes by issuing "clear ip bgp"
Adding BGP Attributes Ignore Received Lists to BGP Neighbors or Peers
To add the feature to a neighbor or peer group, use the following commands:
switch(config)#router bgp
switch(config-router-bgp)#neighbor ip_addresspeer_group received attribute discard bgp_attributes
! To make this command effective for existing BGP sessions, clear all routes by issuing "clear ip bgp"
Adding BGP Attributes Ignore Received Lists to a VRF
Configure BGP Attributes Ignore Received Lists on a VRF with the VRF configuration taking precedence over the global configuration.
For the global configuration, use the following commands:
switch(config)#router bgp
switch(config-router-bgp)#neighbor default received attribute discard 4-255
Use the following commands to configure a BGP Attribute Ignore Received List on VRF1 to ignore attributes 50 and 255 :
switch(config)#router bgp
switch(config-router-bgp)#vrf VRF1
switch(config-router-bgp-vrf-VRF1)#neighbor default received attribute discard 50,255
! To make this command effective for existing BGP sessions, clear all routes by issuing "clear ip bgp"
VRF1 discards only BGP attributes 50 and 255 and overrides the default configuration.
Use the following command to display the configuration:
router(config-router-bgp)#show active
router bgp 1
router-id 0.0.0.1
neighbor default received attribute discard 4-255
vrf vrf1
router-id 0.0.0.2
neighbor default received attribute discard 50,255
The output displays the default configuration discarding BGP attributes 4 through 255 and VRF1 discards only BGP attributes 50 and 255.
Disabling BGP Attributes Ignore Received Lists on a VRF
Configure BGP Attributes Ignore Received on a VRF by VRF basis using the following commands to enable the feature by default and then disabling it on a specific VRF, VRF1.
router(config-router-bgp)#neighbor default received attribute discard 4-255
! To make this command effective for existing BGP sessions, clear all the routes by issuing "clear ip bgp *"
router(config-router-bgp-vrf-vrf1)#neighbor default received attribute discard disabled
! To make this command effective for existing BGP sessions, clear all the routes by issuing "clear ip bgp *"
Use the following command to display the configuration:
router(config-router-bgp)#show active
router bgp 1
router-id 0.0.0.1
neighbor default received attribute discard 4-255
vrf vrf1
router-id 0.0.0.2
neighbor default received attribute discard disabled
The output displays the default configuration discarding BGP attributes 4 through 255, while VRF1 does not discard any BGP attributes.
Release Matrices
The following tables detail the release in which the possible configurations for this feature are available.
Table 4.Release Matrices Values
Configuration
Release
next-hop resolution ribs PROFILE command
4.22.0F
4.22.1F
4.23.1F
4.24.1F
4.25.1F
Unsupported / Not Applicable
IPv4/IPv6 unicast (non 6PE)
X
IPv6 unicast 6PE
X
IPv4/IPv6 VPN (vrf-unicast-rib)
X
IPv4/IPv6 VPN (full profile)
X
EVPN (MPLS)
X
EVPN (VXLAN)
X
IPv4/IPv6 LU
X
IPv4/IPv6 Multicast
X
IPv4/IPv6 SR TE
X
Flowspec
X
Path Selection
X
Link State
X
RT Membership
X
PROFILE configuration
Up to 2 resolution domains
X
Up to 3 resolution domains
X
system-colored-tunnel-rib
X
next-hop resolution ribs route-map NAME command
IPv4/IPv6 unicast (non 6PE)
X
IPv6 unicast 6PE
X
IPv4/IPv6 VPN
X
EVPN (MPLS)
X
EVPN (VXLAN)
X
IPv4/IPv6 LU
X
IPv4/IPv6 Multicast
X
IPv4/IPv6 SR TE
X
Flowspec
X
Path Selection
X
Link State
X
RT Membership
X
Route-map submode
match ip[v6] next-hop
X
match ip[v6] address prefix-list
X
match community
X
match extcommunity
X
match large-community
X
All other match statements
X
All other set statements
X
sub-route-map
X
Default Resolution Profiles
Given the configuration model, the default resolution profiles in EOS for each address-family can be expressed by the following:
This is not supported. Multicast next-hops are first resolved in the MRIB. Failure to resolve in the MRIB results in a lookup in the unicast RIB.
Flowspec
These next hops are not resolved.
Note: Support for the system-colored-tunnel-rib was released in EOS Release 4.24.1F. For earlier releases, the defaults can be determined by omitting this resolution domain.
Semantics
When processing the next-hop of a route, the next-hop resolver attempts resolution by using the first domain in the route’s resolution profile. If the resolution domain successfully resolves the next-hop, the resolver stops. If resolution fails, however, the resolver moves onto the next domain, if it exists, and tries again. This iterative process continues until the next-hop is either resolved, or the profile is exhausted. In the latter case, the next-hop is left unresolved.
To illustrate this, consider the following example. This resolution profile constrains the resolution of a BGP route to only the IP unicast RIB:
When a next-hop is unresolvable in the IP unicast RIB, and there are no further resolution domains to try, then the next-hop is ultimately unresolved. In contrast, the following profile first attempts resolution in the system colored tunnel RIB, then the system tunnel RIB, and finally attempts resolution using connected routes:
Therefore, only when a next-hop cannot be resolved by any of those domains will it be ultimately unresolved.
Route Map Semantics
This section describes semantics and limitations specific to the next-hop resolution ribs route-map NAME command.
The use of a route-map to select a custom resolution profile allows for per-route granularity rather than an entire BGP address-family. The next-hop resolution semantics of a next-hop whose profile is set using a route-map are the same as the per-address family configuration. However, unlike in the per-address family configuration model, a route-map makes it possible to leave the resolution profile for a next-hop unspecified. A next-hop for which the resolution profile is unspecified is left unresolved. The following example illustrates this as well as the recommended configuration.
The profile below constrains the resolution of a subset of IPV4 unicast routes to only the system tunnel RIB:
switch(config)# ip prefix-list SUBSET 192.0.2.1/32 192.0.2.2/32 192.0.2.3/32
switch(config)# route-map TUNNEL_ONLY permit 10
switch(config-route-map-TUNNEL_ONLY)# match ip next-hop prefix-list SUBSET
switch(config-route-map-TUNNEL_ONLY)# set next-hop resolution ribs tunnel-rib system-tunnel-rib
switch(config-route-map-TUNNEL_ONLY)#
switch(config)# router bgp 64512
switch(config-router-bgp)# address-family ipv4
switch(config-router-bgp-af)# next-hop resolution ribs route-map TUNNEL_ONLY
Note, however, that the TUNNEL_ONLY route-map applies to all IPV4 unicast routes. Further, note that only routes whose next-hop value matches SUBSET will have a resolution profile set. All other IPV4 unicast routes will have no resolution profile. Any route without a resolution profile is left unresolved. This is often not intentional.
A more common use case is to allow the route’s which do not match a given sequence to fallback to the system default resolution behavior. This can be achieved by adding a second sequence to the route-map with no match statements (matches all routes), and a single set statement which sets the default profile (see the Default Resolution Profiles section) for the given address family.
This feature provides an explicit token to automatically fallback to the default resolution profile of whichever address family the route-map is applied:
switch(config)# ip prefix-list SUBSET 192.0.2.1/32 192.0.2.2/32 192.0.2.3/32
switch(config)# route-map TUNNEL_ONLY permit 10
switch(config-route-map-TUNNEL_ONLY)# match ip next-hop prefix-list SUBSET
switch(config-route-map-TUNNEL_ONLY)# set next-hop resolution ribs tunnel-rib system-tunnel-rib
switch(config-route-map-TUNNEL_ONLY)# route-map TUNNEL_ONLY permit 20
switch(config-route-map-TUNNEL_ONLY)# set next-hop resolution ribs system-default
switch(config)# router bgp 64512
switch(config-router-bgp)# address-family ipv4
switch(config-router-bgp-af)# next-hop resolution ribs route-map TUNNEL_ONLY
This subfeature affects both the profile used to resolve BGP VPN routes as well as the VRF in which the route resolution takes place. With this feature disabled, or prior to EOS Release 4.22.0F, imported VPN routes and is subject to the following restriction:
For each VPN route received from a neighbor, the route is imported (based on route-targets) and installed into the target VRF (import-vrf), only if the nexthop of the route is resolvable via an MPLS tunnel in the default VRF.
With this feature enabled, the above restriction is lifted, enabling a VPN route to be imported into the target VRF unconditionally. The plain IP unicast route is subsequently resolved using the unicast RIB of the target VRF.
Note: With this feature enabled, no attempt is made to resolve the VPN route over an MPLS tunnel (even if one exists) in the default VRF. Therefore, the VPN routes received from a neighbor remains inactive in the default VRF.
To enable this feature, use the domain token vrf-unicast-rib under the IPV4 / IPV6 address family submodes:
The following IPV4 VPN route has been received from a neighbor:
switch(config)# show bgp vpn-ipv4
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 300
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
RD: 11.0.1.1:0 IPv4 prefix 50.1.1.0/24
42.42.42.42 - 1 0 100 200 i
The route is inactive in the default VRF.
Also, there is a VRF, CUST-1, where the VPN route (based on the route-targets) is imported. In the CUST-1 VRF, the nexthop of the route is resolved via a static route to 42.42.42.42. With this feature enabled, the VPN route is imported and installed in the VRF CUST-1:
switch(config)# show ip bgp vrf CUST-1
BGP routing table information for VRF CUST-1
Router identifier 11.0.0.1, local AS number 300
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 50.1.1.0/24 42.42.42.42 - 1 0 100 200 i
To confirm the route is installed in the VRF CUST-1, use the show ip route command:
switch(config)# show ip route vrf CUST-1
VRF: CUST-1
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service,
DH - DHCP client installed default route, M - Martian,
DP - Dynamic Policy Route
S 42.42.42.42/32 is directly connected, Null0B I 50.1.1.0/24 is directly connected, Null0
The resolution profile used to resolve the next-hop can be seen using the show rib next-hop command. Note how the profile includes (only) the system-unicast-rib for CUST-1.
switch(config)# show rib next-hop ip vrf CUST-1 bgp detail
VRF: CUST-1, Protocol: bgp
Codes: * - Unresolved Next hop
L - Part of a recursive route resolution loop
A - Next hop not resolved in ARP/ND
11.0.1.1 [1 pref/0 metric] [ID: 18] type ipv4
Resolution RIBs: system-unicast-rib
via Null0, directly connected [ID 3]
Viewing the BGP Nexthop Resolution Status
The following existing show commands which have been enhanced for this feature:
show route-mspNAME
show bgp instance [vrfNAME]
show rib next-hop {ip | ipv6}[PROTCOL] detail
show route-map NAME
Use the show route-map NAME command to display the new set statement:
Use the show bgp instance command to inspect the configured profiles and route-maps for each address family. The diplay output has been extended to show the resolution ribs as seen below, done so in order to display the resolution ribs used for EVPN and BGP Labeled-unicast address families. The output displays the resolution rib profile configuration for the respective address families.
Example
switch(config-router-bgp)# show bgp instance
BGP instance information for VRF default
...
Address family IPv4 MplsLabel:
Additional-paths installation is disabled
Convergence based update synchronization is disabled
Target RIBs: Tunnel RIB
Resolution RIBs: tunnel-rib system-tunnel-rib, system-connected
...
Address family IPv6 MplsLabel:
Additional-paths installation is disabled
Convergence based update synchronization is disabled
Target RIBs: Tunnel RIB
Resolution RIBs: tunnel-rib system-tunnel-rib, system-connected
...
Address family L2VPN EVPN:
Additional-paths installation is disabled
Convergence based update synchronization is disabled
VXLAN Resolution RIBs: system-unicast-rib
Mpls Resolution RIBs: tunnel-rib system-tunnel-rib, system-connected
Use the show rib next-hop ip bgp command to display the per-via resolution profile.
show rib-next-hop {ip,ipv6} [proto] detail
Use the show rib next-hop {ip | ipv6}[proto] detail command to display which resolution profile is used to resolve each next-hop.
Example
switch#(config-router-bgp)# show rib next-hop ip bgp detail
VRF: default, Protocol: bgp
Codes: * - Unresolved Next hop
L - Part of a recursive route resolution loop
A - Next hop not resolved in ARP/ND
192.0.2.1 [110 pref/20 metric] [ID: 1] type ipv4
Resolution RIBs: tunnel-rib colored system-colored-tunnel-rib, tunnel-rib system-tunnel-rib, system-unicast-rib
via 198.51.100.1, Ethernet3 [ID: 10]
192.0.2.2 * [ID: 86]
Resolution RIBs: No profile set for this next-hop
192.0.2.3 * [ID: 78]
Resolution RIBs: tunnel-rib colored system-colored-tunnel-rib, tunnel-rib system-tunnel-rib, system-connected
Note how 192.0.2.2 has no profile set, and is therefore unresolved. This show command illustrates this clearly with the No profile set for this next-hop message.
User-defined Tunnel RIBs for NextHop Resolution
Currently, EOS generates a single system-defined tunnel RIB for the next-hop resolution.
When tunnels to the same destination address are learned from multiple protocols, a fixed preference that is associated with each protocol is used to determine the winning tunnel.
However, with the User-defined tunnel RIBs feature the user is allowed to create user-defined tunnel RIBs with:
Control over which protocols may contribute to the tunnel RIB.
The ability to override the preference for all tunnels from a protocol to achieve non-default ordering of tunnels.
The option to use it in a context where the system-defined tunnel RIB does not suffice.
Configuring User-defined Tunnel RIBs
A new tunnel-ribs configuration mode allows the creation of user-defined tunnel RIBs. For example, the following configuration creates a tunnel RIB with tunnels learned from IS-IS SR and LDP only, with IS-IS SR tunnels being preferred over LDP:
When adding a source protocol in a user-defined tunnel RIB, the preference is optional. A lower preference value indicates a more preferred protocol. If the preference is not specified, the following system-defined preference values are used:
Table 6.System Defined Preference Values
Source Protocol
System-defined Preference
Static
15
Nexthop group tunnel
25
RSVP LER
45
LDP
55
IS-IS SR
65
BGP-LU
85
Modifying the system-tunnel-rib
The user can explicitly modify the default preferences for the system-tunnel-rib as well as user-defined RIBs:
switch(config)# tunnel-ribs
switch(config-tunnel-ribs)# tunnel-rib system-tunnel-rib
switch(config-tunnel-rib-system-tunnel-rib)#?
source-protocol Configure the tunnel source
----------------------------------------
comment Up to 240 characters, comment for this mode
default Set a command to its defaults
exit Leave Configure mode
no Disable the command that follows
show Display details of switch operation
!! Append to comment
switch(config-tunnel-rib-system-tunnel-rib)# source-protocol ?
bgp BGP tunnel
isis IS-IS tunnel
ldp LDP tunnel
nexthop-group Nexthop group tunnel
rsvp-ler RSVP LER tunnel
static Static tunnel
switch(config-tunnel-rib-system-tunnel-rib)# source-protocol rsvp-ler preference 2
switch(config-tunnel-rib-system-tunnel-rib)# exit
switch(config-tunnel-ribs)# show active all
tunnel-ribs
tunnel-rib system-tunnel-rib
source-protocol static
source-protocol isis segment-routing
source-protocol bgp labeled-unicast
source-protocol nexthop-group
source-protocol rsvp-ler preference 2
source-protocol ldp
Displaying Tunnel RIB Information
Use the show tunnel rib to display the user defined RIB information:
Use the show active all command to display the information about which source protocols contribute to the system-defined tunnel RIB.
switch(config)# tunnel-ribs
switch(config-tunnel-ribs)# tunnel-rib system-tunnel-rib
switch(config-tunnel-ribs)# show active all
tunnel-ribs
tunnel-rib system-tunnel-rib
source-protocol static
source-protocol isis segment-routing
source-protocol bgp labeled-unicast
source-protocol nexthop-group
source-protocol rsvp-ler
source-protocol ldp
BGP Next Hop Resolution with IGP Distance
A core router with competing advertisements for the same prefixes from different Perimeter Edge (PE) routers should select the local Edge Router (ER) as the best path based on the IGP metric of resolving routes with competing advertisements. The switch supports utilizing the IGP distance in the route selection process when a BGP route has two or more levels of recursion.
Configuring BGP Next Hop Resolution with IGP Distance
Use the following commands to configure the BGP network with IGP Distance:
Displaying BGP Next Hop Resolution with IGP Distance Information
Use the following command to display the resolution details of BGP next hops:
switch# show ip bgp detail
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 100
BGP routing table entry for 1.1.1.0/24
Paths: 1 available
Local (Received from a RR-client)
3.3.3.3 from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, IGP metric 20, weight 0, tag 0
Received 00:02:02 ago, valid, internal, best
Rx SAFI: Unicast
BGP routing table entry for 2.2.2.0/24
Paths: 1 available
Local (Received from a RR-client)
4.4.4.4 from 4.4.4.4 (4.4.4.4)
Origin IGP, metric 0, localpref 100, IGP metric 30, weight 0, tag 0
Received 00:02:02 ago, valid, internal, best
Rx SAFI: Unicast
BGP routing table entry for 10.0.0.0/24
Paths: 2 available
200 (Received from a RR-client)
1.1.1.1 from 3.3.3.3 (3.3.3.3)
Origin INCOMPLETE, metric 0, localpref 100, IGP metric 20, weight 0, tag 0
Received 00:02:02 ago, valid, internal, best
Rx SAFI: Unicast
200 (Received from a RR-client)
2.2.2.2 from 4.4.4.4 (4.4.4.4)
Origin INCOMPLETE, metric 0, localpref 100, IGP metric 30, weight 0, tag 0
Received 00:02:02 ago, valid, internal
Rx SAFI: Unicast
Configuring BGP Confederations
BGP confederations allow you to break an Autonomous System (AS) into multiple sub-ASs, and then to group the sub-ASs as a confederation. The sub-ASs exchange iBGP routing information (next-hop, local-preference and MED), but communicate via eBGP.
To configure a BGP confederation, complete the following tasks on each BGP device in the confederation.
Configure the local AS number: the local AS number is the membership number in a sub-AS. BGP devices with the same local AS number are identified as members of the same sub-AS. BGP devices always use the local AS number when communicating with other BGP4 devices in the confederation.
Configure the confederation ID: the confederation ID is the AS number for those BGP devices that are outside of the confederation. A BGP device outside the confederation is not aware that BGP devices are in multiple sub-ASs. The confederation ID must differ from the sub-AS numbers.
Configure the list of sub-AS numbers that are confederation members: devices in a sub-AS exchange information via iBGP, while devices in different sub-ASs use eBGP.
Figure 5.BGP Confederation Example
Examples
The router bgp command enables BGP and configures the router in sub-autonomous system 65050. The bgp confederation identifier command specifies that confederation 65050 belongs to autonomous system 100.
The neighbors from other autonomous systems within the confederation are treated as special eBGP peers when using the bgp confederation peers command.
Currently, both IPv4 and IPv6 must be enabled together on the interface. A user-defined TCAM profile, a feature introduced in EOS Relaease 4.20.5F, must be configured for TCAM support for BGP FlowSpec.
Warning: Creating user-defined TCAM profile on the Arista switch could cause serious issues that impact traffic. Test the BGP FlowSpec policer with the profile in the example. If you need to add new features in the profile, work with Arista's TAC team to define and test the new profile before deploying it on your production switches.
The ACL counters and BGP FlowSpec counters cannot be enabled simultaneously. To enable reporting of counters for BGP FlowSpec rules, use the following configuration:
Example
switch(config)# no hardware counter feature acl in
switch(config)# hardware counter feature flow-spec in
EOS supports BGP FlowSpec counter telemetry, and BGP updates the BGP FlowSpec counters periodically for a configured specific interval. Configure a range from 30 to 300 seconds.
To add BGP FlowSpec telemetry with an interval of 60 seconds, add the following parameter to the BGP configuration:
Configure FlowSpec for IPv4 or IPv6 on a L2 interface. Also, configure the TCAM profile to include the packet type, packet ipv4 forwarding bridged and packet ipv6 forwarding bridged.
Longest Prefix Match (LPM) Redirect to a VRF
Longest Prefix Match (LPM) uses an algorithm to determine the most specific route for a destination IP address. When a packet arrives, EOS checks the forwarding table (FIB) for matching network prefixes and then routes the packet to the destination VRF.
When enabled, the BGP Flowspec rules with VRF redirection programs the TCAM resource used by the VRF Selection Policy (VSP) while other BGP Flowspec rules continue to program into the BGP Flowspec TCAM. Packets traverse both TCAMs and a packet matches even if the matching criteria overlaps the other. For example, the following occurs on the switch when 2 rules have a BGP Flowspec configuration:
Rule 1 with source prefix, 10.0.0.0/24, action vrf redirect, programs into the VSP TCAM.
Rule 2 with source prefix, 10.0.0.0/16, action drop, programs into the flowspec TCAM.
If a packet arrives with source IP 10.0.0.1, the packet matches the rule in the VSP TCAM and performs FIB route lookup on the new VRF. Later in the pipeline, the packet matches the BGP Flowspec TCAM which drops the packet.
Use the following commands to add LPM redirect for IPv4 addresses to the BGP Flowspec configuration:
The BGP show commands have been enhanced to display the flow-spec content for both IPv4 and IPv6 address families:
Example
The show bgp flow-spec ipv4 summary command displays the count of flowspec rules received from each peer:
switch(config)# show bgp flow-spec ipv4 summary
BGP summary information for VRF default
Router identifier 0.0.0.1, local AS number 10
Neighbor Status Codes: m - Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State RulesRcd RulesAcc
10.0.0.2 4 10 12 4 0 0 00:02:18 Estab 2 2
10.0.1.2 4 10 6 4 0 0 00:02:18 Estab 0 0
The show bgp flow-spec ipv4 displays a brief description of each flowspec rule, including the matching rule and actions. The matching rule uses a format:
dest prefix; src prefix; [component:condition] +
The component is abbreviated, for example, DP for destination port and IP for IP Protocol as shown in the following example. The detail of the show command will display the full component name.
The condition is expressed with logical operators. In the following example, IP:=6|=17 matches any packets whose IP Protocol is 6 (TCP) or 17 (UDP). DP:>1010&<1024 matches any packets whose destination port is greater than 1010 and less than 1024.
Example
switch(config)# show bgp flow-spec ipv4
BGP Flow Specification rules for VRF default
Router identifier 0.0.0.1, local AS number 10
Rule status codes: # - not installed, M - received from multiple peers
Matching Rule Actions
10.2.3.0/24;*; Drop
10.2.4.0/24;10.2.0.0/16;IP:=6|=17;DP:>1010&<1024; Drop
The show bgp flow-spec detail displays the full details of each flowspec rule including the peer(s) it was received from, BGP properties, and an expanded description of the matching rule:
Example
switch(config)# show bgp flow-spec ipv4 detail
BGP Flow Specification rules for VRF default
Router identifier 0.0.0.1, local AS number 10
BGP Flow Specification Matching Rule for 10.2.3.0/24;*;
Rule identifier: 3882065752
Matching Rule:
Destination Prefix: 10.2.3.0/24
Source Prefix: *
Paths: 1 available
Local
from 10.0.0.2 (10.1.1.2)
Origin IGP, metric -, localpref 100, weight 0, valid, internal, best
Actions: Drop
BGP Flow Specification Matching Rule for 10.2.4.0/24;10.2.0.0/16;IP:=6|=17;DP:>1010&<1024;
Rule identifier: 3882090640
Matching Rule:
Destination Prefix: 10.2.4.0/24
Source Prefix: 10.2.0.0/16
IP Protocol: =6 | =17
Destination Port: >1010 & <1024
Paths: 1 available
Local
from 10.0.0.2 (10.1.1.2)
Origin IGP, metric -, localpref 100, weight 0, valid, internal, best
Actions: Drop
The show flow-spec ipv4 summary command displays an overall status of how many flowspec rules were received and how many were installed:
Example
switch(config)# show flow-spec ipv4 summary
Flow specification rules summary for VRF default
Total number of rules: 2
Number of installed rules: 2
The show flow-spec ipv4 displays the installation status of the rule, and a counter of how many hits it has accumulated. This command also compiles the received flowspec rules into rules that can be programmed into the TCAM. For example, logical expressions on values such as the destination port are converted to ranges, as shown below:
Example
switch(config)# show flow-spec ipv4
Flow specification rules for VRF default
Applied on: Ethernet47/1
Flow-spec rule: 10.2.3.0/24;*;
Rule identifier: 3882065752
Matches:
Destination prefix: 10.2.3.0/24
Actions:
Police: 80 Mbps (10 MBps)
Redirect: VRF customer1
Route via LDP tunnel index 4, MPLS label 100123
Route via LDP tunnel index 1, MPLS label 116507
Status:
Installed: yes
Counter: 312 packets
Flow-spec rule: 10.2.4.0/24;10.2.0.0/16;IP:=6|=17;DP:>1010&<1024;
Rule identifier: 3882090640
Matches:
Destination prefix: 10.2.4.0/24
Source prefix: 10.2.0.0/16
Next protocol: 17
6
Destination port: 1011-1023
Actions:
Police: 80 Mbps (10 MBps)
Redirect: VRF customer1
Route via LDP tunnel index 4, MPLS label 100123
Route via LDP tunnel index 1, MPLS label 116507
Status:
Installed: yes
Counter: 0 packets
Infeasible rules are detected and not programmed, and this status is reported using the show flow-spec ipv4 command. Examples of the infeasible rules are:
The lt/gt/eq operator is missing in the numerical opVal component.
Co-existence of TCP flag component with ICMP type or code component in the same rule.
Co-existence of port based component with ICMP type or code component in the same rule.For example, the default route in the specified VRF can be resolved over a GRE or MPLS tunnel. The following show command output verifies the resolution over the tunnel.
For redirect actions, additional information is displayed to show how it was resolved.
Example
Actions:
Redirect: VRF customer1
Route via LDP tunnel index 4, MPLS label 100123
Route via LDP tunnel index 1, MPLS label 116507
The specified nexthop in the flow-spec redirect action can be resolved by the respective VRFs IP RIB over MPLS or GRE tunnel, as shown in the following example:
Example
Actions:
Redirect: VRF default, fc00:91:91:91::91
Route via Static Interface tunnel index 1
BGP Flowspec Interface-Set Extended Community
BGP Flowspec leverages BGP extended communities to disseminate and apply traffic filtering rules across a network. As part of this protocol, Interface-Set Extended Community configures a specific type of BGP Extended Community included with the Flowspec rules. BGP Flowspec rules can specify to apply only to traffic ingressing or egressing a specific set of interfaces, rather than applying the rule to all interfaces on the switch.
The Interface-Set Extended Community provides a mechanism to convey a specific set of interfaces to apply a rule. This may be useful in network environments where a Flowspec action, such as discarding DDoS traffic, must be localized to specific ingress points without affecting other traffic paths.
Configuring BGP Extended Communities
Selectiviely apply BGP Flowspec rules to sets of forwarding interfaces sharing a common group identifier. Configure the maximum number of supported interfaces using the following commands:
By default, the interface-set limit equals 0. Setting the interface-set limit to zero disables the feature, and does not program the interface-set rules. In this case, EOS only programs the VRF rules. EOS supports the following values for the count limit:
Table 7.Supported Values
Interface-Set Count Limit (Valid Values)
Minimum Port Qualifier Size Required (One VRF)
3
3
7
4
15
5
31
6
63
7
127
8
255
9
511
10
1023
11
2047
12
To configure the limit successfully, configure the TCAM profile and set the port qualifier size number bits to a minimum size. Use the following commands to set the TCAM profile, bgp-comm, to use a minimum of 5 banks, ipv4 packets, port qualifier size 4:
switch(config)# hardware tcam
switch(config-tcam)# profile bgp-comm
switch(config-tcam-profile-bgp-comm)# feature flow-spec port ipv4
switch(config-tcam-feature-flow-spec-port-ipv4)# port qualifier 4
The configuration limits the interface-set count limit to 7 and if the configuration does not meet the criteria for port qualifier size, the configuration sets the count limit to zero and only the VRF rules apply.
Configuring the Interface-Set Assignment
Use the following commands to configure the interface-set assignment to 7 on Ethernet1:
The output of the show flow-spec command displays a section with interface-sets information:
switch# show flow-spec
Actions:
Police: 80 Mbps (10 Mbps)
Interface sets: 1
Applied on: Ethernet1/1
Configuring BGP Logical OR of Multiple Community Lists
Adding the or-results token to the match community command allows you to do a logical OR between all provided community lists:
match community or-results COMMLIST1 COMMLIST2
match extcommunity or-results EXTCOMMLIST1 EXTCOMMLIST2
match large-community or-results LARGECOMMLIST1 LARGECOMMLIST2
Full configuration example:
Enable the Multi-agent mode.
switch(config)# service routing protocols model multi-agent
Create community lists (extended and large communities are also compatible with or-results).
switch(config)# ip community-list COMMLIST1 permit 1:1
switch(config)# ip community-list COMMLIST2 permit 2:2
Configure Route-map with or-results.
switch(config)# route-map IN-POLICY
switch(config-route-map-IN-POLICY)#match community or-results
COMMLIST1 COMMLIST2
Displaying BGP Logical OR Information
The or-results match clauses can be seen with the standard show route-map command, as shown in the following command display outputs.
switch# show route-map IN-POLICY
route-map IN-POLICY permit 10
Description:
Match clauses:
match community or-results COMMLIST1 COMMLIST2
SubRouteMap:
Set clauses:
set local-preference 500
route-map IN-POLICY permit 20
Description:
Match clauses:
SubRouteMap:
Set clauses:
switch# show run | in 200.200.200.57
neighbor 200.200.200.57 remote-as 300
neighbor 200.200.200.57 update-source Loopback200
neighbor 200.200.200.57 ebgp-multihop
neighbor 200.200.200.57 route-map IN-POLICY in
neighbor 200.200.200.57 maximum-routes 0
switch# show ip bgp community 1:1
BGP routing table information for VRF default
Router identifier 220.220.220.51, local AS number 200
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 66.170.224.0/20 200.200.200.57 0 500 0 300 ?
* > 66.170.232.0/21 200.200.200.57 0 500 0 300 ?
* > 128.29.0.0/16 200.200.200.57 0 500 0 300 ?
switch# show ip bgp community 2:2
BGP routing table information for VRF default
Router identifier 220.220.220.51, local AS number 200
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 192.12.24.0/24 200.200.200.57 0 500 0 300 ?
* > 192.47.242.0/24 200.200.200.57 0 500 0 300 ?
Setting the BGP Missing Policy Action
To set the default policy behavior for BGP so that all routes can be denied or rejected, use the bgp missing policy command. Options control inbound and outbound directions independently. When the inbound direction is affected, currently installed routes from the peer are removed (and withdrawn from other attached peers). When the outbound direction is affected, currently exported routes to the peer are withdrawn. Setting the Missing Policy Action options back to its default/permit value re-applies the current inbound route-map policy processing to the set of routes received from the peer and export routes according to the configured outbound route-map. If soft-reconfiguration is disabled and the inbound direction is affected then the peer must re-send its routes (e.g. a manual “clear ip bgp” command is required).
Configuring the BGP Missing Policy Action
Permit is the default missing policy action when no/default are applied. Entering the ‘default’ form of the command in a non-default VRF will cause the non-default VRF to inherit the setting from the default VRF. Entering the no form of the command in a non-default VRF will cause the non-default VRF to be configured with the permit setting regardless of the default VRF setting.
The include keyword is optional, and only takes effect in the multi-agent protocol model.
The following configures the BGP missing policy action.
switch(config-router-bgp)# bgp missing-policy [include {prefix-list|sub-route-map}]
direction [in|out] action [permit|deny|deny-in-out]
switch(config-router-bgp)# [no|default] bgp missing-policy [include {prefix-list|sub-route-map}]
direction [in|out] action
Actions
For the actions, the permit and deny options inherit the direction of route denial from the direction, while the deny-in-out option specifically calls out denying routes in both directions.
direction in action permit: allow all routes in the inbound direction when the inbound route-map is misconfigured (default).
direction out action permit: allow all routes in the outbound direction when the outbound route-map is misconfigured (default).
direction in action deny: deny all routes in the inbound direction when the inbound route-map is misconfigured.
direction out action deny: deny all routes in the outbound direction when the outbound route-map is misconfigured.
direction in action deny-in-out: deny all routes in both inbound/outbound directions when the inbound route-map is misconfigured.
direction out action deny-in-out: deny all routes in both inbound/outbound directions when the outbound route-map is misconfigured.
The include keyword specifies that the policy constructs in the route map should also be examined. The options to the include keyword are.
sub-route-map: examine the sub route map references if any are defined in a route map covered by a missing policy statement. If the sub route map statement – or any in a route map chain – makes a reference to a route map which does not exist, then the missing policy action will be applied.
prefix-list: examine the prefix list references if any are defined in a route map covered by a missing policy statement. If the prefix-list statement – or any in the applied route map chain – makes a reference to a prefix list which does not exist, then the missing policy action will be applied.
The show ip bgp neighbors command displays the status of a peer which is currently in the missing policy/default deny state. The Missing policy/default deny lines would be omitted if the configuration option is disabled or the route-maps are configured correctly.
switch(config-router-bgp)# show ip bgp neighbors
BGP neighbor is 1.0.0.2, remote AS 200, external link
BGP version 4, remote router ID 0.0.1.1, VRF default
Negotiated BGP version 4
…Missing policy/default deny import action is active
Missing policy/default deny export action is active
Inbound route map is rm1
Outbound route map is rm2
…
Configuring BGP Inbound Update Processing Delay
Apply an optional delay before processing inbound update messages from peers, and may be useful when routes from a peer depend on routes from another. The routes from the second peer must install before the routes from the first peer process, and applying the delay to the first peer allows the second peer to install the routes first. Configure the delay per peer and apply it to all address families negotiating with the peer. The delay timer starts when the peer becomes established, and routes from the peers with the delay process only after the time expires. EOS supports this feature on default and non-default VRFs on the network. The inbound delay does not apply to switch reloads or BGP agent restarts.
Configure the delay per peer and apply it to all address families negotiating with the peer. The delay timer starts when the peer becomes established, and routes from the peers with the delay process only after the time expires. EOS supports this feature on default and non-default VRFs on the network.
The inbound delay does not apply to switch reloads or BGP agent restarts.
Example
To configure the inbound update processing delay for 30 seconds on a peer group, mybgp-peers, use the following command:
Configuring BGP IPv4-mapped IPv6 Address Next Hops for IPv6 Labeled-Unicast Routes
Receive-side Configuration
To configure BGP to translate IPv4-mapped IPv6 addresses to IPv4 addresses when receiving next hops in labeled-unicast routes, use the neighbor next-hop resolution v4-mapped-v6 translation command. With this configuration, when the switch receives an IPv4-mapped IPv6 address for the next hop of an IPv6 labeled-unicast route, it will translate it to an IPv4 address, which allows the next hop to be resolved in an IPv4 network. This command takes effect only if the multi-agent routing protocol model is running. It applies only to the default VRF.
Example
These commands enter BGP IPv6 Labeled-Unicast Address Family Configuration Mode for AS 64510 (creating the BGP instance if it does not exist) and enable the translation of IPv4-mapped IPv6 addresses to IPv4 addresses for neighbors in the v6_pg peer group.
A BGP router advertising a route can provide the IPv4-mapped IPv6 address of one of its local interfaces, such as a loopback interface, as the next hop. This source interface is specified with the neighbor next-hop-self command. The interface must be configured with an IPv4 address for this to be effective.
This configuration does not enable next-hop-self. It simply specifies the interface to be provided if the router advertises itself as the next hop. The next-hop-self action can be enabled with the neighbor next-hop-self command, or by configuring Egress Peer Engineering (EPE) using the neighbor default-originate command, or by other methods.
Example
These commands enable the switch to advertise itself as a next hop for the peer at 2001:0db8::1, and then configure the switch to use the IPv4 address of the Loopback 0 interface for the next hop for the peer at 2001:0db8::1 if the route is IPv4-mapped IPv6.
For BGP EVPN VXLAN fabrics, automatic route distinguisher (RD) generation simplifies the network configuration by automatically generating unique RD values based on the BGP Router ID and the VRF ID, eliminating manual RD configuration. EOS supports this configuration for the following address families:
L2 EVPN VXLAN
Virtual Private Wire Service (VPWS)
VLAN
VNI
L3 VRFs
L3 EVPN
MPLS VPN
Route Distinguisher Generation
According to RFC4364, a route distinguisher (RD) consists of two fields, type and value. In the type field, the RFC defines three values: 0, 1, and 2 that use the following encoding types:
Type 0 - A 2-byte Administrator subfield plus a 4-byte Assigned Number subfield (<asn><nn>)
Type 1 - A 4-byte Administrator subfield plus a 2-byte Assigned Number subfield (<ip-addr><nn>)
Type 2 - A 4-byte Administrator subfield plus a 2-byte Assigned Number subfield (<asn4><nn>)
Autogeneration of RDs generates a Type 1 RD by using the router ID as the 4-byte administrator subfield and a 2-byte assigned number subfield from a configurable range.
Configuring BGP Automatic RDs
Configure the automatic RD in the BGP Router Configuration Mode using a range for the RD and the address family type:
switch(config)#router bgp asn
switch(config-router-bgp)#route-distinguisher
switch(config-route-distinguisher)#assignment auto range start_rangeend_range
?switch(config-route-distinguisher)#assignment auto address-family l2-evpn
EOS disables this feature by default. All address families within the L2 EVPN configuration share the same range.
BGP Peer Tagging and Route Filtering
Peer Tagging and Route Filtering allows or discards BGP route advertisements from peers with received routes. Assign a peer tag to a peer or peer group for inbound traffic and discard or allow route advertisements by the peer tag in the outbound direction. Use this feature to discard AS loop routes in the outbound direction in data center deployments.
Configure the peer tag at both the instance, router-bgp, and address-family levels, router-bgp-af.
Example Use Case
BGP can detect and prevent Autonomous Systems (AS) loop detection for the inbound direction as well as discard AS loop routes in the outbound direction to optimize network performance. In the example topology, the leaf and spine switches have been configured as EBGP peers and the spine switches configured with the same AS number. Leaf1 receives BGP routes from Spine1 and re-advertises them to Spine2 and Spine3 because of the EBGP peering configuration. Inbound AS loop detection drops the routes on Spine2 and Spine 3 which consumes a significant amount of CPU processing and memory.
Figure 6.Example BGP Topology for Peer Tagging and Route Filtering
Use the following configuration on Leaf1 to prevent Leaf1 from advertising routes received from any Spine back to other Spines. The Spine switches use a peer-group named, SPINES, and a peer-tag called, spine-routes, applied to both inbound and outbound directions of the peer-group, Spines. Routes received from each Spine have a tag, spine-routes, and discarded in route advertisements to the other two Spines.
switch(config)# router bgp 100
switch(config-router-bgp)# neighbor SPINES remote-as 200
switch(config-router-bgp)# neighbor SPINES peer-tag in spine-routes
switch(config-router-bgp)# neighbor SPINES peer-tag out discard spine-routes
switch(config-router-bgp)# neighbor 10.1.1.1 peer group SPINES
switch(config-router-bgp)# neighbor 10.1.2.1 peer group SPINES
switch(config-router-bgp)# neighbor 10.1.3.1 peer group SPINES
The feature can be configured with the parameter, address-family as follows:
switch(config-router-bgp)# address-family ipv4
switch(config-router-bgp-af)# neighbor 10.1.1.1 peer-tag in spine-routes
switch(config-router-bgp-af)# neighbor 10.1.1.1 peer-tag out discard spine-routes
In addition to AS loop detection, use the feature for scenarios that require discarding route advertisements based on the receiving peers. The following example configures a router to accept route advertisements from 1.1.1.1 only if tagged with bgp-lab in the inbound direction. Otherwise, the router rejects the route advertisements.
Use the following show commands to display peer-tag information:
switch# show ip bgp neighbors 10.1.1.1
BGP neighbor is 10.0.0.1, remote AS 100, external link
BGP version 4, remote router ID 10.0.1.1, VRF default
…
BGP session driven failover for IPv4 Unicast is disabled
BGP session driven failover for IPv6 Unicast is disabled
IPv4 Unicast inbound peer-tag: spine-routes
IPv4 Unicast deny outbound peer-tag: spine-routes
IPv6 Unicast inbound peer-tag: spine-routes
IPv6 Unicast Permit outbound peer-tag: spine-routes
Message Statistics:
Use the show bgp update-group command to display the peer-tag configured on the outbound route of an update group with the number of routes matched and dropped by the peer-tag:
switch# show bgp update-group
BGP update groups information for VRF default
BGP version 4 update group 5, external
Policy group ID is 10
Send IPv6 Unicast updates
State of attributes of the reflected routes not preserved
Extended next hop capability is disabled
Private AS number to be removed from updates
Neighbor AS number is 645501
Configured local AS number is 200
Four-byte ASN negotiated
Missing policy action is permit
Deny outbound peer-tag is spine-routes
Advertisement routes: 0
Queued advertisements: 0
Policy Statistics
Path Drop Reason Drop Count
Policy rejects 0
NO_EXPORT / NO_ADVERTISE community 0
Extended next hop mismatch 0
Received link-local next hop 0
Next hop self no local label 0
Outbound peer-tag rejects 100
Has 1 members, 1 member(s) in sync (* indicates member is in sync)
Neighbor InSync
10.1.1.1 *
10.1.2.1 *
10.1.3.1
Use the same command to display information when the outbound peer-tag has an allow action:
switch# show bgp update-group
BGP update groups information for VRF default
BGP version 4 update group 5, external
Policy group ID is 10
Send IPv6 Unicast updates
State of attributes of the reflected routes not preserved
Extended next hop capability is disabled
Private AS number to be removed from updates
Neighbor AS number is 645501
Configured local AS number is 200
Four-byte ASN negotiated
Missing policy action is permit
Permit outbound peer-tag is spine-routes
Advertisement routes: 0
Queued advertisements: 0
Policy Statistics
Path Drop Reason Drop Count
Policy rejects 0
NO_EXPORT / NO_ADVERTISE community 0
Extended next hop mismatch 0
Received link-local next hop 0
Next hop self no local label 0
Outbound peer-tag rejects 0
Has 1 members, 1 member(s) in sync (* indicates member is in sync)
Neighbor InSync
10.1.1.1 *
10.1.2.1 *
10.1.3.1
Configuring BGP Aggregate Minimum Contributors
In Arista EOS, the BGP Aggregate Address Minimum Contributors feature provides a safety mechanism for route summarization. It prevents a partial network from attracting traffic it cannot actually reach, a scenario commonly referred to as traffic blackholing.
EOS does not generate an aggregate route unless the BGP table has a specific number of active component subnets. If the number of active subnets falls below the configured minimum threshold, the switch withdraws the aggregate route. Traffic shifts to the redundant peer with a healthy number of contributor routes.
Use the following commands to configure a minimum of 10 contributors for aggregate route, 172.16.21.35/32, on BGP router, BGP-24:
The bgp monitoring command enables the export of BGP received paths and Loc-Rib routes on non-default VRFs. BMP only supports non-default VRFs with a route distinguisher (RD) configured in the BGP Router VRF Configuration Mode. The RD distinguishes peers with the same IP address but in different VRFs.
If the RD or router ID changes later, BMP sends Peer Down messages with the old RD value to all BGP peers in the VRF, and then sends Peer Up and Route Monitoring messages with the new RD value.
Disabling BMP for a Neighbor
Use the following commands to disable BMP on router 64512 with the router ID 1.0.1.1:
switch(config)# router bgp 64512
switch(config-router-bgp)# no neighbor 1.0.1.1 monitoring
VRF Filtering for Adj-Rib-In Export
With BMP and export for an address family (AFI/SAFI) enabled, the BGP router exports Adj-RIB-In information for all VRFs. Filter the VRFs exported by the BGP router using the following commands:
This prevents the BGP router from exporting the routes on VRF. Using the no or default version of the command reverts the configuration to the default behavior of exporting the Adj-RIB-Ins information.
Configuring a BMP Header Timestamp
Use the monitoring timestamp to set the timestamp in BMP Route Monitoring messages to zero (none) or to the Route Monitoring Message construction time. BMP uses the send-time as the default value.
Note: The send-time indicates the time of Route Monitoring messaging formation and may not be equal to the time that the BGP peer received BGP paths. Since many BGP paths may be packed together into a single Route Monitoring message, the BGP paths all share the same timestamp.
To configure the timestamp to none, use the following commands:
By default, the pre-policy and the post-policy routes advertise to the monitoring station. Use the no monitoring received routes command disables either pre-policy or post-policy routes or both. Use the following commands to disable pre-policy routes:
switch(config)# router bgp 64512
switch(config-router-bgp)# no monitoring received routes pre-policy
To enable exporting pre-policy and post-policy routes, use the following commands:
switch(config)# router bgp 64512
switch(config-router-bgp)# monitoring received routes pre-policy post-policy
Statistics Reporting for BMP Stations
The following table lists the supported statistics counters for BMP:
Table 8.Supported Statics Counters
Statistic Type
Description
0
Number of prefixes rejected by the inbound policy
7
Number of routes in Adj-RIBs-In
9
Number of routes in each AFI/SAFI Adj-RIB-In
BMP disables statistics reporting by default. Use the following commands to turn on statistics reporting for a Monitoring Station:
switch(config)# router bgp 64512
switch(config-router-bgp)# monitoring station S1
switch(config-router-bgp-monitoring-station-S1)# statistics
Once enabled on a monitoring station, the station begins receiving periodic SR announcements containing the supported statistics. The SR announcements generate periodically, every 30 seconds by default, whether or not any changes occur to the statistics. Configure the statistics reporting interval to 45 seconds using the following commands:
BMP supports exporting BGP received paths with a specific address family and exports IPv4 Unicast and IPv6 Unicast Adj-RIB-In paths by default. Enable or disable exporting BGP received paths with a specific address family. Use the following commands to specify IPv4 Unicast Adj-RIB-In paths:
To export BGP received paths, configure a BMP Monitoring Station using the monitoring stationstation_name command. Specify a connection mode, the IP address of the station, and depending on the connection mode, the local or remote TCP port to establish a TCP connection to the station. Use one of the following connection modes:
Active mode - The router initiates a TCP connection to the BMP Monitoring Station.
Passive mode - The router listens for TCP connections from the BMP Monitoring Station which must initiate the connection.
Configuring a Passive Mode Connection
Use the following commands to configure a passive connection with a listening port, 5001:
switch(config)# router bgp 64512
switch(config-router-bgp)# monitoring port 5001
For passive mode connections, configure an IP address for the BMP Monitoring Station:
The connection address must match the source IP address used by the monitoring station to connect to the router. Since the monitoring stations does not send messages to the router, the IP address provides the only way to identify the station and match the correct configuration.
Configuring an Active Mode Connection
For active mode connections, configure the monitoring station IP address and port number:
switch(config)# router bgp 64512
switch(config-router-bgp)# monitoring station S1
switch(config-router-bgp-monitoring-station-S1)# connection mode active port 5000
switch(config-router-bgp-monitoring-station-S1)# connection address 192.168.1.5
The monitoring station must listen for connections at the specified IP address and TCP port number.
Configuring a Monitoring Station on a Non-Default VRF
Use the following commands to configure a monitoring station, Stn-2, on a VRF, mgmt:
The description parameter allows the addition of descriptive text for the monitoring station and displays that information in BMP station show commands.
Use the following commands to add a description, monitoring remote network, to the monitoring station, Stn-2:
Use the following commands to configure export policy filtering at the station level:
switch(config)# router bgp 64512
switch(config-router-bgp)# monitoring station Stn-2
switch(config-router-bgp-monitoring-station-S1)# no export-policy received routes pre-policy
switch(config-router-bgp-monitoring-station-S1)# no export-policy received routes post-policy
Shutting Down Monitoring Station TCP Sessions
Use the shutdown command to shut down TCP sessions to the monitoring station. The router stops initiating TCP connections to stations configured with an active mode connection. For stations configured with a passive mode connection, the router stops accepting TCP sessions from the station.
switch(config)# router bgp 64512
switch(config-router-bgp)# monitoring station Stn-2
switch(config-router-bgp-monitoring-station-S1)# shutdown
Updating the Source for the TCP Session
Use the update-source command to select the source IP address sent by the router for the TCP session. The monitoring station must be able to reach the IP address. Use the following commands to update the source IP address to interface, ethernet1/1:
The connection keepalive command periodically checks the health of the TCP connection with the station. Since the router does not receive messages from the station, the router cannot detect when the station becomes unavailable due to power or link failure. Using a TCP keepalive probe allows the router to quickly detect the loss of a station connection. Configure a keepalive probe with 30 seconds of idletime, 30 seconds between TCP keepalive probes, and sending 100 probes before closing the connection:
For additional security, enable the TCP MD5 signature option for the TCP session with the station. The same key must be configured on the router and the BMP station. The authentication-key command enables this option and configures the key used on the session. Use the following commands to configure a password, mySecretID, for TCP sessions:
Use the following configuration for a BMP station (S1) to receive additional-paths advertisements, for example, NLRIs containing addpath-ids. If any BGP peer has a configuration for additional-paths and can send addpath-id values with the required additional-paths visibility for that peer.
switch(config)# router bgp 64512
switch(config-router-bgp)# monitoring station S1
switch(config-router-bgp-monitoring-station-S1)# export-policy received routes additional-paths
Exporting Local RIB
By default, BMP disables exporting Local RIB for all monitoring stations on all VRFs. Enable exporting the Local RIB per station or per VRF. You must configure the router ID for BGP and the RD for a non-default VRF. BMP exports IPv4 and IPv6 Unicast routes into the Local RIB including imported VPN routes. The following commands configure exporting of the Local RIB to a single station:
switch# show bgp monitoring station bmp_C detail
Station - bmp_C
Connection mode: active
VRF: default
Address: 192.0.2.1
Port: 5000
Connection: connected
State: up
Uptime: 00:13:06
Station flap count: 1
TCP Socket Information:
TCP state is ESTABLISHED
Send-Q: 0/200
Outgoing Maximum Segment Size (MSS): 1448
Total Number of TCP retransmissions: 0
Options:
Timestamps enabled: yes
Selective Acknowledgments enabled: yes
Window Scale enabled: yes
Explicit Congestion Notification (ECN) enabled: no
Socket Statistics:
Window Scale (wscale): 9,9
Retransmission Timeout (rto): 204.0ms
Round-trip Time (rtt/rtvar): 0.1ms/0.1ms
Delayed Ack Timeout (ato): 0.0ms
Congestion Window (cwnd): 10
TCP Throughput: 864.48 Mbps
Advertised Recv Window (rcv_space): 29200
BGP Operational Commands
Shutdown
The shutdown (BGP) command disables BGP operations without disrupting the BGP configuration. The router bgp command disables BGP and removes the BGP configuration.
switch(config-router-bgp)# no shutdown
switch(config-router-bgp)#
Clearing the Routing Table and Resetting BGP Sessions
When entered without parameters, the clear ip bgp command clears all BGP learned routes from the routing table, reads routes from designated peers, and sends routes required by those peers. Routes that are read or sent are processed through any modified route map or AS-path access list.
Followed by an asterisk (*), it clears the BGP sessions with all BGP peers. To reset the session with a specific peer, enter the peer’s IP address at the end of the command.
Example
This command removes all BGP learned routes from the routing table.
switch# clear ip bgp
! Peerings for all neighbors were hard reset
switch#
BGP IPv6 Link Local Peers Discovery
BGP IPv6 Link Local Peers Discovery supports a dynamic configuration model to eliminate the need for the network administrator to assign and configure IPv6 addresses for BGP peering.
Leverage the following details to automatically establish BGP adjacency:
EOS automatically generates the IPv6 link local addresses based on MAC addresses.
EOS uses the IPv6 router advertisements to communicate these addresses among potential BGP peers.
BGP IPv6 Link Local Peers Discovery uses IPv6 router advertisement to discover the peers IPv6 link local address. Devices must have IPv6 routing enabled, and the interface used for peering must have an IPv6 link local address. The time taken to discover the peers IPv6 link local address is proportional to the time taken by the peer to send a router advertisement message. When bringing up BGP sessions based on router advertisements received, a flurry of router advertisements on the interfaces causes the Rib agent to do more work and potentially delays the discovery of BGP neighbors over those interfaces and the establishment of BGP sessions. Since these are link local addresses, the peers must be directly connected at Layer 3.
Debug Show Commands
These show commands are invaluable for debugging route map behavior. By providing a BGP-reachable prefix (from a BGP peer or redistribution source), you can evaluate a specified route map. If no route map is explicitly given, the system will use the route map applied to the peer. You can also select any configured route map, even if it's not currently applied. If no VRF is specified, the default VRF will be used. The output clearly details the evaluation of each sequence, including the results of match clauses, any sub-route map evaluations, applied set clauses, the impact of continue statements, and the final permit/deny outcome for the sequence. This comprehensive output enables users to gain a thorough understanding of how a route map processes specific paths.
switch(config)# show bgp debug policy inbound neighbor 10.1.2.1 ipv4 unicast vrf red route-map foo 10.100.20.0/24
NLRI 10.100.20.0/24, received from 10.1.2.1
route-map foo
seq 10 permit
match as 1 (failed)
Seq result: fall through to next sequence
seq 20 permit
match as 1 (matched)
sub-route-map sub_foo (permit)
seq 10 permit
match as 1 (matched)
Seq result: permit
Route map result: permit, matching sequence 10
Seq result: permit
Route map result: permit, matching sequence 20
Note: When debugging routes received via a neighbor configured with BGP Additional Paths, the path-id parameter must be appended to the command to uniquely identify the path, even if it is the only path received for that NLRI.
BGP Examples
This section shows example configurations and topologies for iBGP (BGP Example 1) and eBGP (BGP Example 2).
BGP Example 1
Example 1 features an internal BGP (iBGP) link that connects peers in AS 100.
BGP Example 1 Diagram
Figure 7 - BGP Example 1 displays an iBGP connection, linking neighbors within AS 100. Each switch advertises two subnets. In UPDATE packets sent by Switch A, the LOCAL_PREF field is 150. In UPDATE packets sent by Switch B, the LOCAL_PREF field is 75.
Figure 7.BGP Example 1
BGP Example 1 Code
This code configures the Example 1 BGP instance on both switches.
Example 2 creates an external BGP (eBGP) link that connects routers in AS 100 and AS 200.
BGP Example 2 Diagram
Figure 8 - BGP Example 2 displays an eBGP connection, linking Switch A in AS 100 to Switch B in AS 200. Each switch advertises two subnets.
Switch A assigns a local preference of 150 to networks advertised by Switch B. Switch B assigns a local preference of 75 to networks advertised by Switch A.
Figure 8.BGP Example 2
BGP Example 2 Code
This code configures the Example 2 BGP instance on both switches.
The address-family command places the switch in address-family configuration mode to configure the address family setting of addresses configured as BGP neighbors. The address-family configuration mode is not a group change mode; running-config is changed immediately after commands are executed. The exit command does not affect the configuration.
The switch supports these address families:
ipv4-unicast
ipv6-unicast
The running-config displays the address-family commands in sub-blocks of the BGP configuration. The following commands are available in address family configuration mode:
neighbor activate configures the address as active in the configuration mode address family.
neighbor activate configures the address as not active in the configuration mode address family.
network (BGP) specifies a network for advertisement through UPDATE packets to BGP peers.
The no address-family and default address-family commands delete the specified address family from running-config by removing all commands previously configured in the corresponding address-family mode.
The exit command returns the switch to router-BGP configuration mode.
Command Mode
Router-BGP Configuration
Command Syntax
bgp [ipv4 | ipv6]
no bgp [ipv4 | ipv6]
default bgp [ipv4 | ipv6]
Parameters
ipv4 subsequent commands apply to the IPv4 unicast address family.
ipv6 subsequent commands apply to the IPv6 unicast address family.
Example
These commands enter address family mode for IPv6-unicast, insert a command, then exit the mode:
Use the address-family flow-spec command to filter or redirect DDoS traffic on edge routers. The no and default versions of the command removes the filter to redirect the DDoS traffic.
The address-family flow-spec neighbor command in the BGP Router Configuration Mode enables Flowspec on a BGP configuration to filter or redirect DDoS traffic on edge routers.
The [no | default] version of the command removes the configuration from the running-config.
The aggregate-address command creates an aggregate route in the Border Gateway Protocol (BGP) database. Aggregate routes combine the characteristics of multiple routes into a single route that the switch advertises. Aggregation can reduce the amount of information that a BGP speaker is required to store and transmit when advertising routes to other BGP speakers. Aggregate routes are advertised only after they are redistributed.
The advertised address of the aggregate is entered as an IP subnet; any routes configured on the switch that lie within that subnet then become contributors to the aggregate. Note that on Arista switches the BGP aggregate route will become active if there are any available contributor routes on the switch, regardless of the originating protocol. This includes routes configured statically.
Note: Aggregate routes are redistributed automatically, and their redistribution cannot be disabled.
Command options affect the attributes associated with the aggregated route, the advertisement of the contributor routes that comprise the aggregate, and which contributor routes are included.
Command options affect the following aggregate routing attributes:
AS_PATH attribute inclusion: the as-set option controls the aggregate route’s AS_PATH and ATOMIC_AGGREGATE attribute contents. AS_PATH identifies the autonomous systems through which UPDATE message routing information passes. ATOMIC_AGGREGATE indicates that the route is an aggregate or summary of more specific routes.
When the command includes as-set, the aggregate route’s AS_SET attribute contains the AS numbers of contributor routes. This can help BGP neighbors to prevent loops by rejecting aggregate routes that include their AS number in the AS_SET.
When the command does not include as-set, the aggregate route’s ATOMIC_AGGREGATE attribute is set and the aggregate route AS_PATH will include the longest leading PATH_SEQ of the AS_PATH which is common to all contributor routes. For example, for the aggregate 1.0.0.0/16 with two contributors present, the AS_PATH for the aggregate is 100 200 as shown.
Aggregate
1.0.0.0/16as-path??
Contributors
1.0.1.0/24as-path100 200 400 500
1.0.2.0/24as-path100 200 300
Attribute assignment: the attribute-map option assigns attributes contained in set commands in a specified route map’s lowest sequence with any set command to the aggregated route, overriding the automatic determination of the aggregate route’s attributes by the switch.
Route suppression: the summary-only option suppresses the advertisement of the contributor routes that comprise the aggregate.
Contributor filtering: the match-map option uses a route map to filter out contributor routes that would otherwise be included in the aggregate.
The no aggregate-address and default aggregate-address commands remove the corresponding aggregate-address command from running-config.
Note: The configuration requires the match-map and the summary-only parameters to enforce the configuration.
no parameterATOMIC_AGGREGATE attribute is set. Route contains no AS_PATH data.
as-set route includes AS_PATH information from contributor routes as AS_SET attributes.
SUMMARY controls advertisement of contributor routes. Options include:
no parameter contributor and aggregate routes are advertised.
summary-only contributor routes are not advertised.
ATTRIBUTE_MAP controls attribute assignments to the aggregate route. Options include:
no parameter attribute values are not assigned to route.
attribute-mapmap_name assigns attribute values in set commands of the map’s permit clauses. Deny clauses and match commands in permit clauses are ignored.
MATCH_MAP filters contributors to the aggregate route. Options include:
no parameter no contributors are filtered.
match-mapmap_name filters contributor routes using the named match-map.
Examples
These commands create an aggregate route (10.16.48.0/20) from the contributor routes 10.16.48.0/23, 10.16.50.0/23, 10.16.52.0/23, and 10.16.54.0/23. The aggregate route includes the AS_PATH information from the contributor routes.
These commands create an aggregate route and use a route map to allow only those contributors which match a specified prefix list to be included in the aggregate route.
The authentication-key command adds security to the TCP session to the BMP monitoring station. Configure the same key on the BGP router and the BMP monitoring station. Access this command in the Monitoring Station Configuration Mode.
Command Mode
Monitoring Station Configuration
Command Syntax
authentication-keykey
Parameters
key - Specify the authentication key in one of the following formats:
0 - Indicates an unencrypted key string follows.
7 - Indicates that a hidden key follows.
8a - Indicates that an AES-256-GCM encrypted key follows.
password - Specify a password up to 80 characters.
Example
Use the following commands to specify an authentication-key as a password, !ckCK!nfxH3!LsyBr3!:
By default, BGP will advertise only those routes that are active in the switch’s RIB. This can contribute to dropped traffic. If a preferred route is available through another protocol (like OSPF), the BGP route will become inactive and not be advertised; if the preferred route is lost, there is no available route to the affected peers. Advertising inactive BGP routes minimizes traffic loss by providing alternative routes.
The bgp advertise-inactive command configures BGP to advertise inactive routes to BGP neighbors. Inactive route advertisement is configured globally, but the global setting can be overridden on a per-VRF basis.
The no bgp advertise-inactive and default bgp advertise-inactive commands restore the default BGP behavior (advertising only active routes) by removing the corresponding bgp advertise-inactive command from running-config.
Command Mode
Router-BGP Configuration
Command Syntax
bgp advertise-inactive
no bgp advertise-inactive
default bgp advertise-inactive
Example
These commands configure BGP to advertise inactive routes.
The bgp always-compare-med command configures the switch to always consider Multi-Exit Discriminator (MED) values (also known as “metric”) in best-path selection. By default, this function is disabled, and MED values are compared only if two paths have the same neighbor AS.
When there are two or more links between autonomous systems, MED values may be set by a router in the originating AS to give preferences to certain routes. In comparing MED values, the lower value is preferred.
The no bgp always-compare-med and default bgp always-compare-med commands restore the default behavior of comparing MED values only on paths with the same neighbor AS.
The bgp bestpath as-path ignore command configures BGP to ignore the length of the Autonomous System (AS) path when comparing routes. This behavior is disabled by default. Normally, the switch compares AS paths as the third step in the best-path selection process (see Best-Path Selection), preferring the route with the shorter AS path.
The no bgp bestpath as-path ignore and default bgp bestpath as-path ignore commands restore the default behavior of considering AS path length in route comparisons.
The bgp bestpath as-path multipath-relax command allows multiple eBGP routes to a destination to be considered equal in ECMP if their AS paths are the same length despite having different autonomous systems in those paths. The no bgp bestpath as-path multipath-relax command configures best-path selection to consider two paths unequal if their AS path contents are different, and prefers the first path received.
Multipath-relax is enabled by default. The bgp bestpath as-path multipath-relax and default bgp bestpath as-path multipath-relax commands restore the default behavior by removing the corresponding no bgp bestpath as-path multipath-relax command from running-config.
For BGP to support equal cost multipath (ECMP) routing, the maximum-paths (BGP) command must be issued in router-BGP configuration mode.
The bgp bestpath d-path command configures BGP to use the domain path length in bestpath route selection.
The no bgp bestpath d-path and default bgp bestpath d-path commands restore the default behavior of considering the domain path length in the route selection process.
Command Mode
Router-BGP Configuration
Command Syntax
bgp bestpath d-path
no bgp bestpath d-path
default bgp bestpath d-path
Example
These commands configure BGP to use the domain path length in the route selection process.
By default, within an ECMP group the BGP best-path selection process prefers the active path (the first path received by the switch) unless a relevant tie-breaker is enabled. The no bgp bestpath ecmp-fast command causes the best-path selection process to ignore order of arrival and continue evaluating paths on other criteria.
The bgp bestpath ecmp-fast and default bgp bestpath ecmp-fast commands restore the default behavior by removing the corresponding no bgp bestpath ecmp-fast command from running-config.
These commands configure BGP to ignore order of arrival in best-path comparisons of paths within an ECMP group.
switch(config)# router bgp 64500
switch(config-router-bgp)# no bgp bestpath ecmp-fast
switch(config-router-bgp)#
bgp bestpath med confed
By default, paths originating within the same confederation as the switch and received from confederation peers do not have their Multi-Exit Discriminator (MED) values compared as part of the best-path selection process. The bgp bestpath med confed command causes comparison of MED values in such routes. To ensure that MED values are considered in the best-path selection process for all routes received, use the bgp always-compare-med command.
The no bgp bestpath med confed and default bgp bestpath med confed commands restore the default behavior by removing the corresponding bgp bestpath ecmp-fast command from running-config.
Command Mode
Router-BGP Configuration
Command Syntax
bgp bestpath med confed [missing-as-worst]
no bgp bestpath med confed [missing-as-worst]
default bgp bestpath med confed [missing-as-worst]
Parameters
missing-as-worst By default, best-path selection considers a missing MED value to be 0, so paths with missing MED values is preferred. This option reverses the behavior in comparisons of routes originating within the same confederation as the switch, treating a missing MED as having the highest (least preferred) value.
Note: The bgp bestpath med missing-as-worst command controls how best-path selection treats missing MED values for all routes received, and, if configured, overrides the missing-as-worst option of this command.
These commands configure the BGP best-path selection process to consider MED values in comparisons between routes originating within the same confederation as the switch.
switch(config)# router bgp 64500
switch(config-router-bgp)# bgp bestpath med confed
switch(config-router-bgp)#
bgp bestpath med missing-as-worst
By default, BGP best-path selection considers a missing MED value to be 0, so paths with missing MED values will be preferred. The bgp bestpath med missing-as-worst command reverses the behavior, treating a missing MED as having the highest (least preferred) value.
The no bgp bestpath med missing-as-worst and default bgp bestpath med missing-as-worst commands restore the default behavior (giving preference to missing MED values) by removing the corresponding bgp bestpath med missing-as-worst command from running-config.
Note: This command overrides the missing-as-worst setting of the bgp bestpath med confed command.
These commands configure the BGP best-path selection process to consider a missing MED value to be considered highest (least preferred) in MED comparisons for all routes received.
switch(config)# router bgp 64500
switch(config-router-bgp)# bgp bestpath med missing-as-worst
switch(config-router-bgp)#
bgp bestpath tie-break cluster-list-length
The bgp bestpath tie-break cluster-list-length command causes the best-path selection process to prefer the multipath route with the shortest CLUSTER_LIST length in case of a tie in step 10. The cluster list length is assumed to be 0 if the route does not carry a CLUSTER_LIST attribute.
The no bgp bestpath tie-break cluster-list-length and default bgp bestpath tie-break cluster-list-length commands restore the default behavior by removing the associated bgp bestpath tie-break cluster-list-length command from running-config.
The bgp bestpath tie-break router-id command causes the best-path selection process to prefer the multipath route with the lowest ROUTER_ID in case of a tie in step 10. If the route is a reflected route (i.e., if it contains route reflector attributes), the process will use the ORIGINATOR_ID as the ROUTER_ID for comparison. This behavior is disabled by default.
The no bgp bestpath tie-break router-id and default bgp bestpath tie-break router-id commands restore the default behavior by removing the associated bgp bestpath tie-break router-id command from running-config.
By default, routes received from a route reflector client and selected as best routes are propagated to all BGP peers, including other route reflector clients. If the clients are fully meshed, however, routes received from a client do not need to be mirrored to other clients. In this case, client-to-client reflection should be disabled.
The no bgp client-to-client reflection command disables client-to-client reflection.
The bgp client-to-client reflection and default bgp client-to-client reflection commands restore the default behavior by removing the no bgp client-to-client reflection command from running-config.
Command Mode
Router-BGP Configuration
Command Syntax
bgp client-to-client reflection
no bgp client-to-client reflection
default bgp client-to-client reflection
Example
These commands disable client-to-client reflection on the switch.
switch(config)# router bgp 1
switch(config-router-bgp)# no bgp client-to-client reflection
switch(config-router-bgp)#
bgp cluster-id
When using route reflectors, an AS is divided into clusters. A cluster consists of one or more route reflectors and a group of clients to which they re-advertise route information, and for redundancy a single cluster may contain multiple route reflectors. Each route reflector has a cluster ID. If the cluster has only one route reflector the cluster ID is its router ID, but if a cluster has multiple route reflectors a 4-byte cluster ID must be assigned to all route reflectors in the cluster. All must be configured with the same cluster ID to allow them to identify updates from the cluster’s other route reflectors.
The bgp cluster-id command configures the cluster ID in a cluster with multiple route reflectors.
The no bgp cluster-id and default bgp cluster-id commands remove the cluster ID by removing the corresponding bgp cluster-id command from running-config. Do not remove the cluster ID if there are multiple route reflectors in the cluster.
Command Mode
Router-BGP Configuration
Command Syntax
bgp cluster-idID_NUM
no bgp cluster-id
default bgp cluster-id
Parameters
ID_NUM cluster ID shared by all route reflectors in the cluster (32-bit dotted-decimal notation). Options include:
0.0.0.1 to 255.255.255.255 valid cluster ID number.
0.0.0.0 removes the cluster-ID from the switch. Equivalent to no bgp cluster-id command.
Example
This command sets the cluster ID for the switch to 172.22.30.101.
The bgp confederation identifier command configures the confederation identifier. Confederation can reduce the number of iBGP connections in a large AS domain. The AS domain is divided into several smaller sub-ASs, and each sub-AS remains fully connected. Devices in a sub-AS exchange information via iBGP, while devices in different sub-ASs use eBGP.
The no bgp confederation identifier and default bgp confederation identifier commands remove the bgp confederation identifier command from running-config.
Command Mode
Router-BGP Configuration
Command Syntax
bgp confederation identifieras_number
no bgp confederation identifier
default bgp confederation identifier
Parameter
as_number the ID of BGP AS confederation. Values range from 1 to 4294967295.
Example
This command sets the BGP confederation identifier to 9.
The bgp confederation peers command configures a confederation consisting of sub-ASs.
Before this command is executed, the confederation ID should be configured using the bgp confederation identifier command. Otherwise this configuration is invalid. The configured ASs in this command are inside the confederation and each AS uses a fully meshed network. The confederation appears as a single AS to the devices outside it.
The no bgp confederation peers and default bgp confederation peers commands delete the specified sub-AS from the confederation by removing the corresponding bgp confederation peers command from running-config.
Command Mode
Router-BGP Configuration
Command Syntax
bgp confederation peersas_range
no bgp confederation peersas_range
default bgp confederation peersas_range
Parameter
as_range the sub-AS number. Formats include number (from 1 to 4294967295), number range, or comma-delimited list of numbers and ranges.
Example
This command configures the confederation that contains AS 1000 and AS 1002.
The bgp convergence time command configures the time BGP waits before declaring all BGP sessions as converged, whether or not a EOR message has been received.
The no bgp convergence time command removes the configured convergence timeout. The default bgp convergence time command sets the timeout value to the default value.
Command Mode
Router-BGP Configuration
Command Syntax
bgp convergence timetimeout_range
no bgp convergence time
default bgp convergence time
Parameter
timeout_range the maximum time to wait for the BGP convergence. Values range from 1 to 3600 seconds. The default value is 300 seconds.
Example
This command configures a convergence time of 200 seconds to wait before establishing a session.
switch(config)# router bgp 1
switch(config-router-bgp)# bgp convergence time 200
switch(config-router-bgp)#
bgp convergence slow-peer time
The bgp convergence slow-peer time command configures the idle peer time to wait for the slow peers to establish a session in a BGP convergence state.
The no bgp convergence slow-peer time command disables the inheritance of the configuration from the global BGP configuration mode. The default bgp convergence slow-peer time command sets the timeout value to the default value.
Command Mode
Router-BGP Configuration
Command Syntax
bgp convergence slow-peer timetimeout
no bgp convergence slow-peer time
default bgp convergence slow-peer time
Parameter
timeout the maximum time to wait for the slow peers to establish a session connection. Values range from 1 to 3600 seconds. The default value is 90 seconds.
Example
This command configures an idle peer timeout of 40 seconds to wait before establishing a session.
The bgp default command configures the default address family activation level of all addresses configured as BGP neighbors. The switch sends the following announcements to addresses active in an address family:
ipv4 address family: IPv4 capability and all network advertisements with IPv4 prefixes.
ipv6 address family: IPv6 capability and all network advertisements with IPv6 prefixes.
The following commands configure default address family activation levels for addresses configured as BGP neighbors:
bgp default ipv4-unicast: all addresses are IPv4 address family active.
no bgp default ipv4-unicast: all addresses are not IPv4 address family active.
bgp default ipv6-unicast: all addresses are IPv6 address family active
no bgp default ipv6-unicast: all addresses are not IPv6 address family active.
bgp default ipv4-unicast transport ipv6: all BGP neighbor addresses are IPv4 address family active and IPv6 neighbors can receive IPv4 NLRIs.
Note: If it is necessary to exchange IPv4 NLRIs over an IPv6 connection, the IPv4 address family must be activated on the IPv6 neighbor. To do this for all IPv6 neighbors, use the command bgp default ipv4-unicast transport ipv6. For an individual neighbor, use the neighbor activate command for the IPv6 neighbor in the IPv4 address-family configuration mode as described below.
The activation state of an individual BGP neighbor address is configured by the neighbor activate command. The neighbor activate command overrides the address’s default activation state for the address family configuration mode in which the command is issued:
neighbor activate: the specified address is active.
no neighbor activate: the specified address is not active.
The default-default address family activation state defines the address family activation level of all addresses configured as BGP neighbors when running-config does not contain any bgp default commands. The default state of the BGP default activation level varies by address family.
ipv4 address family: all BGP addresses are IPv4 address family active.
ipv6 address family: all BGP addresses are not IPv6 address family active.
The default bgp default command restores the default-default activation setting for BGP neighbor addresses in the specified address family:
default bgp ipv4-unicast is equivalent to bgp ipv4-unicast.
default bgp ipv6-unicast is equivalent to no bgp ipv6-unicast.
The show active command does not display the bgp default ipv4-unicast command because it is the default setting for IPv4 peering sessions.
bgp default idle-restart-timer
The bgp default idle-restart-timer command in the BGP Router Configuration Mode allows a BGP peering session to automatically retry a connection after a configured time period.
The [no | default] versions of the command disable the feature and remove the configuration from the running-config.
bgp default idle-restart-timerestart_intervalseconds - Configure default idle restart timer for all neighbors in a BGP configuration. Specify the number of seconds from 60 to 4294967295.
Example
Use the following commands to configure an restart interval of 120 seconds:
The bgp enforce-first-as command causes a forced comparison of the first Autonomous System (AS) in the AS path of eBGP routes received from BGP neighbors to the configured remote external peer Autonomous System Number (ASN). Updates from eBGP peers that do not include that ASN as the first item in the AS path (in the AS_PATH attribute) are discarded.
This behavior is enabled by default upon BGP configuration, and disabled globally by the no form of this command. To configure first-AS enforcement for an individual neighbor or peer group, use the neighbor enforce-first-as command.
Command Mode
Router-BGP Configuration
Command Syntax
bgp enforce-first-as
default bgp enforce-first-as
no bgp enforce-first-as
Example
This command configures BGP to enforce the first AS globally.
The bgp listen range command identifies the BGP peering request from a range of IPv4 or IPv6 address, and names the dynamic peer group to which those peers belong to. To create a static peer group, use the neighbor peer group (create) command.
The request can be from a single AS number or from a range of AS numbers configured. To accept the peering request from single ASN use the remote-as option, and to accept request from multiple ASNs use the peer-filter option.
Members of a dynamic peer group are configured in groups and not as individuals. Once a new peer group is created with a group name, the group name is then used as an argument by the following neighbor commands:
The no bgp listen range and default bgp listen range commands remove the dynamic peer group by deleting the corresponding command from running-config. To remove a static peer group, use the no neighbor command. All peering relationships with group members are terminated when the dynamic peer group is deleted.
PEER-ID Additional specification for identifying a peer.
include Include following fields as part of peer identifier.
router-id Include router ID as part of peer identifier.
group_name name of the peer group.
as_number the autonomous system number, ranges from 1 to 4294967295.
filter_name name of the peer filter.
Examples
These commands create a dynamic peer group called brazil in AS 5 which accepts peering requests from the 192.168.6.0/24 subnet.
switch(config)# router bgp 1
switch(config-router-bgp)# bgp listen range 192.168.6.0/24 peer-group brazil remote-as 5
switch(config-router-bgp)#
These commands create a dynamic peer group called brazil in a range of AS numbers, which accepts peering requests from the 192.0.2.0/24 subnet. The range of AS numbers is defined by peer filter option.
switch(config)# router bgp 1
switch(config-router-bgp)# bgp listen range 192.0.2.0/24 peer-group brazil peer-filter group-1
switch(config-router-bgp)#
These commands enable the same address peering.
switch(config)# router bgp 1
switch(config-router-bgp)# bgp listen range 192.0.2.0/24 peer-id include router-id peer-group brazil peer-filter group-1
bgp log-neighbor-changes
The bgp log-neighbor-changes command configures the switch to generate a log message when a BGP peer enters or exits the established state. This is the default behavior.
The no bgp log-neighbor-changes command disables the generation of these log messages. The default bgp log-neighbor-changes command enables the generation of these log messages.
Command Mode
Router-BGP Configuration
Command Syntax
bgp log-neighbor-changes
no bgp log-neighbor-changes
default bgp log-neighbor-changes
Example
These commands configure the switch to generate a message when a BGP peer enters or exits the established state.
The bgp redistribute-internal command enables the redistribution of iBGP routes into an Interior Gateway Protocol (IGP).
The no bgp redistribute-internal command disables route redistribution from the specified domain by removing the corresponding bgp redistribute-internal command from running-config. The default bgp redistribute-internal command enables the redistribution of iBGP routes into an IGP.
The bgp rib bestpaths monitoring globally enables or disables exporting all Local Routing Information Bases (Loc_RIB) for all BGP VRFs in a BGP VRF configuration. By default, BGP exports all VRF Loc-RIBs to the stations configured to receive them.
Command Mode
Router-BGP-VRF Configuration
Command Syntax
bgp rib bestpaths monitoring [disabled]
Parameter
disabled - Disables the export to BGP VRFs.
Example
Use the following command to disable exporting Loc-RIB for VRF, blue, on BGP router, 64512:
The bgp rib received routes monitoring disabled allows filtering of Adjacency-RIB-In (Adj-RIB-In) exports for BGP Monitoring Protocol and prevents a VRF from exporting the Adj-RIB-In. Adj-RIB-In in BMP provides a view of the BGP routes received from neighbors before applying any local inbound policies.
Using the [no | default] changes the behavior back to the default behavior of exporting Adj-RIB-Ins from the VRF
Command Mode
Router BGP VRF Configuration
Command Syntax
bgp rib received routes monitoring disabled
no bgp rib received routes monitoring disabled
default bgp rib received routes monitoring disabled
Example
Use the following commands to disable exporting Adj-RIB-Ins from VRF, blue:
switch(config)# router bgp 64512
switch(config-router-bgp)# vrf blue
switch(config-router-bgp-vrf-blue)# bgp rib received routes monitoring disabled
bgp route install-map
The bgp route install-map command enables BGP Selective Route Download on the switch and allows the learning and advertising of the BGP routes without installing them in hardware.
The no bgp route install-map and default bgp route install-map commands delete the BGP Selective Route Download instance.
The exit command returns the switch to global configuration mode.
Command Mode
BGP Configuration
Command Syntax
bgp route install-mapmap_name
Parameter
map_name The name of the route map configured.
Example
These commands configure BGP Selective Route Download for test_BGP map.
The bgp route-reflector preserve-attributes command configures the switch, when operating as a BGP route reflector, to preserve the BGP attributes of re-advertised routes. By default, BGP attribute preservation is disabled. When attribute preservation is enabled, the BGP attributes (next-hop,local preference, and metric) are preserved in the reflected routes regardless of outbound BGP policies, except when those policies are part of an outbound route map. To override outbound route maps, use the always keyword.
The no bgp route-reflector preserve-attributes and default bgp route-reflector preserve-attributes commands disable BGP attribute preservation.
The following commands configure the switch as a route reflector and the neighbor at 10.5.2.1 as one of its clients, then configure the switch to preserve the BGP attributes of reflected routes unless overridden by an outbound route map policy.
This example clears the BGP Peer group Purple history from VRF_1.
switch# clear bgp Purple history vrf VRF_1
clear ip bgp
The clear ip bgp command removes learned BGP routes from the routing table, reads all routes from designated peers, and sends routes to those peers as required. This command can also clear the switch’s BGP sessions with its peers.
Routes that are read or sent are processed through modified route maps or AS-path access lists.
Command Mode
Privileged EXEC
Command Syntax
clear ip bgp [PEERS] [RESET_TYPE] [DATA_FLOW] [VRF_INSTANCE]
This command resets general statistics of all IPv4 and IPv6 peers in the context-active VRF.
switch# clear ip bgp counters
! Counters for all neighbors were reset
switch#
clear ip bgp errors
The clear ip bgp errors command resets the error statistics and history of peers. Peer general statistics primarily consist of notification errors, socket errors, and update errors.
This command resets the error statistics of all IPv4 and IPv6 peers in the context-active VRF.
switch# clear ip bgp errors
! Errors for all neighbors were reset
switch#
clear ip bgp neighbor
The clear ip bgp neighbor command clears BGP neighbors belonging to the IPv4 transport address family. To clear BGP neighbors in the IPv6 transport address family, use the clear ipv6 bgp neighbor command.
Command Mode
Privileged EXEC
Command Syntax
clear ip bgp neighbor [*] [vrfvrf_name] [reason
Parameters
* optional; all neighbors in the address family are cleared with or without this option
vrfvrf_name specifies a VRF instance for which IPv4 transport address family BGP neighbors will be cleared. If no VRF is specified, the command clears IPv4 BGP neighbors in the context-active VRF.
vrf all clears IPv4 BGP neighbors in all VRFs.
vrf default clears IPv4 BGP neighbors in the default VRF.
reasonmessage includes the specified message string in the notification sent to neighbors. Maximum string length 250 characters.
This command clears all IPv4 BGP neighbors in the context-active VRF.
switch# clear ip bgp neighbor
! Peerings for all ipv4 neighbors were hard reset
switch#
This command clears all IPv4 BGP neighbors in VRF purple.
switch# clear ip bgp neighbor vrf purple
! Peerings for all ipv4 neighbors were hard reset
switch#
clear ipv6 bgp
The clear ipv6 bgp command removes learned BGP routes from the routing table, reads all routes from designated peers, and sends routes to those peers as required. This command can also clear the switch’s BGP sessions with its peers.
Routes that are read or sent are processed through modified route maps or AS-path access lists.
This command resets general statistics of all IPv4 and IPv6 peers in the context-active VRF.
switch# clear ipv6 bgp counters
! Counters for all neighbors were reset
switch#
clear ipv6 bgp errors
The clear ipv6 bgp errors command resets the error statistics and history of peers. Peer general statistics primarily consist of notification errors, socket errors, and update errors.
This command resets the error statistics of all IPv4 and IPv6 peers in the context-active VRF.
switch# clear ipv6 bgp errors
! Errors for all neighbors were reset
switch#
clear ipv6 bgp neighbor
The clear ipv6 bgp neighbor command clears BGP neighbors belonging to the IPv6 transport address family. To clear BGP neighbors in the IPv4 transport address family, use the clear ip bgp neighbor command.
* optional; all neighbors in the address family are cleared with or without this option
vrfvrf_name specifies a VRF instance for which IPv6 transport address family BGP neighbors will be cleared. If no VRF is specified, the command clears IPv6 BGP neighbors in the context-active VRF.
vrf all clears IPv6 BGP neighbors in all VRFs.
vrf default clears IPv6 BGP neighbors in the default VRF.
reasonmessage includes the specified message string in the notification sent to neighbors. Maximum string length 250 characters.
The connection keepalive command checks on the health of the TCP connection with the BMP monitoring station. Since the router does not receive messages from the monitoring station, the station may become unavailable due to a power or link failure. Using a TCP Keepalive probe allows the router to quickly detect monitoring station connection loss.
Access this command in the Monitoring Station Configuration Mode.
idletimeseconds - Specify the duration in seconds that no messages occur on the connection before sending a probe packet to test the connection. Use a value between 1 and 86400 seconds.
probe-intervalseconds - Specify an interval in seconds between TCP Keepalive Probes. Use a value between 1 and 3600 seconds.
probe-countnum - Specify the number of Keepalive Probes before closing the connection.
Example
Use the following commands to add the idletime 6000, probe-interval 1800, and the probe count 500 to the BMP monitoring station, bmp_E:
The connection mode command configures TCP connection parameters for a BMP monitoring station. Access this command in the Monitoring Station Configuration Mode.
active portport_number - Specify an active mode connection to allow the BGP router to initiate a TCP connection to the BMP monitoring station. port_number - Specify a TCP port that listens for connections to the BMP monitoring station.
reconnect-timertimer_value - Configure the BGP monitoring session reconnect timer.
connection modepassive - Specify a passive mode connection to allow the BGP router to listen for TCP connections from BMP monitoring stations.
Examples
Use the following commands to configure a monitoring station, bmp_D with an active mode connection with port 5000:
switch(config)# router bgp 64512
switch(config-router-bgp)# monitoring bgp
switch(config-router-bgp)# monitoring station bmp_D
switch(config-router-bgp-monitoring-station-bmp_D)# connection mode active port 5000
Use the following commands to configure a monitoring station, bmp_E with a passive mode connection:
The description command adds a description of the BMP monitoring station to display in the show bgp station output. Access this command in the Monitoring Station Configuration Mode.
Command Mode
Monitoring Station Configuration
Command Syntax
descriptiontext
Parameters
text - Assign a description to the BGP monitoring station.
Example
Use the following commands to add the description, remote office location Seattle to the bmp_E:
The distance bgp command assigns an administrative distance to routes that the switch learns through BGP. Routers use administrative distances to select a route when two protocols provide routing information to the same destination. Distance values range from 1 to 255; lower distance values correspond to higher reliability. BGP routing tables do not include routes with a distance of 255.
The distance command assigns distance values to external, internal, and local BGP routes:
external: Best-path routes learned from a neighbor external to the autonomous system. Default distance is 200.
internal: Internal routes are routes learned from a BGP entity within the same autonomous system. Default distance is 200.
local: Local routes are networks listed with a network router configuration command for that router or for networks that are redistributed from another process. Default distance is 200.
The no distance bgp and default distance bgp commands restore the default administrative distances by removing the distance bgp command from running-config.
Command Mode
Router-BGP Configuration
Command Syntax
distance bgpexternal_dist [INTERNAL_LOCAL]
no distance bgp
default distance bgp
Parameters
external_dist distance assigned to external routes. Values range from 1 to 255.
INTERNAL_LOCAL distance assigned to internal and local routes. Values for both routes range from 1 to 255. Options include:
no parameter the external_dist value is also assigned to internal and local routes.
internal_distlocal_dist values assigned to internal and local routes.
Example
This command assigns an administrative distance of 150 to external routes, 200 to internal, and 150 to local routes.
The dynamic peer max command limits the number of dynamic BGP peers allowed on the switch.
The no dynamic peer max and default dynamic peer max commands restore the default limit of dynamic BGP peers by removing the dynamic peer max command from running-config.
Command Mode
Router-BGP Configuration
Command Syntax
dynamic peer maxmaximum
no dynamic peer max
default dynamic peer max
Parameter
maximum the maximum number of dynamic BGP peers to be allowed on the switch. Values range from 1 to 2147483647 with a default value of 1000.
Example
This command sets the maximum number of dynamic BGP peers allowed on the switch to 200.
switch(config)# router bgp 1
switch(config-router-bgp)# dynamic peer max 200
switch(config-router-bgp)#
export-policy received routes
The export-policy command configures the BMP monitoring station to receive additional paths advertisements from BGP peers.
Command Mode
Monitoring Station Configuration Mode
Command Syntax
export-policy received routesadditional-paths [post-policy | pre-policy]
Parameters
additional-paths - Specify per station status of parsing additional paths.
post-policy - Export BGP routes after input policies applied.
pre-policy - Export BGP routes before input policies applied.
Examples
Use the following commands to receive additional paths on BMP monitoring station, bmp_E:
switch(config)# router bgp 64512
switch(config-router-bgp)# monitoring bgp
switch(config-router-bgp)# monitoring station bmp_E
switch(config-router-bgp-monitoring-station-bmp_E)# export-policy received routes additional-paths
Use the following commands to export routes after applying input policies on BMP monitoring station, bmp_E:
switch(config)# router bgp 64512
switch(config-router-bgp)# monitoring bgp
switch(config-router-bgp)# monitoring station bmp_E
switch(config-router-bgp-monitoring-station-bmp_E)# export-policy received routes post-policy
graceful-restart stalepath-time
The graceful-restart stalepath-time command specifies the maximum time that stale routes from a restarting BGP neighbor will be retained after a BGP session is re-established with that peer.
The no graceful-restart stalepath-time and default graceful-restart stalepath-time commands restore the default value of 300 seconds by deleting the graceful-restart stalepath-time statement from running-config.
Command Mode
Router-BGP Configuration
Command Syntax
graceful-restart stalepath-timeinterval
no graceful-restart stalepath-time
default graceful-restart stalepath-time
Parameter
interval Maximum period (in seconds) that stale routes from a restarting BGP neighbor will be retained after the BGP session is re-established. Values range from 1 to 3600 (60 minutes). Default is 300.
Example
These commands configure the stale path retention interval to 15 minutes.
The graceful-restart helper command enables BGP graceful restart helper mode on the switch for all BGP neighbors. When graceful restart helper mode is enabled, the switch will retain routes from neighbors which are capable of graceful restart while those neighbors are restarting BGP. Graceful restart helper is enabled by default. To configure graceful restart helper mode for a specific neighbor or peer group, use the neighbor graceful-restart-helper command. Individual neighbor configuration takes precedence over the global configuration.
The no graceful-restart helper command disables graceful restart helper mode on the switch. The default graceful-restart helper command enables graceful restart helper mode by removing the corresponding no graceful-restart helper command from running-config.
Command Mode
Router-BGP Configuration
Command Syntax
graceful-restart helperlong-lived
no graceful-restart helper long-lived
default graceful-restart helper long-lived
Parameter
long-lived Enables long lived graceful restart helper mode.
Example
These commands disable graceful restart helper mode on the switch.
switch(config)# router bgp 1
switch(config-router-bgp)# no graceful-restart-helper
switch(config-router-bgp)#
interface-set count
The interface-set count command supports BGP Flowspec Interface-set Extended Community and allows BGP Flowspec rules to be selectively applied to sets of forwarding interfaces sharing a common group identifier.
The [no |default] interface-set count commands disable the feature.
interface-set count limit - Configure the interface-set count limit.
1023 - Limit to 1023 interface-sets.
127 - Limit to 127 interface-sets
15 - Limit to 15 interface-sets
2047 - Limit to 2047 interface-sets
255 - Limit to 255 interface-sets
3 - Limit to 3 interface-sets
31 - Limit to 31 interface-sets
511 - Limit to 511 interface-sets
63 - Limit to 63 interface-sets
7 - Limit to 4 interface-sets
Example
Use the following commands to limit the interface sets to 7:
ip as-path access-list
The ip as-path access-list command creates an access list to filter BGP route updates. If access list list_name does not exist, this command creates it. If it already exists, this command appends statements to the list.
The no ip as-path access-list and default ip as-path access-list commands delete the named access list.
Command Mode
Global Configuration
Command Syntax
ip as-path access-listlist_nameFILTER_TYPEregexORIGIN
no ip as-path access-listlist_name
default ip as-path access-listlist_name
Parameters
list_name the name of the AS path access list.
FILTER_TYPE access resolution of the specified AS path. Options include:
permit access is permitted.
deny access is denied.
regex a regular expression describing the AS path being filtered. Regular expressions are pattern-matching strings that are composed of text characters and operators.
ORIGIN the origin of the path information. Values include:
no parameter sets the origin to any.
any any BGP origin.
egp EGP origin.
igp IGP origin.
incomplete incomplete origin.
Example
These commands create an AS path access list named list1 which allows all BGP routes except those originating in AS 3.
switch(config)# ip as-path access-list list1 deny _3$
switch(config)# ip as-path access-list list1 permit .*
switch(config)#
ip as-path regex-mode
The ip as-path regex-mode command specifies how the switch will evaluate regular expressions describing AS paths in ACLs. When the regex mode is set to asn, AS numbers in the ACL are interpreted as AS numbers; only complete AS number matches in the AS path return a match. When it is set to string, AS numbers in the ACL are interpreted as strings; both complete AS number matches and longer AS numbers that include the target string return a match. The default mode is asn.
For example, asn mode returns as false and the string mode returns as true when searching for “10 in an AS path of 100 200.
The no ip as-path regex-mode and default ip as-path regex-mode commands restore the regex mode to asn by removing the ip as-path regex-mode command from running-config.
Command Mode
Global Configuration
Command Syntax
ip as-path regex-modeMODE_SETTING
no ip as-path regex-mode
default ip as-path regex-mode
Parameters
MODE_SETTING Specifies how regular expressions describing AS paths in AS path ACLs will be evaluated. Options include:
asn AS numbers in the ACL are interpreted as AS numbers; only complete AS number matches in the AS path return a match.
string AS numbers in the ACL are interpreted as strings; both complete AS number matches and longer AS numbers that include the target string return a match.
Example
This command sets the regex mode to string.
switch(config)# ip as-path regex-mode string
switch(config)#
ip community-list
The ip community-list command creates and configures a BGP access list based on BGP communities.
The no ip community-list and default ip community-list commands delete the specified community list by removing the corresponding ip community-list command from running-config.
Command Mode
Global Configuration
Command Syntax
ip community-listlist_name [permit | deny] [GSHUT | aa:nn | internet | local-as | no-advertise | no-export | number]
no ip community-listlist_name
default ip community-listlist_name
Parameters
list_name name of the community list. Valid input is text.
permit permits access to the specified community.
deny denies access to the specified community.
Note: The deny statements are ignored for all set community/extcommunity/large-community operations.
GSHUT well-known graceful shutdown community.
aa:nn AA is 65535 and NN specifies the community number (0-65535) within the AS.
internet advertises route to the Internet community.
local-as advertises route only to local peers.
no-advertise does not advertise route to any peer.
no-export advertises route only within BGP AS boundary.
number community number. Values ranges from 0 to 4294967040.
EOS does not support disabling the process of graceful shutdown community.
Note: The ip community-list command with the permitinternet option permits access to all routes associated with any community.
Examples
This command creates a BGP community list (named list_9) that does not match members of route maps configured with AS-network number 100:250.
switch(config)# ip community-list list_9 deny 100:250
switch(config)#
These commands create a BGP community list that permits the graceful shutdown community, then use that list it in a route map to permit routes with that community.
switch(config)# ip community-list gshut_list permit GSHUT
switch(config)# route-map map1
switch(config-route-map-map1)# match community gshut_list
switch(config-route-map-map1)# exit
switch(config)# show route-map map1
route-map map1 permit 10
Description:
Match clauses:
match community gshut_list
SubRouteMap:
Set clauses:
switch(config)#
This command permits access to all routes associated with the BGP community list (CLIST1).
switch(config)# ip community-list CLIST1 permit internet
switch(config)#
ip community-list regexp
The ip community-list regexp command creates and configures a BGP access list based on BGP communities. A BGP community access list filters prefixes based on their BGP communities. The command uses regular expressions to identify the communities specified by the list. To create a community list by explicitly specifying one or more communities, use the ip community-list command.
The no ip community-list regexp and default ip community-list regexp commands delete the specified community list. To delete a specific community-list entry, specify the entry in the no ip community-list regexp command.
Command Mode
Global Configuration
Command Syntax
ip community-list regexplist_name {deny | permit} reg_exp
no ip community-list regexplist_name {deny | permit} reg_exp
default ip community-list regexplist_name
Parameters
list_name name of the community list. Valid input is text.
permit access is permitted for the specified community.
deny access is denied for the specified community.
Note: The deny statements are ignored for all set community/extcommunity/large-community operations.
reg_exp list of communities, formatted as a regular expression. Regular expressions are pattern-matching strings that are composed of text characters and operators.
Note: When using the no form of the command, a regular expression can be used to specify a single entry to be removed from the list, leaving the rest of the list intact. If no entry is specified, the no form of the command removes the entire list.
The ip community-list regexp command with the permit internet option permits access to only those routes that carry the community value of 0.
Examples
This command creates a BGP community list that permits routes from networks 20-24 and 30-34 in autonomous system 10.
switch(config)# ip community-list regexp list_2 permit 10:[2-3][0-4]_
switch(config)#
This command removes the above statement from the community list named list_2, leaving any other statements in the list intact.
switch(config)# no ip community-list regexp list_2 permit 10:[2-3][0-4]_
switch(config)#
This command deletes the community list named list_2 entirely.
switch(config)# no ip community-list regexp list_2
switch(config)#
This command permits access to all routes associated with the BGP community list (CLIST1) that carry the community value 0.
switch(config)# ip community-list regexp CLIST1 permit internet
switch(config)#
ip extcommunity-list
The ip extcommunity-list command creates an extended community list to filter VRF routes or for Link BandWidth (LBW) advertisement.
The following extcommunity-list types are supported:
Route Target (RT) identifies sites that may receive appropriately tagged routes.
Site of Origin (SoO) identifies sites where the switch learned the route.
Link Bandwidth (LBW) advertises BGP link bandwidth.
The no ip extcommunity-list and default ip extcommunity-list commands delete the specified extended community list by removing the corresponding ip extcommunity-list statement from running-config.
Command Mode
Global Configuration
Command Syntax
ip extcommunity-listlist_name {deny | permit} COMM_1 [COMM_2...COMM_n]
no ip extcommunity-listlist_name
default ip extcommunity-listlist_name
Parameters
list_name name of the extended community list.
deny access is denied for the specified community.
permit access is permitted for the specified community.
COMM_x extended community attribute. Options include:
rtaa:nn route target, as specified by autonomous system:network number.
rtip_addr:nn route target, as specified by ip address:network number.
sooaa:nn Site of Origin, as specified by autonomous system:network number.
sooip_addr:nn site of origin, as specified by ip address:network number.
This command creates a BGP extended community list that denies routes from route target 100:250.
switch(config)# ip extcommunity-list list_9 deny rt 100:250
switch(config)#
ip extcommunity-list regexp
The ip extcommunity-list regexp command creates an extended community list to filter VRF routes or for link bandwidth (LBW) advertisement. The command uses regular expressions to define the extended communities specified by the list. To specify particular values, use the ip extcommunity-list command.
The following extcommunity-list types are supported:
Route Target (RT) identifies sites that may receive appropriately tagged routes.
Site of Origin (SoO) identifies sites where the switch learned the route.
Link Bandwidth (LBW) advertises BGP link bandwidth.
The no ip extcommunity-list regexp and default ip extcommunity-list regexp commands delete the specified extended community list by removing the corresponding ip extcommunity-list regexp statement from running-config.
Command Mode
Global Configuration
Command Syntax
ip extcommunity-list regexplist_name {deny | permit} reg_exp
no ip extcommunity-list regexplist_name {deny | permit} reg_exp
default ip extcommunity-list regexplist_name
Parameters
list_name name of the extended community list. Valid input is text.
deny access is denied for the specified extended community list.
Note: The deny statements are ignored for all set community/extcommunity/large-community operations.
permit access is permitted for the specified extended community list.
reg_exp list of communities, formatted as a regular expression. Regular expressions are pattern-matching strings that are composed of text characters and operators.
Expressions beginning with RT: match the route target extended community attribute option.
Expressions beginning with SoO: match the site of origin extended community attribute option.
This command creates a BGP extended community list that denies routes from route target networks 20-24 and 30-34 in autonomous system 10.
switch(config)# ip extcommunity-list regexp list_1 deny RT:10:[2-3][0-4]_
switch(config)#
ip large-community-list regexp
The ip large-community-list regexp command creates and configures a BGP access list based on BGP large communities. A BGP large-community access list filters prefixes based on their BGP large community values. The command uses regular expressions to match large communities. Multiple large-community lists with the same name may be specified. To create a large-community list by explicitly specifying one or more communities, use the ip large-community-list command.
Large-communities are represented as follows: [ASN]:local-part1:local-part2.
The no ip large-community-list regexp and default ip large-community-list regexp commands delete the specified large community list. To delete a specific community-list entry, specify the entry in the no ip large-community-list regexp command.
Command Mode
Global Configuration
Command Syntax
ip large-community-list regexplist_name {deny | permit} reg_exp
no ip large-community-list regexplist_name {deny | permit} reg_exp
default ip large-community-list regexplist_name
Parameters
list_name name of the community list. Valid input is text.
deny access is denied for the specified community.
Note: The deny statements are ignored for all set community/extcommunity/large-community operations.
permit access is permitted for the specified community.
reg_exp list of communities, formatted as a regular expression. Regular expressions are pattern-matching strings that are composed of text characters and operators.
Note: When using the no form of the command, a regular expression can be used to specify a single entry to be removed from the list, leaving the rest of the list intact. If no entry is specified, the no form of the command removes the entire list.
This command creates a BGP large community list that permits routes from autonomous system 10 with local-part1 value of 20-24 or 30-34.
switch(config)# ip large-community-list regexp list_2 permit 10:[2-3][0-4]:_
switch(config)#
This command removes the above statement from the large community list named list_2, leaving any other statements in the list intact.
switch(config)# no ip large-community-list regexp list_2 permit 10:[2-3]:[0-4]_
switch(config)#
This command deletes the large community list named list_2 entirely.
switch(config)# no ip large-community-list regexp list_2
switch(config)#
match as-range
The match as-range command defines the match statement for the peer-filter, based on the match statement the peer-filter accept or reject the incoming peer request. The match statement includes a sequence number, AS number range and a match condition to accept or reject a peer by comparing its remote AS number to the specified range. A peer filter can consist of a single match statement or multiple match statements. The match statement for the peer filter is configured under peer-filter configuration mode.
The no match as-range or default match as-range command deletes the peer-filter condition for the group from running-config.
Command Mode
Peer-Filter Configuration
Command Syntax
[sequence_number] match as-range [as_number1] [as_number2] result {accept | reject} group_name
nomatch as-range [as_number1] [as_number2] result {accept | reject} group_name
defaultmatch as-range [as_number1] [as_number2] result {accept | reject} group_name
Parameters
sequence_number optional sequence number for the match statement; one is automatically created if not assigned. Values range from 0 to 65535.
group_name name of the peer filter group.
as_number the autonomous system number, values range from 1 to 4294967295.
Examples
These commands define a peer filter that accepts any AS number.
switch(config)# peer-filter group1
switch(config-peer-filter-group1)# 10 match as-range 1-4294967295 result accept
switch(config-peer-filter-group1)#
These commands define a peer filter that accepts any AS number within 65000 and 65100 (inclusive) except 65008 and 65009.
switch(config)# peer-filter group2
switch(config-peer-filter-group2)# 10 match as-range 65008-65009 result reject
switch(config-peer-filter-group2)# 20 match as-range 65000-651000 result accept
switch(config-peer-filter-group2)#
These commands define a peer filter that accepts three specific remote AS numbers.
switch(config)# peer-filter group3
eswitch(config-peer-filter-group3)# 10 match as-range 65003 result accept
switch(config-peer-filter-group3)# 20 match as-range 65007 result accept
switch(config-peer-filter-group3)# 30 match as-range 65009 result accept
switch(config-peer-filter-group3)#
maximum-paths (BGP)
The maximum-paths command controls the maximum number of parallel BGP routes that the switch supports. The default maximum is one route. The command provides an Equal Cost Multiple Paths (ECMP) parameter that controls the number of equal-cost paths that the switch stores in the routing table for each route.
For paths to be consider equal, they must have the same weight, local preference, AS-path length, and origin. To require that they also have the same Mmulti-Exit Discriminator (MED) value, use the bgp always-compare-med command. To require that their AS paths have the same contents, use the bgp bestpath as-path multipath-relax command.
The no maximum-paths and default maximum-paths commands restore the default values of the maximum number of parallel routes and the maximum number of ECMP paths by removing the corresponding maximum paths command from running-config.
Command Mode
Router-BGP Configuration
Command Syntax
maximum-pathspaths [ecmpecmp_paths]
no maximum-paths
default maximum-paths
Parameters
paths maximum number of parallel routes. Default value is 1. Value must be less than or equal to the maximum number of ECMP paths.
ecmp_paths maximum number of ECMP paths for each route. Default is maximum value as defined belows.
Value for each parameter ranges from 1 to the number of interfaces available per ECMP group, which is platform dependent.
Arad: Values range from 1 to 128. Default value is 128.
FM6000: Values range from 1 to 32. Default value is 32.
PetraA: Values range from 1 to 16. Default value is 16.
Trident: Values range from 1 to 32. Default value is 32.
Trident II: Values range from 1 to 128. Default value is 128.
Examples
These commands configure the maximum number of BGP parallel paths to 12 without changing the ECMP value.
The monitoring bgp rib bestpaths command configures exporting the BGP Local RIB to all monitoring stations. By default, BMP disables exporting Local RIB for all monitoring stations on all VRFs. Enable exporting the Local RIB per station or per VRF. You must configure the router ID for BGP and the RD for a non-default VRF. BMP exports IPv4 and IPv6 Unicast routes into the Local RIB including imported VPN routes. Use the disable parameter to explicitly disable the feature. BMP disables exporting the BGP Local RIB feature by default.
Command Mode
Router BGP Monitoring Configuration Mode
Router BGP Monitoring Station Configuration Mode
Router BGP VRF Configuration Mode
Command Syntax
monitoring bgp rib bestpaths
monitoring bgp rib bestpaths disable
Parameter
disable - Explicitly disable the feature.
Example
Use the following commands to explicitly disable best paths selection globally:
The monitoring port command configures a port number for stations in passive mode. The no | default removes the configuration from the running-config on the switch.
Command Mode
Router-BGP-Monitoring Configuration Mode
Command Syntax
monitoring portport_number
Parameter
port_number - Configure a port number from 1024 to 65535.
Example
Use the following command to enter Router BGP Monitoring Configuration Mode on the switch and configure port 5000:
The monitoring received command configures the BGP router to advertise pre-policy and post-policy routes to a BMP monitoring station. The no version of the command disables the route advertisement.
Command Mode
Router-BGP-Monitoring Configuration Mode
Command Syntax
monitoring received routes [pre-policy | post-policy]
no monitoring received routes [pre-policy | post-policy]
Parameters
[pre-policy | post-policy] - Specify to advertise pre-policy and post-policy routes to a BMP monitoring station.
pre-policy - BGP routes received directly from peer BGP routers.
post-policy - BGP routes that remain after applying routing policies to the BGP router.
Example
Use the following command to enter Router BGP Monitoring Configuration Mode on the switch and configure the BGP router to send post-policy routes:
The monitoring station command configures a name for the BMP monitoring station and places the switch in Monitoring Switch Configuration Mode. A monitoring station must be configured to enable exporting BGP received paths.
Command Mode
Router-BGP Configuration Mode
Command Syntax
monitoring stationstation_name
Parameter
station_name - Configure a name for the BMP monitoring station.
Example
Use the following commands to configure a monitoring station, bmp_D:
The monitoring statistics command generates statistics counters for BMP and disabled by default for all monitoring stations. In the Monitoring Station Configuration Mode, configure statistics on individual monitoring stations.
The [no | default] versions of the command returns to the default interval of 30 seconds.
Command Mode
Router-BGP Configuration Mode
Command Mode
Router-BGP Configuration Mode
Monitoring Station Configuration Mode
Command Syntax
monitoring statistics [intervalinterval_seconds]
Parameters
intervalinterval_seconds - Specify an interval for sending statistics reports in seconds. Select an interval between 15 to 3600 seconds. The default value uses 30 seconds.
Note: The interval can only be configured in the Router-BGP Configuration Mode. Individual monitoring stations use this value.
Examples
To configure statistics reporting globally and set the interval to 1800 seconds, use the following commands:
The monitoring timestamp command sets the timestamp in BMP Route Monitoring messages to zero or the time of message construction. The timestamp may not be equal to the time when the BGP peer received the BGP paths in the message. The timestamp defaults to send-time unless specifically configured to none
Command Mode
Router-BGP Configuration Mode
Command Syntax
monitoring timestamp [send-time | none]
Parameters
send-time - Specify to use the time that BMP sends the Route Monitoring message.
none - Specify to set the timestamp to zero.
Example
Use the following commands to set the timestamp to zero:
Use the neighbor command to enable large communities on a ‘per-neighbor’ or ‘per-peer group’ basis. This behavior is consistent with all other forms of communities supported by EOS.
EOS enables receiving and processing of large communities by default.
interface Interface range to be used for BGP session establishment.
Example
You can enable large communities on a ‘per-neighbor’ or ‘per-peer group’ basis.
switch(config)# router bgp 1
switch(config-bgp-router)# neighbor 1.1.1.1 send-community large
neighbor activate
The neighbor activate command defines the configuration mode address family activation state of a specified address that is configured as a BGP neighbor. The switch sends the following announcements to addresses active in an address family:
IPv4 address family: IPv4 capability and all network advertisements with IPv4 prefixes.
IPv6 address family: IPv6 capability and all network advertisements with IPv6 prefixes.
The bgp default command configures the default address family activation state of addresses configured as BGP neighbors. The neighbor activate and no neighbor activate commands override the neighbor’s default activation state within the address family configuration mode.
neighbor activate: the specified address is active in the address family.
no neighbor activate: the specified address is not active in the address family.
The default neighbor activate command removes the corresponding neighbor activate or no neighbor activate command from running-config, restoring the default address family activation state for the specified neighbor address.
Command Mode
Router BGP Address-Family Configuration
Command Syntax
neighborneighbor_IDactivate
no neighborneighbor_IDactivate
default neighborneighbor_IDactivate
Parameter
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
Limitations
The switch supports the advertisement of networks with IPv6 prefixes to IPv4 transport neighbors. The switch does not support the advertisement of networks with IPv4 prefixes to IPv6 transport neighbors.
Example
These commands activate the advertising of specified neighbors during IPv4 peering sessions, then display the result.
switch(config)# router bgp 1
switch(config-router-bgp)# no address-family ipv4
switch(config-router-bgp-af)# neighbor 172.41.18.15 activate
switch(config-router-bgp-af)# neighbor 172.49.22.6 activate
switch(config-router-bgp-af)# no neighbor 172.15.21.18 activate
switch(config-router-bgp-af)# show active
address-family ipv4
no neighbor 172.15.21.18 activate
neighbor 172.49.22.6 activate
neighbor 172.41.18.15 activate
switch(config-router-bgp-af)# exit
switch(config-router-bgp)#
neighbor allowas-in
By default, BGP drops received routes if their Autonomous System (AS) paths contain the AS Number (ASN) of the switch. The neighbor allowas-in command configures the switch to accept routes from the specified BGP neighbor even if their AS paths contain the ASN of the switch. Optionally, the command can also configure the maximum number of times that the switch’s ASN can appear in a route before dropping it.
The no neighbor allowas-in command configures the default behavior (dropping BGP routes that contain the ASN of the switch).
The default neighbor allowas-in command applies the system default configuration for individual neighbors and applies the peer group’s setting for neighbors that are members of a peer group.
The no neighbor command removes all configuration commands for the BGP neighbor at the specified address.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDallowas-in [asn_quantity]
no neighborneighbor_IDallowas-in
default neighborneighbor_IDallowas-in
Parameters
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
asn_quantity number of repetitions of the switch’s ASN allowed in the AS path of routes received from the specified BGP neighbor. Values range from 1 to 10. Default is 3.
Related Commands
This command is used on a customer edge router that is part of a split AS; to address the problem at the provider end, use the neighbor as-path remote-as replace out command.
Example
These commands configure the switch to accept routes from the BGP neighbor at 192.168.1.30 which contain the switch’s ASN in their AS paths as many as three times.
By default, BGP drops received routes if their Autonomous System (AS) paths contain the AS Number (ASN) of the switch. In a split AS sharing route advertisements through a provider network, this can result in valid routes being dropped. The neighbor as-path remote-as replace out command configures a provider edge switch to replace the customer’s AS with its own in route advertisements sent to neighbors in that AS.
The no neighbor as-path remote-as replace out command configures the default behavior (leaving the customer’s AS in the AS path attribute of routes advertised to the specified neighbor).
The default neighbor as-path remote-as replace out command applies the system default configuration for individual neighbors and applies the peer group’s setting for neighbors that are members of a peer group.
The no neighbor command removes all configuration commands for the BGP neighbor at the specified address.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDas-path remote-as replace out
no neighborneighbor_IDas-path remote-as replace out
default neighborneighbor_IDas-path remote-as replace out
Parameter
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
Related Commands
This command is used on a provider edge router forwarding BGP routes to a customer in a split AS; to address the problem at the customer end, use the neighbor allowas-in command.
Example
These commands configure the switch to substitute a local ASN for the ASN of the BGP neighbor at 192.168.2.15 in BGP routes advertised to that neighbor.
The neighbor auto-local-addr command configures the switch to automatically determine the local address to be used for the non-transport address family in NLRIs sent to the specified neighbor or peer group. This allows IPv4 NLRIs to be carried over IPv6 transport, or IPv6 NLRIs to be carried over IPv4 transport.
The no neighbor auto-local-addr command applies the system default configuration.
The default neighbor auto-local-addr command applies the system default configuration for individual neighbors, and applies the peer group’s setting for neighbors that are members of a peer group.
Note: While this feature works well in eBGP deployments with directly connected pairing routers and have matching IP address configurations, multi-hop eBGP or iBGP deployments may require manual local address configuration.
To explicitly configure a local address for the non-transport address family for a specific neighbor or peer group, use the neighbor local-v4-addr command for IPv6 neighbors, or the neighbor local-v6-addr for IPv4 neighbors.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDauto-local-addr
no neighborneighbor_IDauto-local-addr
default neighborneighbor_IDauto-local-addr
Parameter
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
Example
For the IPv6 neighbor at 2001:0DB8:c2a4:1761::2, these commands configure the switch to automatically determine the IPv4 NLRI value to be sent during peering sessions.
The neighbor default-originate command advertises a default route to a BGP neighbor or peer group. This default route overrides the default route advertised by any other means to the specified neighbor or peer group. However, the update generated by neighbor default-originate is not processed by neighbor route map out policies.
If a route map is specified in this command, its set clauses are used to modify attributes of the exported default route, but its match clauses are not used to conditionally advertise the route. The default route is always advertised to the specified neighbor.
The no neighbor default-originate command applies the system default configuration.
The default neighbor default-originate command applies the system default configuration for individual neighbors and applies the peer group’s setting for neighbors that are members of a peer group.
The no neighbor command removes all configuration commands for the neighbor at the specified address.
The neighbor description command associates descriptive text with the specified peer or peer group.
The no neighbor description command removes the text association from the specified peer or peer group.
The default neighbor description command removes the text association from the specified peer for individual neighbors, and applies the peer group’s description to neighbors that are members of a peer group.
The no neighbor command removes all configuration commands for the neighbor at the specified address or for the specified peer group.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDdescriptiondescription_string
no neighborneighbor_IDdescription
default neighborneighbor_IDdescription
Parameters
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
description_string text string to be associated with the neighbor or peer group.
Example
These commands associate the string PEER_1 with the peer located at 192.168.1.30.
The neighbor ebgp-multihop command programs the switch to accept and attempt BGP connections to the external peers residing on networks not directly connected to the switch. The command does not establish the multihop if the only route to the peer is the default route (0.0.0.0).
The no neighbor ebgp-multihop command applies the system default configuration.
The default neighbor ebgp-multihop command applies the system default configuration for individual neighbors, and applies the peer group’s setting for neighbors that are members of a peer group.
The no neighbor command removes all configuration commands for the neighbor at the specified address.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDebgp-multihop [hop_number]
no neighborneighbor_IDebgp-multihop
default neighborneighbor_IDebgp-multihop
Parameters
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
hop_number time-to-live (hops). Values range from 1 to 255. Default value is 255.
Example
These commands configure the switch to accept and attempt BGP connections to the external peer located at 192.168.1.30, setting the hop limit to 32.
The neighbor enforce-first-as command causes a forced comparison of the first Autonomous System (AS) in the AS path of eBGP routes received from a specified BGP peer or peer group to the configured remote external peer Autonomous System Number (ASN). Updates from the specified eBGP peers that do not include an ASN as first AS path (in the AS_PATH attribute) are discarded.
This behavior is enabled globally by default upon BGP configuration, and disabled for the specified neighbor or peer group by the no form of the command. To configure first AS enforcement globally, use the bgp enforce-first-as command.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDenforce-first-as
no neighborneighbor_IDenforce-first-as
default neighborneighbor_IDenforce-first-as
Parameter
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
Example
This command disables enforcement of the first BGP AS for the neighbors in peer group region-3.
switch(config-router-bgp)# no neighbor region-3 enforce-first-as
switch(config-router-bgp)#
neighbor export-localpref
The neighbor export-localpref command determines the LOCAL_PREF value that is sent in BGP UPDATE packets to the specified peer or peer group. This command has no effect on external peers.
The no neighbor export-localpref command resets the LOCAL_PREF value to the system default of 100 in packets sent to the specified peer or peer group.
The default neighbor export-localpref command resets the LOCAL_PREF value to the system default of 100 for individual neighbors, and applies the peer groups’s setting for neighbors that are members of a peer group.
The no neighbor command removes all configuration commands for the neighbor at the specified address or the specified peer group.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDexport-localprefpreference
no neighborneighbor_IDexport-localpref
default neighborneighbor_IDexport-localpref
Parameters
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
preference preference value. Values range from 0 to 4294967295.
Example
This command configures the switch to fill the LOCAL_PREF field with 200 in UPDATE packets that it sends to the peer located at 10.1.1.45.
The neighbor graceful-restart command enables the BGP graceful restart mode for a specified BGP neighbor or peer group. When graceful restart mode is enabled, the switch retains routes from neighbors that are capable of graceful restart. By default, graceful restart is disabled for all BGP neighbors. Individual neighbor configuration takes precedence over the global configuration.
The no neighbor graceful-restart and default neighbor graceful-restart commands disable graceful restart mode for the specified BGP neighbor or peer group by removing the corresponding no neighbor graceful-restart command from running-config.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDgraceful-restart
no neighborneighbor_IDgraceful-restart
default neighborneighbor_IDgraceful-restart
Parameter
neighbor_ID neighbors’s IPv4 or IPv6 address or peer group name.
Example
This command enables BGP graceful restart mode for the neighbor with the IP address 192.168.12.1.
The neighbor graceful-restart helper command enables BGP graceful restart helper mode for the specified BGP neighbor or peer group. When graceful restart helper mode is enabled, the switch will retain routes from neighbors which are capable of graceful restart while those neighbors are restarting BGP. The neighbor graceful-restart-helper is enabled by default for all BGP neighbors. To configure graceful restart helper mode for all BGP neighbors, use the graceful-restart-helper command. Individual neighbor configuration takes precedence over the global configuration.
The no neighbor graceful-restart helper command disables graceful restart helper mode for the specified BGP neighbor or peer group. The default neighbor graceful-restart helper command enables graceful restart helper mode for the specified BGP neighbor or peer group by removing the corresponding no neighbor graceful-restart helper command from running-config.
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
long-lived Enables long lived graceful restart helper mode.
Example
These commands disable graceful restart helper mode for the neighbor at 192.168.12.1.
switch(config)# router bgp 1
switch(config-router-bgp)# no neighbor 192.168.12.1 graceful-restart-helper
switch(config-router-bgp)#
neighbor idle-restart-timer
The neighbor idle-restart-timer command in the BGP Router Configuration Mode allows a BGP peering session to automatically retry a connection after a configured time period, and prevents routing loops and CPU exhaustion by constantly flapping links.
The [no | default] versions of the command disable the feature and remove the configuration from the running-config.
ipv4_address - Specify an IPv4 address for a neighbor.
ipv6_address - Specify an IPv6 address for a neighbor.
name - Specify the name of a peer group.
default - Apply to all neighbors.
fe80::A:B:C:D - Specify the neighbor IPv6 link-local address.
interfaceinterface_range - Specify an interface range used to establish BGP sessions.
idle-restart-timerseconds - Specify the time to wait before attempting to retry a session. Use a value between 60 and 4294967295 seconds with a default value of 300 seconds.
Example
Use the following commands to establish a timer of 360 seconds on neighbor 172.16.23.45 for BGP 300:
The neighbor import-localpref command determines the local preference assigned to routes received from the specified external peer or peer group. This command has no effect on routes received from internal peers.no neighbor import-localpref
The command resets the local preference to the default of 100 for routes received from the specified peer or peer group.
The default neighbor import-localpref command resets the local preference to the default of 100 for individual neighbors, and applies the peer group’s setting for neighbors that are members of a peer group.
The no neighbor command removes all configuration commands for the neighbor at the specified address.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDimport-localprefpreference
no neighborneighbor_IDimport-localpref
default neighborneighbor_IDimport-localpref
Parameters
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
preference preference value. Values range from 0 to 4294967295.
Example
These commands configure the switch to assign a local preference of 50 to routes received from the peer located at 192.168.1.30.
The neighbor local-as command changes the local AS value sent to the specified peer in OPEN messages, allowing the switch to appear as a member of a different AS to the selected peer. Arista switches replace the local AS number with the modified value rather than prepending it to routes, so we implement the command only as neighbor local-as no-prepend replace-as.
Note: To establish a BGP connection with a static peer, the peer must also be configured to expect the specified ASN. This is done by using the neighbor remote-as command on the peer switch.
The no neighbor local-as command disables this modification for the specified peer or peer group. The default neighbor local-as command disables this modification for individual neighbors, and applies the peer group’s setting for neighbors that are members of a peer group.
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
as_id AS number that is sent in OPEN messages to the specified peer in place of the actual AS of the switch. Values range from 1 to 4294967295.
This parameter cannot be set to the switch’s AS number or to any AS number in the peer’s network.
Examples
These commands configure the switch to replace its local ASN in OPEN messages sent to the peer at 10.13.64.1 with ASN 64500, and configure the peer to expect that ASN in messages received from the switch.
The neighbor local-v4-addr command specifies the next-hop value that the switch sends as the IPv4 NLRI value to neighbors with whom IPv6 transport peering is established.
The no neighbor local-v4-addr command applies the system default configuration.
The default neighbor local-v4-addr command applies the system default configuration for individual neighbors, and applies the peer group’s setting for neighbors that are members of a peer group.
To configure the switch to automatically determine the IPv4 address to be sent as the next-hop in IPv4 NLRIs to an IPv6 neighbor, use the neighbor auto-local-addr command.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDlocal-v4-addripv4_local
no neighborneighbor_IDlocal-v4-addr
default neighborneighbor_IDlocal-v4-addr
Parameters
neighbor_ID neighbor’s IPv6 address or peer group name.
ipv4_local next hop address.
Example
For the neighbor at 2001:0DB8:c2a4:1761::2, these commands specify an IPv4 NLRI value of 10.7.5.11 to be sent during IPv6 transport peering sessions.
The neighbor local-v6-addr command specifies the next-hop value that the switch sends as the IPv6 NLRI value to neighbors with which IPv4 transport peering is established.
In IPv6 peering sessions, the switch sends the global IPv6 address of the interface that is used to transmit BGP updates.
The no neighbor local-v6-addr command applies the system default configuration.
The default neighbor local-v6-addr command applies the system default configuration for individual neighbors, and applies the peer group’s setting for neighbors that are members of a peer group.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDlocal-v6-addripv6_local
no neighborneighbor_IDlocal-v6-addr
default neighborneighbor_IDlocal-v6-addr
Parameters
neighbor_ID neighbor’s IPv4 address or peer group name.
ipv6_local next hop address (A:B:C:D:E:F:G:H).
Example
For the neighbor at 10.7.5.11, these commands specify an IPv6 NLRI value that is sent during IPv4 transport peering sessions.
The neighbor maximum-routes command determines the number of BGP routes the switch accepts from a specified neighbor and defines an action after exceeding the limit. To remove the maximum route limit, select a limit of zero (0).
The switch generates an error message when the number of routes a peer receives exceeds the limit. This command can also configure the switch to disable peering with the neighbor. In this case, the neighbor state resets with the clear ip bgp command.
The no neighbor maximum-routes command applies the system default maximum-routes value of 256000 for the specified peer.
The default neighbor maximum-routes command applies the system default value for individual neighbors and the peer group settings for neighbors who are members of a peer group.
The no neighbor command removes all configuration commands for the neighbor at the specified address.
neighborneighbor_ID - Specify the neighbor IPv4 or IPv6 address or the peer group name.
maximum-routesquantity - Specify the maximum number of routes. Values include the following:
0 - Specify no defined route limit.
1 to 4294967294 - Specify the maximum number of routes.
action - Specify the action for the switch when exceeding the route limit. Values include:
warning-limit [number_of_routes|percentage] - Percentage of maximum routes to generate a warning. Setting this parameter to 0 does not send a warning.
warning-only - Send a warning when the number of routes exceeds the maximum route limit, but do not restart. Also, drop prefixes sent after exceeding the route limit.
Example
This command configures the switch to accept 15000 routes for the neighbor at 10.3.16.210. If the neighbor exceeds 15000 routes, the switch disables peering with the neighbor.
The neighbor next-hop-peer command configures the switch to list the peer address as the next hop in routes that it receives from the specified peer BGP-speaking neighbor or members of the specified peer group. This command overrides the next hop for all routes received from this neighbor or peer group.
The no neighbor next-hop-peer command applies the system default (no next-hop override) for the specified peer.
The default neighbor next-hop-peer command applies the system default for individual neighbors and applies the peer group’s setting for neighbors that are members of a peer group.
The no neighbor command removes all configuration commands for the neighbor at the specified address or the specified peer group.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDnext-hop-peer
no neighborneighbor_IDnext-hop-peer
default neighborneighbor_IDnext-hop-peer
Parameter
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
Example
This command configures the peer address of 10.3.2.24 as the next hop for routes advertised to the switch from the peer BGP neighbor.
The neighbor next-hop-self command configures the switch to list its address as the next hop in routes that it advertises to the specified BGP-speaking neighbor or neighbors in the specified peer group. This is used in networks where BGP neighbors do not directly access all other neighbors on the same subnet.
The no neighbor next-hop-self command applies the system default (no next-hop override) for the specified peer.
The default neighbor next-hop-self command applies the system default for individual neighbors and applies the peer group’s setting for neighbors that are members of a peer group.
The no neighbor command removes all configuration commands for the neighbor at the specified address or for the specified peer group.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDnext-hop-self
no neighborneighbor_IDnext-hop-self
default neighborneighbor_IDnext-hop-self
Parameter
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
Example
This command configures the switch as the next hop for the peer at 10.4.1.30.
The neighbor next-hop resolution v4-mapped-v6 translation command configures the switch to enable translation of IPv4-mapped IPv6 addresses to IPv4 addresses. With this setting enabled, when the switch receives an IPv4-mapped IPv6 address for a next hop, it will translate it to an IPv4 address. This allows the next hop to be resolved in an IPv4 network.
The no neighbor next-hop resolution v4-mapped-v6 translation and default neighbor next-hop resolution v4-mapped-v6 translation commands disable the translation from IPv4-mapped IPv6 addresses to IPv4 addresses.
Command Mode
BGP IPv6 Labeled-Unicast Address Family Configuration
neighbor_ID a neighboring peer or peer group that may send IPv4-mapped IPv6 addresses to this switch.
Guidelines
This command is active only if the multi-agent routing protocol model is running.
This command requires an IPv6 labeled-unicast address family.
This command applies to the default VRF.
Example
These commands enter BGP IPv6 Labeled-Unicast Address Family Configuration mode for AS 64510 (creating the BGP instance if it does not exist) and enable the translation of IPv4-mapped IPv6 addresses to IPv4 addresses for neighbors in the v6_pg peer group.
The neighbor out-delay command sets the period of time that a route update for the specified neighbor must be in the routing table before the switch exports it to BGP. The out delay interval is used for bundling routing updates.
The no neighbor out-delay command applies the system default (out-delay value of zero) for the specified peer.
The default neighbor out-delay command applies the system default for individual neighbors and applies the peer group’s setting for neighbors that are members of a peer group.
The no neighbor command removes all configuration commands for the specified neighbor.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDout-delaydelay_time
no neighborneighbor_IDout-delaydelay_time
default neighborneighbor_IDout-delaydelay_time
Parameters
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
delay_time the out delay period (seconds). Values range from 0 to 600. Default value is 0.
Example
These commands set the out delay period to 5 seconds for the connection with the peer at 10.24.15.9.
The neighbor passive command sets the TCP connection for the specified BGP neighbor or peer group to passive mode. When the peer’s transport connection mode is set to passive, it accepts TCP connections for BGP but does not initiate them.
The no neighbor passive command sets the specified BGP neighbor or peer group to active connection mode. BGP peers in active mode can both accept and initiate TCP connections for BGP. This is the default behavior.
The default neighbor passive command restores the default connection mode. The default mode is active for individual BGP peers, or the mode inherited from the peer group for peer group members.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDpassive
no neighborneighbor_IDpassive
default neighborneighbor_IDpassive
Parameter
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
Example
These commands configure the neighbor at IP address 10.2.2.14 to not initiate TCP connections for BGP peering.
The neighbor password command enables authentication on a TCP connection with a BGP peer. The plain-text version of the password is a string, up to 80 bytes in length. Peers must use the same password to ensure proper communication.
The running-config displays the encrypted version of the password. The encryption scheme is not strong by cryptographic standards; encrypted passwords should be treated in the same manner as plain-text passwords.
The no neighbor password command applies the system default for the specified peer, removing the neighbor password from the configuration and disabling authentication with the specified peer.
The default neighbor password command applies the system default for individual neighbors and applies the peer group’s setting for neighbors that are members of a peer group.
The no neighbor password and default neighbor password commands remove the neighbor password from the configuration, disabling authentication with the specified peer.
The no neighbor command removes all configuration commands for the neighbor at the specified address.
Running-config stores the password as an encrypted string.
neighbor peer group (create)
Peer groups allow the user to apply settings to a group of BGP neighbors simultaneously. Once a peer group is created, the group name can be used as a parameter in neighbor configuration commands, and the configuration will be applied to all members of the group. Settings applied to an individual neighbor in the peer group override group settings.
The neighbor peer group (create) command is used to create static BGP peer groups. Static peer groups are peer groups whose members are added manually. To assign BGP neighbors to a static peer group, use the neighbor peer group (neighbor assignment) command. To create a dynamic peer group, use the bgp listen range command.
The no neighbor peer group (create) and default neighbor peer group (create) commands remove the specified static peer group from running-config. When a static peer group is deleted, the neighbors that were members of that peer group lose any configuration that was inherited from the peer group. The no form of the bgp listen range command removes a dynamic peer group.
The no neighbor command removes all configuration commands for the specified neighbor.
Command Mode
Router-BGP Configuration
Command Syntax
neighborgroup_namepeer group
no neighborgroup_namepeer group
default neighborgroup_namepeer group
Parameter
group_name peer group name.
Examples
These commands create a BGP peer group called bgpgroup1, assign several neighbors to the group, apply a route map, and adjust the configuration for one group member.
switch(config)# router bgp 9
switch(config-router-bgp)# neighbor bgpgroup1 peer group
switch(config-router-bgp)# neighbor 10.1.1.1 peer group bgpgroup1
switch(config-router-bgp)# neighbor 10.2.2.2 peer group bgpgroup1
switch(config-router-bgp)# neighbor 10.3.3.3 peer group bgpgroup1
switch(config-router-bgp)# neighbor bgpgroup1 route-map corporate in
switch(config-router-bgp)# neighbor 10.3.3.3 maximum-routes 5000
switch(config-router-bgp)# show active
router bgp 9
bgp log-neighbor-changes
neighbor bgpgroup1 peer group
neighbor bgpgroup1 route-map corporate in
neighbor bgpgroup1 maximum-routes 12000
neighbor 10.1.1.1 peer group bgpgroup1
neighbor 10.2.2.2 peer group bgpgroup1
neighbor 10.3.3.3 peer group bgpgroup1
neighbor 10.3.3.3 maximum-routes 5000
switch(config-router-bgp)#
This command removes peer group bgpgroup1 from running-config. The group members remain, but all settings that group members inherited from the peer group are removed.
switch(config-router-bgp)# no neighbor bgpgroup1 peer group
switch(config-router-bgp)# show active
router bgp 9
bgp log-neighbor-changes
neighbor 10.1.1.1 maximum-routes 12000
neighbor 10.2.2.2 maximum-routes 12000
neighbor 10.3.3.3 maximum-routes 5000
switch(config-router-bgp)#
neighbor peer group (neighbor assignment)
Peer groups allow the user to apply settings to a group of BGP neighbors simultaneously. Once a peer group is created, the group name can be used as a parameter in neighbor configuration commands, and the configuration will be applied to all members of the group. Settings applied to an individual neighbor in the peer group override group settings.
The neighbor peer group (neighbor assignment) command is used to assign BGP neighbors to an existing static peer group. To create a static peer group, use the neighbor peer group (create) command. A neighbor can only belong to one peer group, so issuing this command for a neighbor that is already a member of another group will remove it from that group.
The no neighbor peer group and default neighbor peer group commands remove the specified neighbor from all peer groups. When a neighbor is removed from a peer group, the neighbor retains the configuration inherited from the peer group.
The no neighbor command removes all configuration commands for the specified neighbor.
Command Mode
Router-BGP Configuration
Command Syntax
neighborNEIGHBOR_ADDRpeer groupgroup_name
no neighborNEIGHBOR_ADDRpeer group
default neighborNEIGHBOR_ADDRpeer group
Parameters
NEIGHBOR_ADDR address of a neighbor being added to peer group. Values include:
ipv4_addr neighbor’s IPv4 address.
ipv6_addr neighbor’s IPv6 address.
group_name peer group name.
Examples
These commands create a BGP peer group called bgpgroup1, assign several neighbors to the group, and apply a route map.
switch(config)# router bgp 9
switch(config-router-bgp)# neighbor bgpgroup1 peer group
switch(config-router-bgp)# neighbor 10.1.1.1 peer group bgpgroup1
switch(config-router-bgp)# neighbor 10.2.2.2 peer group bgpgroup1
switch(config-router-bgp)# neighbor 10.3.3.3 peer group bgpgroup1
switch(config-router-bgp)# neighbor bgpgroup1 route-map corporate in
switch(config-router-bgp)#
This command removes the neighbor at 1.1.1.1 from the peer group. All settings that neighbor 10.1.1.1 inherited from the peer group are maintained.
switch(config-router-bgp)# no neighbor 10.1.1.1 peer group
switch(config-router-bgp)#
neighbor peer-tag
The neighbor peer-tag command in the BGP Configuration or BGP Address-Family Configuration Mode configures peer tagging and route filtering for BGP route advertisements by received routes from peers. Assign a peer-tag to a peer or a group of peers in the inbound direction and discard or allow route advertisements by the peer-tag in the outbound direction. The router can discard AS loop routes in the outbound direction for data center deployments.
The no | default versions of the command disables the feature.
address-family [ipv4 | ipv6] - If configuring in the Address-Family Configuration Mode, specify an IPv4 or IPv6 address for the neighbor.
neighborpeer_group_name - Specify a peer or a peer group for peer tagging on the network.
peer-tag [intag_name - Specify a peer-tag for the neighbor peer or peer group on the inbound route advertisements.
out [discard | allow]tag_name - Specify a peer-tag to discard or allow on the outbound route advertisements.
Example
Use the following commands to configure a peer-tag in the Address-Family Configuration Mode with an IPv4 address, 10.1.1.1:
switch(config-router-bgp)# address-family ipv4
switch(config-router-bgp-af)# neighbor 10.1.1.1 peer-tag in spine-routes
switch(config-router-bgp-af)# neighbor 10.1.1.1 peer-tag out discard spine-routes
neighbor received attribute discard
The neighbor received attribute discard command allows the configuration of BGP Attribute Ignore Received Lists to discard update messages with a BGP attribute. The default parameter applies the configuration to all BGP neighbors. The disabled parameter explicitly disables the configuration.
Command Mode
Router-BGP Configuration
Command Syntax
neighbor [default | ipv4 | ipv6] received attribute discardbgp_attribute_type
Command Syntax
[default | ipv4 | ipv6] - Specify default to apply the configuration to all BGP neighbors. Specify an IPv4 or IPv6 address to apply the configuration to a specific BGP neighbor.
bgp_attribute_type - Configure a single BGP attribute or a range of BGP attributes to discard.
Examples
Use the following command to configure a BGP Attribute Ignore Received List with the BGP attributes 4-255 for all BGP neighbors on the network:
switch(config)# router bgp
switch(config-router-bgp)# neighbor default received attribute discard 4-255
! To make this command effective for existing BGP sessions, clear all routes by issuing "clear ip bgp"
Use the following command to configure a BGP Attribute Ignore Received List with the BGP attributes 4-255 for BGP neighbor, 10.0.0.2 on the network:
switch(config)# router bgp
switch(config-router-bgp)# neighbor 10.0.0.2 received attribute discard 4-255
! To make this command effective for existing BGP sessions, clear all routes by issuing "clear ip bgp"
neighbor remote-as
The neighbor remote-as command configures the expected AS Number for a neighbor (peer). This configuration is required to establish a static peer connection. Internal neighbors have the same AS Number (ASN); external neighbors have different ASNs.
Note: To establish a BGP session, there must be an IPv4 router ID configured in the same VRF or at least one L3 interface with an IPv4 address in the same VRF. If the VRF contains no L3 interfaces with IPv4 addresses (e.g., in an IPv6-only environment), configure an appropriate router ID using the router-id (BGP) command.
When a static peer is using the neighbor local-as command to replace its local ASN with a configured ASN in OPEN messages, use the neighbor remote-as command to configure the switch to expect the configured ASN for that peer.
The no neighbor remote-as command applies the system default for the specified peer or peer group.
The default neighbor remote-as command applies the system default for individual neighbors and applies the peer group’s setting for neighbors that are members of a peer group.
The no neighbor command removes all configuration commands for the neighbor at the specified address.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDremote-asas_id
no neighborneighbor_IDremote-as
default neighborneighbor_IDremote-as
Parameters
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
as_id Autonomous System (AS) of the peer. Values range from 1 to 4294967295.
Example
These commands establish an eBGP connection with the router at 10.4.3.10 in AS 64500.
The neighbor remove-private-as command removes private autonomous system numbers from outbound routing updates for external BGP (eBGP) neighbors. When the Autonomous System (AS) path includes only private autonomous system numbers, the REMOVAL parameter specifies how the private autonomous system number is removed.
The no neighbor remove-private-as command applies the system default (preserves private AS numbers) for the specified peer.
The default neighbor remove-private-as command applies the system default for individual neighbors and applies the peer group’s setting for neighbors that are members of a peer group.
The no neighbor command removes all configuration commands for the neighbor at the specified address.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDremove-private-as [REMOVAL]
no neighborneighbor_IDremove-private-as
default neighborneighbor_IDremove-private-as
Parameters
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
REMOVAL specifies removal of all private AS numbers when the AS path contains only private AS numbers. Values include:
all removes all private AS numbers from AS path in outbound updates.
all replace-as all private AS numbers in AS path are replaced with router’s local AS number.
Note: This command does not support a mix of public and private AS numbers.
Examples
These commands program the switch to remove all private AS numbers from outbound routing updates for the eBGP neighbor at 10.5.2.11 only if the AS path does not contain any public AS number.
The neighbor rib-in delay command configures an inbound delay for installing routes from a peer on a BGP network. Routes from a second peer install before processing routes on the first peer.
The no|default commands remove the configuration from the switch.
Command Mode
Router-BGP Configuration
Command Syntax
neighborpeerrib-in delaysecondseventpeer-init
Parameters
peer - the peer has one of the following formats:
A.B.C.D - Add the peer IPv4 address.
A:B:C:D:E:F:G:H - Add the peer IPv6 address.
name - Add the name of the peer-group.
default - apply the configuration to all neighbors.
fe0::A:B:C:D%_interface - Add the neighbor IPv6 link-local address.
interface - Specify the interface range to use for BGP session establishment.
By default, inbound BGP routes that are filtered out by the inbound policy are still stored on the switch. Because all routes are retained, this allows policies to be changed without the need to reset the BGP sessions. All routes received by the switch (including those that were filtered out by the inbound policy) can be seen by issuing the show ip bgp neighbor received-routes command.
The no neighbor rib-in pre-policy retain command configures the switch to discard those routes received from the specified neighbor (or peer group) that are filtered out by the inbound policy.
The neighbor rib-in pre-policy retain command restores the system default behavior (retaining routes from the specified neighbor or group regardless of inbound policy).
The default neighbor rib-in pre-policy retain command applies the system default (retaining policy-rejected routes) for individual neighbors and applies the peer group’s setting for neighbors that are members of a peer group.
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
all the command applies to all routes from the specified neighbor or peer group, including those that would otherwise be discarded as invalid (because their AS-Path contains the switch's own ASN, for example). Without this keyword, the command applies only to routes that were filtered out by the inbound policy.
Examples
These commands configure the switch to discard routes received from from the neighbor at 10.5.2.23 which are filtered out by the switch’s inbound policies.
These commands configure the switch to retain all routes received from the neighbor at 10.5.2.23 (including invalid routes).
switch(config)# router bgp 9
switch(config-router-bgp)# no neighbor 10.5.2.23 rib-in pre-policy retain all
switch(config-router-bgp)#
neighbor route-map (BGP)
The neighbor route-map command applies a route map to inbound or outbound BGP routes. When applying a route map to outbound routes, the switch advertises only routes matching at least one section of the route map. Only one outbound route map and one inbound route map can be applied to a given neighbor. A new route map applied to a neighbor replaces the previous route map.
Use the command in the Router BGP and the Router BGP Address Family Configuration Modes. The command execution mode determines the scope of the command:
The Router BGP Configuration Mode applies the route map to the specified neighbor in all peering sessions where advertised.
The Router BGP Address Family Configuration Mode applies the route map to the neighbors only in peering sessions corresponding to the configuration-mode address family.
The no neighbor route-map command applies no route map for individual neighbors and does not apply the peer group setting to neighbors participating as peer group members. Executing this command adds an entry to the running-configfile.
The default neighbor route-map command applies the system default, no route map, for individual neighbors, and applies the peer group setting for neighbors that are members of a peer group.
Command Mode
Router-BGP Configuration
Router-BGP Address-Family Configuration
Command Syntax
neighborneighbor_IDroute-mapmap_name [in | out]
Parameters
neighbor_ID - Specify the neighbor IPv4 or IPv6 address or peer group name.
route-mapmap_name - Specify the name of a route map.
[in | out] Apply the route map to the specified routes. Options include the following:
in - Apply the route map is applied to inbound routes.
out - Apply the route map to outbound routes.
Example
This command applies a route map named inner-map to a BGP inbound route from 10.5.2.11.
Participating BGP routers within an AS communicate eBGP-learned routes to all of their peers, but to prevent routing loops they must not re-advertise iBGP-learned routes within the AS. To ensure that all members of the AS share the same routing information, a fully meshed network topology (in which each member router of the AS is connected to every other member) can be used, but this topology can result in high volumes of iBGP messages when it is scaled. Instead, in larger networks one or more routers can be configured as route reflectors.
A route reflector is configured to re-advertise routes learned through iBGP to a group of BGP neighbors within the AS (its clients), eliminating the need for a fully meshed topology.
The neighbor route-reflector-client command configures the switch to act as a route reflector and configures the specified neighbor as one of its clients. Additional clients are specified by re-issuing the command.
The no neighbor route-reflector-client and default neighbor route-reflector-client commands disable route reflection by deleting the neighbor route-reflector-client command from running-config.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDroute-reflector-client
no neighborneighbor_IDroute-reflector-client
default neighborneighbor_IDroute-reflector-client
Parameter
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
The neighbor route-to-peer command allows BGP to establish a connection to reach the specified peer using kernel routing table information. By default, route-to-peer configuration is enabled for a peer or a peer group.
The no neighbor route-to-peer command prevents BGP from using kernel routing table information to establish a BGP connection to reach a peer and the default neighbor route-to-peer command enables route-to-peer configuration for a peer or a peer group by removing the corresponding no neighbor route-to-peer command from the running-config.
If the peer is directly connected, BGP instead uses ARP table or neighbor table information to establish a BGP connection to reach the peer.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDroute-to-peer
no neighborneighbor_IDroute-to-peer
default neighborneighbor_IDroute-to-peer
Parameter
neighbor_ID neighbor’s IPv4 or IPv6 address or the peer group name.
Example
These commands establish a connection between the switch and the BGP peer located at IP address 172.16.1.1, and prevent BGP from using kernel routing table information to establish a route to that peer.
The neighbor send-community command configures the switch to include community path attributes for routes in the UPDATE messages advertised to the specified BGP neighbor. By default, the command enables the switch to send all community attributes: standard, extended, and large. To advertise only a subset of community attributes, use the keyword(s) for the community attribute(s) to be included. To add additional community attributes in a separate command, or to remove specific community attributes from advertised routes, use the neighbor send-community add / remove command.
The no neighbor send-community command applies the system default (not sending community attributes in BGP UPDATE messages) for the specified peer.
The default neighbor send-community command applies the system default for individual neighbors and applies the peer group’s setting for neighbors that are members of a peer group.
These commands configure the switch to include only large community attributes in the routes sent to the neighbor at address 10.5.2.24.
switch(config)# router bgp 9
switch(config-router-bgp)# neighbor 10.5.2.24 send-community large
switch(config-router-bgp)#
These commands configure the switch to send only standard and large community attributes to the neighbor at address 10.5.2.25.
switch(config)# router bgp 9
switch(config-router-bgp)# neighbor 10.5.2.25 send-community standard large
switch(config-router-bgp)#
neighbor send-community add / remove
The neighbor send-community add / remove command modifies the types of community path attributes included for routes in the UPDATE messages advertised to the specified BGP neighbor without having to issue the neighbor send-community command.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDsend-community {add | remove}{extended | large | standard}
Parameters
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
add appends the specified community path attribute type to the list of community path attribute types sent to the specified neighbor.
remove removes the specified community path attribute type from the list of community path attribute types sent to the specified neighbor.
extended enables (or disables) sending of the extended community path attribute to the specified neighbor.
large enables (or disables) sending of the large community path attribute to the specified neighbor.
standard enables (or disables) sending of the standard community path attribute to the specified neighbor.
If the neighbor send-community command has been issued for the neighbor without specifying any community types, that neighbor will receive all community attributes in the routes advertised to it. Using the neighbor send-community add command then to add an attribute will cause the switch to send only the specified community types in advertised routes. This results in the other community path attributes no longer being advertised to that BGP peer.
If all community types are removed using the neighbor send-community remove command, the switch will then send routes with all community types. (This behavior is maintained for backward compatibility.) To remove all community path attributes from routes sent to the specified neighbor, use the neighbor send-community command.
After using this command, issue the show active command in router-bgp configuration mode to ensure that the intended attributes are being sent to the specified neighbor.
Examples
These commands configure the switch to send large community attributes in the routes sent to the neighbor at address 10.5.2.24, then add extended community attributes as well.
switch(config)# router bgp 9
switch(config-router-bgp)# neighbor 10.5.2.24 send-community large
switch(config-router-bgp)# neighbor 10.5.2.24 send-community add extended
switch(config-router-bgp)# show active
switch(config-router-bgp)# neighbor 10.5.2.24 send-community add extended
switch(config-router-bgp)# show active
router bgp 9
neighbor 10.5.2.24 send-community extended large
neighbor 10.5.2.24 maximum-routes 12000
switch(config-router-bgp)#
These commands configure the switch to include extended and large community attributes in the routes sent to the neighbor at address 10.5.2.27, then remove the large attribute from the list of community types to be included.
switch(config)# router bgp 9
switch(config-router-bgp)# neighbor 10.5.2.27 send-community extended large
switch(config-router-bgp)# neighbor 10.5.2.27 send-community remove large
switch(config-router-bgp)# show active
router bgp 600
neighbor 10.5.2.27 send-community extended
neighbor 10.5.2.27 maximum-routes 12000
switch(config-router-bgp)#
These commands attempt to configure the switch to remove large community attributes from routes sent to the neighbor at address 10.5.2.28, but send all others. However, because the original command did not specify a list of attributes, the remove command has no effect, and all community path attributes are still included.
switch(config)# router bgp 9
switch(config-router-bgp)# neighbor 10.5.2.28 send-community
switch(config-router-bgp)# neighbor 10.5.2.28 send-community remove large
switch(config-router-bgp)# show active
router bgp 600
neighbor 10.5.2.28 send-community
neighbor 10.5.2.28 maximum-routes 12000
switch(config-router-bgp)#
These commands configure the switch to send only large community attributes in routes sent to the neighbor at address 10.5.2.29, then attempt to remove the large attribute from sent routes. However, because this removes the last specified attribute, all community path attributes (including large) will now be included.
switch(config)# router bgp 9
switch(config-router-bgp)# neighbor 10.5.2.29 send-community large
switch(config-router-bgp)# neighbor 10.5.2.28 send-community remove large
switch(config-router-bgp)# show active
router bgp 600
neighbor 10.5.2.29 send-community
neighbor 10.5.2.29 maximum-routes 12000
switch(config-router-bgp)#
neighbor send-community link-bandwidth
The neighbor send-community link-bandwidth command is used to locally regenerate the link-bandwidth value to be advertised to a specific BGP neighbor or peer group. When this command is configured the regenerated link-bandwidth value is included in the extended community path attribute in UPDATE messages.
This command is used specifically for local regeneration of the link-bandwidth value. To send an explictly-configured link-bandwidth value, add an extended community to a route map instead. (see set extcommunity (route-map)) and include extended community attributes in UPDATE messages sent to that neighbor.
The no neighbor send-community command applies the system default (not sending community attributes in BGP UPDATE messages) for the specified peer.
The default neighbor send-community command applies the system default for individual neighbors and applies the peer group’s setting for neighbors that are members of a peer group.
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
aggregate sends the sum of all link-bandwidth values for all paths toward a prefix to the specified neighbor or to each member of the specified peer group.
reference_speed optional value to specify a reference link speed in bits/second. Values range from 0.0 to 4294967295.0; larger values can also be expressed using the multiplier K (*10^3), M (*10^6), or G (*10^9). The link speed of the connection to the peer is divided by this value, and the resulting ratio is used to scale down the link-bandwidth advertised to the peer. If the result is >1, the multiplier is ignored and the full aggregate value is advertised.
divide divides the cumulative link-bandwidth value described above among the peers in an Adj-RIB-Out either equally or proportionally.
equal divides the cumulative total link-bandwidth value equally among all peers in the same Adj-RIB-Out.
ratio divides the cumulative total link-bandwidth value among peers proportionally according to the speed of the connection to each peer in the Adj-RIB-Out.
Examples
These commands configure the switch to locally regenerate the link-bandwidth value, dividing the bandwidth proportionally and including it in UPDATE messages to all peers in the peer group idaho.
These commands configure the switch to locally regenerate the link-bandwidth value, scale it down with a reference link speed of 20 gigabits/second, and include it in UPDATE messages to the neighbor at address 10.5.2.24.
The neighbor shutdown command disables the specified neighbor. Disabling a neighbor also terminates all of its active sessions and removes associated routing information.
The no neighbor shutdown command enables the specified peer.
The default neighbor shutdown command enables individual neighbors and applies the peer group’s setting for neighbors that are members of a peer group.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDshutdownreasonREASON
Parameter
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
The neighbor timers command configures the BGP keepalive and hold times for a specified peer connection. The timers bgp command configures the times on all peer connections for which an individual command is not specified.
Keepalive time is the period between the transmission of consecutive keepalive messages.
Hold time is the period the switch waits for a KEEPALIVE or UPDATE message before it disables peering.
The hold time must be at least 3 seconds and should be three times longer than the keepalive setting.
The no neighbor timers command applies the system default for the specified peer or group (the timers specified by the timers bgp command).
The default neighbor timers command applies the system default for individual neighbors and applies the peer group’s setting for neighbors that are members of a peer group.
The no neighbor command removes all configuration commands for the neighbor at the specified address.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDtimerskeep_alivehold_time
no neighborneighbor_IDtimers
default neighborneighbor_IDtimers
Parameters
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
keep_alive keepalive period, in seconds. Values include:
0 keepalive messages are not sent.
1 to 3600 keepalive time (seconds).
hold_time hold time. Values include:
0 peering is not disabled by timeout expiry; keepalive packets are not sent.
3 to 7200 hold time (seconds).
Example
This command sets the keepalive time to 30 seconds and the hold time to 90 seconds for the connection with the peer at 10.24.15.9.
The neighbor ttl maximum-hops command configures the Generalized TTL Security Mechanism (GTSM) for the specified neighbor(s).
The no neighbor ttl maximum-hops command disables the GTSM configuration in the specified neighbor.
The default neighbor ttl maximum-hops command applies the system default configuration for individual neighbors; and applies the peer group’s setting for neighbors that are members of a peer group.
Command-Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDttl maximum-hopshop_number
no sneighborneighbor_IDttl maximum-hops
default neighborneighbor_IDttl maximum-hops
Parameters
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
hop_number maximum count of hops from a BGP peer. Values range from 0 to 254.
Example
This command configures the TTL security for 10.20.20.30 with a maximum of 4 hops.
The neighbor update-source command specifies the interface that BGP sessions use for TCP connections. By default, BGP sessions use the neighbor’s closest interface (also known as the best local address).
The no neighbor update-source command applies the system default (using best local address for TCP connections) for the specified peer or group.
The default neighbor update-source command applies the system default for individual neighbors and applies the peer group’s setting for neighbors that are members of a peer group.
The no neighbor command removes all configuration commands for the neighbor at the specified address.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDupdate-sourceINTERFACE
no neighborneighbor_IDupdate-source
default neighborneighbor_IDupdate-source
Parameters
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
INTERFACE interface type and number. Options include:
ethernete_num Ethernet interface specified by e_num.
loopbackl_num loopback interface specified by l_num.
managementm_num management interface specified by m_num.
port-channelp_num port-channel interface specified by p_num.
vlan VLAN interface specified by v_num.
Example
This command configures the switch to use ethernet 10 for TCP connections for the neighbor at 10.2.2.14.
The neighbor weight command assigns a weight attribute value to paths from the specified neighbor. Weight is the first parameter that the BGP best-path selection algorithm considers. When multiple paths to a destination prefix exist, the best-path selection algorithm prefers the path with the highest weight. Other attributes are used only when all paths to the prefix have the same weight.
Weight values range from 0 to 65535 and are not propagated to other switches through route updates. The default weight for paths that the router originates is 32768; the default weight for routes received through BGP is 0.
A path’s BGP weight is also configurable through route maps. Weight values set through route-map commands have precedence over neighbor weight command values.
The no neighbor weight command applies the system default (32768 for router-originated paths, 0 for routes received through BGP) for the specified peer or group.
The default neighbor weight command applies the system default for individual neighbors, and applies the peer group’s setting for neighbors that are members of a peer group.
The no neighbor command removes all configuration commands for the neighbor at the specified address.
Command Mode
Router-BGP Configuration
Command Syntax
neighborneighbor_IDweightweight_value
no neighborneighbor_IDweight
default neighborneighbor_IDweight
Parameters
neighbor_ID neighbor’s IPv4 or IPv6 address or peer group name.
weight_value weight value. Values range from 1 to 65535.
Example
This command specifies a weight of 4000 for all paths from the neighbor at 10.1.2.5.
The network command specifies a network for advertisement through UPDATE packets to BGP peers. The configuration zeros the host portion of the specified network address; for example, 192.0.2.4/24 is stored as 192.0.2.0/24. A route map option is available for assigning attributes to the network.
The command is available in Router-BGP and Router-BGP-Address-Family configuration modes. The mode in which the command is issued does not affect the command. The scope of the command depends on the specified network address:
commands with an IPv4 address are advertised to peers activated in the IPv4 address family.
commands with an IPv6 address are advertised to peers activated in the IPv6 address family.
The no network and default network commands remove the network from the routing table, preventing its advertisement.
Command Mode
Router-BGP Configuration
Router-BGP Address-Family Configuration
Command Syntax
networkNET_ADDRESS [ROUTE_MAP]
no networkNET_ADDRESS
default networkNET_ADDRESS
Parameters
NET_ADDRESS IP address range. Entry options include:
The no neighbor command removes all neighbor configuration commands for the specified neighbor.
Neighbor settings can also be removed individually; refer to the command description page of the desired command for details. Neighbor settings for a peer group must be removed individually.
Command Mode
Router-BGP Configuration
Command Syntax
no neighborneighbor_ID
default neighborneighbor_ID
Parameter
neighbor_ID neighbor’s IPv4 or IPv6 address. This command does not accept a peer group name as an argument; peer group settings must be removed individually.
Example
This command removes all neighbor configuration commands for the neighbor at 10.1.1.1.
switch(config)# router bgp 9
switch(config-router-bgp)# no neighbor 10.1.1.1
switch(config-router-bgp)#
peer-filter
The peer-filter command creates a peer filter group and places the switch in peer-filter configuration mode for that group. The peer-filter group parameters are defined using the match as-range command.
The no peer-filter and default peer-filter commands remove the peer-filter group from running-config.
Command Mode
Router-BGP Configuration
Command Syntax
peer-filterfilter_name
no peer-filterfilter_name
default peer-filterfilter_name
Parameters
filter_name name of the peer filter.
Example
This command creates a peer filter called group1 and places the switch in peer-filter configuration mode for that filter.
The rd command adds a Route Distinguisher (RD) to VRF and VNI configuration modes. RDs internally identify routes belonging to a VRF or VNI to distinguish overlapping or duplicate IP address ranges. This allows the creation of distinct routes to the same IP address for different VPNs. The RD is a 64-bit number made up of an AS number or IPv4 address followed by a user-selected ID number.
If the switch is not running EVPN, an RD is not required for a VRF or VNI to function. Use no or default command forms to remove an RD from a VRF or VNI.
Note: Legacy RDs that were assigned in VRF Configuration Mode appear in show vrf outputs if an RD has not been configured using this command, but they no longer have an effect on the system. RDs assigned in the VNI Configuration Mode are displayed in the output of show bgp evpn command.
Command Modes
Router-BGP VRF Configuration
Router-BGP VNI Configuration
Command Syntax
rdadmin_ID:local_assignment
no rd
default rd
Parameters
admin_ID an AS number or globally assigned IPv4 address identifying the entity assigning the RD. This should be an IANA-assigned identifying number.
local_assignment a locally assigned number distinguishing the VRF. Values range from 0-65535 if the admin_ID is an IPv4 address, or from 0-4294967295 if the admin_ID is an AS number. If the admin_ID is an AS number, the local_assignment can also be entered in the form of an IPv4 address.
Examples
These commands identify the administrator of the VRF named purple as AS 530 and assign 12 as its local number.
The redistribute command enables the redistribution of specified routes to the BGP domain.
The no redistribute and default redistribute commands disable route redistribution from the specified domain by removing the corresponding redistribute command from running-config.
Note: EOS redistributes aggregate routes automatically, and redistribution cannot be disabled.
The rib fib fec ecmp ordered command is configured to enforce ordering of next hops as determined by the protocol agents in the FEC programmed for the route.
The no rib fib fec ecmp ordered command removes the Ordered FEC configuration from the running-config.
Command Mode
Router General Configuration Mode
Command Syntax
rib fib fec ecmp ordered
no rib fib fec ecmp ordered
Example
The rib fib fec ecmp ordered command configures the Ordered FEC feature on the switch.
switch(config)# router general
switch(config-router-general)# rib fib fec ecmp ordered
switch(config-router-general)#
route-target auto l3-vrf
The route-target auto l3-vrf command in Router BGP Address Family Configuration Mode auto-generates import and export route targets for Layer 3 Virtual Routing and Forwarding (VRF) instances. Specify the 2-byte Autonomous System Number (ASN) for import route auto-generation whereas export route target auto-generation does not require it.
Command Mode
Router BGP Address Family Configuration
Command Syntax
route-target [import | export] auto l3-vrf2b_ASN disabled
Parameters
route-target [import | export] - Specify if you want to auto-generate import or export route targets for Layer 3 VRFs.
auto l3-vrf - Specify auto-generating route targets for Layer 3 VRFs.
2b_ASN - Specify a 2-byte ASN for the route target.
disabled - Specify if you want to disable route target auto-generation.
Example
Use the following command to configure a BGP router, BGP_1, with an address family, evpn, and a 2-byte ASN, 6500:
switch(config)# router bgp BGP_1
switch(config-router-bgp)# address-family evpn
switch(config-router-bgp-af)# route-target import auto l3-vrf 6500
switch(config-router-bgp-af)# route-target export auto l3-vrf 6500
router bgp
The router bgp command places the switch in router-BGP configuration mode. If BGP was not previously instantiated, this command creates a BGP instance with the specified AS number. Router-BGP configuration mode is not a group-change mode; running-config is changed immediately after commands are executed. The exit command does not affect the configuration.
When a BGP instance exists, the command must include the AS number of the existing BGP instance. Running this command with a different AS number generates an error message.
The no router bgp and default router bgp commands delete the BGP instance.
The exit command returns the switch to global configuration mode.
Command Mode
Global Configuration
Command Syntax
router bgpas_id
no router bgp
default router bgp
Parameter
as_id Autonomous System (AS) number. Values range from 1 to 4294967295.
Examples
This command creates a BGP instance with AS number 64500.
This command attempts to open a BGP instance with a different AS number from that of the existing instance. The switch displays an error and stays in the global configuration mode.
switch(config)# router bgp 64501
% BGP is already running with AS number 64500
switch(config)#
This command exits the bgp configuration mode.
switch(config-router-bgp)# exit
switch(config)#
This command deletes the BGP instance.
switch(config)# no router bgp
switch(config)#
router-id (BGP)
The router-id command sets the local router BGP router ID.
When no ID has been specified, the local router ID is set to the following:
the loopback IP address when a single loopback interface is configured.
the loopback with the highest IP address when multiple loopback interfaces are configured.
the highest IP address on a physical interface when no loopback interfaces are configured.
Note: The router ID must be specified if the switch has no IPv4 addresses configured.
The no router-id and default router-id commands remove the router-id command from running-config.
Command Mode
Router-BGP Configuration
Command Syntax
router-idid_num
no router-id [id_num]
default router-id [id_num]
Parameter
id_num router ID number (32-bit dotted decimal notation).
Example
This command configures the fixed router ID address of 10.10.4.11.
Large communities are an optional transitive attribute of variable length. There are no predefined large-community types or values. Large communities may be configured alongside standard and extended communities within route-maps using additional configuration commands.
Large community values (aa:nn:nn) must consist of three decimal values each in the range (0-4294967295). All three sub-values of a large community value must be present. As-plain and As-dot notation are supported for the leading ASN value.
The no and default versions of the command return the command to the original configuration.
Command Mode
Route map configuration
Command Syntax
set large-community [large-community-listLIST1 [[LIST2] [additive | delete]]]
no set large-community [large-community-listLIST1 [[LIST2] [additive | delete]]]
default set large-community [large-community-listLIST1 [[LIST2] [additive | delete]]]
Parameters
large-community-list Add a large community list entry.
LIST1 Name of large community list.
additive Adds to the existing community.
delete Deletes matching communities.
Examples
The following route-map sets a number of large-community values using both as-plain and as-dot notation.
The following route-map matches multiple large-community values from large-community lists (LC_a1 and LC_a2) and sets local-pref accordingly.
switch(config)# ip large-community-list LC_1 permit 10:20:30 40:50:60
switch(config)# ip large-community-list LC_2 permit 70:80:90
switch(config)# route-map LC permit 10
switch(config-map-LC)# match large-community LC_1 LC_2 exact_match
switch(config-map-LC)# set local-pref 111
show bgp labeled-unicast tunnel
The show bgp labeled-unicast tunnel command displays the contents of the BGP Labeled-Unicast (LU) tunnel table. The user can optionally specify a tunnel index parameter to view the specific single tunnel information.
Command Mode
EXEC
Command Syntax
show bgp labeled-unicast tunneltunnel_index
Parameter
tunnel_index index to view single tunnel information.
The show bgp convergence command displays information about the Border Gateway Protocol (BGP) convergence state and other statistics about the BGP instance in the specified VRF or in all VRFs.
no parameter displays BGP information for the context-active VRF.
vrfvrf_name displays BGP information for the specified VRF.
vrfall displays BGP information for all VRFs.
vrfdefault displays BGP information for the default VRF.
Examples
This command displays the output when no peers have joined before convergence.
switch# show bgp convergence
BGP Convergence information for VRF: default
Configured convergence timeout: 00:02:30
Configured convergence slow peer timeout: 00:00:55
Convergence based update synchronization is enabled
Last Bgp convergence event : None
Bgp convergence state : Not Initiated (Waiting for the first peer to join)
Convergence timer is not running
Convergence timeout in use: 00:02:30
Convergence slow peer timeout in use: 00:00:55
First peer is not up yet
All the expected peers are up: no
All IGP protocols have converged: yes
Outstanding EORs: 0, Outstanding Keepalives: 0
Pending Peers: 2
Total Peers: 2
Established Peers: 0
Disabled Peers: 0
Peers that have not converged yet:
IPv4 peers:
201.1.1.1 (Session : Connect)
202.1.1.1 (Session : Connect)
IPv6 peers:
None
This command displays the output when the first peer has joined before convergence.
switch# show bgp convergence
BGP Convergence information for VRF: default
Configured convergence timeout: 00:02:30
Configured convergence slow peer timeout: 00:00:55
Convergence based update synchronization is enabled
Last Bgp convergence event 00:00:40 ago
Bgp convergence state : Pending (Waiting for EORs/Keepalives from peer(s) and IGP
convergence)
Convergence timer running, will expire in 00:01:50
Convergence timeout in use: 00:02:30
Convergence slow peer timeout in use: 00:00:55
First peer came up 00:00:13 ago
All the expected peers are up: no
All IGP protocols have converged: yes
Outstanding EORs: 0, Outstanding Keepalives: 0
Pending Peers: 1
Total Peers: 2
Established Peers: 1
Disabled Peers: 0
Peers that have not converged yet:
IPv4 peers:
201.1.1.1 (Session : Active)
IPv6 peers:
None
This command displays the output when the convergence timeout value is reached.
switch# show bgp convergence
BGP Convergence information for VRF: default
Configured convergence timeout: 00:02:30
Configured convergence slow peer timeout: 00:00:55
Convergence based update synchronization is enabled
Last Bgp convergence event 00:02:44 ago
Bgp convergence state : Timeout reached
Time taken to converge 00:02:30
Pending Peers: 1
Total Peers: 2
Established Peers: 1
Disabled Peers: 0
Peers that did not converge before local bgp convergence:
IPv4 peers:
201.1.1.1 (Session : Active)
202.1.1.1 (Session : Established)
IPv6 peers:
None
This command displays the output during the converged state.
switch# show bgp convergence
BGP Convergence information for VRF: default
Configured convergence timeout: 00:05:00
Configured convergence slow peer timeout: 00:01:30
Convergence based update synchronization is enabled
Last Bgp convergence event 00:00:05 ago
Bgp convergence state : Converged
Time taken to converge 00:00:02
First peer came up 00:00:05 ago
Pending Peers: 0
Total Peers: 3
Established Peers: 3
Disabled Peers: 0
Peers that did not converge before local bgp convergence:
IPv4 peers:
None
IPv6 peers:
None
show bgp flow-spec
The show bgp flow-spec ipv4 displays a brief description of each flowspec rule, including the matching rule and actions.
Command Mode
EXEC
Command Syntax
show bgp flow-spec [ipv4 | ipv6] [summary | detail] [vrfVRFNAME]
Parameters
ipv4 Displays information releated to IPv4.
ipv6 Displays information releated to IPv6.
summary Displays summarized BGP information.
detail Displays detailed information.
vrfVRFNAME Displays flow-spec information in the named VRF.
The show bgp flow-spec ipv4 summary command displays the count of flowspec rules received from each peer:
switch(config)# show bgp flow-spec ipv4 summary
BGP summary information for VRF default
Router identifier 0.0.0.1, local AS number 10
Neighbor Status Codes: m - Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State RulesRcd RulesAcc
10.0.0.2 4 10 12 4 0 0 00:02:18 Estab 2 2
10.0.1.2 4 10 6 4 0 0 00:02:18 Estab 0 0
The show bgp flow-spec detail displays the full details of each flowspec rule including the peer(s) it was received from, BGP properties, and an expanded description of the matching rule:
switch(config)# show bgp flow-spec ipv4 detail
BGP Flow Specification rules for VRF default
Router identifier 0.0.0.1, local AS number 10
BGP Flow Specification Matching Rule for 10.2.3.0/24;*;
Rule identifier: 3882065752
Matching Rule:
Destination Prefix: 10.2.3.0/24
Source Prefix: *
Paths: 1 available
Local
from 10.0.0.2 (10.1.1.2)
Origin IGP, metric -, localpref 100, weight 0, valid, internal, best
Actions: Drop
BGP Flow Specification Matching Rule for 10.2.4.0/24;10.2.0.0/16;IP:=6|=17;DP:>1010&<1024;
Rule identifier: 3882090640
Matching Rule:
Destination Prefix: 10.2.4.0/24
Source Prefix: 10.2.0.0/16
IP Protocol: =6 | =17
Destination Port: >1010 & <1024
Paths: 1 available
Local
from 10.0.0.2 (10.1.1.2)
Origin IGP, metric -, localpref 100, weight 0, valid, internal, best
Actions: Drop
show bgp instance
The show bgp instance command displays summary Border Gateway Protocol (BGP) information about the BGP instance in the specified VRF or in all VRFs.
no parameter displays BGP information for the context-active VRF.
vrfvrf_name displays BGP information for the specified VRF.
vrfall displays BGP information for all VRFs.
vrfdefault displays BGP information for the default VRF.
Examples
This command displays information about the BGP instance in the context-active VRF.
switch# show bgp instance
BGP instance information for VRF purple
BGP Local AS: 64497, Router ID: 1.2.3.5
Total peers: 5
Configured peers: 3
UnConfigured peers: 2
Disabled peers: 0
Established peers: 3
Graceful restart helper mode enabled
End of rib timer timeout: 00:05:00
BGP Convergence timer is inactive
BGP Convergence information:
BGP has converged:no
Outstanding EORs:0,Outstanding Keepalives: 0
Convergence timeout: 00:10:00
switch#
This command displays information about the BGP instance in the default VRF.
switch# show bgp instance vrf default
BGP instance information for VRF default
BGP Local AS: 64503, Router ID: 1.2.3.5
Total peers: 1
Configured peers: 1
UnConfigured peers: 0
Disabled peers: 0
Established peers: 0
Graceful restart helper mode enabled
End of rib timer timeout: 00:05:00
BGP Convergence timer is inactive
BGP Convergence information:
BGP has converged:no
Outstanding EORs:0,Outstanding Keepalives: 0
Convergence timeout: 00:10:00
switch#
show bgp monitoring
The show bgp monitoring command displays information about the BGP Monitoring Protocol configuration on a switch.
Command Mode
EXEC
Command Syntax
show bgp monitoringsummary
Examples
Use the following command to display information about a BMP configuration on the switch:
switch# show bgp monitoring station
BGP Monitoring status: enabled
BMP Timestamp mode: send-time
BMP Export policies: pre-policy, post-policy
VRFs filtered: vrf1, vrf2
Station - bmp_A
Connection mode: active
VRF: default
Address: 192.0.2.1
Port: 5000
Connection: connected
State: up
Uptime: 00:09:17
Station flap count: 0
Add the summary parameter to display a summary of all station names, status, and duration of activity:
switch# show bgp monitoring summary
BGP Monitoring status: enabled
Station Name Status Uptime
---------------- ------------ ------------
bmp_A connecting -
bmp_B idle -
bmp_C up 00:11:46
show bgp monitoring active
The show bgp monitoring active command displays information about stations in Active Mode and receiving TCP connection requests from a BGP router.
Command Mode
EXEC
Command Syntax
show bgp monitoring active [summary | [stationstation_name]]
Parameters
summary - Display a summary of all BMP monitoring stations with Active mode connections.
stationstation_name - Display information about a specific BMP monitoring station.
Example
To display a summary of all BMP monitoring stations with Active mode connections, use the following command:
switch# show bgp monitoring active
Active Station - bmp_C
VRF: default
Address: 172.24.64.68
Port: 5000
Retry interval: 30s
Connection: connected
Attempts: 4484
Successes: 1
Errors: 5
show bgp neighbors history
The show bgp neighbors history command stores and displays a list of failed BGP connection attempts for each peer. This may be particularly useful while troubleshooting flappy connections. If enabling dynamic peering, the failure history records even after the peers are no longer present.
Command Mode
EXEC
Command Syntax
show bgp neighbors [PEER | PREFIX | peer-groupPEER_GROUP] history [connect-failures | socket |][vrfVRF
Parameters
PEER An IPv4 or IPv6 valid address.
PREFIX An IPv4 or IPv6 valid prefix.
peer-groupPEER_GROUP A peer group name.
connect-failures Optional and does not affect the result.
socket - TCP socket statistics.y
vrfVRF A VRF name. If it is not supplied, the command acts upon the VRF default.
Guidelines
Relevant error messages are recorded by default, without any configuration. To clear all messages for a peer or group of peers, though, use the command clear bgp history. The following output provides the syntax for this command:
switch# clear bgp [PEER|PREFIX|peer-group PEER_GROUP] history [connect-failures][vrf VRF]
If no peer, prefix, or peer-group is supplied, this command clears the history for all peers in the specified VRF.
The number of recorded messages is limited to eight per peer.
Only errors that occur prior to session establishment get recorded.
The show bgp neighbors history becomes available only with the multi-agent protocol model.
For each peer, the address prints at the first line, along with the assigned VRF. Then, a table prints with the following columns:
Type - The peer connection type. May be Static or Dynamic.
AS - The remote Autonomous System number.
Time - The time of the failure, using the local timezone.
Event - A description related to the cause of the failed BGP connection.
switch> show bgp neighbors history
1.1.1.2 VRF default
Type AS Time Event
Static 65538 Mon 2019-05-13 04:16:24 Connect (No route to host)
Static 65538 Mon 2019-05-13 04:16:31 Connect (No route to host)
Static 65538 Mon 2019-05-13 04:16:39 Connect (No route to host)
Static 65538 Mon 2019-05-13 04:16:47 Connect (No route to host)
Static 65538 Mon 2019-05-13 04:16:55 Connect (No route to host)
Static 65538 Mon 2019-05-13 04:17:03 Connect (No route to host)
Static 65538 Mon 2019-05-13 04:18:17 bad AS number
Static 65538 Mon 2019-05-13 04:19:40 bad AS number
show bgp monitoring station
The show bgp monitoring station command displays details about a specific BMP monitoring station.
Command Mode
EXEC
Command Syntax
show bgp monitoring stationstation_namedetail
Parameters
station_name - Specify the name of a BMP monitoring station.
detail - Display TCP connection statistics for a BMP monitoring station.
Examples
Use the following command to display information about the BMP monitoring station, bmp_C:
switch# show bgp monitoring station bmp_C
BGP Monitoring status: enabled
Station - bmp_C
Connection mode: active
VRF: default
Address: 192.0.2.1
Port: 5000
Connection: connected
State: up
Uptime: 00:05:56
Station flap count: 1
Use the following command to display TCP connection statistics for the BMP monitoring station, bmp_C:
switch# show bgp monitoring station bmp_C detail
Station - bmp_C
Connection mode: active
VRF: default
Address: 192.0.2.1
Port: 5000
Connection: connected
State: up
Uptime: 00:13:06
Station flap count: 1
TCP Socket Information:
TCP state is ESTABLISHED
Send-Q: 0/200
Outgoing Maximum Segment Size (MSS): 1448
Total Number of TCP retransmissions: 0
Options:
Timestamps enabled: yes
Selective Acknowledgments enabled: yes
Window Scale enabled: yes
Explicit Congestion Notification (ECN) enabled: no
Socket Statistics:
Window Scale (wscale): 9,9
Retransmission Timeout (rto): 204.0ms
Round-trip Time (rtt/rtvar): 0.1ms/0.1ms
Delayed Ack Timeout (ato): 0.0ms
Congestion Window (cwnd): 10
TCP Throughput: 864.48 Mbps
Advertised Recv Window (rcv_space): 29200
show bgp summary passive
The show bgp monitoring passive command displays information about BMP monitoring stations with Passive mode connections.
Command Mode
EXEC
Command Syntax
show bgp monitoring active [summary | vrfvrf_name]
Parameter
vrfvrf_name - Display information about a specific VRF.
Example
To display a summary of all BMP monitoring stations with passive mode connections, use the following command:
The show bgp update-group command displays how peers are grouped into update groups and can be used to verify that peers with different RCF functions with identical contents are grouped together.
Command Mode
EXEC
Command Syntax
show bgp update-group
Examples
This command displays information about how BGP peers are grouped into update groups.
switch# show bgp update-group
switch#
show flow-spec
The show flow-spec command displays an overall status of how many flowspec rules were received and how many were installed.
Command Mode
EXEC
Command Syntax
show flow-spec (ipv4 | ipv6) [summary][vrfVRFNAME]
Parameters
ipv4 Displays information releated to IPv4.
ipv6 Displays information releated to IPv6.
summary Displays summary of flow-spec rule.
vrfVRFNAME Displays flow-spec information in the named VRF.
The show flow-spec ipv4 summary command displays an overall status of how many flowspec rules were received and how many were installed:
switch(config)# show flow-spec ipv4 summary
Flow specification rules summary for VRF default
Total number of rules: 2
Number of installed rules: 2
The show flow-spec ipv4 displays the installation status of the rule, and a counter of how many hits it has accumulated. This command also compiles the received flowspec rules into rules that can be programmed into the TCAM. For example, logical expressions on values such as the destination port are converted to ranges, as shown below:
switch(config)# show flow-spec ipv4
Flow specification rules for VRF default
Applied on: Ethernet47/1
Flow-spec rule: 10.2.3.0/24;*;
Rule identifier: 3882065752
Matches:
Destination prefix: 10.2.3.0/24
Actions:
Police: 80 Mbps (10 MBps)
Redirect: VRF customer1
Route via LDP tunnel index 4, MPLS label 100123
Route via LDP tunnel index 1, MPLS label 116507
Status:
Installed: yes
Counter: 312 packets
Flow-spec rule: 10.2.4.0/24;10.2.0.0/16;IP:=6|=17;DP:>1010&<1024;
Rule identifier: 3882090640
Matches:
Destination prefix: 10.2.4.0/24
Source prefix: 10.2.0.0/16
Next protocol: 17
6
Destination port: 1011-1023
Actions:
Police: 80 Mbps (10 MBps)
Redirect: VRF customer1
Route via LDP tunnel index 4, MPLS label 100123
Route via LDP tunnel index 1, MPLS label 116507
Status:
Installed: yes
Counter: 0 packets
show ip as-path access-list
The show ip as-path access-list command displays BGP filters on the switch. Specifying an access list displays the statements from that access list. Entering the command without parameters displays the statements from all access lists on the switch.
Command Mode
EXEC
Command Syntax
show ip as-path access-list [list_name]
Parameter
list_name the name of an AS path access list.
Example
This command displays the contents of the AS path access list named list1.
switch# show ip as-path access-list list1
ip as-path access-list list1 deny _3$
ip as-path access-list list1 permit .*
switch#
show ip bgp
The show ip bgp command displays Border Gateway Protocol (BGP) IPv4 routing table entries. The output format depends on the command parameters:
data-block format displays comprehensive information for each specified BGP routing-table entry.
tabular format displays routing-table entries for the specified IPv4 addresses.
Command Mode
EXEC
Command Syntax
show ip bgp [FILTER][VRF_INSTANCE]
Parameters
FILTER routing-table entries to display. Options include:
no parameter displays all routing-table entries in tabular format.
detail displays all routing-table entries in data-block format.
ipv4_addr displays IPv4 host address in data-block format.
PREFIX displays the route information of the specified IPv4 prefix in data block format. Options include:
detailipv4_prefix displays the detailed route information of specified IPv4 prefix in data block format.
longer-prefixesipv4_prefix displays the route information of IPv4 prefix in tabular block format.
longer-prefixesdetailipv4_prefix displays the detailed route information of specified IPv4 prefix in data block format.
community-listcmnty_list_name displays BGP routes filtered by the specified community list.
installed displays the information of installed BGP routes.
labeled-unicast displays the information of labeled-unicast BGP routes only.
not-installed displays the information of BGP routes that are not installed.
no parameter displays routing table for context-active VRF.
vrfvrf_name displays routing table for the specified VRF.
vrfall displays routing table for all VRFs.
vrfdefault displays routing table for default VRF.
Guidelines
You must provide the IPv4 prefix in CIDR notation.
Examples
This command displays the BGP routing table with prefix “L” flag for all BGP LU route entries.
switch# show ip bgp
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 100
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E
- ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop -
Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > L 2.0.0.1/32 1.1.1.2 0 100 0 300 i
* # 2.0.0.1/32 1.0.0.2 0 100 0 200 ?
* > L 2.0.0.2/32 1.1.1.2 0 100 0 300 i
* # 2.0.0.2/32 1.0.0.2 0 100 0 200 ?
* > L 2.0.0.3/32 1.1.1.2 0 100 0 300 i
* # 2.0.0.3/32 1.0.0.2 0 100 0 200 ?
* > L 2.0.0.4/32 1.1.1.2 0 100 0 300 i
* # 2.0.0.4/32 1.0.0.2 0 100 0 200 ?
* > L 2.0.0.5/32 1.1.1.2 0 100 0 300 i
* # 2.0.0.5/32 1.0.0.2 0 100 0 200 ?
This command displays the routing-table information of unicast routes for a default VRF.
switch# show ip bgp
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 100
BGP routing table entry for 2.0.0.1/32
Paths: 2 available
300
1.1.1.2 labels [ 101 102 103 104 ] from 1.1.1.2 (1.1.1.2)
Origin IGP, metric 0, localpref 100, weight 0, valid, external, best
Rx path id: 0x0
200
1.0.0.2 from 1.0.0.2 (0.0.1.1)
Origin INCOMPLETE, metric 0, localpref 100, weight 0, valid, external,
not installed (labeled-route present)
This command displays the BGP routing-table entry for the 10.100.1.0/24 network.
switch# show ip bgp 10.100.1.0/24
BGP routing table information for VRF default
Router identifier 10.0.0.102, local AS number 64500
BGP routing table entry for 10.100.1.0/24
Paths: 1 available
64496 64497 65536
10.1.0.100 from 10.1.0.100 (10.0.0.100)
Origin IGP, metric 0, localpref 100, IGP metric 1, weight 0, received
01:57:33 ago, valid, external, best
Community: 655:23590 64496:1000
Rx SAFI: Unicast
This command displays the label stack associated with the route for a default VRF.
switch# show ip bgp detail
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 100
BGP routing table entry for 2.0.0.1/32
Paths: 2 available
200
1.0.0.2 from 1.0.0.2 (0.0.1.1)
Origin INCOMPLETE, metric 0, localpref 100, weight 0, valid, external, best
300
1.1.1.2 labels [ 101 102 103 104 ] from 1.1.1.2 (1.1.1.2)
Origin IGP, metric 0, localpref 100, weight 0, valid, external
Rx path id: 0x0
Rx SAFI: Labels
Tunnel RIB eligible
This command displays the BGP routing-table entry for the 10.105.1.1/24 network, including the reason why the route was discarded by the best-path algorithm. The reason for discarding a route is preceded by the label “Not best:”.
switch# show ip bgp 10.105.1.1/24 detail
BGP routing table information for VRF default
Router identifier 10.0.0.102, local AS number 64500
Route status: [a.b.c.d] - Route is queued for advertisement to peer.
BGP routing table entry for 10.105.1.0/24
Paths: 2 available
64510
10.2.0.101 from 10.2.0.101 (12.0.0.101)
Origin IGP, metric 0, localpref 100, IGP metric 1, weight 0, received
00:00:58 ago, valid, external, best
Rx SAFI: Unicast
64496
10.1.0.100 from 10.1.0.100 (10.0.0.100)
Origin INCOMPLETE, metric 42, localpref 100, IGP metric 1, weight 0, received
00:00:33 ago, valid, external
Rx SAFI: Unicast
Not best: Origin
Advertised to 2 peers:
peer-group EXTERNAL:
10.1.0.100
peer-group INTERNAL:
10.3.0.103
show ip bgp community
The show ip bgp community command displays Border Gateway Protocol (BGP) routing table entries, filtered by community.
Command Mode
EXEC
Command Syntax
show ip bgp communityCOMM_1 [COMM_2... COMM_n][MATCH_TYPE][DATA_OPTION][VRF_INSTANCE]
Parameters
COMM_x community number or name, as specified in the route map that sets the community list number.
GSHUT well-known graceful shutdown community.
aa:nn AS and network number, separated by colon. Each value ranges from 1 to 4294967295.
comm_num community number. Values range from 1 to 4294967040.
internet advertises route to Internet community.
local-as advertises route only to local peers.
no-advertise does not advertise the route to any peer.
no-export advertises route only within BGP AS boundary.
MATCH_TYPE routes are filtered based on their communities. Options include:
no parameter routes must match at least one community in the list.
exact route must match all communities and include no other communities.
regex display routes matching the regular expression of communities.
DATA_OPTION type of information the command displays. Options include:
no parameter displays table of the routing entry line items.
detail displays data block for each routing table entry.
no parameter displays routing table for context-active VRF.
vrfvrf_name displays routing table for the specified VRF.
vrfall displays routing table for all VRFs.
vrfdefault displays routing table for default VRF.
Guidelines
The interpretation of regular expressions is always based on string mode but not on the ACL configuration.
Example
This command displays the BGP routing table entries with the community 64496:1000.
switch# show ip bgp community 64496:1000 detail
BGP routing table information for VRF default
Router identifier 10.0.0.102, local AS number 64500
BGP routing table entry for 10.100.1.0/24
Paths: 1 available
64496 64497 65536
10.1.0.100 from 10.1.0.100 (10.0.0.100)
Origin IGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:03:16 ago, valid, external, best
Community: 655:23590 64496:1000
Rx SAFI: Unicast
switch#
show ip bgp installed
The show ip bgp installed command displays the list of installed routes in the RIB.
Command Mode
EXEC
Command Syntax
show ip bgp installed
Example
This command displays the list of installed routes in the RIB.
switch# show ip bgp installed
BGP routing table information for VRF default
Router identifier 1.0.0.2, local AS number 100
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E
- ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop -
Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 6.0.0.0/24 1.0.0.1 0 100 0 ?
switch#
show ip bgp neighbors (route type)
The show ip bgp neighbors (route type) command displays information for next-hop routes to a specified IPv4 neighbor. The show ip bgp neighbors (route-type) community command displays the same information for routes filtered by communities.
The output format depends on the selected FILTER parameter:
data-block format displays comprehensive information for each specified route.
tabular format displays routing table entries in tabular format for the specified IP addresses.
Commands that do not include a route type revert to the show ip bgp neighbors command.
Command Mode
EXEC
Command Syntax
show ip bgp neighborsneighbor_addrHOPDIRECT [FILTER] [VRF_INSTANCE]
show ip bgp neighborsneighbor_addr [ROUTE_TYPE] HOPDIRECT [detail]
no parameter displays routing table for context-active VRF.
vrfvrf_name displays routing table for the specified VRF.
vrfall displays routing table for all VRFs.
vrfdefault displays routing table for default VRF.
Example
This command displays information for routes advertised to the neighbor at 10.3.0.103.
switch# show ip bgp neighbors 10.3.0.103 advertised-routes
BGP routing table information for VRF default
Router identifier 10.0.0.102, local AS number 64500
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 10.1.0.0/24 10.3.0.102 - 100 - i
* > 10.2.0.0/24 10.3.0.102 - 100 - i
* > 10.3.0.0/24 10.3.0.102 - 100 - i
* > 10.100.0.0/24 10.1.0.100 200 100 - 64496 i
* > 10.100.1.0/24 10.1.0.100 - 100 - 64496 64497 65536 i
* > 10.100.2.0/24 10.1.0.100 42 100 - 64496 ?
* > 10.101.0.0/24 10.2.0.101 - 100 - 64510 i
* > 10.101.1.0/24 10.2.0.101 - 100 - 64510 i
* > 10.101.2.0/24 10.2.0.101 - 100 - 64510 i
show ip bgp neighbors (route-type) community
The show ip bgp neighbors (route type) community command displays information for next-hop routes to a specified neighbor. Routes are filtered by community.
RTE type of route that the command displays. Options include:
advertised-routes displays routes advertised to the specified neighbor.
received-routes displays routes received from the specified neighbor (accepted and rejected).
routes displays routes received and accepted from specified neighbor.
CM_x community number or name, as specified in the route map that sets the community list number. The command must list at least one of the following community identifiers:
GSHUT well-known graceful shutdown community.
aa:nn AS and network number, separated by colon. Each value ranges from 1 to 4294967295.
comm_num community number. Values range from 1 to 4294967040.
internet advertises route to Internet community.
local-as advertises route only to local peers.
no-advertise does not advertise route to any peer.
no-export advertises route only within BGP AS boundary.
MATCH routes are filtered based on their communities.
no parameter routes must match at least one community in the list.
exact route must match all communities and include no other communities.
INFO type of information the command displays. Values include:
no parameter displays table of routing entry line items.
detail displays data block for each routing table entry.
no parameter displays routing table for context-active VRF.
vrfvrf_name displays routing table for the specified VRF.
vrfall displays routing table for all VRFs.
vrfdefault displays routing table for default VRF.
Example
This command lists the routes advertised to the neighbor at 10.3.0.103 with community 655:23590.
switch# show ip bgp neighbors 10.3.0.103 advertised-routes community 655:23590
BGP routing table information for VRF default
Router identifier 10.0.0.102, local AS number 64500
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 10.100.1.0/24 10.1.0.100 - 100 - 64496 64497 65536 i
show ip bgp neighbors regexp
The show ip bgp neighbors regexp command displays information for next-hop routes to a specified IPv4 neighbor that match the AS path attributes specified in the given regular expression.
Command Mode
EXEC
Command Syntax
show ip bgp neighborsaddrRTEregexpas_paths [VRF_INST]
RTE type of route that the command displays. Options include:
advertised-routes displays routes advertised to the specified neighbor.
received-routes displays routes received from the specified neighbor (accepted and rejected).
routes displays routes received and accepted from specified neighbor.
as_paths list of AS paths, formatted as a regular expression. Regular expressions are pattern-matching strings that are composed of text characters and operators.
no parameter displays routing table for context-active VRF.
vrfvrf_name displays routing table for the specified VRF.
vrfall displays routing table for all VRFs.
vrfdefault displays routing table for default VRF.
Example
This command lists the routes advertised to the neighbor at 10.3.0.103 where the AS path is 64496.
switch# show ip bgp neighbors 10.3.0.103 advertised-routes regex ^64496$
BGP routing table information for VRF default
Router identifier 10.0.0.102, local AS number 64500
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L = labeled-unicast
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST -Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 10.100.0.0/24 10.1.0.100 200 100 - 64496 i
* > 10.100.2.0/24 10.1.0.100 42 100 - 64496 ?
show ip bgp neighbors
The show ip bgp neighbors command displays Border Gateway Protocol (BGP) and TCP-session data for a specified IPv4 BGP neighbor, or for all IPv4 BGP neighbors if an address is not specified.
Command Mode
EXEC
Command Syntax
show ip bgp neighbors [NEIGHBOR_ADDR] [VRF_INSTANCE]
Parameters
NEIGHBOR_ADDR location of the neighbors. Options include:
no parameter command displays information for all IPv4 BGP neighbors.
ipv4_addr command displays information for specified neighbor.
This command displays information of the neighbor at 10.1.0.100.
switch# show ip bgp neighbors 10.1.0.100
BGP neighbor is 10.1.0.100, remote AS 64496, external link
BGP version 4, remote router ID 10.0.0.100, VRF default
Inherits configuration from and member of peer-group EXTERNAL
Negotiated BGP version 4
Member of update group 3
Last read 00:00:17, last write 00:00:18
Hold time is 180, keepalive interval is 60 seconds
Configured hold time is 180, keepalive interval is 60 seconds
Connect timer is inactive
Idle-restart timer is inactive
BGP state is Established, up for 00:05:17
Number of transitions to established: 1
Last state was OpenConfirm
Last event was RecvKeepAlive
Neighbor Capabilities:
Multiprotocol IPv4 Unicast: advertised and received and negotiated
Four Octet ASN: advertised and received and negotiated
Route Refresh: advertised and received and negotiated
Send End-of-RIB messages: advertised and received and negotiated
Additional-paths recv capability:
IPv4 Unicast: advertised
Additional-paths send capability:
IPv4 Unicast: received
Restart timer is inactive
End of rib timer is inactive
Message Statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 4 4
Keepalives: 7 7
Route-Refresh: 0 0
Total messages: 12 12
Prefix Statistics:
Sent Rcvd
IPv4 Unicast: 9 4
IPv6 Unicast: 0 0
IPv4 SR-TE: 0 0
IPv6 SR-TE: 0 0
Inbound updates dropped by reason:
AS path loop detection: 0
Enforced First AS: 0
Originator ID matches local router ID: 0
Nexthop matches local IP address: 0
Unexpected IPv6 nexthop for IPv4 routes: 0
Nexthop invalid for single hop eBGP: 0
Inbound updates with attribute errors:
Resulting in removal of all paths in update (treat-as-withdraw): 0
Resulting in AFI/SAFI disable: 0
Resulting in attribute ignore: 0
Inbound paths dropped by reason:
IPv4 labeled-unicast NLRIs dropped due to excessive labels: 0
IPv6 labeled-unicast NLRIs dropped due to excessive labels: 0
Outbound paths dropped by reason:
IPv4 local address not available: 0
IPv6 local address not available: 0
Local AS is 64500, local router ID 10.0.0.102
TTL is 255, BGP neighbor may be upto 1 hops away
Local TCP address is 10.1.0.102, local port is 179
Remote TCP address is 10.1.0.100, remote port is 33171
Auto-Local-Addr is disabled
TCP Socket Information:
TCP state is ESTABLISHED
Recv-Q: 0/32768
Send-Q: 0/32768
Outgoing Maximum Segment Size (MSS): 1448
Total Number of TCP retransmissions: 0
Options:
Timestamps enabled: yes
Selective Acknowledgments enabled: yes
Window Scale enabled: yes
Explicit Congestion Notification (ECN) enabled: no
Socket Statistics:
Window Scale (wscale): 9,9
Retransmission Timeout (rto): 204.0ms
Round-trip Time (rtt/rtvar): 3.0ms/5.4ms
Delayed Ack Timeout (ato): 40.0ms
Congestion Window (cwnd): 10
TCP Throughput: 39.20 Mbps
Advertised Recv Window (rcv_space): 28960
This command displays neighbor information for all neighbors.
switch# show ip bgp neighbors
BGP neighbor is 172.24.77.5, remote AS 100, external link
BGP version 4, remote router ID 172.24.77.5, VRF default
...
Neighbor Capabilities:
Multiprotocol IPv4 Unicast: advertised
Multiprotocol IPv4 Labeled Unicast: advertised and received and negotiated
Four Octet ASN: advertised and received
Route Refresh: advertised
Send End-of-RIB messages: advertised
Additional-paths Receive:
IPv4 Unicast: advertised
IPv4 Labeled Unicast: advertised
...
Inbound updates dropped by reason:
AS path loop detection: 0
Enforced First AS: 0
Malformed MPBGP routes: 0
Originator ID matches local router ID: 0
Nexthop matches local IP address: 0
Unexpected IPv6 nexthop for IPv4 routes: 0
Inbound paths dropped by reason:
IPv4 labeled-unicast NLRIs dropped due to excessive labels: 0
show ip bgp not-installed
The show ip bgp not-installed command displays the list of non-installed routes in the RIB.
Command Mode
EXEC
Command Syntax
show ip bgp not-installed
Example
This command displays the list of non-installed routes in the RIB.
switch# show ip bgp not-installed
BGP routing table information for VRF default
Router identifier 1.0.0.2, local AS number 100
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E
- ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop -
Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* # 7.0.0.0/24 1.0.0.1 0 100 0 ?
switch#
show ip bgp paths
The show ip bgp paths command displays all BGP AS paths in the database.
Command Mode
EXEC
Command Syntax
show ip bgp paths [VRF_INSTANCE]
Parameters
VRF_INSTANCE specifies VRF instances.
no parameter displays routing table for context-active VRF.
vrfvrf_name displays routing table for the specified VRF.
vrfall displays routing table for all VRFs.
vrfdefault displays routing table for default VRF.
Display Values
Refcount: number of routes using a listed path.
Metric: the path’s Multi Exit Discriminator (MED).
Path: the route’s AS path and its origin code.
Example
This command displays all BGP AS paths in the switch’s database.
switch# show ip bgp paths
Refcount Metric Path
6 0 64510 64505 64506 64507 i (HashID 9)
6 0 64510 ? (HashID 8)
12 0 65530 65531 65532 e (HashID 5)
12 0 i (HashID 6)
6 0 64100 64200 i (HashID 4)
28 0 i (HashID 1)
7 0 ? (HashID 2)
40 0 64510 i (HashID 10)
19 0 64510 i (HashID 7)
2 0 i (HashID 3)
show ip bgp peer-group
The show ip bgp peer-group command displays the BGP version, address family, and group members for all BGP peer groups defined on the switch.
Command Mode
EXEC
Command Syntax
show ip bgp peer-group [GROUP][VRF_INSTANCE]
Parameters
GROUP peer group for which command displays information. Options include:
no parameter command displays information for all peer groups.
group_name name of peer group for which command displays information.
VRF_INSTANCE specifies VRF instances.
no parameter displays routing table for context-active VRF.
vrfvrf_name displays routing table for the specified VRF.
vrfall displays routing table for all VRFs.
vrfdefault displays routing table for default VRF.
Example
This command displays BGP peer group information for all peer groups on the switch.
switch# show ip bgp peer-group
BGP peer-group is EXTERNAL
BGP version 4
Static peer-group members:
VRF default:
10.1.0.100, state: Connect
Negotiated MP Capabilities:
IPv4 Unicast: No
IPv6 Unicast: No
IPv4 SR-TE: No
IPv6 SR-TE: No
10.2.0.101, state: Connect
Negotiated MP Capabilities:
IPv4 Unicast: No
IPv6 Unicast: No
IPv4 SR-TE: No
IPv6 SR-TE: No
BGP peer-group is INTERNAL
BGP version 4
Listen-range subnets:
VRF default:
10.3.0.0/24, remote AS 64500
Dynamic peer-group members:
VRF default:
show ip bgp regexp
The show ip bgp regexp command displays Border Gateway Protocol (BGP) IPv4 routing-table entries that match the AS path attributes specified in the given regular expression.
Command Mode
EXEC
Command Syntax
show ip bgp regexpas_paths [VRF_INSTANCE]
Parameters
as_paths list of AS paths, formatted as a regular expression. Regular expressions are pattern matching strings that are composed of text characters and operators.
Note: The AS delimiter (_) regular expression is not supported when BGP routes are filtered by community lists and the command output does not display BGP route information.
VRF_INSTANCE specifies the VRF instance of the BGP routing table to be displayed. Options include:
no parameter displays routing table for context-active VRF.
vrfvrf_name displays routing table for the specified VRF.
vrfall displays routing table for all VRFs.
vrfdefault displays routing table for default VRF.
Example
This command displays information about the BGP IPv4 routes in the context-active VRF where the AS path is 64510.
switch# show ip bgp regex ^64510$
BGP routing table information for VRF default
Router identifier 10.0.0.102, local AS number 64500
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L = labeled-unicast
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST -Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* 10.2.0.0/24 10.2.0.101 0 100 0 64510 i
* > 10.101.0.0/24 10.2.0.101 0 100 0 64510 i
* > 10.101.1.0/24 10.2.0.101 0 100 0 64510 i
* > 10.101.2.0/24 10.2.0.101 0 100 0 64510 i
show ip bgp summary
The show ip bgp summary command displays the summary of all IPv4 and IPv6 BGP neighbors based on exchanged Address Family Identifiers (AFI) and Subsequent Address Family Identifiers (SAFI) negotiations where AFI is “IP” and SAFI is “unicast” information.
no parameter displays routing table for context-active VRF.
vrfvrf_name displays routing table for the specified VRF.
vrfall displays routing table for all VRFs.
vrfdefault displays routing table for default VRF.
Display Values
Header Row
BGP router identifier: the router identifier loopback address or highest IP address.
Local AS Number: AS number assigned to the switch.
Neighbor Table Columns
(First) Neighbor: neighbor’s IP address.
(Second) V: BGP version number.
(Third) AS: neighbor's AS number.
(Fourth) MsgRcvd: messages received from the neighbor.
(Fifth) MsgSent: messages sent to neighbor.
(Sixth) InQ: messages queued from neighbor.
(Seventh) OutQ: messages queued to send neighbor.
(Eighth) Up/Down: period the BGP session has been Established, or its current status.
(Ninth) State: State of the BGP session and the number of routes received from a neighbor.
After the maximum number of routes are received, the ninth field displays PfxRcd, and the connection becomes Idle. Maximum number of routes is set using the maximum paths (BGP) command.
This command displays the status of the switch’s BGP connections.
switch# show ip bgp summary
BGP summary information for VRF default
Router identifier 10.0.0.102, local AS number 64500
Neighbor Status Codes: m - Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc
10.1.0.100 4 64496 1075 1083 0 0 00:04:04 Connect
10.2.0.101 4 64510 1079 1088 0 0 00:04:14 Connect
show ip community-list
The show ip community-list command displays the BGP community lists configured on the switch.
Command Mode
EXEC
Command Syntax
show ip community-list [COMMUNITY_LIST]
Parameters
COMMUNITY_LIST community list for which command displays information. Options include:
no parameter command displays information for all community lists.
listname name of the community list (text string).
Example
This command displays the BGP paths in the switch’s database.
switch# show ip community-list hs-comm-list
ip community-list hs-comm-list permit 0:10
show ip extcommunity-list
The show ip extcommunity-list command displays the BGP extended community lists configured on the switch.
Command Mode
EXEC
Command Syntax
show ip extcommunity-list [COMMUNITY_LIST]
Parameters
COMMUNITY_LIST extended community list for which command displays information. Options include:
no parameter command displays information for all extended community lists.
listname command displays information for the specified extended community list.
Example
This command displays information for all extended extcommunity lists on the switch.
switch# show ip extcommunity-list
ip extcommunity-list hs-extcomm-list permit rt 3050:20
ip extcommunity-list hs-extcomm-list permit soo 172.17.52.2:30
ip extcommunity-list hs-extcomm-list permit rt 3050:70000
show ipv6 bgp
The show ipv6 bgp command displays IPv6 Border Gateway Protocol (BGP) routing-table entries. The output format depends on the command parameters:
data-block format displays comprehensive information for each specified BGP routing-table entry.
tabular format displays routing-table entries for specified IPv6 addresses.
Command Mode
EXEC
Command Syntax
show ipv6 bgp [FILTER][VRF_INSTANCE]
Parameters
FILTER routing table entries that the command displays. Options include:
no parameter displays all routing-table entries in tabular format.
detail displays all routing-table entries in data-block format.
ipv6_addr displays IPv6 host address in data-block format.
ipv6_prefix displays the route information of specified IPv6 prefix address in data-block format. Options include:
detail displays the detailed route information of specified IPv6 prefix address in data-block format.
longer-prefixes displays the route information of IPv6 prefix in data-block format.
longer-prefixesdetail displays detailed route information of specified IPv6 prefix in data-block format.
community-listcmnty_list_name displays BGP routes filtered by the specified community list.
installed displays the information of installed BGP routes.
labeled-unicast displays the information of labeled-unicast BGP routes only.
not-installed displays the information of BGP routes that are not installed.
no parameter displays routing-table for context-active VRF.
vrfvrf_name displays routing table for the specified VRF.
vrfall displays routing table for all VRFs.
vrfdefault displays routing table for default VRF.
Example
This command displays information in data-block format for each routing-table entry with community 655:23590.
switch(config)# show ipv6 bgp match community 655:23590 detail
BGP routing table information for VRF default
Router identifier 10.0.0.102, local AS number 64500
BGP routing table entry for 2001:10:100:1::/64
Paths: 1 available
64496 64497 65536
2001:10:1::100 from 2001:10:1::100 (10.0.0.100)
Origin IGP, metric 0, localpref 100, IGP metric 1, weight 0, received 01:09:29 ago, valid, external, best
Community: 655:23590 64496:1000
Rx SAFI: Unicast
switch(config)#
show ipv6 bgp peers
The show ipv6 bgp peers command displays IPv6 Border Gateway Protocol (BGP) and TCP session data for a specified neighbor. Command displays data for all neighbors if an address is not included.
Command Mode
EXEC
Command Syntax
show ipv6 bgp peers [NEIGHBOR_ADDR] [VRF_INSTANCE]
Parameters
NEIGHBOR_ADDR location of the neighbors. Options include:
no parameter command displays information for all neighbors.
ipv6_addr command displays information for the specified neighbor.
This command displays information for the neighbor at 2001:10:1:0::100.
switch# show ipv6 bgp peers 2001:10:1:0::100
BGP neighbor is 2001:10:1::100, remote AS 64496, external link
BGP version 4, remote router ID 10.0.0.100, VRF default
Inherits configuration from and member of peer-group EXTERNAL
Negotiated BGP version 4
Member of update group 3
Last read 00:00:01, last write 00:00:01
Hold time is 180, keepalive interval is 60 seconds
Configured hold time is 180, keepalive interval is 60 seconds
Connect timer is inactive
Idle-restart timer is inactive
BGP state is Established, up for 00:12:01
Number of transitions to established: 1
Last state was OpenConfirm
Last event was RecvKeepAlive
Neighbor Capabilities:
Multiprotocol IPv6 Unicast: advertised and received and negotiated
Four Octet ASN: advertised and received and negotiated
Route Refresh: advertised and received and negotiated
Send End-of-RIB messages: advertised and received and negotiated
Additional-paths recv capability:
IPv6 Unicast: advertised
Additional-paths send capability:
IPv6 Unicast: received
Restart timer is inactive
End of rib timer is inactive
Message Statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 4 5
Keepalives: 14 14
Route-Refresh: 0 0
Total messages: 19 20
Prefix Statistics:
Sent Rcvd
IPv4 Unicast: 0 0
IPv6 Unicast: 6 4
IPv4 SR-TE: 0 0
IPv6 SR-TE: 0 0
Inbound updates dropped by reason:
AS path loop detection: 0
Enforced First AS: 0
Originator ID matches local router ID: 0
Nexthop matches local IP address: 0
Unexpected IPv6 nexthop for IPv4 routes: 0
Nexthop invalid for single hop eBGP: 0
Inbound updates with attribute errors:
Resulting in removal of all paths in update (treat-as-withdraw): 0
Resulting in AFI/SAFI disable: 0
Resulting in attribute ignore: 0
Inbound paths dropped by reason:
IPv4 labeled-unicast NLRIs dropped due to excessive labels: 0
IPv6 labeled-unicast NLRIs dropped due to excessive labels: 0
Outbound paths dropped by reason:
IPv4 local address not available: 0
IPv6 local address not available: 0
Local AS is 64500, local router ID 10.0.0.102
TTL is 1
Local TCP address is 2001:10:1::102, local port is 45983
Remote TCP address is 2001:10:1::100, remote port is 179
Auto-Local-Addr is disabled
TCP Socket Information:
TCP state is ESTABLISHED
Recv-Q: 0/32768
Send-Q: 0/32768
Outgoing Maximum Segment Size (MSS): 1428
Total Number of TCP retransmissions: 0
Options:
Timestamps enabled: yes
Selective Acknowledgments enabled: yes
Window Scale enabled: yes
Explicit Congestion Notification (ECN) enabled: no
Socket Statistics:
Window Scale (wscale): 9,9
Retransmission Timeout (rto): 204.0ms
Round-trip Time (rtt/rtvar): 1.4ms/2.7ms
Delayed Ack Timeout (ato): 40.0ms
Congestion Window (cwnd): 10
TCP Throughput: 80.00 Mbps
Advertised Recv Window (rcv_space): 28800
show ipv6 bgp peers (route type)
The show ipv6 bgp peers (route type) command displays information about the routes either advertised to or received from a specified IPv6 BGP neighbor. The show ipv6 bgp peers (route type) community command displays the same information for routes filtered by communities. Commands that do not include a route type revert to the show ipv6 bgp peers command.
The output format depends on the selected FILTER parameter:
data-block format displays comprehensive information for each specified route.
tabular format displays routing table entries in tabular format for the specified IP addresses.
Output produced by the longer-prefixes option includes the specified route and all more specific routes.
Command Mode
EXEC
Command Syntax
show ipv6 bgp peersneighbor_addrHOPDIRECT [FILTER] [VRF_INSTANCE]
show ipv6 bgp peersneighbor_addr [ROUTE_TYPE] HOPDIRECT [detail]
Parameters
neighbor_addr location of the neighbor.
ROUTE_TYPE filters route on route type. Options include:
ipv4unicast displays IPv4 unicast routes.
ipv6unicast displays IPv6 unicast routes.
HOPDIRECT filters route on the basis of direction from neighbor. Options include:
advertised-routes displays routes advertised to the specified neighbor.
received-routes displays routes received from the specified neighbor (accepted and rejected).
routes displays routes received and accepted from specified neighbor.
FILTER routing table entries that the command displays. Options include:
no parameter displays all routing table entries in tabular format.
detail displays all routing table entries in data-block format.
ipv6_addr displays the IPv6 host address in data-block format.
ipv6_prefix displays the route information of specified IPv6 prefix in data-block format. Additional option:
longer-prefixes displays the route information of IPv4 prefix in data-block format.
This command displays information of all routes advertised to the neighbor at 2001:10:1:0::100.
switch# show ipv6 bgp peers 2001:10:1:0::100 advertised-routes
BGP routing table information for VRF default
Router identifier 10.0.0.102, local AS number 64500
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 2001:10:1::/64 2001:10:1::102 - - - 64500 i
* > 2001:10:2::/64 2001:10:1::102 - - - 64500 i
* > 2001:10:3::/64 2001:10:1::102 - - - 64500 i
* > 2001:10:101::/64 2001:10:1::102 - - - 64500 64510 i
* > 2001:10:101:1::/64 2001:10:1::102 - - - 64500 64510 i
* > 2001:10:101:2::/64 2001:10:1::102 - - - 64500 64510 i
switch#
show ipv6 bgp peers (route type) community
The show ipv6 bgp peers (route type) community command displays information about the routes either advertised to or received from a specified IPv6 BGP neighbor. The routes are filtered by community.
show ipv6 bgp peersaddrRTEcommunityCM_1 [CM_2...CM_n] [MATCH] [INFO] [VRF_INST]
Parameters
addr neighbor location (IPv6 address).
RTE type of route that the command displays. Options include:
advertised-routes displays routes advertised to the specified neighbor.
received-routes displays routes received from the specified neighbor (accepted and rejected).
routes displays routes received and accepted from specified neighbor.
CM_x community number or name, as specified in the route map that sets the community list number. The command must list at least one of the following community identifiers:
GSHUT well-known graceful shutdown community.
aa:nn AS and network number, separated by colon. Each value ranges from 1 to 4294967295.
comm_num community number. Values range from 1 to 4294967040.
internet advertises route to Internet community.
local-as advertises route only to local peers.
no-advertise does not advertise route to any peer.
no-export advertises route only within BGP AS boundary.
MATCH routes are filtered based on their communities. Options include:
no parameter routes must match at least one community in the list.
exact route must match all communities and include no other communities.
INFO type of information the command displays. Values include:
no parameter displays table of the routing entry line items.
detail displays data block for each routing table entry.
This command lists the routes advertised to the neighbor at 2001:10:1:0::102 with the community 64496:1000.
switch# show ipv6 bgp peers 2001:10:1:0::102 advertised-routes community 64496:1000
BGP routing table information for VRF default
Router identifier 10.0.0.100, local AS number 64496
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 2001:10:100:1::/64 2001:10:1::100 - - - 64496 64497 65536 i
switch#
show ipv6 bgp peers regexp
The show ipv6 bgp peers regexp command displays information about routes (advertised or received) from a specified IPv6 neighbor that match the AS-path attributes specified in the given regular expression.
Command Mode
EXEC
Command Syntax
show ipv6 bgp peersaddrROUTEregexpas_paths [VRF_INST]
Parameters
addr neighbor location (IPv6 address).
ROUTE type of route that the command displays. Options include:
advertised-routes displays routes advertised to the specified neighbor.
received-routes displays routes received from the specified neighbor (accepted and rejected).
routes displays routes received and accepted from specified neighbor.
as_paths list of AS paths, formatted as a regular expression. Regular expressions are pattern-matching strings that are composed of text characters and operators.
This command displays information for routes received from the neighbor at 2001:10:1:0::100 which include AS number 64496 in their AS paths.
switch# show ipv6 bgp peers 2001:10:1:0::100 received-routes regex 64496
BGP routing table information for VRF default
Router identifier 10.0.0.102, local AS number 64500
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* 2001:10:1::/64 2001:10:1::100 42 - - 64496 ?
* > 2001:10:100::/64 2001:10:1::100 200 - - 64496 i
* > 2001:10:100:1::/64 2001:10:1::100 - - - 64496 64497 65536 i
* > 2001:10:100:2::/64 2001:10:1::100 42 - - 64496 ?
switch#
show ipv6 bgp regexp
The show ipv6 bgp regexp command displays Border Gateway Protocol (BGP) IPv6 routing-table entries that match the AS-path attributes specified in the given regular expression.
Command Mode
EXEC
Command Syntax
show ipv6 bgp regexpas_paths [VRF_INSTANCE]
Parameters
as_paths slist of AS paths, formatted as a regular expression. Regular expressions are pattern matching strings that are composed of text characters and operators.
VRF_INSTANCE specifies the VRF instance of the BGP routing table to be displayed. Options include:
no parameter displays routing table for context-active VRF.
vrfvrf_name displays routing table for the specified VRF.
vrfall displays routing table for all VRFs.
vrfdefault displays routing table for default VRF.
This command displays information about the BGP IPv6 routes in the context-active VRF that pass through AS 64496.
switch# show ipv6 bgp regex _64496_
BGP routing table information for VRF default
Router identifier 10.0.0.102, local AS number 64500
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L = labeled-unicast
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST -Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* 2001:10:1::/64 2001:10:1::100 42 100 0 64496 ?
* > 2001:10:100::/64 2001:10:1::100 200 100 0 64496 i
* > 2001:10:100:1::/64 2001:10:1::100 0 100 0 64496 64497 65536 i
* > 2001:10:100:2::/64 2001:10:1::100 42 100 0 64496 ?
switch#
show ipv6 bgp summary
The show ipv6 bgp summary command displays the summary of all IPv4 and IPv6 BGP neighbors based on Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI) negotiations where AFI is “IPv6” and SAFI is “Unicast” information.
This command displays the status of the switch’s BGP connections.
switch# show ipv6 bgp summary
BGP summary information for VRF default
Router identifier 10.0.0.102, local AS number 64500
Neighbor Status Codes: m - Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc
2001:10:1::100 4 64496 37 36 0 0 00:29:33 Estab 4 4
2001:10:2::101 4 64510 35 38 0 0 00:29:37 Estab 4 4
switch#
show peer-filter
The show peer-filter command displays the definition of a peer filter.
Command Mode
EXEC
Command Syntax
show peer-filterfilter_name
Parameter
filter_name name of the peer-filter group.
Example
This command displays the peer-filter group information for group3.
switch# show peer-filter group3
peer-filter group3
10 match as-range 65003 result accept
20 match as-range 65007 result accept
30 match as-range 65009 result accept
switch#
show run|section bgp
When using the show run command, it displays the entire running configuration. Sometimes this is unnecessary, so to target your output you can use the show run|section bgp command which will display only the BGP section.
Command Mode
bgp-router
Command Syntax
show run | section bgp [name]
Parameter
name name of the peer-group.
Example
Once the peer group request are completed, then run the show run|section bgp command to display only the BGP section of the running configuration.
The show tunnel rib brief command displays the preferred tunnels for various IP endpoints, optionally filtered by endpoint. Each tunnel RIB entry in the output displays the type of the tunnel (such as BGP LU) and a numerical index uniquely identifying that tunnel within the type-specific tunnel table.
Command Mode
EXEC
Command Syntax
show bgp tunnel rib brief
Example
This command displays the tunnel type and the index value.
switch# show tunnel rib brief
Endpoint Tunnel Type Indexes
----------------- ----------------- -------
10.1.1.0/32 BGP LU 2
11.1.1.0/32 BGP LU 1, 3
switch#
shutdown (BGP)
The shutdown command disables BGP on the switch without modifying the BGP configuration.
The no shutdown and default shutdown commands enable the BGP instance by removing the shutdown command from running-config.
switch(config)# router bgp 9
switch(config-router-bgp)# no shutdown
switch(config-router-bgp)#
shutdown
The shutdown command closes TCP sessions on BMP monitoring stations. For an active mode connection, stops initiating TCP connections to the BMP monitoring station. For a passive mode connection, the router stops accepting TCP connections from the BMP monitoring station.
Access this command in the Monitoring Station Configuration Mode.
Command Mode
Monitoring Station Configuration
Command Syntax
shutdown
Example
To shutdown BMP monitoring station, bmp_E, use the following commands:
The timers bgp command configures the BGP keepalive and hold times.Timer settings apply to each peer connection. The neighbor timers command configures the times on a specified peer connection.
Keepalive time: period between the transmission of consecutive keepalive messages.
Hold time: period the switch waits for a keepalive or UPDATE message before it disables peering.
The hold time must be at least 3 seconds and should be three times longer than the keepalive setting.
The no timers bgp and default timers bgp commands return the time settings to their default values by removing the timers bgp command from running-config. The default values are:
keepalive: 60 seconds.
hold time: 180 seconds.
Command Mode
Router-BGP Configuration
Command Syntax
timers bgpkeep_alivehold_time
no timers bgp
default timers bgp
Parameters
keep_alive keepalive period, in seconds. Values include:
0 keepalive messages are not sent.
1 to 3600 keepalive time (seconds).
hold_time hold time. Values include:
0 peering is not disabled by timeout expiry; keepalive packets are not sent.
3 to 7200 hold time (seconds).
Example
This command sets the keepalive time to 30 seconds and the hold time to 90 seconds.
The update-source command specifies a local source interface for the BGP monitoring session. Access this command in Monitoring Station Configuration Mode.
Command Mode
Monitoring Station Configuration
Command Syntax
update-sourceinterface
Parameter
interface - Specify a local interface to send the source IP address from the router for the TCP session.
Example
Use the following commands to specify the interface, Eth1/1, and use the source IP address:
The update wait-for-convergence command disables FIB updates and route advertisement when the BGP instance is initiated until the BGP convergence state is reached.
The no update wait-for-convergence command allows FIB updates and route advertisement irrespective of the BGP convergence state.
Command Mode
Router-BGP Configuration
Command Syntax
update wait-for-convergence
no update wait-for-convergence
default update wait-for-convergence
Related Commands
clear ip bgp removes learned BGP routes from the routing table, reads all routes from designated peers, and sends routes to those peers as required.
show bgp convergence displays information about the BGP convergence state; and other statistics about the BGP instance in either the specified VRF or all VRFs.
Guidelines
The initiation of BGP instance includes the following scenarios:
the BGP instance starts for the first time after a switch is reloaded.
the BGP instance restarts.
all sessions are cleared by using the clear ip bgp * command.
Configuration changes made by using this command are effective from the next initiation of a BGP instance.
Example
This command disables FIB updates and route advertisement when the BGP instance is initiated until the BGP convergence state is reached.
The update wait-install command causes BGP to defer the advertisement of routes until the routes have been programmed in hardware. This applies to new routes and does not affect routes that have already been advertised to peers.
vrf
The vrf command places the switch in BGP VRF configuration mode for the specified VRF. Commands issued in this mode will override global BGP configuration for the specified VRF.
Command Mode
Router-BGP Configuration
Command Syntax
vrfvrf_instance
Parameter
vrf_instance VRF to be configured.
Example
These commands place the switch in BGP VRF configuration mode for VRF purple.
Using maintenance mode, you can perform several maintenance activities, such as:
EOS image upgrade.
Initial configuration or reconfiguration of a production system.
Replacement of hardware.
Changing line cards or transceiver modules.
Replace, reattach, and reroute cables.
Maintenance mode uses BGP to reroute traffic from the switch when performing maintenance tasks,
minimizing traffic impact. Set the traffic thresholds and time limits at which the
switch or parts of the switch are considered available for maintenance tasks.
You can activate maintenance mode on a switch at boot-up or during operation. The mode provides
the following benefits:
Rerouting of traffic when activating the mode during operation and other routes
are present.
Replace hardware in modular systems or redundant hardware systems.
The switch is placed into maintenance mode, serviced, and returned to normal operation.
Maintenance Mode Elements
Maintenance mode elements include Units, Groups of
Interfaces and BGP Peers, and Profiles. Arista Network switches perform maintenance mode
operations on a fundamental, configurable element called a Unit. Maintenance
mode will quiesce a unit, which places the unit into maintenance mode by
gracefully transitioning traffic away from it.
For the most common maintenance mode operations, such as removing an entire switch system or
individual switch components, including a single line card, interface, or
BGP peer, from service, minimal configuration is required.
Units
Units contain configurable maintenance mode elements that comprise a collection of various
groups. In addition, units contain policies that decide if the member groups should be
put into maintenance mode automatically upon boot. By default, EOS configures built-in
units, such as the System unit representing the entire system. EOS executes all
maintenance mode operations at the Unit level.
Built-in Units
Various built-in units, such as System and Linecard<n> consist of fixed
systems with only one built-in unit called System, which comprises the interface
group containing all Ethernet interfaces, sub-interfaces and BGP groups per VRF
containing all the peers in the respective VRF.
Modular Systems have both System and Linecard<n> units. EOS
hasLinecard<n> units for each line card, which comprises the
Linecard<n> groups containing all Ethernet interfaces and
sub-interfaces of that line card.
User-configured Units
You can also configure customized units containing user-defined groups and policies. The
following example creates a custom group called BG1 with a
custom interface IG1 and a unit profile
UP1. The show command
displays the details.
Example
switch(config)# maintenance
switch(config-maintenance)# unit UNIT1
switch(config-unit-UNIT1)# group bgp BG1
switch(config-unit-UNIT1)# group interface IG1
switch(config-unit-UNIT1)# profile unit UP1
switch(config-unit-UNIT1)# exit
switch(config-maintenance)# show maintenance units
Unit Name: System
Origin: Built-in
Status: Not Under Maintenance
Unit Profile: Default
Time Since Last State Change: never
Bgp Groups:
AllBgpNeighborVrf-default
Interface Groups:
AllEthernetInterface
Unit Name: UNIT1
Origin: User Configured
Status: Under Maintenance
Unit Profile: UP1
Time Since Last State Change: 0:00:08 ago
Bgp Groups:
BG1
Interface Groups:
IG1
Groups of Interfaces and BGP
Peers
Maintenance mode group types include the groups for interfaces and BGP peers. A unique group name
identifies a particular group type.
By default, EOS provides several built-in groups on the device such as linecard groups
containing physical interfaces.
Built-in Groups
Several built-in groups include AllEthernetInterface, Linecard1, Linecard2,
and AllBgpNeighborVrf-vrf_name.
AllEthernetInterface contains the built-in interface group with all physical
Ethernet interfaces and sub-interfaces on the switch as part of the System unit.
Linecard1, Linecard2, and other groups, are the built-in groups
containing respective line card interfaces and sub-interfaces, and are part of the
Linecard1 and Linecard2 units, respectively.
AllBgpNeighborVrf-vrf_name, a built-in BGP group, contains all
the BGP peers in that particular VRF.
User-defined Groups
The following series of commands creates a custom group (IG1)
of interfaces, which includes physical ports, port-channels, and SVIs.
Profiles contain configurable maintenance mode elements that define policies for
related software or hardware components to carry out maintenance mode operations.
Default Profiles
Default profiles use built-in policies applied to groups interface/BGP and unit.
The system uses the default profile in the absence of an explicit interface or BGP
profile associated with the group or explicit unit profile associated with
the unit.
BGP Profile
The default BGP profile has route-map with Set
clauses set community GSHUT additive and
set local-preference
0.
switch(config-maintenance)# show maintenance profile bgp default
Bgp Profile: Default
Initiator route-map: SystemGenerated
route-map SystemGenerated permit 10
Description:
description System generated initiator route-map
Match clauses:
SubRouteMap:
Set clauses:
set local-preference 0
set community GSHUT additive
Interface Profile
Default interface profile has rate-monitoring
load-interval set to 60
seconds, threshold set to
100 kbps, and
shutdown disabled as shown. The
max-delay parameter is set to
300 seconds but not
enabled.
Default unit profile with the on-boot setting
disabled.
switch(config-maintenance)# show maintenance profiles unit default
Unit Profile: Default
On-boot:
enabled: no
duration: 300 seconds
User-defined Profiles
Define your profiles and associate them with groups or set as default profiles.
Interface Profile: The following set of commands creates an Interface Profile
(IP1) with a load interval set to
10 seconds, a rate-monitoring
threshold set to 100kbps, and a maximum delay for
shutting down the interface set to 100 seconds.
The interface will be shut down with cause maint-down if
traffic does not drain below the threshold even after the specified maximum
delay period of 100 seconds.
BGP Profile: The following set of commands sets up a BGP profile
(BP1) with an initiator route map
called RM that applies to both inbound and outbound directions..
Unit Profile: The following set of commands sets up a Unit profile
(UP1) with an on-boot duration of
300 seconds. The unitenters into
maintenance mode at boot-up and exit maintenance mode at the end of
5 minutes
(300sec) after boot-up.
A Unit profile can be associated to a Unit using the following commands.
switch(config)# maintenance
switch(config-maintenance)# unit UNIT1
switch(config-unit-UNIT1)# profile unit UP1
switch(config-unit-UNIT1)# exit
switch(config-maintenance)#
You can set the Unit profile as the default
Unit profile using the following set of commands.
switch(config)# maintenance
switch(config-maintenance)# profile unit UP1 default
switch(config-maintenance)# exit
switch(config)#
Maintenance Profile Selection Order
When an interface or BGP peer belongs to multiple maintenance units, EOS applies
a single maintenance profile to the specific object. The chosen
profile dictates the exact maintenance behavior.
If multiple profiles exist in EOS, EOS selects the profile with the highest ASCII order. User-defined profiles have precedence over
built-in profiles.
ASCII Value Order - EOS selects the profile name
with the highest ASCII value.
EOS uses ASCII case-sensitivity that sorts uppercase letters before
lowercase letters, for example, Z precedes a.
Therefore, a lowercase profile name such as
myprofile overrides an uppercase
profile name such as SHUTDOWN.
Table 1. Selection Examples
Conflicting Profiles
Selected Profile
ASCII Logic
NOOP_SYSTEM and
SHUTDOWN_LINKS
SHUTDOWN_LINKS
S ranks higher than N
NOOP_BGP and
SHUTDOWN_BGP
SHUTDOWN_BGP
S ranks higher than N
SHUTDOWN and
noop
noop
Lowercase n ranks higher than
uppercase S
Maintenance Mode Features
Arista Network switches provide maintenance mode features including, rate monitoring,
BGP maintenance route map, on-boot maintenance, and EventMgr integration.
Rate Monitoring
Rate monitoring provides a mechanism for monitoring traffic on interfaces identified for
maintenance. You can set the traffic threshold and a time limit for shutting down the
interface for maintenance tasks.
Configure the shutdown parameter in the interface profile that
signals the interface to shut down after it has entered maintenance mode.
The max-delay parameter specifies the maximum number of seconds
for traffic to dissipate from the interface before shutting it down.
The default interface profile settings appear in the output of the show maintenance
profile interface default command.
Note: EOS does not support the exclusive rate monitoring of sub-interfaces. Sub-interfaces inherit
the interface profile from their parent interface. Regarding multiple sub-interfaces
configured for a single parent interface, rate monitoring of the parent interface
includes aggregate values of all respective sub-interfaces.
BGP Maintenance Route Map
Route-maps are used within a BGP maintenance profile to tag the inbound and outbound
routes to direct traffic away from the unit.
The default profile tags the inbound and outbound routes with the global shutdown community.
Other methods, such as alternate communities or AS_PATH prepend
operations, can be configured under the route map.
On-boot Maintenance
There are two ways of placing a unit in maintenance mode on switch boot-up:
Place the unit into maintenance mode before the switch reboots, and save the running-config
before the switch boot-up.
The on-boot property in the unit maintenance profile specifies that the unit goes into
maintenance mode as part of the boot-up, and remains so for the specified
duration.
Note: The duration value in the on-boot unit maintenance
profile starts when the unit enters maintenance mode on
boot-up.
Single Event Upset Handling
All electronic devices are subject to interference from cosmic radiation. Arista products
use a combination of hardware and software to detect and correct the results
of this interference automatically. For instance, many chip memories contain
parity or Error Correcting Code (ECC) bits. However, Single Event Handling
(SEU) is a random event, and the following configuration determines the
handling behavior.
switch(config)# platform sand seu
switch(config-sand-seu)#
By default, the system corrects the first instance of an ECC or parity event
without logging. However, the system logs a message if a further error
occurs within a 4-hour time window, whether related to the first or not.
The following example illustrates changing the default 4-hour logging window and
detecting a second SEU within 3 hours (10800
seconds) from a prior SEU.
switch(config-sand-seu)# log window 10800 seconds
Hardware uses static memories to hold configuration and determine switching behavior.
When SEUs occur, repairs are made automatically. The following command
disables automatic repair by a specific agent.
The following command disables dynamic memories globally. Dynamic memories are
internal memory the hardware uses to hold transient data, such as packet
header
encapsulations.
All SEU interrupt names are in the form of
<block>_ECC_<type>Int.
The block indicates the part of a switch chip affected. The type can
be one of the following:
Ecc_1bErr - Single bit error
in ECC-protected memory, corrected automatically in
hardware.
Ecc_2bErr - Two bit error in
ECC-protected memory detected, requires software
correction.
ParityErr - Single bit error
in parity protected memory detected, requires
software correction.
Single bit ECC errors do not affect the correct operation of the switch.
Two bit ECC and parity errors can disrupt correct operation, for
example, by dropping one or more packets or by misforwarding
packets. The exact effect depends on the memory and location
affected by the SEU.
Maintenance Mode Configuration
You can configure maintenance mode for the entire device, specific line cards, or any other Unit
and set up the configuration for maintenance mode for the device
at boot-up or while it is running.
Note: EOS does not support xxplicit maintenance of sub-interfaces. Sub-interfaces go into
maintenance implicitly in the case of built-in unit maintenance
and interface maintenance but not in the case of user-configured
units.
Unit Configuration
Arista Network switches provide the ability to place the switch in maintenance mode, provide
configuration options for groups and profiles, associate profiles with groups and units, and
perform maintenance mode operations.
System is a predefined (built-in) unit on all switches. Built-in groups include
AllEthernetInterface, AllBgpNeighborVRF-<vrf_name>, and
Linecardn.
Linecardn can also be a built-in unit and differentiated depending on the command, as
shown in the following examples.
switch(config-maintenance)# unit Linecardn
switch(config)# group interface Linecardn
Built-in unit System comprises the following groups:
AllEthernetInterface provides a built-in interface group that contains all
physical Ethernet interfaces on the switch on a fixed system.
Linecardn provides a built-in interface group that contains all interfaces for
the line card numbered n for modular systems.
AllBgpNeighborVRF-<vrf_name> provides a built-in BGP group that contains
all the BGP peers in the named VRF.
For each Linecard n,the switch has a built-in unit consisting of all the
Linecardn groups.
By default, EOS applies the default interface and BGP profiles to the built-in interface and BGP
groups, and applies the default built-in unit profile to the built-in unit. You can also
configure your own profiles and choose a default.
In the following example, traffic flows through multiple switches in the spine to and from one
switch to another when you elect to put one of the Units (entire switch or parts of the
switch) in the spine switch in maintenance mode. The traffic then gracefully steers away from
the Unit, provided other paths are available. Traffic continues to flow through the Unit
placed into maintenance mode if no other path is available.
Example
Note: The illustration shows an entire switch as the Unit. Replace
switch with Linecardn or another relevant Unit as appropriate.Figure 1. Traffic Flow Pattern Between TOR and Core Before Maintenance Figure 2. Traffic Flow Pattern Between TOR and Core After Unit on Spine-1 is put into
Maintenance
For the earlier example, you can see the status of the Unit (System) using the
show maintenance units System command before placing the system
into maintenance mode. If the device being placed into maintenance mode is Modular and the
Unit is a line card, replace the argument System with Linecardn to see the
status of the Unit
(Linecardn).
switch(config)# show maintenance units System
Unit Name: System
Origin: Built-in
Status: Not Under Maintenance
Unit Profile: Default
Time Since Last State Change: never
Bgp Groups:
AllBgpNeighborVrf-default
Interface Groups:
AllEthernetInterface
Place the Unit (System) into maintenance mode and recheck the status using the following
series of commands.
switch(config-maintenance)# unit System
switch(config-builtin-unit-System)# quiesce
switch(config-builtin-unit-System)# exit
switch(config-maintenance)# show maintenance
Flags:
o - On-boot maintenance
v - Violating traffic threshold
Unit Name Status Time since last change Flags
---------------------- ----------------------- -------------------------- -----
System Under Maintenance 0:02:03 ago
switch(config-maintenance)# show ip bgp summary
BGP summary information for VRF default
Router identifier 1.1.1.1, local AS number 101
Neighbor Status Codes: m - Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State
PfxRcd PfxAcc
m 1.1.1.2 4 100 24 17 0 0 00:00:40 Estab 5 5
m 3.3.3.33 4 102 15 16 0 0 00:06:23 Estab 1 1
Note: The o flag appears for on-boot
maintenance in the show maintenance command, and the
m neighbor status flag in the show ip bgp
summary command indicates that the peer is in maintenance mode.
On-boot Maintenance Mode Configuration
To configure on-boot maintenance, you can use one of two methods:
quiesce config, or
on-boot profile
Configuring Maintenance Mode Using the quiesce Command
Perform the following tasks to place the Unit in maintenance mode on boot-up using
the quiesce command.
Place the unit into maintenance mode before switch reboot using the following
commands.
switch(config)# maintenance
switch(config-maintenance)# unit System
switch(config-unit-System)# quiesce
switch(config-unit-System)# exit
switch(config-maintenance)# show maintenance
Flags:
o - On-boot maintenance
v - Violating traffic threshold
Unit Name Status Time since last change Flags
--------- ------ ---------------------- -----
System Under Maintenance 00:01:10 ago
Save the running-config using the following command.
switch(config)# reload
Proceed with reload? [Confirm] Yes
Connection to switch closed.
After the device comes up, you must execute the no
quiesce command for the Unit to come out of maintenance
mode. Check the status of the device after it comes up using the
show maintenance command.
switch# show maintenance
Flags:
o - On-boot maintenance
v - Violating traffic threshold
Unit Name Status Time since last change Flags
--------- ------ ---------------------- -----
System Under Maintenance 00:03:10 ago
Configuring Maintenance Mode Using the on-boot Profile
The on-boot property in the Unit maintenance profile
specifies that the Unit will be placed into maintenance mode during boot-up for the
specified duration. To use this method, you must perform the following tasks.
Check whether the on-boot maintenance mode is enabled using the
show maintenance profiles unit default.
switch# show maintenance profiles unit default
Unit Profile: Default
On-boot:
enabled: no
duration: 300 seconds
Configure an on-boot profile with on-boot enabled and a
duration specified. Make this the default Unit profile. The following code
example shows the creation of an on-boot duration of
300 seconds in the profile unit
UP1.
switch(config)# maintenance
switch(config-maintenance)# profile unit UP1
switch(config-profile-unit-UP1)# on-boot duration 300
switch(config-profile-unit-UP1)# exit
switch(config-maintenance)# profile unit UP1 default
switch(config-maintenance)# show maintenance profiles unit default
Unit Profile: UP1
On-boot:
enabled: yes
duration: 300 seconds
switch(config-maintenance)#
After the device comes up, execute the show
maintenance and show maintenance units
System commands.
switch(config)# show maintenance
Flags:
o - On-boot maintenance
v - Violating traffic threshold
Unit Name Status Time since last change Flags
--------- ------ ---------------------- -----
System Under Maintenance 00:00:08 ago o
switch(config)# show maintenance units System
Unit Name: System
Origin: Built-in
Status: Under Maintenance (on-boot)
Unit Profile: UP1
Time Since Last State Change: 0:00:16 ago
Will come out of on-boot Maintenance after 0:04:43
Interface Groups:
AllEthernetInterface
History:
2017-01-18 00:44:39 old state: 'maintenanceModeEnter' to new state:
'underMaintenance' 0:00:16 ago
2017-01-18 00:43:54 old state: 'active' to new state: 'maintenanceModeEnter'
0:01:01 ago
The o - flag shows that the unit, System, is under maintenance due to the
on-boot profile. Also, show maintenance units
System output shows the following - Will
come out of on-boot Maintenance after 0:04:43, which is
the time remaining of the specified duration of 5
minutes.
The Unit will come up in maintenance mode when the device boots up and will
exit maintenance mode when the specified duration of
300 seconds in the default profile
finishes. The BGP sessions will remain under maintenance for the duration
and will resume after the specified duration ends.
Interface-level Maintenance Mode Configuration
To configure the maintenance mode at the interface-level, you must perform the
following tasks:
Configure an interface-level profile (or use a pre-configured one). The
following code example creates a user-defined interface profile IP1 with a
rate-monitoring load-interval of 100 seconds, a
rate-monitoring threshold of 500 kbps and a maximum
shutdown delay of 100 seconds.
Remove the interface from maintenance mode after the service has been
performed.
switch(config-maintenance)# interface Ethernet 1
switch(config-maint-if-Et1)# no quiesce
Note: If interface Et1 has sub-interfaces
(Et1.1, Et1.2,
etc.) with BGP peers on these sub-interfaces, then these sub-interfaces are
also placed into maintenance mode. The show maintenance
interface sub-interface detail command displays the
maintenance state of sub-interfaces.
Enter configuration commands unit and no quiesce using the maintenance profile bgp mode command for the switch to exit maintenance mode.
The following code sequence causes unit ex1, the
interface 3/3, and BGP
1.1.1.1 to exit maintenance
mode.
Example
switch(config)# maintenance
switch(config-maintenance)# unit ex1
switch(config-unit-ex1)# no quiesce
switch(config-unit-ex1)# exit
switch(config-maintenance)# interface ethernet 3/3
switch(config-maint-if-Et3/3)# quiesce
switch(config-unit-if-Et3/3)# exit
switch(config-maintenance)# bgp 1.1.1.1
switch(config-maint-bgp-1.1.1.1)# no quiesce
switch(config-maint-bgp-1.1.1.1)# exit
switch(config-maintenance)#
Configuring Event Handlers
Enter configuration options for the show maintenance command to fire at
different stages while entering or exiting maintenance mode.
Example for Maintenance Mode Event Handler
for all Stages
switch(config)# event-handler ex1
switch(config-handler-ex1)# trigger on-maintenance enter unit unit-ex1 all
switch(config-handler-ex1)# action bash /mnt/flash/mm-event-handler-script
switch(config-handler-ex1)# timeout 20
switch(config-handler-ex1)# exit
switch(config)#
Note: The system expects a configured timeout value as this is when the
script should complete execution and exit. If the script has not
exited by the end of this period, then the following will occur:
Send the SIGUSR1 signal to the
script.
Wait for a GRACE-PERIOD of
10 seconds for the
script to exit.
If the script does not exit even after that
GRACE-PERIOD, then send a
SIGKILL to the
script.
The maintenance operation progresses to the next
stage.
GRACE-PERIOD is not
configurable.
switch(config)# event-handler bar
switch(config-handler-bar)# trigger on-maintenance exit unit unit-ex1 before
stage ratemon
switch(config-handler-bar)# action bash /mnt/flash/mm-event-handler-script
switch(config-handler-bar)# exit
switch(config)#
Configuring Groups
Enter the maintenance mode configuration options for groups with the maintenance and group bgp commands.
Note: An interface or BGP profile can be associated with the interface
group, and a BGP profile can be associated with the BGP
group.
Configuring Units
Enter the maintenance mode configuration options for units using the unit,
group bgp, and maintenance
commands.
Example
switch(config)# maintenance
switch(config-maintenance)# unit ex1
switch(config-unit-ex1)# group bgp BG1
switch(config-unit-ex1)# group interface IG1
switch(config-unit-ex1)#profile unit UP1
ipv4_addr - Specify the BGP neighbor IPv4
address.
ipv6_addr Specify the BGP neighbor IPv6
address.
peer_group_name Specify the BGP peer group
name.
vrfvrf_name Specify the name of the VRF for the BGP
peer belongs.
quiesce - Execute the maintenance operation.
Example
This command creates dynamic BGP unit for IPv4
address 1.0.1.1, IPv6 addr 1::1
with quiesce and peer-group PG in VRF
VRF1 under maintenance configuration.
The group bgp command places the switch in group-BGP
configuration mode for configuring the members of a BGP group in a particular VRF
and associating a BGP maintenance profile for these members.
The command creates the group if the specified
group does not exist prior to issuing the command.
The no group bgp and default group
bgp removes the BGP group.
Command Mode
Global Configuration
Command Syntax
group bgpgroup_name
no group bgpgroup_name
default group bgpgroup_name
Parameters
group_name name of the BGP group.
Commands available in group-BGP configuration mode:
Note: Built-in BGP groups like
AllBgpNeighborVrf-default and
AllBgpNeighborVrf-<vrf_name> do not allow
neighbor configuration. Only BGP maintenance profile can be associated to
them.
Examples
This command creates a BGP group BG1 and enters
into group BGP BG1 configuration
mode.
switch(config)# group bgp BG1
switch(config-group-bgp-BG1)# show active
group bgp BG1
exit
switch(config-group-bgp-BG1)#
This command enters into BGP built-in configuration mode for
AllBgpNeighborVrf-default.
switch(config)# group bgp AllBgpNeighborVrf-default
switch(config-builtin-group-bgp-AllBgpNeighborVrf-default)#
group bgp AllBgpNeighborVrf-default
exit
switch(config-builtin-group-bgp-AllBgpNeighborVrf-default)# exit
switch(config)# show maintenance groups bgp AllBgpNeighborVrf-default
BGP Group: AllBgpNeighborVrf-default
Origin: Built-in
Neighbors:
Ipv4 Peers: 1.0.0.1, 1.0.1.2
Bgp Profile: Default
Vrf: default
Units: System
switch(config)#
group bgp <group_name>
The group bgp <group_name> command adds a BGP group
to a unit.
The no group bgp <group_name> and default
group bgp <group_name> removes the BGP group from a
unit.
Command Mode
Maintenance Unit Configuration
Command Syntax
group bgpgroup_name
no group bgpgroup_name
default group bgpgroup_name
Parameter
group_name name of the BGP group.
Example
This command adds a BGP group BG1 to unit
UNIT1.
switch(config)# maintenance
switch(config-maintenance)# unit UNIT1
switch(config-unit-UNIT1)# group bgp BG1
switch(config-unit-UNIT1)# show active
maintenance
unit UNIT1
group bgp BG1
switch(config-unit-UNIT1)
group interface
The group interface command places the switch in group-intf
configuration mode for configuring the members of interface group and associating a
BGP/interface maintenance profile for these members.
The command creates the group if the specified group does not exist prior to issuing
the command.
The no group interface <group_name> and
default group interface <group_name> removes
the interface group.
Command Mode
Global Configuration
Command Syntax
group interfacegroup_name
no group interfacegroup_name
default group interfacegroup_name
Parameter
group_name name of the interface group.
Commands available in group-BGP configuration mode:
interface
maintenance profile bgp
maintenance profile interface
Note: Built-in Interface groups like AllEthernetInterface,
Linecard3, Linecard4,
etc. do not allow interface configurations. Only BGP/interface maintenance profiles
can be associated to them.
Examples
This command creates an interface group IG1 and
enters into group interface IG1 configuration
mode.
switch(config)# group interface IG1
switch(config-group-if-IG1)# show active
group interface IG1
exit
switch(config-group-if-IG1)#
This command enters into built-in interface group
AllEthernetInterface.
switch(config)# group interface AllEthernetIntetrface
switch(config-builtin-group-if-AllEthernetInterface)# show active
group interface AllEthernetInterface
exit
switch(config-builtin-group-if-AllEthernetInterface)# exit
switch(config)# show maintenance groups interface AllEthernetInterface
Interface Group: AllEthernetInterface
Origin: Built-in
Interfaces:
Et1, Et2, Et3, Et4, Et5/1, … Et34, Et35, Et36
Profiles:
Interface Profile: Default
Bgp Profile: Default
Units: System#
group interface <group_name>
The group interface <group_name> command adds an
interface to a unit.
The no group interface <group_name> and
default group interface <group_name> removes
the interface group from a unit.
Command Mode
Maintenance Unit Configuration
Command Syntax
group interfacegroup_name
no group interfacegroup_name
default group interfacegroup_name
Parameter
group_name name of the interface group.
Example
This command adds an group interface IG1 to unit
UNIT1.
switch(config)# maintenance
switch(config-maintenance)# unit UNIT1
switch(config-unit-UNIT1)# group interface IG1
switch(config-unit-UNIT1)# show active
maintenance
unit UNIT1
group interface IG1
switch(config-unit-UNIT1)
initiator route-map <route-map-name>
inout
The initiator route-map <route-map-name> inout
command is a maintenance BGP profile configuration option for assigning the
initiator route-map, which will be applied to inout (inbound and outbound).
The no initiator route-map <route-map-name>
inout and default initiator route-map
<route-map-name> inout removes this configuration from
the BGP profile.
Command Mode
Maintenance-Profile-BGP Configuration
Command
Syntax
initiator route-maproute-map-nameinout
no initiator
route-map
default initiator route-map
Parameter
route-map-name initiator
route-map name.
Example
This command configures initiator route-map
RM1 within a BGP profile
BP1.
The interface command adds interfaces to interface
group.
The interface <intf-name> and default
interface <intf-name> removes the interface from the
group.
Command Mode
Group-Interface Configuration
Command Syntax
interfaceinterface-name
no interfaceinterface-name
default interfaceinterface-name
Parameters
interface-name name of the interface.
ethernete_range Ethernet interfaces specified by
e_range.
port-channel p_range port channel interfaces
specified by p_range.
vlan v_range vlans specified by
v_range.
Valid e_range, p_range, and
v_range formats include number, range, or
comma-delimited list of numbers and ranges. Valid Ethernet numbers depend on the
Ethernet interfaces available on the switch.
Example
This command adds Ethernet8,
Ethernet9, and
port-channel10 to the interface group
IG1.
switch(config)# group interface IG1
switch(config-group-if-IG1)# interface Ethernet8-9
switch(config-group-if-IG1)# interface port-channel10
switch(config-group-if-IG1)# show active
group interface IG1
interface Et8-9
interface Po10
switch(config-group-if-IG1)# exit
switch(config)#
interface intf-name
The interface <intf-name> command places the switch
in maintenance dynamic interface unit configuration mode.
The command creates the dynamic interface unit if the specified dynamic interface
unit does not exist prior to issuing the command.
The no interface <intf-name> and default
interface <intf-name> removes the dynamic interface unit
from running-config.
Command Mode
Maintenance Configuration
Command Syntax
interfaceinterface-name
no interfaceinterface-name
default interfaceinterface-name
Parameters
interface-name name of the interface.
ethernete_range Ethernet interfaces specified by
e_range.
port-channelp_range port channel interfaces specified by
p_range.
vlanv_range vlans specified by
v_range.
Valid e_range, p_range and
v_range formats include number, range, or
comma-delimited list of numbers and ranges.
Note: Different dynamic interface units are created for each interface in the
range.
Commands available in maintenance dynamic interface unit configuration
mode:
quiesce
Example
This command creates two dynamic interface units for interfaces
Ethernet1-2 under maintenance configuration.
switch(config)# maintenance
switch(config-maintenance)# interface Ethernet1-2
switch(config-maint-if-Et1-2)# exit
switch(config-maintenance)# show active
maintenance
interface Ethernet1
!
interface Ethernet2
switch(config-maintenance)#
maintenance
The maintenance command allows you to enter maintenance
configuration mode and specify maintenance configuration options.
The no maintenance and default
maintenance command removes the maintenance configuration from
the running-config.
Command Mode
Global Configuration
Command Syntax
maintenance
no maintenance
default maintenance
Commands available in maintenance configuration mode:
unit
bgp
interface
profile bgp
profile interface
profile unit
profile interface <profile-name>
default
profile bgp <profile-name> default
profile unit <profile-name> default
Example
This example shows the commands to enter maintenance configuration mode and configure
maintenance related parameters.
switch(config)# maintenance
switch(config-maintenance)# profile unit foo
switch(config-profile-unit-foo)# on-boot duration 300
switch(config-profile-unit-foo)# exit
switch(config-maintenance)# unit U1
switch(config-unit-U1)# group interface IG1
switch(config-unit-U1)# group bgp BG1
switch(config-unit-U1)# profile unit foo
switch(config-unit-U1)# exit
switch(config-maintenance)# show active
maintenance
profile unit foo
on-boot duration 300
unit U1
group interface IG1
group bgp BG1
profile unit foo
switch(config-maintenance)#
maintenance profile bgp
The maintenance profile bgp <profile-name> command
associates a BGP maintenance profile to an interface/BGP group. A BGP profile can be
associated to both the interface and BGP group.
The no maintenance profile bgp <profile-name> and
default maintenance profile bgp
<profile-name> removes the profile from the interface/BGP
group.
Command Mode
Group-Interface Configuration
Group-BGP Configuration
Built-in-Group-Interface Configuration
Built-in-Group-BGP Configuration
Command Syntax
maintenance profile bgpprofile-name
no maintenance profile bgpprofile-name
default maintenance profile bgpprofile-name
Parameter
profile name name of the BGP profile.
Examples
This command adds BGP profile BP1 to a BGP group
BG1.
switch(config)# group bgp BG1
switch(config-group-bgp-BG1)# neighbor 1.0.1.1
switch(config-group-bgp-BG1)# neighbor 1::1
switch(config-group-bgp-BG1)# neighbor PG
switch(config-group-bgp-BG1)# maintenance profile bgp BP1
switch(config-group-bgp-BG1)# show active
group bgp BG1
neighbor 1.0.1.1
neighbor 1::1
neighbor PG
maintenance profile bgp BP1
switch(config-group-bgp-BG1)# exit
switch(config)#
This command adds BGP profile BP1 to interface group
IG1.
switch(config)# group interface IG1
switch(config-group-if-IG1)# interface Ethernet8-9
switch(config-group-if-IG1)# maintenance profile bgp BP1
switch(config-group-if-IG1)# show active
group interface IG1
interface Et8-9
maintenance profile bgp BP1
switch(config-group-if-IG1)# exit
switch(config)#
This command adds BGP profile BP1 to built-in interface group
AllEthernetInterface.
switch(config)# group interface AllEthernetInterface
switch(config-builtin-group-if-AllEtherentInterface)# maintenance profile bgp BP1
switch(config-builtin-group-if-AllEtherentInterface)# show active
group interface AllEthernetInterface
maintenance profile bgp BP1
switch(config-builtin-group-if-AllEtherentInterface)#
maintenance profile interface
The maintenance profile interface <profile-name>
command associates interface profile to interface group.
The no maintenance profile interface <profile-name>
and default maintenance profile interface
<profile-name> removes the interface profile from interface
group.
Command Mode
Group-Interface Configuration
Built-in-Group-Interface Configuration
Command Syntax
maintenance profile interfaceprofile-name
no maintenance profile interfaceprofile-name
default maintenance profile interfaceprofile-name
Parameter
profile-name name of the interface profile.
Example
This command adds profile interface IP1 to interface group
IG1.
switch(config)# group interface IG1
switch(config-group-if-IG1)# interface Ethernet8-9
switch(config-group-if-IG1)# maintenance profile interface IP1
switch(config-group-if-IG1)# show active
group interface IG1
interface Et8-9
maintenance profile interface IP1
switch(config-group-if-IG1)#
This command adds profile interface IP1 to built-in interface
group AllEthernetInterface.
switch(config)# group interface AllEthernetInterface
switch(config-builtin-group-if-AllEtherentInterface)# maintenance profile
interface IP1
switch(config-builtin-group-if-AllEtherentInterface)# show active
group interface AllEthernetInterface
maintenance profile interface IP1
switch(config-builtin-group-if-AllEtherentInterface)#
neighbor
The neighbor command adds BGP peer(s) to a BGP group. The
neighbors can be IPv4, IPv6, or a peer group. The no neighbor
<peer> and default neighbor
<peer> removes the BGP peer from the group.
Command Mode
Group-BGP Configuration
Command Syntax
neighbor [ipv4_addr |
ipv6_addr | peer group name]
no neighbor [ipv4_addr |
ipv6_addr | peer group name]
default neighbor [ipv4_addr |
ipv6_addr | peer group name]
Parameters
ipv4_addr BGP neighbor ipv4 address.
ipv6_addr BGP neighbor ipv6 address.
peer group name BGP peer group name.
Example
This command adds ipv4 peer 1.0.1.1,
ipv6 peer 1::1, and peer group
PG to the BGP group
BG1.
The on-boot duration command is a maintenance unit profile
configuration option for specifying the duration after which the associated unit
will be brought out of maintenance after reboot. The on-boot property in the
maintenance unit profile specifies that the unit will be placed into maintenance
mode as part of boot-up, and remain so for the specified duration.
The no on-boot and default
on-boot removes this configuration from the unit profile.
Command Mode
Maintenance-Profile-Unit Configuration
Command Syntax
on-boot durationduration
no on-boot
default on-boot
Parameter
duration number of seconds for which unit will remain under
maintenance after reboot (from 300 to
3600 seconds).
Example
This command configures on-boot duration of 1000 seconds in
profile unit UP1.
switch(config)# maintenance
switch(config-maintenance)# profile unit UP1
switch(config-profile-unit-UP1)# on-boot duration 1000
switch(config-profile-unit-UP1)# show active
maintenance
profile unit UP1
on-boot duration 1000
switch(config-profile-unit-UP1)#
profile bgp
The profile bgp command places the switch in maintenance
profile BGP configuration mode for configuring initiator route-map.
The command creates the profile if the
specified BGP profile does not exist prior to issuing the command.
The no profile bgp <profile-name> and
default profile bgp <profile-name> removes
the profile from running-config.
Command Mode
Maintenance Configuration
Command Syntax
profile bgpprofile-name
no profile bgpprofile-name
default profile bgpprofile-name
Parameter
profile-name name of the BGP profile.
Commands available in maintenance profile BGP configuration mode:
initiator route-map (route-map name) inout
Example
This command creates BGP profile BP1.
switch(config)# maintenance
switch(config-maintenance)# profile bgp BP1
switch(config-profile-bgp-BP1)# show active
maintenance
profile bgp BP1
switch(config-profile-bgp-BP1)#
profile bgp <profile_name> default
The profile bgp <profile_name> default command
configures a user-configured BGP profile as default BGP profile.
The no profile bgp <profile_name> default and
default profile bgp <profile_name> default
removes the user-configured BGP profile as default BGP profile.
Command Mode
Maintenance Configuration
Command Syntax
profile bgpprofile_name default
no profile bgpprofile_name default
default profile bgpprofile_name default
Parameter
profile_name name of the BGP profile.
Example
This command configures user configured BGP profile BP1 as default BGP profile.
switch(config)# maintenance
switch(config-maintenance)# profile bgp BP1
switch(config-profile-bgp-BP1)# initiator route-map RM1 inout
switch(config-profile-bgp-BP1)# exit
switch(config-maintenance)#
switch(config-maintenance)# show maintenance profile bgp default
Bgp Profile: Default
Initiator route-map: SystemGenerated
route-map SystemGenerated permit 10
Description:
description System generated initiator route-map
Match clauses:
Set clauses:
set community GSHUT additive
set local-preference 0
switch(config-maintenance)# profile bgp BP1 default
switch(config-maintenance)# show maintenance profile bgp default
Bgp Profile: BP1
Initiator route-map: RM1
switch(config-maintenance)#
switch(config-maintenance)# show active
maintenance
profile bgp BP1
initiator route-map RM1 inout
profile bgp BP1 default
switch(config-maintenance)#
profile interface
The profile interface command places the switch in
maintenance profile interface configuration mode for configuring rate-monitoring
threshold, load-interval, and shutdown max-delay.
The command creates the profile if the
specified interface profile does not exist prior to issuing the command.
The no profile interface <profile-name> and
default profile interface <profile-name>
removes the profile from running-config.
Command Mode
Maintenance Configuration
Command Syntax
profile interfaceprofile-name
no profile interfaceprofile-name
default profile interfaceprofile-name
Parameters
profile-name name of the interface profile.
Commands available in maintenance profile interface configuration mode:
rate-monitoring load-interval
rate-monitoring threshold
shutdown max-delay
Example
This command creates interface profile IP1.
switch(config)# maintenance
switch(config-maintenance)# profile interface IP1
switch(config-profile-intf-IP1)# show active
maintenance
profile interface IP1
switch(config-profile-intf-IP1)#
profile interface <profile_name>
default
The profile interface <profile_name> default command
configures a user-configured interface profile as default interface profile.
The no profile interface <profile_name> default and
default profile interface <profile_name>
default removes the user-configured interface profile as default
interface profile.
Command Mode
Maintenance Configuration
Command Syntax
profile interfaceprofile_name default
no profile interfaceprofile_name default
default profile interfaceprofile_name default
Parameter
profile_name name of the interface profile.
Example
This command configures user configured interface profile
IP1 as default interface profile.
The profile unit command places the switch in maintenance
profile unit configuration mode for configuring on-boot duration.
The command creates the profile if the
specified BGP profile does not exist prior to issuing the command.
The no profile unit <profile-name> and
default profile unit <profile-name> removes
the profile from running-config.
Command Mode
Maintenance Configuration
Command Syntax
profile unitprofile-name
no profile unitprofile-name
default profile unitprofile-name
Parameter
profile-name name of the unit profile.
Commands available in maintenance profile unit configuration mode:
on-boot duration
Example
This command creates unit profile UP1.
switch(config)# maintenance
switch(config-maintenance)# profile unit UP1
switch(config-profile-unit-UP1)# show active
maintenance
profile unit UP1
switch(config-profile-unit-UP1)#
profile unit <profile_name>
The profile unit <profile_name> command associates
unit profile to a particular unit.
The no profile unit <profile_name> and
default profile unit <profile_name> removes
the unit profile from a unit.
Command Mode
Maintenance-Unit Configuration
Maintenance-Built-in-Unit Configuration
Command Syntax
profile unitprofile-name
no profile unitprofile-name
default profile unitprofile-name
Parameter
profile-name name of the unit profile.
Examples
This command adds profile unit UP1 to
UNIT1.
switch(config)# maintenance
switch(config-maintenance)# unit UNIT1
switch(config-unit-UNIT1)# group interface IG1
switch(config-unit-UNIT1)# exit
switch(config-maintenance)# show maintenance units UNIT1
Unit Name: UNIT1
Origin: User Configured
Status: Not Under Maintenance
Unit Profile: Default
Time Since Last State Change: never
Interface Groups:
IG1
switch(config-maintenance)# unit UNIT1
switch(config-unit-UNIT1)#profile unit UP1
switch(config-unit-UNIT1)# show maintenance units UNIT1
Unit Name: UNIT1
Origin: User Configured
Status: Not Under Maintenance
Unit Profile: UP1
Time Since Last State Change: never
Interface Groups:
IG1
switch(config-unit-UNIT1)# show active
maintenance
unit UNIT1
group interface IG1
profile unit UP1
switch(config-unit-UNIT1)#
This command adds profile unit UP2 to built-in unit
System.
switch(config)# maintenance
switch(config-maintenance)#profile unit UP2
switch(config-profile-unit-UP2)# on-boot duration 600
switch(config-profile-unit-UP2)# exit
switch(config-maintenance)#
switch(config-maintenance)# unit System
switch(config-builtin-unit-System)# show active
maintenance
unit System
switch(config-builtin-unit-System)# exit
switch(config-maintenance)# show maintenance units System
Unit Name: System
Origin: Built-in
Status: Not Under Maintenance
Unit Profile: Default
Time Since Last State Change: never
Interface Groups:
AllEthernetInterface
switch(config-maintenance)#
switch(config-maintenance)# unit System
switch(config-builtin-unit-System)# profile unit UP2
switch(config-builtin-unit-System)# show active
maintenance
unit System
profile unit UP2
switch(config-builtin-unit-System)# exit
switch(config-maintenance)# show maintenance units System
Unit Name: System
Origin: Built-in
Status: Not Under Maintenance
Unit Profile: UP2
Time Since Last State Change: never
Interface Groups:
AllEthernetInterface
switch(config-maintenance)#
profile unit <profile_name>
default
The profile unit <profile_name> default command
configures a user-configured unit profile as default unit profile.
The no profile unit <profile_name> default and
default profile unit <profile_name> default
removes the user-configured unit profile as default unit profile.
Command Mode
Maintenance Configuration
Command Syntax
profile unitprofile_namedefault
no profile unitprofile_namedefault
default profile unitprofile_namedefault
Parameters
profile_name name of the interface profile.
Example
This command configures user-configured unit profile UP1 as
the default unit profile.
switch(config)# maintenance
switch(config-maintenance)# profile unit UP1
switch(config-profile-unit-UP1)# on-boot duration 1000
switch(config-profile-unit-UP1)# exit
switch(config-maintenance)#
switch(config-maintenance)# show maintenance profiles unit default
Unit Profile: Default
On-boot:
enabled: no
duration: 300 seconds
switch(config-maintenance)# profile unit UP1 default
switch(config-maintenance)# show maintenance profile unit default
Unit Profile: UP1
On-boot:
enabled: yes
duration: 1000 seconds
switch(config-maintenance)#
switch(config-maintenance)# show active
maintenance
profile unit UP1 default
profile unit UP1
on-boot duration 1000
switch(config-maintenance)#
quiesce
The quiesce command places a unit or dynamic interface/BGP
unit into maintenance mode, gracefully transitioning traffic away from it.
The no quiesce and default
quiesce exits the unit from maintenance.
Command Mode
Maintenance-Unit Configuration
Maintenance-Built-in-Unit Configuration
Maintenance Dynamic-Interface Unit Configuration
Maintenance Dynamic-Bgp Unit Configuration
Command Syntax
quiesce
no quiesce
default quiesce
Example
This command places unit UNIT1, interface
Et1, BGP peer 1.0.1.1 in VRF
default, and BGP peer 1::1 in
vrfVRF1 into maintenance.
switch(config)# group interface IG1
switch(config-group-if-IG1)# interface Ethernet3-6
switch(config-group-if-IG1)# maintenance profile interface IP1
switch(config-group-if-IG1)# exit
switch(config)# maintenance
switch(config-maintenance)# unit UNIT1
switch(config-unit-UNIT1)# group interface IG1
switch(config-unit-UNIT1)# quiesce
switch(config-unit-UNIT1)# exit
switch(config-maintenance)# interface Ethernet1
switch(config-maint-if-Et1)# quiesce
switch(config-maint-if-Et1)# exit
switch(config-maintenance)# bgp 1.0.1.1
switch(config-maint-bgp-1.0.1.1)# quiesce
switch(config-maint-bgp-1.0.1.1)# exit
switch(config-maintenance)# bgp 1::1 vrf VRF1
switch(config-maint-bgp-1::1)# quiesce
switch(config-maint-bgp-1::1)# exit
switch(config-maintenance)# show active
maintenance
bgp 1.0.1.1
quiesce
!
bgp 1::1 vrf VRF1
quiesce
interface Et1
quiesce
unit UNIT1
quiesce
switch(config-maintenance)# show maintenance
Flags:
o - On-boot maintenance
v - Violating traffic threshold
Unit Name Status Time since last change Flags
---------------------- ----------------------- -------------------------- -----
System Not Under Maintenance never
UNIT1 Under Maintenance 0:00:06 ago
Interface Name Status Time since last change Flags
---------------------- ----------------------- -------------------------- -----
Ethernet1 Entering Maintenance 0:00:06 ago
Bgp Neighbor(vrf: defa Status Time since last change Flags
---------------------- ----------------------- -------------------------- -----
1.0.1.1 Under Maintenance 0:00:06 ago
Bgp Neighbor(vrf: VRF1 Status Time since last change Flags
---------------------- ----------------------- -------------------------- -----
1::1 Under Maintenance 0:00:06 ago
switch(config-maintenance)#
rate-monitoring load-interval
The rate-monitoring load-interval command is a maintenance
interface profile configuration option for configuring the interfaces rate
monitoring load interval with a load interval value between 5 and 600 seconds.
The rate-monitoring threshold command is a maintenance
interface profile configuration option for configuring the interfaces rate
monitoring threshold with a threshold value between 1 and
4294967295 kilobytes.
The no rate-monitoring threshold and default
rate-monitoring threshold removes this configuration from the
interface profile.
The show interface command displays detailed information
about the interface.
It displays an extra line that reads:
Under maintenance for time in hours and minutes.
Command Mode
EXEC
Command Syntax
show interfaceintf_name
Parameters
intf_name name of the interface.
ethernete_range Ethernet interfaces specified by
e_range.
port-channelp_range port channel interfaces specified by
p_range.
vlanv_range vlans specified by
v_range.
Note: Valid
e_range,
p_range, and
v_range formats include number, range, or
comma-delimited list of numbers and ranges. Valid Ethernet numbers
depend on the Ethernet interfaces available on the switch.
Example
This command displays detailed information about interface ethernet
16/1.
switch# show interface ethernet 16/1
Ethernet16/1 is up, line protocol is up (connected)
Hardware is Ethernet, address is 001c.7373.efc7
Internet address is 1.0.1.1/24
Broadcast address is 255.255.255.255
Address determined by manual configuration
IP MTU 1500 bytes, BW 40000000 kbit
Full-duplex, 40Gb/s, auto negotiation: off, uni-link: n/a
Up 4 hours, 44 minutes, 36 seconds
Under maintenance for 4 hours, 22 minutes, 26 seconds
Loopback Mode : None
2 link status changes since last clear
Last clearing of "show interface" counters 4:45:12 ago
5 minutes input rate 20 bps (0.0% with framing overhead), 0 packets/sec
5 minutes output rate 20 bps (0.0% with framing overhead), 0 packets/sec
580 packets input, 46286 bytes
Received 1 broadcasts, 0 multicast
0 runts, 0 giants
0 input errors, 0 CRC, 0 alignment, 0 symbol, 0 input discards
0 PAUSE input
601 packets output, 48954 bytes
Sent 7 broadcasts, 15 multicast
0 output errors, 0 collisions
0 late collision, 0 deferred, 0 output discards
0 PAUSE output
switch#
show interface <intf_name>
status
The show interface <intf_name> status command
displays an m flag if the interface is undergoing maintenance operation.
Command Mode
EXEC
Command Syntax
show interface [intf_name]
status
Parameters
intf_name name of the interface.
ethernete_range Ethernet interfaces specified by
e_range.
port-channelp_range port channel interfaces specified by
p_range.
vlanv_range vlans specified by
v_range.
Note: Valid
e_range,
p_range, and
v_range formats include number, range, or
comma-delimited list of numbers and ranges. Valid Ethernet numbers
depend on the Ethernet interfaces available on the
switch.
Example
This command display tabular output and shows m flag for
Ethernet16/1
status.
switch# show interface Ethernet16/1 status
Port Name Status Vlan Duplex Speed Type Flags
Et1 disabled 1 auto auto 1000BASE-T
...
Et14/1 connected 2 full 40G 40GBASE-CR4
Et15/1 connected 2 full 40G 40GBASE-CR4
Et16/1 connected routed full 40G 40GBASE-CR4 m
Et17/1 notconnect 1 full 10G Not Present
...
switch#
show ip | ipv6 bgp
The show ip | ipv6 bgp command displays maintenance related
information when relevant.
Command Mode
EXEC
Command Syntax
show ip bgp neighborspeer_addr [vrfvrf_name]
show ipv6 bgp peerspeer_addr [vrfvrf_name]
Parameters
peer_addr name of the peer.
ipv4_addr BGP neighbor IPv4 address.
ipv6_addr BGP neighbor IPv6 address.
peer-group-name BGP peer group name.
vrf_name name of the VRF.
Example
This command displays the m flag in show ip
bgp summary output for peer 1.0.1.2 which is in
maintenance mode.
switch# show ip bgp neighbors 1.0.1.2
BGP neighbor is 1.0.1.2, remote AS 300, external link
BGP version 4, remote router ID 0.0.2.1, VRF default
Negotiated BGP version 4
Last read 00:00:09, last write 00:00:11
Hold time is 180, keepalive interval is 60 seconds
Configured hold time is 180, keepalive interval is 60 seconds
Connect timer is inactive
Idle-restart timer is inactive
Session is under maintenance
BGP state is Established, up for 04:55:11
Number of transitions to established: 1
Last state was OpenConfirm
Last event was RecvKeepAlive
Neighbor Capabilities:
Multiprotocol IPv4 Unicast: advertised and received and negotiated
Four Octet ASN: advertised and received
Route Refresh: advertised and received and negotiated
Send End-of-RIB messages: advertised and received and negotiated
Additional-paths Receive:
IPv4 Unicast: advertised and received
Restart timer is inactive
End of rib timer is inactive
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 6 2
Keepalives: 297 297
Route-Refresh: 0 0
Total messages: 304 300
Prefix statistics:
Sent Rcvd
IPv4 Unicast: 2 1
IPv6 Unicast: 0 0
Inbound updates dropped by reason:
AS path loop detection: 0
Enforced First AS: 0
Malformed MPBGP routes: 0
Originator ID matches local router ID: 0
Nexthop matches local IP address: 0
Unexpected IPv6 nexthop for IPv4 routes: 0
Nexthop invalid for single hop eBGP: 0
Inbound paths dropped by reason:
IPv4 labeled-unicast NLRIs dropped due to excessive labels: 0
Outbound paths dropped by reason:
IPv4 local address not available: 0
IPv6 local address not available: 0
Maintenance-mode:
Inbound and Outbound policy
Route map is SystemGenerated
Local AS is 200, local router ID 0.0.1.1
TTL is 1
Local TCP address is 1.0.1.1, local port is 179
Remote TCP address is 1.0.1.2, remote port is 51936
Auto-Local-Addr is disabled
TCP Socket Information:
TCP state is ESTABLISHED
Recv-Q: 0/32768
Send-Q: 0/32768
Outgoing Maximum Segment Size (MSS): 1448
Total Number of TCP retransmissions: 0
Options:
Timestamps enabled: yes
Selective Acknowledgments enabled: yes
Window Scale enabled: yes
Explicit Congestion Notification (ECN) enabled: no
Socket Statistics:
Window Scale (wscale): 9,7
Retransmission Timeout (rto): 204.0ms
Round-trip Time (rtt/rtvar): 7.5ms/3.0ms
Delayed Ack Timeout (ato): 40.0ms
Congestion Window (cwnd): 10
TCP Throughput: 15.45 Mbps
Advertised Recv Window (rcv_space): 14480
show ip | ipv6 bgp summary
[ vrf <vrf_name>]
The show ip | ipv6 bgp summary [ vrf <vrf_name>]
command displays the m flag if the BGP IPv4 or IPv6 peer is undergoing maintenance
operation.
Command Mode
EXEC
Command Syntax
show ip bgp summary [vrf vrf_name]
show ipv6 bgp summary [vrf vrf_name]
Parameter
vrf_name name of the VRF.
Example
This command displays the m flag in show ip
bgp summary output for peer 1.0.1.2
which is in maintenance mode.
switch# show ip bgp summary
BGP summary information for VRF default
Router identifier 0.0.1.1, local AS number 200
Neighbor Status Codes: m - Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd
PfxAcc
1.0.0.1 4 100 292 296 0 0 04:47:44 Estab 1 1
m 1.0.1.2 4 300 292 296 0 0 04:47:44 Estab 1 1
show maintenance
The show maintenance command provides brief information
about all units/dynamic interface unit/dynamic bgp unit and status.
o'- flag displays that unit is undergoing or has
undergone a maintenance operation because of on-boot.
v - flag displays that one/some of the interfaces
are violating traffic, i.e. traffic for those interfaces is above threshold.
Command Mode
EXEC
Command Syntax
show maintenance
Example
This command displays maintenance mode
details.
switch# show maintenance
Flags:
o - On-boot maintenance
v - Violating traffic threshold
Unit Name Status Time since last change Flags
---------- ----------------------- ---------------------- -----
System Not Under Maintenance never
Foo Under Maintenance 0:00:40 ago o
Interface Name Status Time since last change Flags
-------------- -------------------- ---------------------- -----
Ethernet16/1 Entering Maintenance 0:00:02 ago v
Bgp Neighbor(vrf: defa Status Time since last change Flags
-------------- ---------------------- ----------------------- -----
1.0.0.2 Not Under Maintenance never
Bgp Neighbor(vrf: red) Status Time since last change Flags
------------- ----------------------- ----------------------- -----
2.0.1.2 Under Maintenance 0:00:16 ago
switch#
show maintenance bgp
The show maintenance bgp command displays detailed
maintenance information about BGP peers.
Command Mode
EXEC
Command Syntax
show maintenance bgpipv4_addr [vrfvrf_name] | ipv6_addr [vrfvrf_name] | peer_group [vrfvrf_name] | ip all [vrfvrf_name | vrfall] | ipv6all [vrfvrf_name | vrfall]
Parameters
ipv4_addr BGP neighbor ipv4 address.
ipv6_addr BGP neighbor ipv6 address.
peer_group BGP peer group name.
vrf_name name of the VRF to which peer
belongs.
ip all vrfvrf_name all ipv4 peers in specified VRF.
ipv6 all vrfvrf_name all ipv6 peers in specified VRF.
ip all vrf all all ipv4 peers in all the
VRFs.
ipv6 all vrf all all ipv6 peers in all the
VRFs.
Example
This command displays maintenance information about BGP peers
1.0.0.1 and 1.0.1.1 and
maintenance route-map
applied.
switch# show maintenance bgp ip all vrf all
BGP peer maintenance information for VRF default
Router identifier 0.0.1.1, local AS number 200
Neighbor: 1.0.0.1
Maintenance state: Under Maintenance
Maintenance route-map: SystemGenerated
Neighbor: 1.0.1.2
Maintenance state: Under Maintenance
Maintenance route-map: SystemGenerated
switch#
show maintenance bgp
receiver route-map
The show maintenance bgp receiver route-map command
displays receiver route-map which is applied during maintenance operation.
Command Mode
EXEC
Command Syntax
show maintenance bgp receiver route-map
Example
This command displays receiver route-map
contents.
switch# show maintenance bgp receiver route-map
route-map SystemGenerated permit 10
Description:
description System generated receiver route-map
Match clauses:
match community GSHUT-LIST
SubRouteMap:
Set clauses:
route-map SystemGenerated permit 50
Description:
description System generated receiver route-map
Match clauses:
SubRouteMap:
Set clauses:
switch#
show maintenance interface status quiesced
This example of the show maintenance interface status quiesced command
displays maintenance mode interface status details for quiesced interfaces.
Example
switch(config)# show maintenance interface status quiesced
Flags:
v - Violating traffic threshold
s - Shutdown for maintenance
Rate (Mbps)
Interface Status In Out Flags
--------- ----------------- --- --- -----
Ethernet1 Under Maintenance 0.3 0.0 v
Ethernet2 Under Maintenance 0.0 0.0
Ethernet4 Under Maintenance 0.0 0.0
switch(config)#
show maintenance debug
The show maintenance debug command displays the history of
various maintenance operations on a unit/interface/BGP peer.
Command Mode
EXEC
Command Syntax
show maintenance debug bgp [peer_name] | interface
[intf_name] | units
[unit_name]
Parameters
bgp display history of all dynamic BGP units which
have undergone maintenance operation.
interface display history of all dynamic interface
units which have undergone maintenance operation.
units display history of all units which have
undergone maintenance operation.
peer_name name of the peer.
ipv4_addr BGP neighbor IPv4 address.
ipv6_addr BGP neighbor IPv6 address.
peer-group-name BGP peer group
name.
intf_name name of the interface.
ethernete_range Ethernet interfaces specified by
e_range.
port-channelp_range port channel interfaces specified
by p_range.
vlanv_range vlans specified by
v_range.
Note: Valid
e_range,
p_range, and
v_range formats include
number, range, or comma-delimited list of numbers and ranges.
Valid Ethernet numbers depend on the Ethernet interfaces
available on the switch.
unit_name name of the unit.
Example
This command displays history of maintenance operation on Ethernet
16/1.
switch# show maintenance debug interface Ethernet 16/1-4
Interface Ethernet16/1
History:
Maintenance Enter Stage Progression started 4:07:07 ago @ 2016-08-29 22:38:54
0.000000 maintEnter stages started
0.000091 stage begin started
0.000151 event begin:EventMgr started
0.004222 event begin:EventMgr completed
0.004256 stage begin is complete
0.004315 stage before_bgp started
0.004368 event before_bgp:EventMgr started
0.005820 event before_bgp:EventMgr completed
0.005843 stage before_bgp is complete
0.005904 stage bgp started
0.005947 event bgp:Rib started
0.013821 event bgp:Rib completed
0.013855 stage bgp is complete
0.013921 stage after_bgp started
0.013974 event after_bgp:EventMgr started
0.015848 event after_bgp:EventMgr completed
0.015878 stage after_bgp is complete
0.015935 stage before_ratemon started
0.015982 event before_ratemon:EventMgr started
0.017394 event before_ratemon:EventMgr completed
0.017423 stage before_ratemon is complete
0.017470 stage ratemon started
0.017506 event ratemon:MaintenanceMode started
5.021404 event ratemon:MaintenanceMode completed
5.021438 stage ratemon is complete
5.021500 stage after_ratemon started
5.021556 event after_ratemon:EventMgr started
5.023223 event after_ratemon:EventMgr completed
5.023247 stage after_ratemon is complete
5.023300 stage end started
5.023352 event end:EventMgr started
5.024683 event end:EventMgr completed
5.024705 stage end is complete
5.024762 maintEnter stages complete
show maintenance groups
The show maintenance groups command displays all the
interface/BGP groups along with their members and associated profiles.
Command Mode
EXEC
Command Syntax
show maintenance groupsinterface | bgpgroup_name
Parameters
interface display only interface groups
bgp display only BGP groups
group_name name of the group
Example
This command displays group details for built-in interface group
AllEthernetInterface and built-in BGP group
AllBgpNeighborVrf-default and user-configured
interface group IG1.
The show maintenance interface command displays detailed
information about interfaces and their maintenance status with traffic rates.
Command Mode
EXEC
Command Syntax
show maintenance interface [intf_name
[detail] | detail]
Parameters
intf_name name of the interface or sub-interface.
Options include:
ethernete_range Ethernet interfaces specified by
e_range.
port-channelp_range port channel interfaces specified
by p_range.
vlanv_range vlans specified by
v_range.
detail provides the detailed rate-monitoring
information
Guidelines
Valid e_range, p_range, and
p_range formats include number, range, or
comma-delimited list of numbers and ranges.
Examples
This command displays interface status and traffic rates.
switch# show maintenance interface
Flags:
v - Violating traffic threshold
s - Shutdown for maintenance
Rate (Mbps)
Interface Status In Out Flags
-------------------- ---------------------------- --------- ---------- ------
Ethernet1 Not Under Maintenance - -
Ethernet2 Not Under Maintenance - -
Ethernet3 Under Maintenance 0.0 0.0
Ethernet4 Not Under Maintenance - -
...
Ethernet35 Entering Maintenance 8.7 2.9
Ethernet36 Not Under Maintenance - -
switch#
This command displays detailed information about the interface
Ethernet16/1.
switch# show maintenance interface Ethernet16/1 detail
Ethernet16/1 is Under Maintenance
Groups: AllEthernetInterface
Selected profiles from Interface groups:
Interface Maintenance profile: low-load-interval-profile
Bgp Maintenance profile: Default
Bgp:
Maintenance State: Under Maintenance
Vrf: default
Neighbor: 1.0.1.2
Maintenance routemap: SystemGenerated
Rate Monitoring:
Passive monitoring since 0:42:25 ago
Total samples taken: 236
Before Maintenance:
Below threshold: 1
Above threshold: 0
After Maintenance:
Below threshold: 235
Above threshold: 0
Last sample information:
Sample taken 0:00:04 ago
In: 0.0 Mbps
Out: 0.0 Mbps
switch#
show maintenance interface
status
The show maintenance interface status command displays
maintenance status and rates for interfaces.
Command Mode
EXEC
Command Syntax
show maintenance interface status [active |
entering | exiting |
quiesced]
Parameters
active interfaces which are active.
entering interfaces which are entering
maintenance.
exiting interfaces which are exiting
maintenance.
quiesced interfaces which are under
maintenance.
Example
This command displays interface status and traffic rates of interfaces which are
quiesced.
switch# show maintenance interface status quiesced
Flags:
v - Violating traffic threshold
s - Shutdown for maintenance
Rate (Mbps)
Interface Status In Out Flags
-------------------- ---------------------------- ----- ------ ------
Ethernet1 Not Under Maintenance - -
Ethernet2 Not Under Maintenance - -
Ethernet3 Not Under Maintenance - -
Ethernet4 Not Under Maintenance - -
Ethernet16/1 Under Maintenance 0.0 0.0
Port-Channel10 Under Maintenance 100.5 50.5v
Port-Channel11 Entering Maintenance 15.5 10.5
Port-Channel10 Under Maintenance - -
switch#
show maintenance profiles
The show maintenance profiles command displays all the
interface/BGP/unit profiles configuration.
Command Mode
EXEC
Command Syntax
show maintenance profilesinterface | bgp | unitprofile_name
Parameters
interface display only interface profiles.
bgp display only BGP profiles.
unit display only unit profiles.
profile_name name of the profile.
Example
This command displays profile configuration details for interface profile
IP1, unit profile UP1
and BGP profile BP1.
The show maintenance summary command displays summarized
information about the maintenance mode operations such as number of units
configured, number of units Entering/Exiting maintenance etc.
Command Mode
EXEC
Command Syntax
show maintenance summary
Example
This command displays summary of maintenance mode operations.
switch# show maintenance summary
Number of Units Configured: 0
Number of Units Exiting Maintenance: 0
Number of Units Entering Maintenance: 0
Number of Units Not Under Maintenance: 1
Number of Units Under Maintenance: 0
Directly Put Under Maintenance:
Number of interfaces Entering Maintenance: 0
Number of interfaces Under Maintenance: 1
Number of bgp peers Entering Maintenance: 0
Number of bgp peers Under Maintenance: 1
Rate Monitoring:
Number of interfaces Entering Maintenance: 0
Number of interfaces Under Maintenance: 1
Number of interfaces Under Maintenance with threshold violation: 0
Number of interfaces shutdown for maintenance: 0
switch#
show maintenance units
The show maintenance units command displays detailed
information about the particular unit.
Command Mode
EXEC
Command Syntax
show maintenance units [unit_name]
Parameters
unit_name name of unit.
Example
This command displays maintenance units details.
switch# show maintenance units
Unit Name: System
Origin: Built-in
Status: Not Under Maintenance
Unit Profile: Default
Time Since Last State Change: never
Bgp Groups:
AllBgpNeighborVrf-default
Interface Groups:
AllEthernetInterface
Unit Name: UNIT1
Origin: User Configured
Status: Under Maintenance
Unit Profile: UP1
Time Since Last State Change: 0:00:08 ago
Bgp Groups:
BG1
Interface Groups:
IG1
History:
2016-08-29 23:05:30 old state: 'maintenanceModeEnter' to new state:
'underMaintenance' 0:00:08 ago
2016-08-29 23:05:30 old state: 'active' to new state: 'maintenanceModeEnter'
0:00:08 ago
shutdown max-delay
The shutdown max-delay command is a maintenance interface
profile configuration option for configuring the maximum duration after which the
interface is shutdown with a value between 1 and
4294967295 seconds.
The no shutdown and default
shutdown removes this configuration from the interface
profile.
Command Mode
Maintenance-Profile-Interface Configuration
Command Syntax
shutdown max-delaydelay
no shutdown max-delaydelay
default shutdown max-delaydelay
Parameter
delay maximum shutdown delay between
1 and 4294967295
seconds.
Example
This command configures the shutdown max-delay for the profile interface
IP1 to 500 seconds or
1 hour.
The trigger on-maintenance command is an event handler
configuration for triggering actions during the maintenance operation of a unit,
interface and BGP peer at specified stages.
The event-handler configuration takes
effect only after exiting the event-handler configuration mode.
enter trigger on-maintenance event-handler on
maintenance enter operation.
exit trigger on-maintenance event-handler on
maintenance exit operation.
bgp trigger event-handler on dynamic BGP unit
maintenance operation.
pv4_addr BGP neighbor ipv4 address.
pv6_addr BGP neighbor ipv6 address.
peer_group BGP peer group name.
vrf vrf_name name of the VRF to which BGP peer
belongs.
interface trigger event-handler on dynamic
interface unit maintenance operation.
intf_name name of the interface.
ethernet trigger event-handler on
specified Ethernet interface.
port-channel trigger event-handler
on specified port channel interface.
vlan trigger event-handler on
specified VLAN.
Note: Comma-delimited list, ranges
are not supported.
unit trigger event-handler on maintenance
operation of unit.
begin action is triggered in the beginning of
maintenance operation.
end action is triggered at the end of maintenance
operation.
stage_name action is triggered at specified
stage.
bgp and ratemon
are the two stages.
all action is triggered at all the
stages.
before action is triggered before the specified
stage.
after action is triggered after the specified
stage.
Examples
This command configures event-handler E1, which triggers
on maintenance an enter operation of unit UNIT1 at
all the stages.
switch(config)# event-handler E1
switch(config-handler-E1)# trigger on-maintenance enter unit UNIT1 all
switch(config-handler-E1)# action bash FastCli -c "show maintenance"
switch(config-handler-E1)# exit
switch(config)# show event-handler E1
Event-handler E1
Trigger: Asynchronous on-maintenance enter unit UNIT1 all delay 0 seconds
Threshold Time Window: 0 Seconds, Event Count: 1 times
Action: FastCli -c "show maintenance"
Action expected to finish in less than 10 seconds
Last Trigger Detection Time: Never
Total Trigger Detections: 0
Last Trigger Activation Time: Never
Total Trigger Activations: 0
Last Action Time: Never
Total Actions: 0
switch(config)#
This command configures event-handler E2, which
triggers on maintenance an exit operation of dynamic interface unit
Ethernet1 before stage bgp.
switch(config)# event-handler E2
switch(config-handler-E2)# trigger on-maintenance exit interface Ethernet1 before
stage bgp
switch(config-handler-E2)# action bash FastCli -c "show maintenance summary"
switch(config-handler-E2)# exit
switch(config)# show event-handler E2
Event-handler E2
Trigger: Asynchronous on-maintenance exit interface Ethernet1 before stage bgp
delay 0 seconds
Threshold Time Window: 0 Seconds, Event Count: 1 times
Action: FastCli -c "show maintenance summary"
Action expected to finish in less than 10 seconds
Last Trigger Detection Time: Never
Total Trigger Detections: 0
Last Trigger Activation Time: Never
Total Trigger Activations: 0
Last Action Time: Never
Total Actions: 0
switch(config)#
This command configures event-handler E3, which
triggers on maintenance an enter operation of dynamic BGP unit
1::1 in VRF VRF1
at the last stage end.
switch(config)# event-handler E3
switch(config-handler-E3)# trigger on-maintenance enter bgp 1::1 vrf VRF1 end
switch(config-handler-E3)# action bash FastCli -c "show maintenance bgp ip all vrf
all"
switch(config-handler-E3)# exit
switch(config)# show event-handler E3
Event-handler E3
Trigger: Asynchronous on-maintenance enter bgp 1::1 vrf VRF1 end delay 0 seconds
Threshold Time Window: 0 Seconds, Event Count: 1 times
Action: FastCli -c "show maintenance bgp ip all vrf all"
Action expected to finish in less than 10 seconds
Last Trigger Detection Time: Never
Total Trigger Detections: 0
Last Trigger Activation Time: Never
Total Trigger Activations: 0
Last Action Time: Never
Total Actions: 0
switch(config)#
unit
The unit <unit_name> command places the switch in
maintenance unit configuration mode for configuring BGP/interface groups in the
unit.
The command creates the unit if the specified unit profile does not exist prior to
issuing the command.
The no unit <unit-name> and default unit
<unit-name> removes the unit from
running-config.
Command Mode
Maintenance Configuration
Command Syntax
unit linecard [l_range | 0
l_range | unit_name]
no unit linecard [l_range | 0
l_range | unit_name]
default unit linecard [l_range | 0
l_range | unit_name]
Parameters
l_range name of the Linecard built-in unit.
0 l_range linecards available on the switch.
unit_name name of the user-configured unit.
Commands available in maintenance unit configuration mode:
group interface
group bgp
profile unit
quiesce
Note: Built-in units like System,
Linecard3, Linecard4, etc. do not allow group configuration but unit
profile can be associated to these units.
Examples
This command creates maintenance unit
UNIT1.
switch(config)# maintenance
switch(config-maintenance)# unit UNIT1
switch(config-unit-UNIT1)# show active
maintenance
unit UNIT1
switch(config-unit-UNIT1)#
This command enters the built-in Linecard1 unit
configuration mode.
switch(config)# maintenance
switch(config-maintenance)# unit Linecard1
switch(config-builtin-unit-Linecard1)# show active
maintenance
unit Linecard1
switch(config-builtin-unit-Linecard1)#
vrf
The vrf command specifies the VRF for BGP group. All the
neighbors configured in the BGP group are considered to be members of the BGP group
in the particular VRF context.
The no vrf <vrf-name> and default vrf
<vrf-name> removes the VRF configuration from the BGP
group and sets the VRF context to default.
Command Mode
Group-BGP Configuration
Command Syntax
vrfvrf_name
no vrfvrf_name
default vrfvrf_name
Parameter
vrf_name name of the VRF in a group belonging to neighbors
in that group.
Example
This command specifies VRF VRF1 for the neighbors in the
BGP group BGP1.
switch(config)# group bgp BG1
switch(config-group-bgp-BG1)# neighbor 1.0.1.1
switch(config-group-bgp-BG1)# neighbor 1::1
switch(config-group-bgp-BG1)# neighbor PG
switch(config-group-bgp-BG1)# vrf VRF1
switch(config-group-bgp-BG1)# show active
group bgp BG1
neighbor 1.0.1.1
neighbor 1::1
neighbor PG
vrf VRF1
switch(config-group-bgp-BG1)# exit
switch(config)#
The switch uses rule-based lists to control packet access to ports and to select routes for redistribution to routing domains defined by dynamic routing protocols.
This section describes the construction of Access Control Lists (ACLs), prefix lists, and route maps and includes the following topics:
The following provides an introduction to Access Control Lists (ACL), Service ACLs, Route Maps, Prefix Lists, and Router Access Control List (RACL) Divergence:
The switch processes ACLs, Service ACLs, route maps, and prefix lists in order, beginning with the first rule and continuing until a match is found.
An ACL contains a list of rules that control the inbound and outbound flow of packets into Ethernet interfaces, subinterfaces, port-channel interfaces, or the switch control plane. The switch supports implementing various filtering criteria, including IP and MAC addresses and TCP/UDP ports, with include/exclude options without compromising its performance or feature set. Filtering syntax is the industry standard.
Note: EOS supports egress IPv4 and IPv6 Port Access Control Lists (PACLs) by default. To enable egress MAC PACLs, add the configuration to the current TCAM profile.
A Service ACL applies a control-plane process to control connections to, or packets processed by, the agent process.
A route map contains a list of rules that control the redistribution of IP routes into a protocol domain based on criteria such as route metrics, access control lists, next-hop addresses, and route tags. Additionally, route maps can modify route parameters during redistribution.
A prefix list contains a list of rules that defines route redistribution access for a specified IP address space. Route maps often use prefix lists to filter routes.
The RACL divergence optimizes hardware resource usage on each forwarding ASIC. EOS installs ACLs only on the hardware components corresponding to the member interfaces of the SVIs with an applied ACL, and saves hardware resources and scales the RACLs to a larger configuration.
Tip: Use the show commands to display the interface mapping, Ternary Content Addressable Memory (TCAM) entries, and TCAM utilization information.
IPv4 matches on IPv4 source or destination addresses, with L4 modifiers including protocol, port number, IPsec tunnel interfaces, and DSCP value.
IPv6 matches on IPv6 source or destination addresses, with L4 modifiers including protocol, port number, or GRE tunnel interface.
Standard IPv4 matches only on source IPv4 addresses.
Standard IPv6 matches only on source IPv6 addresses.
MAC matches on L2 source and destination addresses.
ACLs can also be made dynamic using payload, turning them into a User-Defined Field (UDF) alias for use in other ACLs.
ACL Structure
An ACL is an ordered list of rules that defines access restrictions for the entities (the control plane or an interface) to which it is applied. Route maps also use ACLs to select routes for redistribution into specified routing domains.
ACL rules specify the data to which packet contents are compared when filtering data.
The interface forwards packets that match all commands in a permit rule.
The interface drops packets that match all commands in a deny rule.
The interface drops packets that do not match at least one rule.
Upon its arrival at an interface, the switch compares a packet’s fields to the first rule of the ACL applied to the interface. Packets that match the rule are forwarded (permit rule) or dropped (deny rule). The process continues whereby the switch compares packets that do not match the rule to the next rule in the list and continues until the packet either matches a rule or the rule list is exhausted. The interface drops packets that do not match a rule.
The sequence number designates the rule's placement in the ACL.
ACL Rules
The switch compares an ACL rule's command list to inbound and outbound packet fields. When all of a rule’s criteria match a packet’s contents, the interface performs the action specified by the rule.
The set of available commands depends on the ACL type and the specified protocol within the rule. The following is a list of commands available for supported ACL types:
IPv4 ACL Rule Parameters
All rules in IPv4 ACLs include the following criteria:
Protocol: The packet’s IP protocol. Valid rule inputs include:
Protocol name for a limited set of common protocols.
A subnet address (CIDR or address mask). Discontiguous masks are supported.
A host IP address (dotted decimal notation.)
Using any to denote that the rule matches all source addresses.
Destination Address: The packet’s destination IP address. Valid rule inputs include:
A subnet address (CIDR or address mask). Discontiguous masks are supported.
A host IP address (dotted decimal notation.)
Using any to denote that the rule matches all destination addresses.
All rules in IPv4 ACLs may include the following criteria:
Fragment: Rules filter on the fragment bit.
Time-to-live: Compares the packet TTL (time-to-live) value to a specified value and is valid in ACLs applied to the control plane. The validity of ACLs applied to the data plane varies by switch platform. Comparison options include:
Equal: Packets match if the packet value equals the statement value.
Greater than: Packets match if the packet value is greater than the statement value.
Less than: Packets match if the packet value is less than the statement value.
Not equal: Packets match if the packet value does not equal the statement value.
The availability of the following optional criteria depends on the specified protocol:
Source Ports / Destination Ports: A rule filters on ports when the specified protocol supports IP address-port combinations. Rules provide one of these port filtering values:
Using any denotes that the rule matches all ports.
A list of ports that matches the packet port. The maximum list size is 10 ports.
Negative port list. The rule matches any port not in the list. The maximum list size is 10 ports.
Integer (lower bound): The rule matches any port with a number larger than the integer.
Integer (upper bound): The rule matches any port with a number smaller than the integer.
Range integers: The rule matches any port whose number is between the integers.
Flag bits: Rules filter TCP packets on flag bits.
Message type: Rules filter ICMP type or code.
Tracked: Matches packets in existing ICMP, UDP, or TCP connections and is valid in ACLs applied to the control plane. The validity of ACLs applied to the data plane varies by switch platform.
IPv6 ACL Rule Parameters
Note: When calculating the size of ACLs, be aware that Arista switches install four rules in every IPv6 ACL so that ICMPv6 neighbor discovery packets bypass the default drop rule.
All rules in IPv6 ACLs include the following criteria:
Protocol: All rules filter on the packet’s IP protocol field. Rule input options include:
Protocol name for a limited set of common protocols.
An IPv6 prefix (CIDR). Discontiguous masks are supported.
A host IP address (dotted decimal notation).
Using any to denote that the rule matches all addresses.
Destination Address: The packet’s destination IP address. Valid rule inputs include:
A subnet address (CIDR or address mask). Discontiguous masks are supported.
A host IP address (dotted decimal notation).
Using any to denote that the rule matches all addresses.
All rules in IPv6 ACLs may include the following criteria:
Fragment: Rules filter on the fragment bit.
HOP Compares the packet’s hop-limit value to a specified value. Comparison options include:
eq: Packets match if the hop-limit value equals the statement value.
gt: Packets match if the hop-limit value is greater than the statement value.
lt: Packets match if the hop-limit value is less than the statement value.
neq: Packets match if the hop-limit value is not equal to the statement value.
The availability of the following optional criteria depends on the specified protocol:
Source Ports / Destination Ports: A rule filters on ports when the specified protocol supports IP address-port combinations. Rules provide one of these port filtering values:
Using any denotes that the rule matches all ports.
A list of ports that matches the packet port. The maximum list size is 10 ports.
Negative port list. The rule matches any port not in the list. The maximum list size is 10 ports.
Integer (lower bound): The rule matches any port with a number larger than the integer.
Integer (upper bound): The rule matches any port with a number smaller than the integer.
Range integers: The rule matches any port whose number is between the integers.
Flag bits: Rules filter TCP packets on flag bits.
Message type: Rules filter ICMP type or code.
Tracked: Matches packets in existing ICMP, UDP, or TCP connections and is valid in ACLs applied to the control plane. The validity of ACLs applied to the data plane varies by switch platform.
Standard IPv4 and IPv6 ACL Rule Parameters
Note: When calculating the size of ACLs, be aware that Arista switches install four rules in every IPv6 ACL so that ICMPv6 neighbor discovery packets bypass the default drop rule.
Standard ACLs filter only on the source address.
MAC ACL Rule Parameters
MAC ACLs filter traffic on a packet’s layer 2 header. Criteria that MAC ACLs use to filter packets include:
Source Address and Mask: The packet’s source MAC address. Valid rule inputs include:
MAC address range (address mask in 3x4 dotted hexadecimal notation).
Using any to denote that the rule matches all source addresses.
Destination Address and Mask: The packet’s destination MAC address. Valid rule inputs include:
MAC address range (address mask in 3x4 dotted hexadecimal notation).
Using any to denote that the rule matches all destination addresses.
Protocol: The packet’s protocol as specified by its EtherType field contents. Valid inputs include:
Protocol name for a limited set of common protocols.
Assigned protocol number for all protocols.
Creating and Modifying Lists
The switch provides configuration modes for creating and modifying ACLs. The command that enters an ACL configuration mode specifies the name of the list that the mode modifies. When the configuration mode is exited, the switch saves the list to the running configuration.
ACLs are created and modified in ACL configuration mode.
Standard ACLs are created and modified in Standard-ACL-configuration mode.
MAC ACLs are created and modified in MAC-ACL-configuration mode.
Lists created in one mode cannot be modified in any other mode.
A sequence number determines a rule's position within a list. New rules are inserted into a list based on their sequence numbers. You can reference a rule's sequence number to delete it from a list.
Implement an Access Control List (ACL) by assigning the list to an Ethernet interface, subinterface, port channel interface, or control plane. The switch assigns a default ACL to the control plane unless the configuration contains a valid control-plane ACL assignment statement. Ethernet and port-channel interfaces are not assigned an ACL by default. Apply standard ACLs to interfaces in the same manner as other ACLs.
IPv4 and MAC ACLs are separately applied for inbound and outbound packets. An interface or subinterface can be assigned multiple ACLs, with a limit of one ACL per packet direction per ACL type. A subset of all available switches supports Egress ACLs. The control plane does not support egress ACLs.
Applying ACLs describes procedures for applying ACLs to interfaces or the control plane.
ACL Rule Tracking
ACL rule tracking determines how ACL rules impact traffic on the interfaces where those rules are applied. ACLs provide two tracking mechanisms:
ACL logging: Logs a syslog entry when a packet matches specified ACL rules.
ACL counters: ACL counters increment when a packet matches a rule in specified ACLs.
ACL Logging
ACL rules provide a log option that produces a log message when a packet matches the rule. ACL logging creates a syslog entry when a packet matches an ACL rule where logging is enabled. Packets that match a logging-enabled ACL rule are copied to the CPU by the hardware. These packets trigger the creation of a syslog entry. The information provided in the entry depends on the ACL type or the protocol specified by the ACL. The system applies hardware rate limiting to packets written to the CPU, which prevents potential Denial-of-Service attacks. The logging rate is also limited in software to avoid creating syslog lists that are too large for human operators to use in practical ways.
The system assigns an ACL counter to each ACL rule. The activity of the ACL counters for rules within a list depends on the list’s counter state. When the list is in a counting state, the ACL counter of a rule increments when the rule matches a packet. When the list is in a non-counting state, the counter does not increment. A list’s counter state applies to all rules in the ACL. The default state for new ACLs is non-counting.
The system maintains the values of the counters for all rules in the list when an ACL changes from a counting state to a non-counting state or is no longer applied to any interfaces that increment counters. The counters do not reset. When the ACL returns to counting mode or is applied to an interface that increments counters, the counter operation continues from its last value.
Counters never decrement and are reset only through CLI commands.
Egress ACL counters count the number of packets matching rules associated with egress ACLs applied to various interfaces in a switch. 7050 and 7060 series switches maintain these counters for every TCAM rule. On these platforms, commands such as show platform trident tcam, show platform trident counters, and show ip access-list always display packet counters greater than zero.
Other switches do not enable counters by default. You must configure counters for each ACL. The show hardware counter and show ip access-list commands display the counters.
Configuring Egress ACL Counters
7050 and 7060 series switches enable egress ACL counters and do not require configuration.
For other platforms, to enable egress ACL counters for a specific ACL, use the counters per-entry command in the ACL's configuration mode.
Example
As shown in the following example, configure the counters per-entry command in the ACL configuration mode.
switch(config)# ip access-list acl1
switch(config-acl-acl1)# counters per-entry
Enabling Egress Counters Globally
7050 and 7060 series switches enable egress counters.
For other switches, enable IPv4 and IPv6 egress ACL counters in the global configuration mode using the hardware counter feature acl out command.
Example
The following examples show how to enable IPv4 and IPv6 egress ACL counters:
switch(config)# hardware counter feature acl out ipv4
switch(config)#
switch(config)# hardware counter feature acl out ipv6
switch(config)#
Disabling Egress Counters Globally
For 7050 and 7060 series switches, egress counters cannot be disabled.
For other switches, disable IPv4 and IPv6 egress ACL counters in the global configuration mode by using the hardware counter feature acl out command.
The following examples show how to disable IPv4 and IPv6 egress ACL counters:
switch(config)# no hardware counter feature acl out ipv4
switch(config)#
switch(config)# no hardware counter feature acl out ipv6
switch(config)#
Egress Counter Roll Over in the Global Mode
The counters roll over when the counter value for an ACL rule exceeds 2^64 (2 to the power of 64).
Example
In the following example, the hardware counter feature acl ipv6 out command is configured using units and packets.
switch(config)# hardware counter feature acl ipv6 out units packets
switch(config)#
The clear ip access-lists counters command clears the counters for all of the IPv4 ACLs or a specific IPv4 ACL, either globally or per CLI session.
Example
In the following example the ACL list named red is selected.
switch(config)# clear ip access-list counters red session
switch(config)#
The IPv6 egress ACL counters do not work in unshared mode.
Example
Use the hardware access-lists resource sharing vlan ipv6 out command to enable egress IPv6 ACL sharing.
switch(config)# hardware access-list resource sharing vlan ipv6 out
switch(config)#
The clear ipv6 access-list counters command clears the counters for all of the IPv6 ACLs or a specific IPv6 ACL, either globally or per CLI session.
Example
In the following example the ACL list named green is selected.
switch(config)# clear ipv6 access-list counters green session
switch(config)#
Displaying Egress ACL Counters
Use the following show commands to display information on Egress ACL Counters.
Use the show ip access-lists command to display all the IPv4 ACLs, or a specific IPv4 ACL configured in a switch. The output contains details such as ACL rules and counter values for each rule.
switch(config)# show ip access-list acl1
IP Access List acl1
counter per-entry
10 deny ip 11.1.1.0/24 any dscp af11
20 deny ip any any [match 39080716, 0:00:00 ago]
Total rules configured: 2
Configured on Ingress: Et2/1
Active on Ingress: Et2/1
Use the show ipv6 access-lists command to display all the IPv6 ACLs or a specific IPv6 ACL configured in a switch. The output contains details such as rules in an ACL and respective counter values with each rule.
switch(config)# show ipv6 access-list acl1
IPV6 Access List acl1
counter per-entry
10 permit ipv6 any any [match 3450000, 0:00:10 ago]
20 deny ipv6 any any
Total rules configured: 2
Configured on Ingress: Et2/1
Active on Ingress: Et2/1
The counter name EgressAclDropCounter in the output of this show command signifies the aggregate counter value for the remaining egress IPv4 ACL. In this example, the deny rules, with per-rule counters, do not allocate. No per-rule counters are allocated if you do not configure the counter per-entry parameter for the respective ACL.
switch(config)# show hardware counter drop
Summary:
Total Adverse (A) Drops: 0
Total Congestion (C) Drops: 0
Total Packet Processor (P) Drops: 250
Type Chip CounterName : Count : First Occurrence : Last Occurrence
-------------------------------------------------------------------------------
P Fap0 EgressAclDropCounter : 250 : 2015-11-11 22:39:02 : 2015-11-11 22:51:44
ACL Configuration
You create and modify Access Control Lists (ACLs) in an ACL-configuration mode. You can edit a list only in the mode where you created it. The switch provides five configuration modes for creating and modifying access control lists:
ACL configuration mode for IPv4 access control lists.
IPv6-ACL configuration mode for IPv6 access control lists.
Std-ACL configuration mode for Standard IPv4 access control lists.
Std-IPv6-ACL configuration mode for Standard IPv6 access control lists.
MAC-ACL configuration mode for MAC access control lists.
These sections describe the creation and modification of ACLs:
The switch enters the appropriate ACL Configuration Mode for the list. When adding the name of an existing ACL to the command, subsequent commands edit that list (see Modifying an ACL for additional information).
Examples
This command places the switch in ACL Configuration Mode to create an ACL named test1.
switch(config)# ip access-list test1
switch(config-acl-test1)#
This command places the switch in ACL Configuration Mode to create a Standard ACL named stest1.
switch(config)# ip access-list standard stest1
switch(config-std-acl-stest1)#
This command places the switch in ACL Configuration Mode to create an MAC ACL named mtest1.
switch(config)# mac access-list mtest1
switch(config-mac-acl-mtest1)#
Saving List Modifications
ACL Configuration Modes are group-change modes. Changes made in a group-change mode are saved when exiting the mode. To discard changes, use the abort command instead of exit.
Examples
Use the following commands to configure the first three rules into a new ACL.
switch(config-acl-test1)# permit ip 10.10.10.0/24 any
switch(config-acl-test1)# permit ip any host 10.20.10.1
switch(config-acl-test1)# deny ip host 10.10.10.1 host 10.20.10.1
To view the edited list, use the show command.
switch(config-acl-test1)# show
IP Access List test1
10 permit ip 10.10.10.0/24 any
20 permit ip 10.30.10.0/24 host 10.20.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
Because EOS has not saved the changes, the ACL remains empty, as displayed by show ip access-lists.
switch(config-acl-test1)# show ip access-lists test1
switch(config-acl-test1)#
Use the exit command to save all current changes to the ACL and exit the ACL configuration mode.
switch(config-acl-test1)# exit
switch(config)# show ip access-lists test1
IP Access List test1
10 permit ip 10.10.10.0/24 any
20 permit ip 10.30.10.0/24 host 10.20.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
Total rules configured: 4
Configured on Ingress: Et1/1
Active on Ingress: Et1/1
To apply the ACL test1 on an interface, Ethernet1/1, for example, and on the ingress direction, use the following command:
switch(config)# int et1/1
switch(config-if-Et1/1)# ip access-group test1 in
Use the exit command to save all changes to the Ethernet interface and exit the interface configuration mode.
switch(config-if-Et1/1)# exit
switch(config)#
switch(config)# show ip access-lists test1
IP Access List test1
10 permit ip 10.10.10.0/24 any
20 permit ip 10.30.10.0/24 host 10.20.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
Total rules configured: 4
Configured on Ingress: Et1/1
Active on Ingress: Et1/1
Discarding List Changes
The abort command exits ACL Configuration mode without saving pending changes.
Examples
The following commands enter the first three rules into a new ACL.
switch(config-acl-test1)# permit ip 10.10.10.0/24 any
switch(config-acl-test1)# permit ip any host 10.20.10.1
switch(config-acl-test1)# deny ip host 10.10.10.1 host 10.20.10.1
To view the edited list, use the show command.
switch(config-acl-test1)# show
IP Access List test1
10 permit ip 10.10.10.0/24 any
20 permit ip 10.30.10.0/24 host 10.20.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
To discard the changes, use the abort command. If the ACL existed before entering the ACL Configuration Mode, the abort command restores the version that existed before entering the ACL Configuration Mode. Otherwise, the show ip access-lists command displays no output.
switch(config-acl-test1)# abort
switch(config)#
Modifying an ACL
An existing ACL, including those applied to interfaces, can be modified by entering the appropriate configuration mode for the ACL as described in Creating and Opening a List. By default, while modifying an ACL, all traffic is blocked on any interface using the ACL.
Permit All Traffic During ACL Update
To avoid packet loss and interference with features like routing and dynamic NAT, you can configure the following switches to permit all traffic on Ethernet and VLAN interfaces during ACL modifications:
To append a rule to the end of a list, enter the rule without a sequence number while in ACL configuration mode for the list. The switch computes the new rule’s sequence number by adding 10 to the last rule’s sequence number.
Examples
The following command configures the switch to permit all traffic during ACL modifications on interfaces using the ACL. The rules in modified ACLs go into effect after exiting ACL configuration mode and after populating the ACL rules in hardware.
The following commands enter the first three rules into a new ACL.
switch(config-acl-test1)# permit ip 10.10.10.0/24 any
switch(config-acl-test1)# permit ip any host 10.20.10.1
switch(config-acl-test1)# deny ip host 10.10.10.1 host 10.20.10.1
To view the edited list, use the show command.
switch(config-acl-test1)# show
IP Access List test1
10 permit ip 10.10.10.0/24 any
20 permit ip any host 10.20.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
The following command appends a rule to the ACL. The new rule’s sequence number is 40.
switch(config-acl-test1)# permit ip any any
switch(config-acl-test1)# show
IP Access List test1
10 permit ip 10.10.10.0/24 any
20 permit ip any host 10.20.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
Inserting a Rule
To insert a rule into an ACL, enter the rule with a sequence number between the existing rules’ numbers.
Example
The following command inserts a rule between the first two by assigning the sequence number 15.
Switch(config-acl-test1)# 15 permit ip 10.30.10.0/24 host 10.20.10.1
Switch(config-acl-test1)# show
IP Access List test1
10 permit ip 10.10.10.0/24 any
15 permit ip 10.30.10.0/24 host 10.20.10.1
20 permit ip any host 10.20.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
Deleting a Rule
To remove a rule from the current ACL, perform one of these commands:
Enter no, followed by the sequence number to delete a rule.
Enter no, followed by the actual rule to delete it.
Enter default, followed by the actual rule to delete it.
Examples
These equivalent commands remove rule 20 from the list.
switch(config-acl-test1)# no 20
switch(config-acl-test1)# no permit ip any host 10.20.10.1
switch(config-acl-test1)# default permit ip any host 10.20.10.1
This ACL results from entering one of the preceding commands.
switch(config-acl-test1)# show
ip access list test1
10 permit ip 10.10.10.0/24 any
15 permit ip 10.30.10.0/24 host 10.20.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
Resequencing Rule Numbers
Sequence numbers determine the order of the rules in an ACL. After editing a list and deleting existing rules while inserting new rules between existing rules, the sequence number distribution may not be uniform. Resequencing rule numbers changes the sequence number of rules to provide a constant difference between adjacent rules. The resequence (ACLs) command adjusts the sequence numbers of ACL rules.
Example
The resequence (ACLs) command renumbers rules in the test1 ACL. The sequence number of the first rule is 100; subsequent rule numbers are incremented by 20.
switch(config-acl-test1)# show
IP Access List test1
10 permit ip 10.10.10.0/24 any
25 permit ip any host 10.20.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
50 permit ip any any
90 remark end of list
switch(config-acl-test1)# resequence 100 20
switch(config-acl-test1)# show
IP Access List test1
100 permit ip 10.10.10.0/24 any
120 permit ip any host 10.20.10.1
140 deny ip host 10.10.10.1 host 10.20.10.1
160 permit ip any any
180 remark end of list
ACL Rule Tracking Configuration
ACL Rules provide a log option that produces a syslog message about the packets matching a desired packet. ACL Logging creates a syslog entry when a packet matches an ACL rule with logging enabled.
Example
The following command creates an ACL Rule with logging enabled.
switch(config-acl-test1)# 15 permit ip 10.30.10.0/24 host 10.20.10.1 log
switch(config-acl-test1)#
The format of the generated Syslog message depends on the ACL type and the specified protocol:
Messages generated by a TCP or UDP packet matching an IP ACL:
Variables in the Syslog messages display the following values:
acl - Specifies the name of the ACL.
intf - Specifies the name of the interface receiving the packet.
filter - Specifies the action triggered by the ACL as denied or permitted.
protocol - Specifies the IP protocol specified by the packet.
vlan - Specifies the number of the VLAN receiving the packet.
ether - Specifies the EtherType protocol specified by the packet.
src-ip and dst-ip - Specifies the source and destination IP addresses.
src-prt and dst-prt - Specifies the source and destination ports.
src-mac and dst-mac - Specifies the source and destination MAC addresses.
ACLs provide a command that configures as counter state as counting or non-counting. The counter state applies to all rules in the ACL. The initial state for new ACLs defaults to non-counting.
The following command places the configuration mode ACL in counting mode.
switch(config-acl-test1)# counters per-entry
switch(config-acl-test1)# exit
switch(config-acl-test1)# show ip access-list test1
IP Access List test1
counters per-entry
10 permit ip 10.10.10.0/24 any
20 permit ip any host 10.20.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
50 remark end of list
Total rules configured: 5
Configured on Ingress: Et1
Active on Ingress: Et1
The following command clears the ACL counter for the test1 ACL.
switch(config)# clear ip access-lists counters test1
switch(config)#
Displaying ACLs
Display ACLs using the show running-config command. The show ip access-lists command also displays ACL rosters and contents as specified by command parameters.
When editing an ACL, the show (ACL configuration modes) command displays the current or pending list as specified by command parameters.
Displaying a List of ACLs
To display the roster of ACLs on the switch, use the show [ip | ipv6 | mac] access-lists command with the summary option.
Example
The following command lists the available IPv4 access control lists.
switch(config)# show ip access-lists summary
IPV4 ACL default-control-plane-acl
Total rules configured: 12
Configured on: control-plane
Active on : control-plane
IPV4 ACL list2
Total rules configured: 3
IPV4 ACL test1
Total rules configured: 6
IPV4 ACL test_1
Total rules configured: 1
IPV4 ACL test_3
Total rules configured: 0
switch(config)#
Each command can display the contents of one ACL or of all ACLs of the type specified by the command:
To display the contents of one ACL, enter showacl_typeaccess-lists followed by the name of the ACL. The acl_type can be ip, ipv6, mac or null.
To display the contents of all ACLs on the switch, enter the command without any options.
ACLs in counting mode display the number of inbound packets matching each rule in the list and the elapsed time since the last match.
Examples
The following command displays the rules in the default-control-plane-acl IP ACL, configuration, and status.
switch# show ip access-lists default-control-plane-acl
IP Access List default-control-plane-acl [readonly]
counters per-entry
10 permit icmp any any
20 permit ip any any tracked [match 1725, 0:00:00 ago]
30 permit ospf any any
40 permit tcp any any eq ssh telnet www snmp bgp https
50 permit udp any any eq bootps bootpc snmp [match 993, 0:00:29 ago]
60 permit tcp any any eq mlag ttl eq 255
70 permit udp any any eq mlag ttl eq 255
80 permit vrrp any any
90 permit ahp any any
100 permit pim any any
110 permit igmp any any [match 1316, 0:00:23 ago]
120 permit tcp any any range 5900 5910
Total rules configured: 12
Configured on Ingress: control-plane(default VRF)
Active on Ingress: control-plane(default VRF)
The following command displays the rules, configuration, and status of all the IP ACLs on the switch.
switch# show ip access-lists
IP Access List default-control-plane-acl [readonly]
counters per-entry
10 permit icmp any any
20 permit ip any any tracked [match 1371, 0:00:00 ago]
30 permit ospf any any
40 permit tcp any any eq ssh telnet www snmp bgp https
50 permit udp any any eq bootps bootpc snmp
60 permit tcp any any eq mlag ttl eq 255
70 permit udp any any eq mlag ttl eq 255
80 permit vrrp any any
90 permit ahp any any
100 permit pim any any
110 permit igmp any any [match 1316, 0:00:23 ago]
120 permit tcp any any range 5900 5910
Total rules configured: 12
Configured on Ingress: control-plane(default VRF)
Active on Ingress: control-plane(default VRF)
IP Access List list2
10 permit ip 10.10.10.0/24 any
20 permit ip 10.30.10.0/24 host 10.20.10.1
30 permit ip any host 10.20.10.1
40 deny ip host 10.10.10.1 host 10.20.10.1
50 permit ip any any
Total rules configured: 5
Configured on Ingress: Et1/1
Active on Ingress: Et1/1
IP Access List test1
switch(config)#
Displaying ACL Modifications
While editing an ACL in ACL Configuration Mode, the show command provides options for displaying ACL contents.
To display the list, as modified in ACL configuration mode, enter show or show pending.
To display the list, as stored in running-config, enter show active.
To display differences between the pending list and the stored list, enter show diff.
Examples
The examples in this section display previously configured ACL commands.
The configuration stores these parameters:
10 permit ip 10.10.10.0/24 any
20 permit ip any host 10.21.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
50 remark end of list
The current edit session removed this command, and the change not yet stored to the running-config:
20 permit ip any host 10.21.10.1
The current edit session added these commands to the ACL, and the change not yet stored to the running-config:
20 permit ip 10.10.0.0/16 any
25 permit tcp 10.10.20.0/24 any
45 deny pim 239.24.124.0/24 10.5.8.4/30
The following command displays the pending ACL as modified in the ACL Configuration Mode.
switch(config-acl-test_1)# show pending
IP Access List test_1
10 permit ip 10.10.10.0/24 any
20 permit ip 10.10.0.0/16 any
25 permit tcp 10.10.20.0/24 any
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
45 deny pim 239.24.124.0/24 10.5.8.4/30
50 remark end of list
The following command displays the ACL as stored in the configuration.
switch(config-acl-test_1)# show active
IP Access List test_1
10 permit ip 10.10.10.0/24 any
20 permit ip any host 10.21.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
50 remark end of list
The following command displays the difference between the saved and modified ACLs.
A plus sign (+) denotes rules added to the pending list.
A minus sign (-) denotes rules removed from the saved list.
switch(config-acl-test_1)# show diff
---
+++
@@ -1,7 +1,9 @@
IP Access List test_1
10 permit ip 10.10.10.0/24 any
- 20 permit ip any host 10.21.10.1
+ 20 permit ip 10.10.0.0/16 any
+ 25 permit tcp 10.10.20.0/24 any
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
+ 45 deny pim 239.24.124.0/24 10.5.8.4/30
Displaying Egress ACL Counters
The following show commands display Egress ACL Counters information.
Use the show ip access-lists command to display all the IPv4 ACLs, or a specific IPv4 ACL configured in a switch. The output contains details such as rules in an ACL as well as the respective counter values with each rule, configuration, and status.
switch(config)# show ip access-list acl1
IP Access List acl1
counter per-entry
10 deny ip 11.1.1.0/24 any dscp af11
20 deny ip any any [match 39080716, 0:00:00 ago]
Total rules configured: 2
Configured on Ingress: Et2/1
Active on Ingress: Et2/1
Use the show ipv6 access-lists command to display all the IPv6 ACLs or a specific IPv6 ACL configured in a switch. The output contains details such as rules in an ACL and the respective counter values with each rule along with the configuration and status.
switch(config)# show ipv6 access-list acl1
IPV6 Access List acl1
counter per-entry
10 permit ipv6 any any [match 3450000, 0:00:10 ago]
20 deny ipv6 any any
Total rules configured: 2
Configured on Ingress: Et1/1
Active on Ingress: Et1/1
The counter name EgressAclDropCounter in the output of this show command signifies the aggregate counter value for the remaining egress IPv4 ACL. In this example, the deny rules, with per rule counters, are not allocated. The per-rule counters are not allocated when the user does not configure the counter per-entry parameter for the respective ACL.
switch(config)# show hardware counter drop
Summary:
Total Adverse (A) Drops: 0
Total Congestion (C) Drops: 0
Total Packet Processor (P) Drops: 250
Type Chip CounterName : Count : First Occurrence : Last Occurrence
-------------------------------------------------------------------------------
P Fap0 EgressAclDropCounter : 250 : 2015-11-11 22:39:02 : 2015-11-11 22:51:44
Configuring Per-Port Per-VLAN QoS
To configure per-port per-VLAN Quality of Service (QoS), first configure the ACL policing for QoS and then apply the policy map on a single Ethernet or port-channel interface on a per-port per-VLAN basis. The per port per VLAN QoS allows a class map to match traffic for a single VLAN or for a range of VLANs separated by commas. Per-port per-VLAN only works with QoS-based class maps.
To configure per-port per-VLAN QoS on DCS-7280(R) and DCS-7500(R), change the TCAM profile to QoS as shown in the following steps:
Access Control Lists (ACLs) are configured to permit or deny traffic between source and destination ports on Strata-based platforms. Mirror ACLs are used in mirroring traffic by matching VLAN ID of the configured ACLs. Mirror ACLs are applied for IPv4, IPv6, and MAC ACLs.
Note:Mirror ACLs work only in the receiving direction.
Examples
The following commands configure ACL to permit VLAN traffic between any source and destination host.
switch(config)# ip access-list acl1
switch(config-acl-acl1)# permit vlan 1234 0x0 ip any any
The following commands configure monitor session sess1 with Ethernet 1 as source port and Ethernet 2 as the destination port for an ingress ip acl_1.
Access Control Lists (ACLs) become active when assigned to an interface, subinterface, or control plane. This section describes the process of adding and removing ACL interface assignments.
Applying an ACL to an Interface
The switch must be in interface configuration mode to assign an ACL to an interface or subinterface.
The ip access-group command applies the specified IP or standard IP ACL to the configuration mode interface or subinterface.
The ip access-group command applies the specified IP or standard IP ACL to the control plane traffic.
The mac access-group command applies the specified MAC ACL to the configuration mode interface.
IPv4, IPv6, and MAC ACLs are separately applied for inbound and outbound packets. You can assign an interface or subinterface with multiple ACLs, with a limit of one ACL per packet direction per ACL type. A subset of all available switches support Egress ACLs. IPv6 egress ACLs have limited availability, and IPv6 egress ACLs applied to routed interfaces or subinterfaces across the same chip on the DCS-7500E and the DCS-7280E series can be shared. In addition to that, the DSCP value can match on IPv6 egress ACLs. This ability results in more efficient utilization of system resources and is particularly useful for environments with few, potentially large, IPv6 egress ACLs applied across multiple routed interfaces.
Examples
These commands assign test1 ACL to interface ethernet 3, and verify the assignment.
switch(config)# interface ethernet 3
switch(config-if-Et3)# ip access-group test1 in
switch(config-if-Et3)# show running-config interfaces ethernet 3
interface Ethernet3
ip access-group test1 in
switch(config-if-Et3)#
The following commands place the switch in control plane configuration mode and applies the ACL assignment to the control plane traffic.
switch(config)# control-plane
switch(config-cp)# ip access-group test_cp in
The following command enables shared ACLs.
switch(config)# hardware access-list resource sharing vlan ipv6 out
switch(config)#
The following command disables shared ACLs.
switch(config)# no hardware access-list resource sharing vlan ipv6 out
switch(config)#
The following commands apply an IPv4 ACL named test_ACL to ingress traffic on interface ethernet 5.1.
switch(config)# interface ethernet 5.1
switch(config-if-Et5.1)# ipv4 access-group test_ACL in
switch(config-if-Et5.1)#
Removing an ACL from an Interface
The no ip access-group command removes an IP ACL assignment statement from running-config for the configuration mode interface. After removing an ACL, the interface is no longer associated with an IP ACL.
The no mac ip access-group command removes a MAC ACL assignment statement from running-config for the configuration mode interface. After removing a MAC ACL is removed, the interface is no longer associated with an MAC ACL.
To remove an ACL from the control plane, enter the no ip access-group command in control plane configuration mode. Removing the control plane ACL command from running-config reinstates default-control-plane-acl as the control plane ACL.
Examples
The following commands remove the assigned IPv4 ACL from interface ethernet 3.
switch(config)# interface ethernet 3
switch(config-if-Et3)# no ip access-group test in
switch(config-if-Et3)#
The following commands place the switch in control plane configuration mode and remove the ACL assignment from running-config, restoring default-control-plane-acl as the control plane ACL.
switch(config)# control-plane
switch(config-cp)# no ip access-group test_cp in
switch(config-cp)#
Service ACL enforcement is a feature added to a control plane service (the SSH server, the SNMP server, routing protocols, etc.) that allows the switch administrator to restrict the processing of packets and connections by the control plane processes that implement that service. The control plane program run by the control plane process checks already received packets and connections against a user-configurable Access Control List (ACL), a Service ACL.
The Service ACL contains permit and deny rules matching any source address, destination address, and TCP or UDP ports of received packets or connections. After receiving a packet or connection, the control plane process evaluates the packet or connection against the rules of the Service ACL configured for the control plane process. If the received packet or connection matches a deny rule, the control plane process drops or closes it without further processing.
Control Plane Process Enforced Access Control enables the system administrator to restrict which systems on the network can access the services provided by the switch. Each service has its own access control list, giving the system administrator fine-grained control over access to the switch's control plane services. The CLI for this uses the familiar pattern of access control lists assigned for a specific purpose, in this case, for each control plane service.
Configuring Service ACLs and Displaying Status and Counters
switch(config)# management ssh
switch(config-mgmt-ssh)# ip access-group <acl_name> [vrf <vrf_name>] in
switch(config-mgmt-ssh)# ipv6 access-group <acl_name> [vrf <vrf_name>] in
In Release EOS-4.19.0, all VRFs are required to use the same SSH Server Service ACL. The Service ACL assigned without the vrf keyword is applied to all VRFs where the SSH Server is enabled.
Use the following commands to display the status and counters of the SSH Server Service ACLs:
switch# show management ssh ip access-list
switch# show management ssh ipv6 access-list
SNMP Server
Use the snmp-server community command to apply the SNMP Server Service ACLs to restrict which hosts can access SNMP services on the switch:
Use the following commands to display the status and counters of the BGP routing protocol Service ACLs:
switch# show bgp ipv4 access-list
switch# show bgp ipv6 access-list
UCMP Auto Adjust for BGP
Unequal Cost MultiPath (UCMP) for BGP forwards traffic based on weight assignments for next hops of Equal Cost MultiPath (ECMP) routes. The system programs the weights in the Forwarding Information Base (FIB).
Devices that receive BGP routes disseminate BGP link-bandwidth extended community attribute information. These devices then program the next hops in the FIB using the received link-bandwidth values. The system appends the percentage of interface speed to the received link bandwidth extended community value of the route. It adjusts the weight ratio of the traffic sent over egress ports to forward more traffic toward the peer with a higher interface speed.
Configuring UCMP Auto Adjust for BGP
The following command enables the weight adjustment and configures the adjust auto to 62.3 percent.
switch(config-router-bgp)# neighbor group1 link-bandwidth adjust auto percent 62.3
PERCENT is a float value between 0.0 and 100.0 and is optional.
Use the following command to display the status and counters of the PIM routing protocol Service ACLs.
switch# show ip pim access-list
IGMP
Use the ip igmp access-group command to apply Service ACLs for controlling packets processed by the IGMP management protocol agent:
switch(config)# router igmp
switch(config-router-igmp)# ip igmp access-group <acl_name>
switch(config-router-igmp)# vrf <vrf_name>
switch(config-router-igmp-vrf-<vrf>)# ip igmp access-group <acl_name>
Use the following command to display the status and counters of the IGMP management protocol Service ACLs.
switch# show ip igmp access-list
DHCP Relay
Use the ip dhcp relay access-group and ipv6 dhcp relay access-group commands to apply Service ACLs for controlling packets processed by the DHCP relay agent:
Use the following commands to display the status and counters of the DHCP relay agent Service ACLs:
switch# show ip dhcp relay access-list
switch# show ipv6 dhcp relay access-list
LDP
Use the ip access-group (Service ACLs) to apply Service ACLs for controlling packets and connections processed by the LDP MPLS label distribution protocol:
switch(config)# mpls ldp
switch(config-mpls-ldp)# ip access-group <acl_name>
Use the following command to display the status and counters of the LDP Service ACLs.
switch(config)# management telnet
switch(config-mgmt-telnet)# ip access-group <acl_name> [vrf <vrf_name>] in
switch(config-mgmt-telnet)# ipv6 access-group <ipv6_acl_name> [vrf <vrf_name>] in
In EOS 4.19.0, all VRFs are required to use the same Telnet server Service ACL. The Service ACL assigned without the vrf keyword is applied to all VRFs where the Telnet server is enabled.
Use the following commands to display the status and counters of the LDP Service ACLs:
switch# show management telnet ip access-list
switch# show management telnet ipv6 access-list
Sub-interface ACLs
This Sub-interface ACLs feature enables ACL functionality on subinterfaces.
Configuring Sub-interface ACLs
Configure the ACLs on subinterfaces using the following command.
ip|ipv6 access-groupacl-namein | out
Use the following command to unconfigure the ACLs on subinterfaces.
no ip|ipv6 access-groupin | out
Configuring ACL Mirroring on a Subinterface Source
Configure a mirror session using subinterface sources and apply explicit ACLs to each source in the session. EOS only supports ingress mirroring from the Rx direction.
Use the following commands to configure a session, ACLMirror1, on Ethernet5/1.1, Ethernet5/1.2, Ethernet6/1 as the source, acl1 as the ACL group, and Ethernet 14/1 as the destination:
switch(config)# show monitor session
Session ACLMirror1
------------------------
Programmed in HW: Yes
Source Ports:
Rx Only: Et5/1.2(IP ACL: acl1), Et5/1.1
Et6/1
Destination Ports:
Et14/1 : active
Sub-interface ACLs Limitations
The sub-interface ACLs feature contains the following limitations:
EOS does not support egress IPv4 ACLs on subinterfaces when sharing mode is disabled for Egress IPv4 RACLs.
EOS does not support egress IPv6 ACL deny logging on subinterfaces.
Blocking traffic while modifying ACLs is not supported on Egress IPv4 ACLs on subinterfaces.
Sub-interface ACLs Show Commands
The show ip access-lists and show ipv6 access-lists commands display the summary of a configured ACL including the subinterface on which the ACL is configured and active.
show ip|ipv6 access-listsacl-namesummary
Examples
switch(config)# show ip access-lists acl1 summary
IPV4 ACL acl1
Total rules configured: 1
Configured on Ingress: Et5.1
Active on Ingress: Et5.1
switch(config)# show ipv6 access-lists acl1 summary
IPV6 ACL acl1
Total rules configured: 1
Configured on Egress: Et5.1
Active on Egress: Et5.1
RACL Sharing on SVIs
IPv4 Ingress Sharing
IPv4 ingress sharing optimizes the utilization of hardware resources by sharing them between different VLAN interfaces when they have the same ACL attached.
Larger deployments benefit from this function, where IPv4 ingress sharing is applied on multiple SVIs with member interfaces on the same forwarding ASIC. For example, a trunk port carrying multiple VLANs and an ingress sharing is applied on all VLANs; it occupies lesser hardware resources irrespective of the number of VLANs. By default, IPv4 ingress sharing is disabled on the switches.
To enable IPv4 Ingress Sharing, use the no hardware access-list resource sharing vlan in command.
Note: Enabling or disabling the IPv4 ingress sharing requires the restart of software agents on the switches which is a disruptive process and will impact the traffic forwarding.
The no form of the command disables the IPv4 ingress sharing on the switch. To display the IPv4 ingress sharing information use show platform trident command on the switch.
IPv4 Egress Sharing
IPv4 Egress Sharing optimizes the utilization of hardware resources by sharing TCAM entries for a group of SVIs on which IPv4 ACLs are shared. The TCAM entries are shared for all the SVIs per chip, saving a lot of hardware resources and enabling ACLs to scale to larger configurations.
Larger deployments benefit from IPv4 Egress Sharing, which is applied on multiple SVIs with member interfaces on the same forwarding ASIC. For example, a trunk port carrying multiple VLANs, and when applying Egress Sharing on all VLANs, it occupies lesser hardware resources irrespective of the number of VLANs.
By default, the system enables IPv4 Egress Sharing on the switches. However, enabling both IPv4 Egress Sharing and uRPF cannot at the same time is not possible. Disabling IPv4 RACL sharing will allow uRPF configuration and ensure the simultaneous configuration of the RACL in non-shared mode.
To enable unicast Reverse Path Forwarding (uRPF) on the switch, the IPv4 Egress Sharing must be disabled using the no hardware access-list resource sharing vlan ipv4 out command.
Note: Enabling or disabling IPv4 Egress Sharing requires restarting software agents on the switches, which is a disruptive process and will impact the traffic forwarding.
Use the following show commands to verify the IPv4 Egress Sharing information on the switch.
The no form of the command disables the switch's IPv4 Egress Sharing, allowing you to configure the uRPF.
Displaying IPv4 Egress Sharing Information
Examples
The show ip access-lists command displays the list of all the configured IPv4 ACLs.
switch# show ip access-lists summary
IPV4 ACL default-control-plane-acl [readonly]
Total rules configured: 17
Configured on Ingress: control-plane(default VRF)
Active on Ingress: control-plane(default VRF)
IPV4 ACL ipAclLimitTest
Total rules configured: 0
Configured on Egress: Vl2148,2700
Active on Egress: Vl2148,2700
The show vlan command displays the list of all the member interfaces under each SVI.
switch# show vlan
VLAN Name Status Ports
----- -------------- --------- -----------------
1 default active
2148 VLAN2148 active Cpu, Et1, Et26
2700 VLAN2700 active Cpu, Et18
The show platform arad acl tcam command displays the number of TCAM entries (hardware resources) occupied by the ACL on each forwarding ASIC and the percentage of TCAM utilization per forwarding ASIC.
switch# show platform arad acl tcam detail
ip access-list ipAclLimitTest (Shared RACL, 0 rules, 1 entries, direction out,
state success, Acl Label 2)
Fap: Arad0, Shared: true, Interfaces: Vl2148, Vl2700
Bank Offset Entries
0 0 1
Fap: Arad1, Shared: true, Interfaces: Vl2148
Bank Offset Entries
0 0 1
switch# show platform arad acl tcam summary
The total number of TCAM lines per bank is 1024.
========================================================
Arad0:
========================================================
Bank Used Used % Used By
0 1 0 IP Egress PACLs/RACLs
Total Number of TCAM lines used is: 1
========================================================
Arad1:
========================================================
Bank Used Used % Used By
0 1 0 IP Egress PACLs/RACLs
Total Number of TCAM lines used is: 1
The show ip route command displays the unicast ip routes installed in the system.
switch# show ip route
VRF name: default
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I - ISIS, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route
Gateway of last resort is not set
C 10.1.0.0/16 is directly connected, Vlan2659
C 10.2.0.0/16 is directly connected, Vlan2148
C 10.3.0.0/16 is directly connected, Vlan2700
S 172.17.0.0/16 [1/0] via 172.24.0.1, Management1
S 172.18.0.0/16 [1/0] via 172.24.0.1, Management1
S 172.19.0.0/16 [1/0] via 172.24.0.1, Management1
S 172.20.0.0/16 [1/0] via 172.24.0.1, Management1
S 172.22.0.0/16 [1/0] via 172.24.0.1, Management1
C 172.24.0.0/18 is directly connected, Management1
The show platform arad ip route command displays the platform unicast forwarding routes.
A route map is an ordered set of rules that controls the redistribution of IP routes into a protocol domain based on criteria such as route metrics, access control lists, next-hop addresses, and route tags. Route maps can also alter route parameters as they are redistributed.
Route Map Description
Route maps are composed of route map statements, each consisting of a list of match and set commands.
Route Map Statements
Route map statements are categorized by the resolution of routes that the statement filters.
Permit statements facilitate the redistribution of matched routes.
Deny statements prevent the redistribution of matched routes.
Route map statement elements include name, sequence number, filter type, match commands, set commands, and continue commands.
The name identifies the route map to which the statement belongs.
The sequence number designates the statement’s placement within the route map.
A filter type specifies the route resolution. Valid types are permit and deny.
The match commands specify criteria that select the routes the statement evaluates for redistribution.
The set commands modify route parameters for redistributed routes.
The continue commands prolong the route map evaluation of routes that match a statement.
Statements filter routes for redistribution. Routes that statements pass are redistributed (permit statements) or rejected (deny statements). The next statement in the route map then filters routes that statements fail.
When a statement does not contain a match command, the statement passes all routes.
When a statement contains a single match command that lists a single object, the statement passes routes whose parameters match the object.
When a statement contains a single match command that lists multiple objects, the statement passes routes whose parameters match at least one object.
When a statement contains multiple match commands, the statement passes routes whose parameters match all match commands.
The Set commands modify parameters for redistributed routes and are valid in permit statements.
Example
The following route map statement is named MAP_1 with sequence number 10. The statement matches all routes from BGP Autonomous System 10 and redistributes them with a local preference set to 100. Routes that do not match the statement are evaluated against the next statement in the route map.
switch# route-map MAP_1 permit 10
match as 10
set local-preference 100
Route Maps with Multiple Statements
A route map consists of statements with the same name and different sequence numbers. Statements filter routes by ascending order based on their sequence numbers. When a statement passes a route, the redistribution action is performed as the filter type specifies, ignoring all subsequent statements. When the statement fails the route, the statement with the smallest sequence number larger than the current one filters the route.
All route maps contain an implied final statement containing a single deny statement without a match command. This statement denies the redistribution of any routes that no other statement passes.
Example
The following route map is named MAP_1 and has two permit statements. Routes that do not match either statement are denied redistribution into the target protocol domain.
switch# route-map MAP_1 permit 10
match as 10
set local-preference 100
!
switch# route-map MAP_1 permit 20
match metric-type type-1
match as 100
Route Maps with Multiple Statements and Continue Commands
Route map statements that contain a continue (route map) command support additional route map evaluation of routes whose parameters meet the statement’s match commands. Routes that match a statement containing a continue command are evaluated against the statement specified by the continue command.
When a route matches multiple route-map statements, the filter action (deny or permit) is determined by the last statement that the route matches. The set commands in all statements matching the route are applied to the route after the route map evaluation is complete. Multiple set commands are applied in the same order by which the route was evaluated against the statements containing them.
Example
The following route map is named MAP_2 with a permit and a deny statement. The permit statement contains a continue command. Routes that match statement 10 are evaluated against statement 20.
switch# route-map MAP_2 permit 10
match as 10
continue 20
set local-preference 100
!
switch# route-map MAP_2 deny 20
match metric-type type-1
match as 100
The route is redistributed if it passes statement 10 and is rejected by statement 20. The route is denied redistribution in all other instances. The continue command guarantees the evaluation of all routes against both statements.
Route Map Configuration
Route maps are created and modified in route-map configuration mode. These sections describe the configuration mode and its commands.
To create a route map, use the route-map command, including the map name and filter type (deny or permit). If the command does not specify a number, the system assigns a default sequence number to the statement.
Example
The following command places the switch in the route map configuration mode and creates a route map statement named map1 with a sequence number of 50.
To edit an existing route map statement, use the route-map, including the map’s name and the statement’s number. The switch enters the route map configuration mode for the statement. Subsequent match (route-map) and set (route-map) commands add the corresponding commands to the statement.
The show command displays the contents of the existing route map.
Example
The following command places the switch in the route map configuration mode to edit an existing route map statement. The show command displays the contents of all statements in the route map.
switch(config)# route-map MAP2
switch(config-route-map-MAP2)#show
Match clauses:
match as 10
match tag 333
Set clauses:
set local-preference 100
switch(config-route-map-MAP2)#
Saving Route Map Modifications
Route map configuration mode is a group-change mode. You can save changes by exiting the mode, either with an explicit exit command or by switching directly to another configuration mode. This includes switching to the configuration mode for a different route map.
Example
The first command creates the map1 statement with a sequence number of 10. The second command is not yet saved to the route map, as displayed by the show command.
switch(config)# route-map map1 permit
switch(config-route-map-map1)# match as 100
switch(config-route-map-map1)# show
switch(config-route-map-map1)#
The exit command saves the match command.
switch(config-route-map-map1)# exit
switch(config)# show route-map map1
route-map map1 permit 10
Match clauses:
match as 100
Set clauses:
switch(config)#
Discarding Route Map Modifications
The abort command discards all pending changes and exits route-map configuration mode.
Example
The abort command discards the pending match command and restores the original route map.
switch(config)# route-map map1 permit
switch(config-route-map-map1)# match as 100
switch(config-route-map-map1)# abort
switch(config)# show route-map map1
switch(config)#
Modifying Route Map Components
The following commands add rules to the configuration mode route map:
To insert a new statement into an existing route map, create a new statement with a sequence number that differs from any existing statement in the map.
Example
The following commands add statement 50 to the Map1 route map and a match statement of 150. They save the configuration using exit then display the new route map using show route-map Map1.
switch(config)# route-map Map1 permit 50
switch(config-route-map-Map1)# match as 150
switch(config-route-map-Map1)# exit
switch(config)# show route-map Map1
route-map Map1 deny 10
Match clauses:
match as 10
match tag 333
Set clauses:
set local-preference 100
route-map Map1 permit 50
Match clauses:
match as 150
Set clauses:
switch(config)#
Deleting Route Map Components
To remove a component from a route map, perform one of the following:
To remove a command from a statement, enter no, followed by the command you want to remove.
To remove a statement, enter no, followed by the route map with the filter type and the sequence number of the statement you want to remove.
To remove a route map, enter no followed by the route map without a sequence number.
Using Route Maps
Protocol redistribution commands include a route map parameter determining the routes to be redistributed into the specified protocol domain.
Example
The following commands use the Map1 route map to select OSPFv2 routes for redistribution into BGP AS1.
A prefix list is an ordered set of rules that defines route redistribution access for a specified IP address space. It consists of a filter action (deny or permit), an address space identifier (IPv4 subnet
address or IPv6 prefix), and a sequence number.
Prefix lists are referenced by route map match commands when filtering routes for redistribution.
A prefix list is an ordered set of rules that defines route redistribution access for a specified IP address space. A prefix list rule consists of a filter action (deny or permit), a network address (IPv4 subnet or IPv6 prefix), and a sequence number. A rule may also include an alternate mask size.
The switch supports IPv4 and IPv6 prefix lists. The switch is placed in a Prefix-list configuration mode to create and edit IPv4 or IPv6 prefix lists.
IPv4 Prefix Lists
IPv4 prefix lists are created or modified by adding an IPv4 prefix list rule in the Prefix-list configuration mode. Each rule includes the name of a prefix list and the sequence number, network address, and filter action. A list consists of all rules that have the same prefix-list name.
The ip prefix-list command creates a prefix list or adds a rule to an existing list. Route map match commands use prefix lists to filter routes for redistribution into OSPF, RIP, or BGP domains.
Creating an IPv4 Prefix List
To create an IPv4 prefix list, enter the ip prefix-list command, followed by the list's name. The switch enters the IPv4 prefix-list configuration mode for the list. If the name of an existing ACL follows the command, subsequent commands edit that list.
Examples
The following command places the switch in IPv4 prefix list configuration mode to create an IPv4 prefix list named route-one.
switch(config)# ip prefix-list route-one
switch(config-ip-pfx)#
This series of commands creates four different rules for the prefix-list named route-one.
To view the list, save the rules by exiting the Prefix-list command mode using the exit command, then re-enter the configuration mode and use the show active command.
switch(config-ip-pfx)# exit
switch(config)# ip prefix-list route-one
switch(config-ip-pfx)# show active
ip prefix-list route-one
seq 10 deny 10.1.1.0/24
seq 20 deny 10.1.0.0/16
seq 30 permit 12.15.4.9/32
seq 40 deny 1.1.1.0/24
switch(config-ip-pfx)# ip prefix-list route-one
The switch provides an IPv6 prefix-list configuration mode for creating and modifying IPv6 prefix lists. A list can be edited only in the mode where it was created.
To create an IP ACL, enter the ipv6 prefix-list command and the list's name. The switch enters the list's IPv6 prefix-list configuration mode. If the name of an existing ACL follows the command, subsequent commands edit that list.
Example
This command places the switch in the IPv6 prefix list configuration mode to create an IPv6 prefix list named map1.
To append a rule to the end of a list, enter the rule without a sequence number while in Prefix-List configuration mode for the list. The system derives the new rule’s sequence number by adding 10 to the last rule’s sequence number.
Example
These commands enter the first two rules into a new prefix list.
To view the list, save the rules by exiting the prefix-list command mode using the exit command, then re-enter the configuration mode and use the show active command.
To insert a rule into a prefix list, use the seq (IPv6 Prefix Lists) command to enter a rule with a sequence number between the numbers of two existing rules.
Example
This command inserts a rule between the first two by assigning sequence number 15.
Route map match commands include an option that matches a specified prefix list.
Example
The MAP_1 route map uses a match command that references the PL_1 prefix list.
switch(config)# route-map MAP_1 permit
switch(config-route-map-MAP_1)# match ip address prefix-list PL_1
switch(config-route-map-MAP_1)# set community 500
switch(config-route-map-MAP_1)# exit
Static Routes Redistribution into IGPs
Use match ip next-hop to match against next-hops in a route-map. This can be used to redistribute matching static routes into an IGP (IS-IS, OSPF, etc.).
The following example applies the match ip next-hop clause for static routes redistributed into IGPs for multi-agent mode. The following configures a static route.
switch(config)# ip route 10.20.30.0/24 1.2.3.4
The following commands configure a prefix-list:
switch (config)# ip prefix-list prefixListName
switch(config-ip-pfx)# permit 1.2.3.4/32
1.2.3.4 is a configured next-hop for static route 10.20.30.0/24.
The following commands configure a route map:
switch(config)# route-map routeMapName
switch(config-route-map-routeMapName)# match ip next-hop prefix-list prefixListName
For example, based on the route-map mentioned in the preceding command, to redistribute matching static routes into an IGP, use the following command for IS-IS:
View redistributed routes using the following show commands.
The show ip route command displays the IP route.
switch# show ip route
VRF: default
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B - BGP, B I - iBGP, B E - eBGP,
R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service,
DH - DHCP client installed default route, M - Martian,
DP - Dynamic Policy Route, L - VRF Leaked
Gateway of last resort is not set
...
I L2 10.20.30.0/24 [115/10] via 1.2.3.4, Ethernet1
Use the show isis database detail command to view routes redistributed into IS-IS.
switch# show isis database detail
IS-IS Instance: B VRF: default
IS-IS Level 1 Link State Database
LSPID Seq Num Cksum Life IS Flags
...
IS-IS Level 2 Link State Database
LSPID Seq Num Cksum Life IS Flags
0000.0000.0001.00-00 6 10364 840 L2 <>
...
Reachability : 10.20.30.0/24 Metric: 0 Type: 1 Up
...
While the preceding example applies to IS-IS, a similar approach may be taken for other IGPs, such as OSPF.
Port ACLs with User-Defined Fields
Describes the support for specifying User-Defined Fields (UDF) in Port ACLs, including IPv4, IPv6, and MAC ACLs. The purpose of the User-Defined Fields feature is to permit or deny packets based on custom offset pattern matching.
User-Defined Fields, or UDFs, are part of an access-list filter and comprise an offset, length, pattern match and mask. This describes a single portion of any incoming packet that matches the provided value.
UDFs may also be defined via aliases. Aliases can save a UDF configuration for reuse in multiple access lists or access list rules. An alias may substitute for a fully defined UDF, including the offset, pattern, and mask. The pattern or mask may be overridden when the alias is used in an access list rule.
The behavior, CLI syntax, and configuration of UDFs are identical to Traffic Steering UDF and Mirroring ACL UDF.
This section describes port ACLs with user-defined fields, including configuration instructions. Topics covered by this section include:
User-Defined Fields (UDFs) are specified as part of an access list. However, the type of access list dictates the base position of the UDF and the options available. In addition, you must configure a TCAM profile to include UDFs as part of the Port ACL feature’s key.
TCAM Profile
User-Defined Fields are defined as additional fields in the Port ACL feature’s key. By default, UDFs are not included in the keys for the Port ACL features. Adding a UDF to the key requires removing different key fields to fit within the TCAM width restrictions.
Note: Each UDF is either 16 bits wide or 32 bits wide.
The following are example configurations of the TCAM profile.
IPv4 Port ACL
The following configurations create a new profile based on the default profile. This new profile replaces the Layer 4 port key fields with one 16-bit UDF and one 32-bit UDF.
switch(config)# hardware tcam
switch(config-hw-tcam)# profile ipv4Udf copy default
switch(config-hw-tcam-profile-ipv4Udf)# feature acl port ip
switch(config-hw-tcam-profile-ipv4Udf-feature-acl-port-ip)# no key field l4-ops
switch(config-hw-tcam-profile-ipv4Udf-feature-acl-port-ip)# no key field l4-src-port
switch(config-hw-tcam-profile-ipv4Udf-feature-acl-port-ip)# no key field l4-dst-port
switch(config-hw-tcam-profile-ipv4Udf-feature-acl-port-ip)# key field udf-16b-1
switch(config-hw-tcam-profile-ipv4Udf-feature-acl-port-ip)# key field udf-32b-1
switch(config-hw-tcam-profile-ipv4Udf-feature-acl-port-ip)# exit
switch(config-hw-tcam-profile-ipv4Udf)# exit
switch(config-hw-tcam)# system profile ipv4Udf
16-bit IPv4 Header Match
Example
The following configurations match IPv4 packets based on the Identification (ID) field.
Packets ingressing into interface ethernet 7 with an ID equal to 1000 (0x03E80000) are forwarded, while packets with an ID different from 1000 are dropped.
(config)# ip access-list udfAcl
(config-acl-udfAcl)# permit ip any any payload header start offset 1 pattern 0x03E80000 mask 0x0000FFFF
(config-acl-udfAcl)# deny ip any any
(config-acl-udfAcl)# exit
(config)# interface ethernet 7
(config-if-Et7)#
IPv6 Port ACL
The following configurations create a new profile based on the default profile. This new profile replaces the destination IPv6 address key field with two 32-bit UDFs.
switch(config)# hardware tcam
switch(config-hw-tcam)# profile ipv6Udf copy default
switch(config-hw-tcam-profile-ipv6Udf)# feature acl port ipv6
switch(config-hw-tcam-profile-ipv6Udf-feature-acl-port-ipv6)# no key field dst-ipv6
switch(config-hw-tcam-profile-ipv6Udf-feature-acl-port-ipv6)# key field udf-32b-1
switch(config-hw-tcam-profile-ipv6Udf-feature-acl-port-ipv6)# key field udf-32b-2
switch(config-hw-tcam-profile-ipv6Udf-feature-acl-port-ipv6)# exit
switch(config-hw-tcam-profile-ipv6Udf)# exit
switch(config-hw-tcam)# system profile ipv6Udf
32-bit IPv6 Payload Match
Example
The following configurations match IPv6 UDP packets based on the first 32 bits of the packet payload.
UDP packets ingressing into interface ethernet 7 that starts with 0x1234567X (where X can be any valid hexadecimal) in the payload are forwarded while dropping any other packets. The offset is set to 2 (2 x 4-byte words) to skip the UDP header.
(config)# ipv6 access-list udfAcl
(config-ipv6-acl-udfAcl)# permit udp any any payload offset 2 pattern 0x12345670 mask 0x0000000f
(config-ipv6-acl-udfAcl)# deny ipv6 any any
(config-ipv6-acl-udfAcl)# exit
(config)# interface ethernet 7
(config-if-Et7)# ipv6 access-group udfAcl in
Port ACLs with User-Defined Fields Limitations
User-defined fields consume a limited set of copy resources. For each unique offset, if a pattern is specified masked to be > 16 bits wide, then a 32-bit resource is used. If no 32-bit resource is available, then two 16-bit resources are used if available. Copy resources depend on the number of UDF key fields added to the feature key. Each UDF key field maps to one copy resource. Using the above TCAM profile configurations:
IPv4: 1 × 16-bit pattern + 1 × 32-bit pattern.
IPv6: 2 × 32-bit pattern.
MAC: 1 × 16-bit pattern + 1 × 32-bit pattern.
Other limitations include:
The maximum offset value is 31, which is 31 4-byte words, or 124 bytes.
UDFs only work on ingress Port ACLs.
ACL, Route Map, and Prefix List Commands
This section describes CLI commands that this chapter references.
The clear ip access-lists counters command sets ACL counters to zero for the specified IPv4 Access Control List (ACL). The session parameter limits ACL counter clearing to the current CLI session.
Command Mode
Privileged EXEC
Command Syntax
clear ip access-lists countersacl_namescope
Parameters
acl_name - Specify the name of ACL list. Options include the following:
no parameter - Specifies all ACLs.
access_list - Specifies the name of ACL.
scope - Specify the session affected by command. Options include the following:
no parameter - Clears all counters on all CLI sessions.
session - Clears counters only on the current CLI session.
Example
This command resets all IPv4 ACL counters.
switch(config)# clear ip access-lists counters
switch(config)#
clear ipv6 access-lists counters
The clear ipv6 access-lists counters command sets ACL counters to zero for the specified IPv6 Access Control List (ACL). The session parameter limits ACL counter clearing to the current CLI session.
The continue command creates a route map statement entry that enables additional route map evaluation of routes with parameters meeting the statement matching criteria.
A statement typically contains a match (route-map) and a set (route-map) command. The evaluation of routes with settings the same as match command parameters normally ends and the statement's set commands apply to the route. Routes that match a statement containing a continue command evaluate against the statement specified by the continue command.
When a route matches multiple route map commands, the last statement that the route matches determines the filter action (deny or permit) . The set commands in all statements matching the route apply to the route after completing the route map evaluation. Multiple set commands apply in the same order by the route evaluation against the statement containing them.
The no continue and default continue commands remove the corresponding continue command from the configuration mode route map statement by deleting the corresponding command from running-config.
Command Mode
Route-Map Configuration
Command Syntax
continuenext_seq
no continuenext_seq
default continuenext_seq
Parameters
next_seq - Specifies next statement for evaluating matching routes. Options include the following:
no parameter - The next statement in the route map, as determined by sequence number.
seq_number - Specifies the number of the next statement. Values range from 1 to 16777215.
Restrictions
A continue command cannot specify a sequence number smaller than the sequence number of the route map statement.
Related Command
route-map command enters the Route-Map Configuration Mode.
Example
This command creates route map map1, statement 40 with a match command, a set command, and a continue command. Routes that match the statement subsequently evaluate against statement 100. The set local-preference command applies to matching routes regardless of subsequent matching operations.
switch(config)# route-map map1 deny 40
switch(config-route-map-map1)# match as 15
switch(config-route-map-map1)# continue 100
switch(config-route-map-map1)# set local-preference 50
switch(config-route-map-map1)#
counters per-entry
The counters per-entry command places the ACL in counting mode. In counting mode, the feature generally displays the number of instances in which each rule in the list matches an inbound packet and the elapsed time since the last match. However, for certain select platforms, in addition to the packet counter, ACL counters can also be enabled for byte counts when applied to data plane ACLs. Review the complete list of platforms that support byte count for data plan ACLslisted below:
Note: Only dataplane ACLs support byte counting on the switch.
The following platforms support ACL byte counting:
On the FM6000 platform, this command has no effect when used in an ACL for a PBR class map.
The no counters per-entry and default counters per-entry commands place the ACL in non-counting mode.
Command Mode
ACL Configuration
IPv6-ACL Configuration
Std-ACL Configuration
Std-IPv6-ACL Configuration
MAC-ACL Configuration
Command Syntax
counters per-entry
no counters per-entry
default counters per-entry
Examples
This command places the test1 ACL in counting mode.
switch(config)# ip access-list test1
switch(config-acl-test1)# counters per-entry
switch(config-acl-test1)#
This command displays the ACL, with counter information, for an ACL in counting mode.
switch# show ip access-lists
IP Access List default-control-plane-acl [readonly]
counters per-entry
10 permit icmp any any
20 permit ip any any tracked [match 12041 packets, 0:00:00 ago]
30 permit ospf any any
40 permit tcp any any eq ssh telnet www snmp bgp https [match 11 packets, 1:41:07 ago]
50 permit udp any any eq bootps bootpc snmp rip [match 78 packets, 0:00:27 ago]
60 permit tcp any any eq mlag ttl eq 255
70 permit udp any any eq mlag ttl eq 255
80 permit vrrp any any
90 permit ahp any any
100 permit pim any any
110 permit igmp any any [match 14 packets, 0:23:27 ago]
120 permit tcp any any range 5900 5910
130 permit tcp any any range 50000 50100
140 permit udp any any range 51000 51100
Total rules configured: 14
Configured on Ingress: control-plane(default VRF)
Active on Ingress: control-plane(default VRF)
On platforms that support byte counting, Counter information displays as shown below:
switch# show ip access-lists
IP Access List default-control-plane-acl [readonly]
counters per-entry
10 permit icmp any any [match 30 packets, 0:02:08 ago]
20 permit ip any any tracked [match 97777 packets, 0:00:00 ago]
30 permit udp any any eq bfd ttl eq 255
40 permit udp any any eq bfd-echo ttl eq 254
50 permit udp any any eq multihop-bfd micro-bfd sbfd
60 permit udp any eq sbfd any eq sbfd-initiator
70 permit ospf any any
80 permit tcp any any eq ssh telnet www snmp bgp https msdp ldp netconf-ssh gnmi [match 72 packets, 0:00:00 ago]
90 permit udp any any eq bootps bootpc snmp rip ntp ldp ptp-event ptp-general
100 permit tcp any any eq mlag ttl eq 255
110 permit udp any any eq mlag ttl eq 255
120 permit vrrp any any
130 permit ahp any any
140 permit pim any any
Total rules configured: 14
Configured on Ingress: control-plane(default VRF)
Active on Ingress: control-plane(default VRF)
IP Access List ipCountersTest:The ipCountersTest ACL is applied to the data plane. Hence, it displays the byte count information as shown below:
counters per-entry
10 permit tcp host 10.1.1.1 range 2000 4000 host 10.2.1.1 [match 486 bytes in 3 packets, 0:00:26 ago]
20 permit tcp host 10.1.1.1 range 14000 16000 host 10.2.1.1 [match 486 bytes in 3 packets, 0:00:18 ago]
30 permit udp host 10.1.1.1 range 62000 64000 host 10.2.1.1 [match 450 bytes in 3 packets, 0:00:00 ago]
40 permit tcp host 10.1.1.1 range 50000 52000 host 10.2.1.1 [match 486 bytes in 3 packets, 0:00:02 ago]
50 permit tcp host 10.1.1.1 range 38000 40000 host 10.2.1.1 [match 486 bytes in 3 packets, 0:00:10 ago]
60 permit tcp host 10.1.1.1 range 26000 28000 host 10.2.1.1 [match 486 bytes in 3 packets, 0:00:18 ago]
Total rules configured: 6
ipCountersTest ACL applies to the data plane and displays the byte count information.
deny (IPv4 ACL)
The denycommand adds a deny rule to the configuration mode IPv4 Access Control List (ACL). Interfaces with the ACL drop packets filtered by a deny rule. Sequence numbers determine rule placement in the ACL. Sequence numbers for commands without numbers derive from adding 10 to the number of the ACL's last rule.
The no deny and default deny commands remove the specified rule from the configuration mode ACL. The no sequence number (ACLs) command also removes the specified rule from the ACL.
Note: Commands use a subset of the listed fields. Available parameters depend on specified protocol.
Parameters
seq_num - The sequence number assigned to the rule. Options include the following:
no parameter The number derive from adding 10 to the number of the ACL last rule.
14294967295 -The number assigned to the entry.
protocol Specify the protocol field filter. Values include the following:
ahp - Authentication Header Protocol (51
icmp - Internet Control Message Protocol (1)
igmp - Internet Group Management Protocol (2)
ip - Internet Protocol v4 (4)
ospf - Open Shortest Path First (89)
pim - Protocol Independent Multicast (103)
tcp - Transmission Control Protocol (6)
udp - User datagram protocol (17)
vrrp - Virtual Router Redundancy Protocol (112)
protocol_num - An integer corresponding to an IP protocol. Values range from 0 to 255.
source_addr and dest_addr - Specify the source and destination address filters. Values include the following:
network_addr - Specify the subnet address as a CIDR or address-mask.
any - Filter packets from all addresses.
hostip_addr - Specify an IP address in dotted decimal notation.
Subnet addresses support discontiguous masks.
source_port and dest_port - Specify the source and destination port filters. Values include the following:
any - Specify all ports.
eqport-1port-2 ... port-n - Specify a list of ports. Maximum list size is 10 ports.
neqport-1port-2 ... port-n - Specify the set of all ports not listed. Maximum list size is 10 ports.
gtport - Specify the set of ports with larger numbers than the listed port.
ltport - Specify the set of ports with smaller numbers than the listed port.
rangeport_1port_2 - Specify a range of ports.
fragments Filters packets with FO bit set that indicates a non-initial fragment packet.
flags Flag bit filters (TCP packets).
message Message type filters (ICMP packets).
tracked Rule filters packets in existing ICMP, UDP, or TCP connections.
Valid in ACLs applied to the control plane.
Validity in ACLs applied to data plane varies by switch platform.
dscp_filter - Filters a packet by the DSCP value. Values include the following:
no parameter -Specify that the rule does not use DSCP to filter packets.
dscpdscp_value - Specify to match packets match if the DSCP field in packet equals the dscp_value.
TTL_FILTER - Filters a packet by the TTL (time-to-live) value. Values include the following:
ttl eqttl_value - Match packets if ttl in packet is equal to ttl_value.
ttl gtttl_value - Match packets if ttl in packet is greater than ttl_value.
ttl ltttl_value - Match packets if ttl in packet is less than ttl_value.
ttl neqttl_value - Match packets if ttl in packet is not equal to ttl_value.
Valid in ACLs applied to the control plane.
Validity in ACLs applied to data plane varies by switch platform.
log - Triggers an informational log message to the console about the matching packet.
Valid in ACLs applied to the control plane.
Validity in ACLs applied to data plane varies by switch platform.
Examples
This command appends a deny statement at the end of the ACL. The deny statement drops OSPF packets from 10.10.1.1/24 to any host.
switch(config)# ip access-list text1
switch(config-acl-text1)# deny ospf 10.1.1.0/24 any
switch(config-acl-text1)#
This command inserts a deny statement with the sequence number 65. The deny statement drops all PIM packets.
switch(config-acl-text1)# 65 deny pim any any
switch(config-acl-text1)#
deny (IPv6 ACL)
The denycommand adds a deny rule to the an IPv6 Access Control List (ACL). Interfaces with the ACL drop packets filtered by a deny rule. Sequence numbers determine rule placement in the ACL. Sequence numbers for commands without numbers derive from adding 10 to the number of the ACL's last rule.
The no deny and default deny commands remove the specified rule from the configuration mode ACL. The no <sequence number> (ACLs) command also removes the specified rule from the ACL.
Note: Commands use a subset of the listed fields. Available parameters depend on specified protocol. Use CLI syntax assistance to view parameters for specific protocols when creating a deny rule.
Parameters
seq_num - The sequence number assigned to the rule. Optionsinclude the following:
no parameter - The number derived from adding 10 to the number of the ACL last rule.
1 - 4294967295 - A number assigned to an entry.
prot - Specify the protocol field filter. Values include the following:
icmpv6 - Internet Control Message Protocol for version 6 (58)
ipv6 - Internet Protocol IPv6 (41)
ospf - Open Shortest Path First (89)
tcp - Transmission Control Protocol (6)
udp - User Datagram Protocol (17)
protocol_num - An integer corresponding to an IP protocol. Values range from 0 to 255.
SRC_ADDR and DEST_ADDR - Specify source and destination address filters. Options include the following:
ipv6_prefix - Specify an IPv6 address with prefix length (CIDR notation).
any - Filter packets from all addresses.
hostipv6_addr - Specify an IPv6 host address.
SRC_PT and DEST_PT - Specify the source and destination port filters. Options include the following:
any - Specify all ports.
eqport-1port-2 ... port-n - Specify a list of ports. Maximum list size is 10 ports.
neqport-1port-2 ... port-n - Specify the set of all ports not listed. Maximum list size is 10 ports.
gt port - Specify the set of ports with larger numbers than the listed port.
ltport - Specify the set of ports with smaller numbers than the listed port.
rangeport_1port_2 - Specify a range of ports.
HOP - Filters by packet hop-limit value. Options include the following:
no parameter - The rule does not use hop limit to filter packets.
hop-limit eqhop_value - Match packetsif hop-limit value in packet equals hop_value.
hop-limit gthop_value - Match packets if hop-limit in packet is greater than hop_value.
hop-limit lthop_value - Match packets if hop-limit in packet is less than hop_value.
hop-limit neqhop_value - Match packets if hop-limit in packet is not equal to hop_value.
FLAG - Specify flag bit filters (TCP packets).
MSG - Specify message type filters (ICMPv6 packets).
tracked - Specify rule filters packets in existing ICMP, UDP, or TCP connections.
Valid in ACLs applied to the control plane.
Validity in ACLs applied to data plane varies by switch platform.
DSCP_FILTER- Filters packet by theDSCP value. Values include the following:
no parameter - The rule does not use DSCP to filter packets.
dscpdscp_value - Match packets if DSCP field in packet equalsthe dscp_value.
log - Triggers an informational log message to the console about the matching packet.
Valid in ACLs applied to the control plane.
Validity in ACLs applied to data plane varies by switch platform.
Example
This command appends a deny statement at the end of the ACL. The deny statement drops IPv6 packets from 3710:249a:c643:ef11::/64 to any host.
switch(config)# ipv6 access-list text1
switch(config-acl-text1)# deny ipv6 3710:249a:c643:ef11::/64 any
switch(config-acl-text1)#
deny (IPv6 Prefix List)
The deny command adds a deny rule in the IPv6 Prefix List Configuration Mode . Route map match commands use prefix lists to filter routes for redistribution into OSPF, RIP, or BGP domains. Routes are denied access when they match the prefix in a deny statement.
The no deny and default deny commands remove the specified rule from theIPv6 prefix list. The no deny command also removes the specified rule from the prefix list.
Command Mode
IPv6-pfx Configuration
Command Syntax
sequencedenyipv6_prefixmask
Parameters
sequence - A sequence number assigned to the rule. Options include the following:
no parameter - A number derived by adding 10 to the number of the list last rule.
seqseq_num - A number specified by seq_num. Value ranges from 0 to 65535.
ipv6_prefix - Specify the IPv6 prefix to filter routes (CIDR notation).
mask - Specify the range of the prefix to match.
no parameter - Requires an exact match with the subnet mask.
eqmask_e - Specify a prefix length equal to mask_e.
gemask_g Specify a range from mask_g to 128.
lemask_l - Specify a range from subnet mask length to mask_l.
gemask_lle mask_g - Specify a range from mask_g to mask_l.
mask_e, mask_land, and mask_g -from 1 to 128.
Example
This command appends a deny statement at the end of the text1 prefix list. The deny statement denies redistribution of routes with the specified prefix.
The deny command adds a deny rule to the MAC Access Control List (ACL) Configuration Mode.
Interfaces with an applied ACL drop packets filtered by a deny rule. Sequence numbers determine rule placement in the ACL. Sequence numbers for commands without numbers derive from adding 10 to the number of the ACL last rule.
The no deny and default deny commands remove the specified rule from the MAC Access Control List (ACL) Configuration Mode. The no <sequence number> (ACLs) command also removes the specified rule from the ACL.
Command Mode
MAC-ACL Configuration Mode
Command Syntax
seq_numdenysource_addrdest_addr [protocol][log]
no denysource_addrdest_addr [protocol][log]
default denysource_addrdest_addr [protocol][log]
Parameters
seq_num Sequence number assigned to the rule. Options include the following:
no parameter - A number derived by adding 10 to the number of the ACL's last rule.
1 - 4294967295 - A number assigned to entry.
source_addr and dest_addr - Configure source and destination address filters. Options includethe following:
mac_address mac_mask - Specify the MAC address and mask.
any - Filters all Packets from all addresses.
mac_address - Specifies a MAC address in 3x4 dotted hexadecimal notation (hhhh.hhhh.hhhh).
mac_mask - Specifies a MAC address mask in 3x4 dotted hexadecimal notation (hhhh.hhhh.hhhh).
0 - Requires an exact match to filter.
1 - Filters on any value.
protocol - Configure a protocol field filter. Values include the following:
protocol_num An integer corresponding to a MAC protocol. Values range from 0 to 65535.
log Triggers an informational log message to the console about the matching packet.
Examples
This command appends a permit statement at the end of the ACL. The deny statement drops all aarp packets from 10.1000.0000 through 10.1000.FFFF to any host.
switch(config)# mac access-list text1
switch(config-mac-acl-text1)# deny 10.1000.0000 0.0.FFFF any aarp
This command inserts a permit statement with the sequence number 25. The deny statement drops all packets through the interface.
switch(config-mac-acl-text1)# 25 deny any any
deny (Standard IPv4 ACL)
The deny command adds a deny rule to the Standard IPv4 Access Control List (ACL) Configuration Mode. Standard ACL rules filter on the source field.
Interfaces with an applied ACL drop packets filtered by a deny rule. Sequence numbers determine rule placement in the ACL. Sequence numbers for commands without numbers derive from adding 10 to the number of the ACL last rule.
The no deny and default deny commands remove the specified rule from the Standard IPv4 Access Control List (ACL) Configuration Mode. The no sequence number (ACLs) command also removes the specified rule from the ACL.
Command Mode
Std-ACL Configuration
Command Syntax
[seq_num] denysource_addrlog
no denysource_addrlog
default denysource_addrlog
Parameters
seq_num - Specify the sequence number assigned to the rule. Options include the following:
no parameter - A number derived by adding 10 to the number of the ACL last rule.
1 - 4294967295 - A number assigned to entry.
source_addr- Specify a source address filter. Options include the following:
network_addr - Specify a subnet address as a CIDR or address-mask.
any Filter packets from all addresses.
hostip_addr - Specify an IP address in dotted decimal notation.
Subnet addresses support noncontinuous masks.
log - Triggers an informational log message to the console about the matching packet.
Valid in ACLs applied to the control plane.
Validity in ACLs applied to data plane varies by switch platform.
Example
This command appends a deny statement at the end of the ACL. The deny statement drops packets from 10.10.1.1/24.
switch(config)# ip access-list standard text1
switch(config-std-acl-text1)# deny 10.1.1.1/24
switch(config-std-acl-text1)#
deny (Standard IPv6 ACL)
The denycommand adds a deny rule to the Standard IPv6 Access Control List (ACL) Configuration Mode. Standard ACL rules filter on the source field.
Interfaces with an applied ACL drop packets filtered by a deny rule. Sequence numbers determine rule placement in the ACL. Sequence numbers for commands without numbers derive from adding 10 to the number of the ACL's last rule.
The no deny and default deny commands remove the specified rule from the Standard IPv6 Access Control List (ACL) Configuration Mode. The no <sequence number> (ACLs) command also removes the specified rule from the ACL.
Command Mode
Std-IPv6-ACL Configuration
Command Syntax
seq_numdenysource_addr
no denysource_addr
default denysource_addr
Parameters
seq_num Sequence number assigned to the rule. Options include:
no parameter - A Number derived by adding 10 to the number of the ACL's last rule.
1 - 4294967295 - The number assigned to entry.
source_addr- The Source address filter configured for the ACL. Options include:
ipv6_prefix - IPv6 address with prefix length (CIDR notation).
any - Filter all packets from all addresses.
hostipv6_addr - Specify the IPv6 host address.
Example
This command appends a deny statement at the end of the ACL. The deny statement drops packets from 2103::/64.
switch(config)# ipv6 access-list standard text1
switch(config-std-acl-ipv6-text1)# deny 2103::/64
switch(config-std-acl-ipv6-text1)#
description (route map)
The description command adds a text string to the configuration mode route map. The string has no functional impact on the route map.
The no description and default description commands remove the text string from the configuration mode route map by deleting the corresponding description command from running-config.
Command Mode
Route-Map Configuration
Command Syntax
descriptionlabel_text
no description
default description
Parameter
label_text Character string assigned to the route map configuration.
These commands add description text to the XYZ-1 route map.
switch(config)# route-map XYZ-1
switch(config-route-map-XYZ-1)# description This is the first map.
switch(config-route-map-XYZ-1)# exit
switch(config)# show route-map XYZ-1
route-map XYZ-1 permit 10
Description:
description This is the first map.
Match clauses:
Set clauses:
switch(config)#
hardware access-list resource sharing vlan in
The hardware access-list resource sharing vlan in command enables the IPv4 Ingress Sharing of hardware resources on the switch when the same ACL applies to different VLANs.
The no hardware access-list resource sharing vlan in command disables the IPv4 Ingress Sharing of hardware resources on the switch.
Command Mode
Global Configuration
Command Syntax
hardware access-list resource sharing vlan [ipv4 | ipv6] in
no hardware access-list resource sharing vlan in
Guidelines
Ccompatible only with the DCS-7010 and DCS-7050x series switches.
Enabling IPv4 Ingress Sharing requires the restart of software agents on the platform. This is a disruptive process and impacts traffic forwarding.
Use the show platform trident command to verify the Ingress IPv4 Sharing information.
hardware access-list resource sharing vlan ipv4 out
The hardware access-list resource sharing vlan ipv4 out command enables IPv4 Egress RACL TCAM sharing on the switch.
The no hardware access-list resource sharing vlan ipv4 out command disables the IPv4 Egress RACL TCAM sharing on the switch. By default, the switch enables IPv4 Egress RACL sharing.
Command Mode
Global Configuration
Command Syntax
hardware access-list resource sharing vlan ipv4 out
no hardware access-list resource sharing vlan ipv4 out
Guidelines
Compatible only with the DCS-7280E and DCS-7500E series switches.
Disabling IPv4 RACL sharing requires the restart of software agents on the platform. This is a disruptive process and impacts traffic forwarding.
Enabling IPv4 RACL sharing, if previously disabled from the default configuration, requires the restart of software agents on the platform. This is a disruptive process and impacts traffic forwarding. Enabling IPv4 RACL sharing if uRPF is configured disables uRPF.
Use the show running-config all | include sharing command to verify whether or not sharing for egress IPv4 RACLs is enabled.
Example
This command verifies if IPv4 RACL sharing is enabled or disabled.
switch# show running-config all | include sharing
hardware access-list resource sharing vlan ipv4 out
---->It returns the following output if IPv4 RACL sharing is enabled.
hardware access-list update default-result permit
The hardware access-list update default-result permit command configures the switch to permit all traffic on Ethernet and VLAN interfaces with ACLs applied to them while modifying the ACLs. Permits traffic when modifying the ACL using one of the ip access-list commands, and ends when exiting the ACL Configuration Mode and rules populated in hardware. EOS disables this by default.
The no hardware access-list update default-result permit and default hardware access-list update default-result permit commands restore the switch to the default state and blocks traffic during ACL modifications by removing the corresponding hardware access-list update default-result permit command from the running-config.
Command Mode
Global Configuration
Command Syntax
hardware access-list update default-result permit
no hardware access-list update default-result permit
The hardware counter feature acl out command enables egress ACL hardware counters for IPv4 or IPv6 and count the number of packets matching rules associated with egress ACLs applied to various interfaces on a switch.
The no hardware counter feature acl out and default hardware counter feature acl out commands disable or return the egress ACL hardware counters to the default state.
Command Mode
Global Configuration
Command Syntax
hardware counter feature acl out [options [ipv4 | ipv6]
no hardware counter feature acl out [options [ipv4 | ipv6]
default hardware counter feature acl out [options [ipv4 | ipv6]
Parameters
options - ACL hardware counter options include the following:
ipv4 - Specify an IPv4 address.
ipv6 - Specify an IPv4 address.
Examples
This command enables IPv4 egress ACL hardware counters.
switch(config)# hardware counter feature acl out ipv4
switch(config)#
This command disables IPv4 egress ACL hardware counters.
switch(config)# no hardware counter feature acl out ipv4
switch(config)#
ip access-group (Service ACLs)
The ip access-group (Service ACLs) command configures a Service ACL to apply to a control-plane service. Specify the service by the command mode used to apply the Service ACL.
The no ip access-group and default ip access-group commands remove the corresponding ip access-group (Service ACLs) command from running-config.
Command Mode
Mgmt-SSH Configuration
Mgmt-API Configuration
Router-BGP Configuration
Router-OSPF Configuration
Router-IGMP Configuration
MPLS-LDP Configuration
Queue-Monitor-Streaming Configuration
MPLS-Ping Configuration
Mgmt-Telnet Configuration
Command Syntax
ip access-group acl_name [vrfvrf_name][in]
no ip access-groupacl_name [vrfvrf_name][in]
default ip access-groupacl_name [vrfvrf_name][in]
Parameters
Parameters vary by process.
acl_name - Specify the name of the Service ACL assigned to control-plane service.
vrfvrf_name - Specifies the VRF to apply the Service ACL.
in - Specifies inbound connections or packets only. Requires a keyword for SSH and Telnet services.
Example
These commands apply the Service ACL bgpacl to the BGP routing protocol in VRF purple.
The ip access-group command applies an IPv4 or standard IPv4 Access Control List (ACL) to an interface or subinterface in the Interface Configuration Mode.
The no ip access-group and default ip access-group commands remove the corresponding ip access-group command from running-config.
Command Mode
Interface-Ethernet Configuration
Interface-Port-Channel Configuration
Interface-VLAN Configuration
Command Syntax
ip access-grouplist_name[direction [in | out]]
no ip access-grouplist_name[direction [in | out]]
default ip access-grouplist_name [direction [in | out]]
Parameters
list_name - Specify the name of ACL assigned to interface.
direction Transmission direction of packets, relative to interface. Valid options include the following:
in - Inbound packets.
out - Outbound packets.
Considerations
Filtering of outbound packets by ACLs not supported on Petra platform switches.
Filtering of outbound packets by ACLs on FM6000 switches supported on physical interfaces only (Ethernet and port channels).
ACLs on sub-interfaces are supported on DCS-7280E, DCS-7500E, DCS-7280R, and DCS-7500R.
Example
These commands apply the IPv4 ACL named test2 to interface ethernet 3.
switch(config)# interface ethernet 3
switch(config-if-Et3)# ip access-group test2 in
switch(config-if-Et3)#
ip access-list
The ip access-list command places the switch in ACL Configuration Mode, a group change mode that modifies an IPv4 access control list. The command specifies the name of the IPv4 ACL that subsequent commands modify and creates an ACL if it references a nonexistent list. All changes in a group change mode edit session are pending until the end of the session.
The exit command saves pending ACL changes to running-config, then returns the switch to Global Configuration Mode. ACL changes are also saved by entering a different configuration mode.
The abort command discards pending ACL changes, returning the switch to Global Configuration Mode.
The no ip access-list and default ip access-list commands delete the specified IPv4 ACL.
Command Mode
Global Configuration
Command Syntax
ip access-listlist_name
no ip access-listlist_name
default ip access-listlist_name
Parameter
list_name - Specify the name of the ACL. Must begin with an alphabetic character. Cannot contain spaces or quotation marks.
This command places the switch in ACL configuration mode to modify the filter1 IPv4 ACL.
switch(config)# ip access-list filter1
switch(config-acl-filter1)#
This command saves changes to filter1 ACL, then returns the switch to Global Configuration Modee.
switch(config-acl-filter1)# exit
switch(config)#
This command discards changes to filter1, then returns the switch to Global Configuration Mode.
switch(config-acl-filter1)# abort
switch(config)#
ip access-list standard
The ip access-list standard command places the switch in STD-ACL Configuration Mode, a group change mode that modifies a standard IPv4 access control list. The command specifies the name of the standard IPv4 ACL that subsequent commands modify, and creates an ACL if it references a nonexistent list. All group change mode edit session changes are pending until the session ends.
The exit command saves pending ACL changes to running-config, then returns the switch to Global Configuration Mode. Pending changes are also saved by entering a different configuration mode.
The abort command discards pending ACL changes, returning the switch to global configuration mode.
The no ip access-list standard and default ip access-list standard commands delete the specified ACL.
Command Mode
Global Configuration
Command Syntax
ip access-list standardlist_name
no ip access-list standardlist_name
default ip access-list standardlist_name
Parameter
list_name - Specify the name of standard ACL. Must begin with an alphabetic character. Cannot contain spaces or quotation marks.
The ip prefix-list command creates a prefix list or adds an entry to an existing list. Route map match commands use prefix lists to filter routes for redistribution into OSPF, RIP, or BGP domains.
A prefix list comprises all prefix list entries with the same label. The sequence numbers of the rules in a prefix list specify the order for applying rules to a route evaluated by the match command.
The no ip prefix-list and default ip prefix-listcommands delete the specified prefix list entry by removing the corresponding ip prefix-list statement from running-config. If the no or default ip prefix-list command does not list a sequence number, the command deletes all entries of the prefix list.
Command Mode
Global Configuration
Command Syntax
ip prefix-listlist_name[deny | permit] [seqindex] network_addr [mask] resequenceseq_numberremarkcomment
no ip prefix-listlist_nameseq [index]
default ip prefix-listlist_nameseq [index]
Parameters
list_name - Specify a name for the prefix list.
seqseq_num- Specify the sequence number for the prefix list entry Value ranges from 0 to 65535.
permit | deny - Specifies route access when a route matches IP prefix list. Options include:
permit - Allows access when matching the specified subnet.
deny - Denies access when matching the specified subnet.
network_addr - Specify the subnet to filter routes. Use either a CIDR or address-mask format.
MASK - Specifies the range of the prefix to be matched.
no parameter Exact match with the subnet mask is required.
eqmask_e Prefix length is equal to mask_e.
gemask_g Range is from 1 to 32.
le mask_l Range is from subnet mask length to mask_l.
ge mask_llemask_g Range is from mask_g to mask_l.
mask_e, mask_l, and mask_g range from 1 to 32. When le and ge are specified, subnetmaskmask_g>mask_l.
remarkcomment - Add a comment to the prefix list configuration.
Example
This command places the switch in IPv4 prefix list configuration mode to create an IPv4 prefix list named route-one.
switch(config)# ip prefix-list route-one
switch(config-ip-pfx)#
These commands create four different rules for the prefix-list named route-one.
The ipv6 access-groupcommand applies an IPv6 or standard IPv6 Access Control List (ACL) to the configuration mode interface.
The no ipv6 access-group and default ipv6 access-group commands remove the corresponding ipv6 access-group command from running-config.
Command Mode
Interface-Ethernet Configuration
Interface-Port-Channel Configuration
Interface-VLAN Configuration
Command Syntax
ipv6 access-grouplist_name[in | out]
no ipv6 access-grouplist_name[in | out]
default ipv6 access-grouplist_name[in | out]
Parameters
list_name - Specify the name of the ACL assigned to interface.
[in | out] - Specify the transmission direction of packets, relative to interface. Valid options include the following:
in Inbound packets.
out Outbound packets.
Examples
These commands assign the IPv6 ACL named test2 to the interface ethernet 3.
switch(config)# interface ethernet 3
switch(config-if-Et3)# ipv6 access-group test2 in
switch(config-if-Et3)#
ipv6 access-group (Service ACLs)
The ipv6 access-group (Service ACLs) command configures an IPv6 or standard IPv6 Service ACL to be applied by a control-plane service. Specify the service with the command mode to apply the Service ACL.
The no ipv6 access-group (Service ACLs) and default ipv6 access-group (Service ACLs) commands remove the corresponding ipv6 access-group (Service ACLs) command from running-config.
Command Mode
Mgmt-SSH Configuration
Mgmt-API Configuration
Router-BGP Configuration
Router-OSPF Configuration
MPLS-LDP Configuration
Queue-Monitor-Streaming Configuration
MPLS-Ping Configuration
Mgmt-Telnet Configuration
Command Syntax
ipv6 access-groupipv6_acl_name [vrfvrf_name][in]
no ipv6 access-group [ipv6_acl_name][vrfvrf_name][in]
The ipv6 access-list command places the switch in IPv6-ACL Configuration Mode, a group change mode that modifies an IPv6 access control list. The command specifies the name of the IPv6 ACL that subsequent commands modify and creates an ACL if it references a nonexistent list. All changes in a group change mode edit session pend until the end of the session.
The exit command saves pending ACL changes to running-config, then returns the switch to global configuration mode. ACL changes are also saved by entering a different configuration mode.
The abort command discards pending ACL changes, returning the switch to Global Configuration Mode.
The no ipv6 access-list and default ipv6 access-list commands delete the specified IPv6 ACL.
Command Mode
Global Configuration
Command Syntax
ipv6 access-listlist_name
no ipv6 access-listlist_name
default ipv6 access-listlist_name
Parameters
list_name - Specify a name for the ACL. Must begin with an alphabetic character and cannot contain spaces or quotation marks.
Commands Available in IPv6-ACL configuration mode:
The ipv6 access-list standard command places the switch in std-IPv6-ACL-configuration mode, a group change mode that modifies a standard IPv6 access control list. The command specifies the name of the standard IPv6 ACL that subsequent commands modify and creates an ACL if it references a nonexistent list. All group change mode edit session changes are pending until the session ends.
The exit command saves pending ACL changes to running-config, then returns the switch to Global Configuration Mode. Pending changes are also saved by entering a different configuration mode.
The abort command discards pending ACL changes, returning the switch to global configuration mode.
The no ipv6 access-list standard and default ipv6 access-list standard commands delete the specified ACL.
Command Mode
Global Configuration
Command Syntax
ipv6 access-list standardlist_name
no ipv6 access-list standardlist_name
default ipv6 access-list standardlist_name
Parameters
list_name - Specify a name for the ACL. Must begin with an alphabetic character and cannot contain spaces or quotation marks.
Commands Available in std-IPv6-ACL configuration mode:
The ip prefix-list command places the switch in IPv6 prefix-list configuration mode, which is a group change mode that modifies an IPv6 prefix list. The command specifies the name of the IPv6 prefix list that subsequent commands modify and creates a prefix list if it references a nonexistent list. All changes in a group change mode edit session are pending until the end of the session.
The exit command saves pending prefix list changes to running-config, then returns the switch to global configuration mode. ACL changes are also saved by entering a different configuration mode.
The abort command discards pending changes, returning the switch to global configuration mode.
The no ipv6 prefix-list and default ipv6 prefix-list commands delete the specified IPv6 prefix list.
Command Mode
Global Configuration
Command Syntax
ipv6 prefix-listlist_name
no ipv6 prefix-listlist_name
default ipv6 prefix-listlist_name
Parameter
list_name Name of prefix list. Must begin with an alphabetic character. Cannot contain spaces or quotation marks.
Commands Available in IPv6-pfx configuration mode:
This command discards changes to the prefix list, then returns the switch to global configuration mode.
switch(config-ipv6-pfx)# abort
switch(config)#
mac access-group
The mac access-group command applies a MAC Access Control List (MAC ACL) when in the Interface Configuration Mode.
The no mac access-group and default mac access-group commands remove the specified mac access-group command from running-config.
Command Mode
Interface-Ethernet Configuration
Interface-Port-Channel Configuration
Command Syntax
mac access-grouplist_name [direction [in | out]]
no mac access-grouplist_name[direction [in | out]]
default mac access-grouplist_name [direction [in | out]]
Parameters
list_name - Specify the name of MAC ACL.
direction - Specify the transmission direction of packets, relative to interface. Valid options include:
in Inbound packets.
out Outbound packets.
Restrictions
Only Helix, Trident, and Trident II platform switches support filtering of outbound packets by MAC ACLs.
Example
These commands assign the MAC ACL named mtest2 to interface ethernet 3 to filter inbound packets.
switch(config)# interface ethernet 3
switch(config-if-Et3)# mac access-group mtest2 in
switch(config-if-Et3)#
mac access-list
The mac access-list command places the switch in MAC-ACL Configuration Mode, a group change mode that modifies a MAC access control list. The command specifies the name of the MAC ACL that subsequent commands modify and creates an ACL if it references a nonexistent list. All changes in a group change mode edit session are pending until the end of the session.
The exit command saves pending ACL changes to running-config, then returns the switch to Global Configuration Mode. ACL changes are also saved by entering a different configuration mode.
The abort command discards pending ACL changes, returning the switch to Global Configuration Mode.
The no mac access-list and default mac access-listcommands delete the specified list.
Command Mode
Global Configuration
Command Syntax
mac access-listlist_name
no mac access-listlist_name
default mac access-listlist_name
Parameter
list_name - Specify the name of the MAC ACL. Names must begin with an alphabetic character and cannot contain a space or quotation mark.
The match command creates a route map statement entry that specifies one route filtering command. When a statement contains multiple match commands, the permit or deny filter applies to a route only if the properties equal the corresponding parameters in each match command. When a route properties do not equal the command parameters, the route is evaluated against the next statement in the route map, as determined by sequence number. If all statements fail to permit or deny the route, the route is denied.
The no match and default match commands remove the matchcommand from the configuration mode route map statement by deleting the corresponding command from running-config.
Note: The route map configuration supports only standard ACL.
Command Mode
Route-Map Configuration
Command Syntax
matchcondition
no matchcondition
default matchcondition
Parameters
condition - Specifies criteria for evaluating a route. Options include the following:
aggregate-role - Specify the role in BGP contributor-aggregate relation. Options include the following:
contributor - Specify BGP aggregate contributor.
aggregate-attributes - Specify the Route map to apply against the aggregate route.
as1 to 4294967295 - Specify the BGP Autonomous System number.
as-pathpath_name - Specify the BGP Autonomous System path access list.
as-path length { <= | = | => } length
<= - Length of AS path must be less than or equal to specified value.
= - Length of AS path must be equal to specified value.
=> Length of AS path must be equal to or greater than specified value.
length - Value for AS path length comparison (0-4000).
communityname BGP community. Options include the following:
listname - Specify the BGP community.
listname - Specify the exact-match BGP community. The list must match the present set.
extcommunitylistname - Specify the BGP extended community. Options include the following:
listname - Specify the BGP community.
listname - Specify the exact-match BGP community. The list must match the present set.
interfaceintf_name - Specifies an interface. Options include the following::
ethernete_num - Specify the Ethernet interface.
loopbackl_num - Specify the Loopback interface.
port-channelp_num - Specify the Port channel interface.
vlanv_num - Specify the VLAN interface.
invert-result - Specify the Invert sub route map result.
ip addressLIST - Specify the IPv4 address filtered by an ACL or prefix list. Options include the following:
access-listacl_name - Specify the IPv4 address filtered by access control list (ACL).
prefix-listplv4_name- Specify the IPv4 address filtered by IP prefix list.
ip next-hop prefix-list plv4_name - Specify the IPv4 next-hop filtered by IP prefix list.
ip resolved-next-hop prefix-listplv4_name - Specify the IPv4 resolved next-hop filtered by IP prefix list.
ipv6 address prefix-list plv6_name - Specify the IPv6 address filtered by IPv6 prefix list.
ipv6 next-hop prefix-list plv6_name - Specify the IPv6 next-hop filtered by IPv6 prefix list.
ipv6 resolved-next-hop prefix-list plv6_name - Specify the IPv6 resolved nexthop filtered by IPv6 prefix list.
local-preference 1 to 4294967295 - Specify the BGP local preference metric.
metric 1 to 4294967295 - Specify the route metric.
metric-typeOSPF_TYPE - Specify the OSPF metric type. Options include the following:
type-1 OSPF type 1 metric.
type-2 OSPF type 2 metric.
source-protocol protocol_type - Specify the Routing protocol of route source. Options include the following:
This command creates a route map match rule that filters routes from BGP as 15.
switch(config)# route-map map1
switch(config-route-map-map1)# match as 15
switch(config-route-map-map1)#
This command adds a route-map match rule that the AS path be less than or equal to 300.
switch(config-route-map-map1)# match as-path length <= 300
switch(config-route-map-map1)#
no sequence number
The nosequence number command removes the rule with the specified sequence number from the ACL. The default <sequence number> command also removes the specified rule.
Command Mode
ACL Configuration
IPv6-ACL Configuration
Std-ACL Configuration
Std-IPv6-ACL Configuration
MAC-ACL Configuration
Command Syntax
noline_num
defaultline_num
Parameter
line_num - Specify the sequence number of rule to delete. Values range from 1 - 4294967295.
Example
This command removes statement 30 from the list.
switch(config-acl-test1)# show IP Access Lists test1
10 permit ip 10.10.10.0/24 any
20 permit ip any host 10.20.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
50 remark end of list
Total rules configured: 5
Configured on Ingress: Et1/1
Active on Ingress: Et1/1
switch(config-acl-test1)# no 30
switch(config-acl-test1)# show IP Access Lists
20 permit ip any host 10.20.10.1
40 permit ip any any
50 remark end of list
Total rules configured: 4
Configured on Ingress: Et1/1
Active on Ingress: Et1/1
permit (IPv4 ACL)
The permit command adds a permit rule to the configuration mode IPv4 Access Control List (ACL). Interfaces with the applied ACL accept packets filtered by a permit rule the ACL is applied. Sequence numbers determine rule placement in the ACL. Sequence numbers for commands without numbers derive from adding 10 to the number of the ACL last rule.
The no permit and default permit commands remove the specified rule from the configuration mode ACL. The no <sequence number> (ACLs) command also removes a specified rule from the ACL.
Commands use a subset of the listed fields and available parameters depend on specified protocol.
Parameters
seq_num- Specify the sequence number assigned to the rule. Options include the following:
no parameter - A number derived from adding 10 to the number of the ACL's last rule.
1 - 4294967295 - Specify the number assigned to entry.
protocol - Specify the protocol field filter. Options include the following:
ahp- Authentication Header Protocol (51)
gre - Generic Routing Encapsulation
gtp - GPRS Tunneling Protocol
icmp - Internet Control Message Protocol (1)
igmp -Internet Group Management Protocol (2)
ip -Any Internet Protocol v4 (4)
ospf -Open Shortest Path First (89)
pim -Protocol Independent Multicast (103)
tcp -Transmission Control Protocol (6)
udp -User datagram protocol (17)
vlan - Enter VLAN number and mask. VLAN value range from 1 to 4094, and mask value range from 0x000-0xFFF .
vrrp - Virtual Router Redundancy Protocol (112).
protocol_num -An integer corresponding to an IP protocol. Values range from 0 to 255.
src_addr and dest_addr - Specify the source and destination address filters. Options include the following:
network_addr - Specify the subnet address (CIDR or address-mask).
any - Filter packets from all addresses.
hostip_addr - Specify the IP address in dotted decimal notation.
Source and destination subnet addresses support discontiguous masks.
source_port and dest_port Source and destination port filters. varnames include:
any - Specify all ports.
eqport-1port-2 ... port-n - Specify a list of ports. Maximum list size is 10 ports.
neqport-1port-2 ... port-n - Specify the set of all ports not listed. Maximum list size is 10 ports.
gtport - Specify the set of ports with larger numbers than the listed port.
ltport - Specify the set of ports with smaller numbers than the listed port.
rangeport_1port_2 - Specify the set of ports within a range.
fragments -Filters packets with FO bit set (indicates a non-initial fragment packet).
flags -Specify the flags bit filters (TCP packets). Use CLI syntax assistance (?) to display varnames.
msg - Specify the message type filters (ICMP packets). Use CLI syntax assistance (?) to display varnames.
tracked - Specify the rule filters packets in existing ICMP, UDP, or TCP connections.
Valid in ACLs applied to the control plane.
Validity in ACLs applied to data plane varies by switch platform.
dscp_filter -Specify the rule filters packet by its DSCP value. Values include:
no parameter - The rule does not use DSCP to filter packets.
dscpdscp_value - Packets match if DSCP field in packet is equal to dscp_value.
ttl_filter - Rule filters packet by its TTL (time-to-live) value. Values include:
ttl eqttl_value - Match packets if ttl in packet is equal to ttl_value.
ttl gtttl_value - Match packets if ttl in packet is greater than ttl_value.
ttl ltttl_value - Match packets if ttl in packet is less than ttl_value.
ttl neqttl_value - Match packets if ttl in packet is not equal to ttl_value.
Valid in ACLs applied to the control plane.
Validity in ACLs applied to data plane varies by switch platform.
log-Specify to trigger an informational log message to the console about the matching packet.
Valid in ACLs applied to the control plane.
Validity in ACLs applied to data plane varies by switch platform.
Examples
This command appends a permit statement at the end of the ACL. The permit statement passes all OSPF packets from 10.10.1.1/24 to any host.
switch(config)# ip access-list text1
switch(config-acl-text1)# permit ospf 10.1.1.0/24 any
switch(config-acl-text1)#
This command inserts a permit statement with the sequence number 25. The permit statement passes all PIM packets through the interface.
switch(config-acl-text1)# 25 permit pim any any
switch(config-acl-text1)#
These commands configure ACL to permit VLAN traffic between any source and destination host.
switch(config)# ip access-list acl1
switch(config-acl-acl1)# permit vlan 1234 0x0 ip any any
permit (IPv6 ACL)
The permit command adds a permit rule to the configuration mode IPv6 Access Control List (ACL). Interfaces with the applied ACL accept packets filtered by a permit rule the ACL is applied. Sequence numbers determine rule placement in the ACL. Sequence numbers for commands without numbers derive from adding 10 to the number of the ACL last rule.
The no permit and default permit commands remove the specified rule from the configuration mode ACL. The no <sequence number> (ACLs) command also removes a specified rule from the ACL.
Note: Commands use a subset of the listed fields and available parameters depend on specified protocol.
Parameters
seq_num - The sequence number assigned to the rule. Options include the following:
no parameter.Number is derived by adding 10 to the number of the ACL’s last rule.
1 - 4294967295 Number assigned to entry.
protocol Specify the protocol field filter. Options include the following:
icmpv6 - Internet Control Message Protocol for IPv6 (58).
ipv6 - Internet Protocol IPv6 (41).
ospf - Open Shortest Path First (89).
tcp - Transmission Control Protocol (6).
udp - User Datagram Protocol (17).
vlan - Enter VLAN number. Value ranges from 1 to 4094.
protocol_num - Integer corresponding to an IP protocol. Values range from 0 to 255.
src_addr and dest_addr - Specify the source and destination address filters. Options include the following:
ipv6_prefix - Specify the IPv6 address with prefix length (CIDR notation).
any - Specify the Packets from all addresses are filtered.
hostipv6_addr - Specify the IPv6 host address.
source_pt and DEST_PT - Specify the source and destination port filters. Options include the following:
any All ports.
eqport-1port-2 ... port-n - Specify the list of ports. Maximum list size is 10 ports.
neqport-1port-2 ... port-n Specify the set of all ports not listed. Maximum list size is 10 ports.
gtport - Specify theset of ports with larger numbers than the listed port.
ltport - Specify the set of ports with smaller numbers than the listed port.
rangeport_1port_2 - Specify the set of ports whose numbers are in the range.
hop - Filter using the packet’s hop-limit value. Options include the following:
no parameter - The rule does not use hop limit to filter packets.
hop-limit eqhop_value - Match packets if hop-limit value in packet equals hop_value.
hop-limit gthop_value - Match packets if hop-limit in packet is greater than hop_value.
hop-limit lthop_value - Match packets if hop-limit in packet is less than hop_value.
hop-limit neqhop_value - Match packets if hop-limit in packet is not equal to hop_value.
flag - Flag bit filters (TCP packets).
msg - Message type filters (ICMPv6 packets).
tracked The rule filters packets in existing ICMP, UDP, or TCP connections.
Valid in ACLs applied to the control plane.
Validity in ACLs applied to data plane varies by switch platform.
dscp_filter The rule filters packet by its DSCP value. Options include the following:
no parameter - The rule does not use DSCP to filter packets.
dscpdscp_value - Match packets if DSCP field in packet is equal to dscp_value.
flow_label - The rule permits packets with IPv6 flow labels matching an exact value or a pattern based on a mask. varnames include:
no parameter - The rule does not use IPv6 flow labels to filter packets.
flow-label eqipv6_flow_label - The IPv6 flow label must exactly match ipv6_flow_label. Flow labels can range from 0 to 1048575.
flow-labelipv6_flow_labelflow_label_mask The IPv6 flow label must match a pattern defined by ipv6_flow_label and flow_label_mask. The mask is an inverse mask. Where the mask has a 0 bit, the flow label must match the ipv6_flow_label value, and where the mask has a 1 bit, the corresponding bit in the flow label is ignored. For example, if ipv6_flow_label is 10 (0b01010 in binary) and flow_label_mask is 0x14 (0b10100 in binary), the rule matches flow labels described by 0b.1.10 where “.” is a wildcard and can be either 0 or 1. The flow labels that match include 10 (0b01010), 14 (0b0110), 26 (0b11010), and 30 (0b1110). Flow labels can range from 0 to 1048575 and flow label masks can range from 0x00000 to 0xfffff.
log - Send an informational log message to the console when a packet matches.
Valid in ACLs applied to the control plane.
Validity in ACLs applied to data plane varies by switch platform.
Examples
This command appends a permit statement at the end of the ACL. The permit statement passes all IPv6 packets with the source address 3710:249a:c643:ef11::/64 and with any destination address.
These commands configure ACL to permit VLAN traffic between any source and destination host.
switch(config)# ip access-list acl2
switch(config-acl-acl2)# permit ipv6 vlan 1234 0x0 ip any any
switch(config-acl-acl2)# exit
switch(config)#
These commands add a rule to permit all IPv6 packets with flow label 23.
switch(config)# ipv6 access-list acl3
switch(config-acl-acl3)# permit ipv6 any any flow-label eq 23
switch(config-acl-acl3)# exit
switch(config)#
These commands create a rule to permit all IPv6 packets matched by the flow label 23 and the mask 0x5678.
switch(config)# ipv6 access-list acl4
switch(config-acl-acl4)# permit ipv6 any any flow-label 23 0x5678
switch(config-acl-acl4)# exit
switch(config)#
permit (IPv6 Prefix List)
The permitcommand adds a rule to the configuration mode IPv6 prefix list. Route map match commands use prefix lists to filter routes for redistribution into OSPF, RIP, or BGP domains. Routes are redistributed into the specified domain when they match the prefix that a permit statement specifies.
The no permit and default permit commands remove the specified rule from the prefix list. The noseq (IPv6 Prefix Lists) command also removes the specified rule from the prefix list.
Command Mode
IPv6-pfx Configuration
Command Syntax
seq_numpermitipv6_prefixmask
Parameters
seq_num - Specify the sequence number assigned to the rule. Options include the following:
no parameter - Number derived from adding 10 to the number of the list's last rule.
seqseq_num - Specify the number from the seq_num. Value ranges from 0 to 65535.
ipv6_prefix - Specify the IPv6 prefix that filters the routes in CIDR notation.
mask - Specify the range of the prefix to match.
no parameter - Requires an exact match with the subnet mask.
eqmask_e - Specify the prefix length equal to mask_e.
gemask_g - Specify the range from the mask_g to 128.
le mask_l - Specify the range from the subnet mask length to mask_l.
gemask_llemask_g Range is from mask_g to mask_l.
mask_e, mask_l and mask_g range from 1 to 128.
When le and ge are specified, the prefix list size mask_gmask_l.
Example
This command appends a permit statement at the end of the text1 prefix list. The permit statement allows redistribution of routes with the specified prefix.
The permit command adds a permit rule to the configuration mode MAC access control list packets through the interface to which the list is applied. Rule filters include protocol, source, and destination.
The no permit and default permit commands remove the specified rule from the configuration mode ACL. The no <sequence number> (ACLs) command also removes the specified rule from the ACL.
Command Mode
MAC-ACL Configuration
Command Syntax
seq_numpermitsource_addrdest_addrprotocollog
no permit source_addrdest_addrprotocollog
default permit source_addrdest_addrprotocollog
Parameters
seq_num - Specify the sequence number assigned to the rule. Options include the following:
no parameter - Specify the number derived by adding 10 to the number of the ACL's last rule.
1 - 4294967295 - Specify the number assigned to entry.
source_addr and dest_addr- Specify the source and destination address filters. Options include the following:
mac_addressmac_mask - Specify the MAC address and mask.
any - Filter packets from all addresses.
mac_address - Specifies a MAC address in 3x4 dotted hexadecimal notation (hhhh.hhhh.hhhh).
mac_mask - Specifies a MAC address mask in 3x4 dotted hexadecimal notation (hhhh.hhhh.hhhh).
0 - Require an exact match to filter.
1 - Filter on any value.
protocol - Specify the protocol field filter. Options include the following:
protocol_num Integer corresponding to a MAC protocol. Values range from 0 to 65535.
log - Specify to trigger an informational log message to the console about the matching packet.
Examples
This command appends a permit statement at the end of the ACL. The permit statement passes all aarp packets from 10.1000.0000 through 10.1000.FFFF to any host.
switch(config)# mac access-list text1
switch(config-mac-acl-text1)# permit 10.1000.0000 0.0.FFFF any aarp
switch(config-mac-acl-text1)#
This command inserts a permit statement with the sequence number 25. The permit statement passes all packets through the interface.
switch(config-mac-acl-text1)# 25 permit any any
switch(config-mac-acl-text1)#
permit (Standard IPv4 ACL)
The permit command adds a permit rule to a standard IPv4 Access Control List (ACL). Standard ACL rules filter on the source field.
Interfaces with the applied ACL accept packets filtered by a permit rule. Sequence numbers determine rule placement in the ACL. Sequence numbers for commands without numbers derive from adding 10 to the number of the ACL's last rule..
The no permit and default permit commands remove the specified rule from the ACL. The no <sequence number> (ACLs) command also removes the specified rule from the ACL.
seq_num - Specify the sequence number assigned to the rule. Options include the following:
no parameter - A number derived from adding 10 to the number of the ACL's last rule.
1 - 4294967295 Number assigned to entry.
source_addr - Specify the source address filter. Options include the following:
network_addr - Specify the subnet address in CIDR or as an address-mask.
any - Filter packets from all addresses.
hostip_addr - Specify the IP address in dotted decimal notation.
Subnet addresses support discontiguous masks.
log - Specify to trigger an informational log message to the console about the matching packet.
Valid in ACLs applied to the control plane.
Validity in ACLs applied to data plane varies by switch platform.
Example
This command appends a permit statement at the end of the ACL. The permit statement passes all packets with a source address of 10.10.1.1/24.
switch(config)# ip access-list standard text1
switch(config-std-acl-text1)# permit 10.1.1.1/24
switch(config-std-acl-text1)#
permit (Standard IPv6 ACL)
The permit command adds a permit rule to the standard IPv6 access control list. Standard ACL rules filter on the source field.
Interfaces with the applied ACL accept packets filtered by a permit rule. Sequence numbers determine rule placement in the ACL. Sequence numbers for commands without numbers derive from adding 10 to the number of the ACL's last rule.
The no permit and default permit commands remove the specified rule from the configuration mode ACL. The no <sequence number> (ACLs) command also removes the specified rule from the ACL.
Command Mode
Std-IPv6-ACL Configuration
Command Syntax
[seq_num] permitsource_addr
no permitsource_addr
default permitsource_addr
Parameters
seq_num - Specify the sequence number assigned to the rule. Options include the following:
no parameter - The number derived by adding 10 to the number of the ACL's last rule.
1 - 4294967295 - The number assigned to entry.
source_addr - Specify the source address filter. Options include the following:
ipv6_prefix - Specify the IPv6 address with prefix length (CIDR notation).
any - Filter packets from all addresses.
hostipv6_addr - Specify the IPv6 host address.
Example
This command appends a permit statement at the end of the ACL. The permit statement drops packets with a source address of 2103::/64.
switch(config)# ipv6 access-list standard text1
switch(config-std-acl-ipv6-text1)# permit 2103::/64
switch(config-std-acl-ipv6-text1)#
remark
The remark command adds a non-executable comment statement into the pending ACL. Remarks entered without a sequence number are appended to the end of the list. Remarks with a sequence number insert into the list as specified by the sequence number.
The default remark command removes the comment statement from the ACL.
The no remark command removes the comment statement from the ACL. The command can specify the remark by content or by sequence number.
Command Mode
ACL Configuration
IPv6-ACL Configuration
Std-ACL Configuration
Std-IPv6-ACL Configuration
MAC-ACL Configuration
Command Syntax
remarktext
line_numremark [text]
no remarktext
default remarktext
Parameters
text The comment text.
line_num Sequence number assigned to the remark statement. Value ranges from 1 - 4294967295.
Example
This command appends a comment to the list.
switch(config-acl-test1)# remark end of list
switch(config-acl-test1)# show
IP Access List test1
10 permit ip 10.10.10.0/24 any
20 permit ip any host 10.20.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
50 remark end of list
resequence (ACLs)
The resequence command assigns sequence numbers to rules in the configuration mode ACL. Command parameters specify the number of the first rule and the numeric interval between consecutive rules.
Maximum rule sequence number is 4294967295.
Command Mode
ACL Configuration
IPv6-ACL Configuration
Std-ACL Configuration
Std-IPv6-ACL Configuration
MAC-ACL Configuration
Command Syntax
resequence [start_num [inc_num]]
Parameters
start_num Sequence number assigned to the first rule. Default is 10.
inc_num Numeric interval between consecutive rules. Default is 10.
Example
The resequence command re-numbers the list, starting the first command at number 100 and incrementing subsequent lines by 20.
switch(config-acl-test1)# show
IP Access List test1
10 permit ip 10.10.10.0/24 any
20 permit ip any host 10.20.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
50 remark end of list
switch(config-acl-test1)# resequence 100 20
switch(config-acl-test1)# show
IP Access List test1
100 permit ip 10.10.10.0/24 any
120 permit ip any host 10.20.10.1
140 deny ip host 10.10.10.1 host 10.20.10.1
160 permit ip any any
180 remark end of list
route-map
The route-map command places the switch in Route-Map Configuration Mode, a group change mode that modifies a route map statement. The command specifies the name and number of the route map statement that subsequent commands modify and creates a route map statement if it references a nonexistent statement. All changes in a group change mode edit session pend until the end of the session.
Route maps define commands for redistributing routes between routing protocols. Use names, filter type (permit or deny), and sequence number to identify a route map statement. Statements with the same name are components of a single route map, and the sequence number determines the order in which the statements compare to a route.
The exit command saves pending route map statement changes to running-config, then returns the switch to global configuration mode. Also, save ACL changes by entering a different configuration mode.
The abort command discards pending changes, returning the switch to global configuration mode.
The no route-map and default route-map commands delete the specified route map statement from running-config.
Note: The route map configuration supports only standard ACL.
map_name - Assign a label to the route map. Protocols reference this label to access the route map.
filter_type - Specify the disposition of routes matching commands specified by route map statement.
permit - Redistribute routes when they match route map statement.
deny - Do not redistribute routes when they match route map statement.
no parameter Assigns permit as the filter_type.
When a route does not match the route map criteria, EOS evaluates the next statement within the route map to determine the redistribution action for the route.
sequence_number - Specify the route map position relative to other statements with the same name.
no parameter - Assign the sequence number of 10 (default) to the route map.
1-16777215 - Specifies sequence number assigned to route map.
Commands Available in Route-Map Configuration Mode:
The set command specifies modifications to routes selected for redistribution by the Route-Map Configuration Mode.
The no set and default set commands remove the specified set command from the Route-Map Configuration Mode statement by deleting the corresponding set command from running-config.
This command creates a route map entry that sets the local preference metric to 100 on redistributed routes.
switch(config)# route-map map1
switch(config-route-map-map1)# set local-preference 100
switch(config-route-map-map1)#
set as-path match
The set as-path match command configures the as_path attribute for prefixes either received from a BGP neighbor or advertised to a BGP neighbor in the Route-Map Configuration Mode.
The no set as-path match command removes the AS path specified for the BGP prefix.
Command Mode
Route-Map Configuration
Command Syntax
set as-path match [all replacement [none| auto]] as_path
set as-path match[all replacement [none| auto]] as_path
Parameters
none - Replaces the as_path of the matching routes with a null or an empty as_path.
auto - Applying the specific route map as an inbound policy to a corresponding BGP neighbor statement, then replace the as_path of the prefixes received from this neighbor with the neighbor AS number. If applying this route map as an outbound policy to a corresponding neighbor statement, then replace the as_path of the prefixes advertised to this neighbor with the locally configured AS number.
as_path - Replaces the AS-Path of the matching routes with an arbitrary as_path.
Examples
This command replaces the AS-Path with the none option.
switch# show ip bgp neighbors 80.80.1.2 advertised-routes
BGP routing table information for VRF default
Router identifier 202.202.1.1, local AS number 200
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E
- ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast, q - Queued
for advertisement
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop -
Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 101.101.1.0/24 80.80.1.1 - - - 200 i
* > 102.102.1.0/24 80.80.1.1 - - - 200 i
* > 103.103.1.0/24 80.80.1.1 - - - 200 302 i
* > 202.202.1.0/24 80.80.1.1 - - - 200 i
switch# configure terminal
switch(config)# route-map foo permit 10
switch(config-route-map-foo)# set as-path match all replacement none
switch(config-route-map-foo)# exit
switch(config)# router bgp 200
switch(config-router-bgp)# neighbor 80.80.1.2 route-map foo out
switch(config-router-bgp)# end
switch# show ip bgp neighbors 80.80.1.2 advertised-routes
BGP routing table information for VRF default
Router identifier 202.202.1.1, local AS number 200
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E
- ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast, q - Queued
for advertisement
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop -
Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 101.101.1.0/24 80.80.1.1 - - - 200 i
* > 102.102.1.0/24 80.80.1.1 - - - 200 i
* > 103.103.1.0/24 80.80.1.1 - - - 200 i
* > 202.202.1.0/24 80.80.1.1 - - - 200 i
Replace the AS-Path of matching prefixes with an empty or a null AS-Path. Remove AS 302 from prefix 103.103.1.0/24 as shown in the above output.
This command replaces the AS-Path with the auto option.
switch(config)# route-map foo permit 10
switch(config-route-map-foo)# set as-path match all replacement auto
switch(config-route-map-foo)# end
switch# show ip bgp neighbors 80.80.1.2 advertised-routes
BGP routing table information for VRF default
Router identifier 202.202.1.1, local AS number 200
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E
- ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast, q - Queued
for advertisement
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop -
Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 101.101.1.0/24 80.80.1.1 - - - 200 200 i
* > 102.102.1.0/24 80.80.1.1 - - - 200 200 i
* > 103.103.1.0/24 80.80.1.1 - - - 200 200 i
* > 202.202.1.0/24 80.80.1.1 - - - 200 200 i
Replaces the AS-Path of matching prefixes with the locally configured AS 200.
This command replaces the AS-Path with another AS-Path.
switch(config)# route-map foo permit 10
switch(config-route-map-foo)# set as-path match all replacement 500 600
switch(config-route-map-foo)# end
switch# show ip bgp neighbors 80.80.1.2 advertised-routes
BGP routing table information for VRF default
Router identifier 202.202.1.1, local AS number 200
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E
- ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast, q - Queued
for advertisement
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop -
Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 101.101.1.0/24 80.80.1.1 - - - 200 500 600 i
* > 102.102.1.0/24 80.80.1.1 - - - 200 500 600 i
* > 103.103.1.0/24 80.80.1.1 - - - 200 500 600 i
* > 202.202.1.0/24 80.80.1.1 - - - 200 500 600 i
Replaces the AS-Path of matching prefixes with 500 600 as configured.
Replaces the AS-Path with a combination of auto and an AS-Path.
switch(config)# route-map foo permit 10
switch(config-route-map-foo)# set as-path match all replacement auto 500 600
switch(config-route-map-foo)# end
switch# show ip bgp neighbors 80.80.1.2 advertised-routes
BGP routing table information for VRF default
Router identifier 202.202.1.1, local AS number 200
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E
- ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast, q - Queued
for advertisement
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop -
Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > 101.101.1.0/24 80.80.1.1 - - - 200 200 500 600 i
* > 102.102.1.0/24 80.80.1.1 - - - 200 200 500 600 i
* > 103.103.1.0/24 80.80.1.1 - - - 200 200 500 600 i
* > 202.202.1.0/24 80.80.1.1 - - - 200 200 500 600 i
Replaces the AS-Path of matching prefixes with the locally configured AS 200 and 500 600.
set as-path prepend
The set as-path prepend command adds a set statement to a route map to prepend one or more Autonomous System (AS) numbers to the as_path attribute of a BGP route.
The no set as-path prepend and default set as-path prepend commands remove the specified set statements from the route map and update all corresponding routes.
Command Mode
Route-Map Configuration
Command Syntax
set as-path prependauto | as_number [auto | as_number | last-ascount]
no set as-path prependauto | as_number [auto | as_number | last-ascount]
auto - Prepends the peer AS number for peer inbound route maps and the local AS number for peer outbound route maps.
as_number - Prepends the specified AS number. Enter in plain notation (values range from 1-4294967295) or in asdot notation as described in RFC 5396. In asdot notation, enter AS numbers from 1-65535 in plain notation, and enter AS numbers from 65536 to 4294967295 as two values separated by a dot. The first value is high-order and represents a multiple of 65536, and the second value is low-order and represents a decimal integer. For example, AS number 65552 can be entered as either 65552 or 1.16 (i.e., 1*65536+16). However entered, EOS stores the AS numbers internally in plain decimal notation and appear that way in show outputs.
last-ascount - Prepends the last AS number in the AS path count times. Values range from 1 to 15. Mutually exclusive with the use of the auto cmdname or the entry of one or more specified AS numbers, and not supported in multi-agent mode.
Examples
These commands create a route-map entry that prepends AS number 64496 and prepends either the peer or local AS number twice.
switch(config)# route-map map1
switch(config-route-map-map1)# set as-path prepend 64496 auto auto
switch(config-route-map-map1)# exit
switch(config)# show route-map map1
route-map map1 permit 10
Description:
Match clauses:
SubRouteMap:
Set clauses:
set as-path prepend 64496 auto auto
switch(config)#
The commands create a route-map entry that prepends AS numbers 64496, 64498, and 65552.
switch(config)# route-map map2
switch(config-route-map-map2)# set as-path prepend 64496 64498 1.16
switch(config-route-map-map2)# exit
switch(config)# show route-map map2
route-map map2 permit 10
Description:
Match clauses:
SubRouteMap:
Set clauses:
set as-path prepend 64496 64498 65552
switch(config)#
These commands create a route map entry that prepends the last AS number 12 times.
switch(config)# route-map map3
switch(config-route-map-map3)# set as-path prepend last-as 12
switch(config-route-map-map3)# exit
switch(config)# show route-map map3
route-map map3 permit 10
Description:
Match clauses:
SubRouteMap:
Set clauses:
set as-path prepend last-as 12
switch(config)#
set community (route-map)
The set community command specifies community attribute modifications to routes selected for redistribution. The set community none command removes community attributes from the route.
The no set community and default set community commands remove the specified community from the Route-Map Configuration Modestatement by deleting the corresponding statement from the running config.
Command Mode
Route-Map Configuration
Command Syntax
set community [gshut | aa:nn | community-list | internet | local-as | no-advertise | no-export | none | number]
no set community [gshut | aa:nn | additive | community-list | delete | internet | local-as | no-advertise | no-export | none | number]
default set community [gshut | aa:nn | additive | community-list | delete | internet | local-as | no-advertise | no-export | none | number]
Parameters
gshut - Configures a graceful shutdown in BGP.
aa:nn - Configures the community AS and network number, separated by colon. Value ranges from 0:0 to 65535:65535.
community-list - A label for community list.
internet - Advertises route to the Internet community.
local-as - Advertises route only to local peers.
no-advertise - Does not advertise route to any peer.
no-export - Advertises route only within BGP AS boundary.
none - Does not provide any community attributes.
number - Configures the community number. Value ranges from 1 to 4294967040.
additive - Adds specified attributes to the current community.
delete - Removes specified attributes from the current community.
EOS does not support disabling the process of graceful shutdown community.
Example
This command advertises routes only to local peers.
switch(config-route-map-map1)# show active
route-map map1 permit 10
match community instances <= 50
set community 0:456 0:2345
switch(config-route-map-map1)# set community local-as
switch(config-route-map-map1)# ip community-list 345 permit 23
switch(config)# route-map map1
switch(config-route-map-map1)# show active
route-map map1 permit 10
match community instances <= 50
set community 0:456 0:2345 local-as
switch(config-route-map-map1)#
set extcommunity (route-map)
The set extcommunity command specifies extended community attribute modifications to routes selected for redistribution. The set extcommunity none command removes extended community attributes from the route.
The no set extcommunity and default set extcommunity commands remove the specified set extcommunity command from the Route-Map Configuration Mode statement by deleting the corresponding statement from running-config.
Command Mode
Route-Map Configuration Mode
Command Syntax
set extcommunitycond_x [cond_2][cond_n][mod_type]
set extcommunity none
no set extcommunitycond_x [cond_2][cond_n][mod_type]
default set extcommunity cond_x [cond_2][cond_n][mod_type]
default set extcommunity none
Parameters
cond_x - Specifies extended community route map modification. Command may contain multiple attributes. Options include the following:
rtasn:nn - Specifies the route target attribute (AS:network number).
set (route-map) specifies attribute modifications for the redistributed routes.
Example
This command creates a route map entry in map1 that sets the route target extended community attribute.
switch(config)# route-map map1
switch(config-route-map-map1)# set extcommunity rt 10.13.2.4:100
switch(config-route-map-map1)#
show (ACL configuration modes)
The show command displays the contents of an Access Control List (ACL).
show or show pending displays the list as modified in ACL configuration mode.
show active displays the list as stored in running-config.
show comment displays the comment stored with the list.
show diff displays the modified and stored lists, with flags denoting the modified rules.
Exiting the ACL configuration mode stores all pending ACL changes to running-config.
Command Mode
ACL Configuration
IPv6-ACL Configuration
Std-ACL Configuration
Std-IPv6-ACL Configuration
MAC-ACL Configuration
Command Syntax
show
show active
show comment
show diff
show pending
Examples
The examples in this section assume these ACL commands are entered as specified.
These commands are stored in none:
10 permit ip 10.10.10.0/24 any
20 permit ip any host 10.21.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
50 remark end of list
The current edit session removed this command. This change is not yet stored to none:
20 permit ip any host 10.21.10.1
The current edit session added these commands ACL. They are not yet stored to none:
20 permit ip 10.10.0.0/16 any
25 permit tcp 10.10.20.0/24 any
45 deny pim 239.24.124.0/24 10.5.8.4/30
This command displays the ACL, as stored in the configuration.
switch(config-acl-test_1)# show active
IP Access List test_1
10 permit ip 10.10.10.0/24 any
20 permit ip any host 10.21.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
50 remark end of list
This command displays the pending ACL, as modified in ACL configuration mode.
switch(config-acl-test_1)# show pending
IP Access List test_1
10 permit ip 10.10.10.0/24 any
20 permit ip 10.10.0.0/16 any
25 permit tcp 10.10.20.0/24 any
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
45 deny pim 239.24.124.0/24 10.5.8.4/30
50 remark end of list
This command displays the difference between the saved and modified ACLs.
Rules added to the pending list are denoted with a plus sign (+).
Rules removed from the saved list are denoted with a minus sign (-)
switch(config-acl-test_1)# show diff
---
+++
@@ -1,7 +1,9 @@
IP Access List test_1
10 permit ip 10.10.10.0/24 any
20 permit ip any host 10.21.10.1
20 permit ip 10.10.0.0/16 any
25 permit tcp 10.10.20.0/24 any
30 deny ip host 10.10.10.1 host 10.20.10.1
40 permit ip any any
45 deny pim 239.24.124.0/24 10.5.8.4/30
show hardware tcam profile
The show hardware tcam profile command displays the hardware specific information for the current operational TCAM profile in the running configuration.
This command is applicable to DCS-7280(E/R) and DCS-7500(E/R) series switches only.
Command Mode
EXEC
Command Syntax
show hardware tcam profile [[profileName [[featurefeatureName] detail]]|[detail]
Parameters
profileName Selects the named profile.
featurefeatureNameSelects the specific feature by name.
detail Displays the content of the TCAM profile.
Guidelines
If the profile cannot be programmed, the Status column will print ‘ERROR‘. Any features that use TCAM functionality will not work properly. Do not expect any features to work if the profile is in the ‘ERROR’ state. If there are warnings or errors, a summary message will display warnings or errors found in programming the profile in addition to the system log messages.
Examples
The show hardware tcam profile lists the TCAM profile status on each line card. In case of successful programming it is as shown below.
switch(config)# show hardware tcam profile
Configuration Status
FixedSystem testprofile testprofile
If the profile cannot be programmed, the Status column prints ‘ERROR‘.
(config)# show hardware tcam profile
Configuration Status
Linecard3 newprofile1 ERROR
Linecard4 newprofile1 ERROR Linecard5 newprofile1 ERROR
Linecard6 newprofile1 ERROR
Linecard7 newprofile1 WARNING
Detailed Programming Status
Linecard3, Linecard4, Linecard5
[Error] feature flow is not supported on this hardware platform
Linecard7
[Warning] the key size of feature flow exceeds the configured key size limit
The show hardware tcam profile <profile> detail command displays further info about the TCAM profile features.
Note: The profile contains all the features that are untouched after copying from the base profile.
You can use the show hardware tcam profile command without the detail keyword to see all of the features configured in a profile without seeing how the features are defined.
(config-hw-tcam-profile-newfeature)# show hardware tcam profile default
Features enabled in TCAM profile default: [ Linecard3, Linecard4, Linecard6, Linecard
7, Linecard8, Linecard9, Linecard10 ]
mpls
acl vlan ipv6
acl subintf ipv6
acl vlan ipv6 egress
acl port ipv6
pbr ipv6
acl vlan ip
acl subintf ip
acl port ip
tunnel vxlan
acl port mac
pbr ip
pbr mpls
qos ipv6
qos ip
mirror ip
counter lfib
mpls pop ingress
show access-lists
The show access-lists command displays the contents of all IPv4, IPv6, and MAC Access Control Lists (ACLs) on the switch in addition to the configuration and status. Use the summary option to display only the configuration and status, which contains details such as the name of the ACL, total rules configured, configured and active status containing interface information, and supplicant information as in the case of dynamic ACLs from dot1x sessions.
Command Mode
Privileged EXEC
Command Syntax
show access-lists[interfaceinterface_acl] | [acl_nameacl_name] acl_name | [scopesummary]
Parameters
interface - Filter by interfaces such as Ethernet, VLANs, and Port Channels. Selection options include the following:
no parameter - Display all ACLs.
interface_acl - Display ACLs attached to the interface if present.
acl_name - Display the list name. Selection options include the following:
no parameter - Display all ACLs.
acl_name - Display a specific ACL.
scope - Display detailed or summarized information. Selection options include the following:
no parameter - Display all rules in the specified lists including the configuration and status.
summary - Display only the configuration and status of the ACL.
Examples
This command displays all rules in all the ACLs including IPv4, IPv6, and MAC and the configuration and status.
switch# show access-lists
Phone ACL bypass: disabled
IP Access List default-control-plane-acl [readonly]
counters per-entry
10 permit icmp any any
20 permit ip any any tracked [match 149061 bytes in 1721 packets, 0:00:00 ago]
30 permit udp any any eq bfd ttl eq 255
40 permit udp any any eq bfd-echo ttl eq 254
50 permit udp any any eq multihop-bfd micro-bfd sbfd
60 permit udp any eq sbfd any eq sbfd-initiator
70 permit ospf any any
80 permit tcp any any eq ssh telnet www snmp bgp https msdp ldp netconf-ssh gnmi [match 180 bytes in 3 packets, 0:03:08 ago]
90 permit udp any any eq bootps bootpc snmp rip ntp ldp ptp-event ptp-general [match 984 bytes in 3 packets, 1 day, 9:02:21 ago]
100 permit tcp any any eq mlag ttl eq 255
110 permit udp any any eq mlag ttl eq 255
120 permit vrrp any any
130 permit ahp any any
140 permit pim any any
150 permit igmp any any
160 permit tcp any any range 5900 5910
170 permit tcp any any range 50000 50100
180 permit udp any any range 51000 51100
190 permit tcp any any eq 3333
200 permit tcp any any eq nat ttl eq 255
210 permit tcp any eq bgp any
220 permit rsvp any any
230 permit tcp any any eq 9340
240 permit tcp any any eq 9559
250 permit udp any any eq 8503
260 permit udp any any eq lsp-ping
270 permit udp any eq lsp-ping any
Total rules configured: 27
Configured on Ingress: control-plane(default VRF)
Active on Ingress: control-plane(default VRF)
IP Access List v4Acl
10 permit ip any any
Total rules configured: 1
Configured on Ingress: Et1/1
Active on Ingress: Et1/1
Standard IP Access List stAcl
10 permit any
Total rules configured: 1
IP Access List noRulesAcl
Total rules configured: 0
Configured on Ingress: Et2/1
Active on Ingress: Et2/1
IPV6 Access List default-control-plane-acl [readonly]
counters per-entry
10 permit icmpv6 any any [match 335448 bytes in 4424 packets, 0:01:13 ago]
20 permit ipv6 any any tracked
30 permit udp any any eq bfd hop-limit eq 255
40 permit udp any any eq bfd-echo hop-limit eq 254
50 permit udp any any eq multihop-bfd micro-bfd sbfd
60 permit udp any eq sbfd any eq sbfd-initiator
70 permit ospf any any
80 permit 51 any any
90 permit 50 any any
100 permit tcp any any eq ssh telnet www snmp bgp https netconf-ssh gnmi
110 permit udp any any eq bootps bootpc snmp ntp ptp-event ptp-general
120 permit tcp any any eq mlag hop-limit eq 255
130 permit udp any any eq mlag hop-limit eq 255
140 permit tcp any any range 5900 5910
150 permit tcp any any range 50000 50100
160 permit udp any any range 51000 51100
170 permit udp any any eq dhcpv6-client dhcpv6-server
180 permit tcp any eq bgp any
190 permit tcp any any eq nat hop-limit eq 255
200 permit udp any any eq nat hop-limit eq 255
210 permit rsvp any any
220 permit pim any any
230 permit tcp any any eq 9340
240 permit tcp any any eq 9559
250 permit udp any any eq 8503
260 permit udp any any eq lsp-ping
270 permit udp any eq lsp-ping any
Total rules configured: 27
Configured on Ingress: control-plane(default VRF)
Active on Ingress: control-plane(default VRF)
IPV6 Access List v6Acl
10 permit ipv6 3891:3c58:6300::/64 any
20 permit ipv6 any host 2fe1:b468:24a::
30 deny ipv6 host 3411:91c1:: host 4210:cc23:d2de::
Total rules configured: 3
Configured on Ingress: Et1/1
Active on Ingress: Et1/1
MAC Access List mlist
10 deny any any
Total rules configured: 1
Configured on Ingress: Et11/1
Configured on Egress: Et11/1
Active on Ingress: Et11/1
Active on Egress: Et11/1
This command displays only the configuration and status of each ACL on the switch.
switch# show access-lists summary
Phone ACL bypass: disabled
IPV4 ACL default-control-plane-acl [readonly]
Total rules configured: 27
Configured on Ingress: control-plane(default VRF)
Active on Ingress: control-plane(default VRF)
IPV4 ACL v4Acl
Total rules configured: 1
Configured on Ingress: Et1/1
Active on Ingress: Et1/1
Standard IPV4 ACL stAcl
Total rules configured: 1
IPV4 ACL noRulesAcl
Total rules configured: 0
Configured on Ingress: Et2/1
Active on Ingress: Et2/1
IPV6 ACL default-control-plane-acl [readonly]
Total rules configured: 27
Configured on Ingress: control-plane(default VRF)
Active on Ingress: control-plane(default VRF)
IPV6 ACL v6Acl
Total rules configured: 3
Configured on Ingress: Et1/1
Active on Ingress: Et1/1
MAC ACL mlist
Total rules configured: 1
Configured on Ingress: Et11/1
Configured on Egress: Et11/1
Active on Ingress: Et11/1
Active on Egress: Et11/1
This command displays all rules in list2 ACL and the configuration and status.
switch# show access-list list2
IP Access List list2
10 permit ip 10.10.10.0/24 any
20 permit ip any host 10.20.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
Total rules configured: 3
Configured on Ingress: Et1/1
Active on Ingress: Et1/1
IPV6 Access List list2
10 permit ipv6 3891:3c58:6300::/64 any
20 permit ipv6 any host 2fe1:b468:24a::
30 deny ipv6 host 3411:91c1:: host 4210:cc23:d2de::
Total rules configured: 3
Configured on Ingress: Et2/1
Active on Ingress: Et2/1
switch#
The above output displayed two ACLs as the switch had an IPv4 ACL and an IPv6 ACL with the same name.
This command displays all rules in list2 ACL on Ethernet 1/1 with the configuration and status.
switch# show access-list list2 interface Ethernet 1/1
IP Access List list2
10 permit ip 10.10.10.0/24 any
20 permit ip any host 10.20.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
Total rules configured: 3
Configured on Ingress: Et1/1
Active on Ingress: Et1/1
switch#
show ip access-lists
The show ip access-lists command displays the contents of IPv4 and standard IPv4 Access Control List (ACLs) on the switch with the configuration and status. Use the summary option to display only the configuration and status with details such the name of the ACL, total rules configured, configured and active status containing interface information, and supplicant information as in the case of dynamic ACLs from dot1x sessions.
Command Mode
Privileged EXEC
Command Syntax
show ip access-lists [interfaceinterface_ipv4]|[acl_nameacl_name] | [scopesummary]
Parameters
interface Filter on interfaces such as Ethernet, VLANs, and Port Channels. Selection options include the following:
no parameter - Displays all IPv4 ACLs.
interface_ipv4 - Display the ACLs on a specified interface.
acl_name - Specify the name of a list to display. Selection options include the following:
no parameter - Displays all IPv4 ACLs.
acl_name - Specify an IPv4 ACL to display.
scope - Displays detailed or summarized information. Selection options include the following:
no parameter - Display all rules in the specified lists with the configuration and status.
summary - Display only the configuration and status.
Examples
This command displays all rules in list2 IPv4 ACL, configuration, and status.
switch# show ip access-lists list2
IP Access List list2
10 permit ip 10.10.10.0/24 any
20 permit ip any host 10.20.10.1
30 deny ip host 10.10.10.1 host 10.20.10.1
Total rules configured: 3
Configured on Ingress: Et1/1
Active on Ingress: Et1/1
switch#
The above output can also be displayed with the help of the show ip access-lists interface Ethernet 1/1 command since the ACL list2 applies to the Ethernet 1/1 interface.
This command displays the name and number of rules in each list on the switch.
switch# show ip access-lists summary
IPV4 ACL default-control-plane-acl
Total rules configured: 12
Configured on: control-plane
Active on : control-plane
IPV4 ACL list2
Total rules configured: 3
IPV4 ACL test1
Total rules configured: 6
Standard IPV4 ACL test_1
Total rules configured: 1
IPV4 ACL test_3
Total rules configured: 0
switch#
This command displays the summary and lists all the configured IPv4 ACLs.
switch # show ip access-lists summary
IPV4 ACL default-control-plane-acl [readonly]
Total rules configured: 17
Configured on Ingress: control-plane(default VRF)
Active on Ingress: control-plane(default VRF)
IPV4 ACL ipAclLimitTest
Total rules configured: 0
Configured on Egress: Vl2148,2700
Active on Egress: Vl2148,2700
show ip prefix-list
The show ip prefix-list command displays all rules for the specified IPv4 prefix list. The command displays all IPv4 prefix list rules if a prefix list name is not specified.
Command Mode
EXEC
Command Syntax
show ip prefix-list [display_itemslist_name]
Parameters
display_items - Specifies the name of prefix lists to display rules. Options include:
no parameter - Display all IPv4 prefix list rules.
list_name Specifies the IPv4 prefix list to display rules.
Example
This command displays all rules in the route-one IPv4 prefix list.
switch(config-ip-pfx)# show ip prefix-list
ip prefix-list route-one
seq 10 deny 10.1.1.0/24
seq 20 deny 10.1.0.0/16
seq 30 permit 12.15.4.9/32
seq 40 deny 1.1.1.0/24
switch(config-ip-pfx)#
show ipv6 access-lists
The show ipv6 access-lists command displays the contents of all IPv6 Access Control Lists (ACLs) on the switch with the configuration and status. Use the summary option to display only the configuration and status with contains details such as the name of the ACL, total rules configured, configured and active on status with interface information, and supplicant information in case of dynamic ACLs from dot1x sessions.
Command Mode
Privileged EXEC
Command Syntax
show ipv6 access-lists [ interfaceinterface_ipv6] [supplicantsupplicant][acl_nameacl_name][scopesummary]
Parameters
interface Filter on interfaces such as Ethernet, VLANs, and Port Channels. Selection options include the following:
no parameter - Displays all IPv6 ACLs.
interface_ipv6 - Display the ACLs on a specified interface.
acl_name - Specify the name of a list to display. Selection options include the following:
no parameter - Displays all IPv6 ACLs.
acl_name - Specify an IPv6 ACL to display.
scope - Displays detailed or summarized information. Selection options include the following:
no parameter - Display all rules in the specified lists with the configuration and status.
summary Display only the configuration and status.
Examples
This command displays all rules in test1 IPv6 ACL.
switch# show ipv6 access-lists list2
IP Access List list2
10 permit ipv6 3891:3c58:6300::/64 any
20 permit ipv6 any host 2fe1:b468:024a::
30 deny ipv6 host 3411:91c1:: host 4210:cc23:d2de:::
Total rules configured: 3
Configured on Ingress: Et1/1
Active on Ingress: Et1/1
switch#
The above output can also be displayed using the show ipv6 access-lists interface Ethernet 1/1 command since the ACL list2 applies to the Ethernet 1/1 interface.
This command displays the name and number of rules in each list on the switch.
switch# show ipv6 access-lists summary
IPV6 ACL list2
Total rules configured: 3
Configured on Ingress: Et1/1
Active on Ingress: Et1/1
IPV6 ACL test1
Total rules configured: 6
IPV6 ACL test_1
Total rules configured: 1
Standard IPV6 ACL test_3
Total rules configured: 0
switch#
show ipv6 prefix-list
The show ipv6 prefix-list command displays all rules for the specified IPv6 prefix list. The command displays all IPv6 prefix lists if a prefix list name is not specified.
Command Mode
EXEC
Command Syntax
show ipv6 prefix-list [display_itemslist_name]
Parameters
display_items Specifies the name of prefix lists for which rules are displayed. Options include:
no parameter All IPv6 prefix lists are displayed.
list_name Specifies the IPv6 prefix list for which rules are displayed.
Examples
This command displays all rules in the map1 IPv6 prefix list:
The show mac access-lists command displays the contents of all MAC Access Control Lists (ACLs) on the switch, along with their configuration and status. Use the summary option to display only the configuration and status, which contain details such as the name of the ACL, the total rules configured, and where the ACL is configured/active with a status containing specific interface information.
Command Mode
Privileged EXEC
Command Syntax
show mac access-lists [interfaceinterface_acl] [acl_nameacl_name] [scopesummary]
Parameters
interface - Filter by interfaces such as Ethernet, VLANs, and Port Channels. Selection options include the following:
no parameter - Display all MAC ACLs.
interface_acl - Display MAC ACLs attached to the interface if present.
acl_name Display the list name. Selection options include the following:
no parameter - Display all MAC ACLs.
acl_name - Display a specific MAC ACL.
scope - Display detailed or summarized information. Selection options include the following:
no parameter - Display all rules in the specified lists including the configuration and status.
summary - Display only the configuration and status of the MAC ACL.
Examples
This command displays all rules in mtest2 MAC ACL.
switch# show mac access-list mlist2
MAC Access List mlist2
10 permit 1024.4510.F125 0.0.0 any aarp
20 permit any 4100.4500.0000 0.FF.FFFF novell
30 deny any any
Total rules configured: 3
Configured on Ingress: Et1/1
Active on Ingress: Et1/1
The above output can also be displayed with the help of show mac access-lists interface Ethernet 1/1 command since the ACL mlist2 applies to the Ethernet 1/1 interface.
This command displays the number of rules in each MAC ACL on the switch.
switch# show mac access-list summary
MAC ACL mlist1
Total rules configured: 6
MAC ACL mlist2
Total rules configured: 3
Configured on Ingress: Et1/1
Active on Ingress: Et1/1
MAC ACL mlist3
Total rules configured: 1
MAC ACL mlist4
Total rules configured: 0
show platform arad acl tcam summary
The show platform arad tcam summary command displays the percentage of TCAM utilization per forwarding ASIC.
Command Mode
EXEC
Command Syntax
show platform arad acl tcamsummary
Parameter
summary - Displays the ACL TCAM summary.
Example
This command displays the percentage of TCAM utilization per forwarding ASIC.
switch# show platform arad acl tcam summary
The total number of TCAM lines per bank is 1024.
========================================================
Arad3/0:
========================================================
Bank Used Used % Used By
1 4 0 IP RACLs
Total Number of TCAM lines used is: 4
========================================================
Arad3/4:
========================================================
Bank Used Used % Used By
1 2 0 IP RACLs
Total Number of TCAM lines used is: 2
show platform arad acl tcam
The show platform arad acl tcam command displays the number of TCAM entries (hardware resources) occupied by the ACL on each forwarding ASIC.
This command applies only to DCS-7500E, DCS-7280E series switches.
scope Specifies the information displayed. Options include:
detail - Displays the ACL TCAM details.
diff - Displays the difference between hardware and shadow.
hw - Displays the ACL entries from hardware.
shadow - Displays the ACL entries from shadow.
summary - Displays the ACL TCAM summary.
Examples
This command displays the number of TCAM entries used by Arad0 ASIC. In this example, apply the ACL on two VLANs (Vl2148 and Vl2700) but number of TCAM entries occupied is only one.
switch# show platform arad acl tcam detail
ip access-list ipAclLimitTest (Shared RACL, 0 rules, 1 entries, direction out,
state success, Acl Label 2)
Fap: Arad0, Shared: true, Interfaces: Vl2148, Vl2700
Bank Offset Entries
0 0 1
Fap: Arad1, Shared: true, Interfaces: Vl2148
Bank Offset Entries
0 0 1
This command displays the percentage of TCAM utilization per forwarding ASIC.
switch# show platform arad acl tcam summary
The total number of TCAM lines per bank is 1024.
========================================================
Arad0:
========================================================
Bank Used Used % Used By
0 1 0 IP Egress PACLs/RACLs
Total Number of TCAM lines used is: 1
========================================================
Arad1:
========================================================
Bank Used Used % Used By
0 1 0 IP Egress PACLs/RACLs
Total Number of TCAM lines used is: 1
show platform arad mapping
The show platform arad mapping command displays the mapping between the interfaces and the forwarding ASICs.
Command Mode
EXEC
Command Syntax
show platform aradchip_namemapping
Parameter
chip_name Specifies the Arad chip name.
Example
This command displays the mapping between the interfaces and the forwarding ASICs on the Arad3/0 chip.
The show platform fap tcam command displays the number of TCAM entries (hardware resources) occupied by the ACL on each forwarding ASIC of Sand platform devices.
detail - Displays the number of TCAM entries (hardware resources) occupied by the ACL on each forwarding ASIC.
diff - Displays the difference between hardware and shadow.
hw - Displays ACL entries from hardware.
shadow - Displays ACL entries from shadow.
summary - Displays the percentage of TCAM utilization per forwarding ASIC.
Example
This command displays the number of TCAM entries and other ACL TCAM detail.
switch# show platform fap acl tcam detail
ip access-list ipAcl0000 (RACL, 1 rules, 2 entries, direction in, state success)
Shared: false
Interface: Vlan0002
-------------------
Fap: Arad3/0
Bank Offset Entries
1 0 2
Interface: Vlan0003
-------------------
Fap: Arad3/0
Bank Offset Entries
1 2 2
Fap: Arad3/4
Bank Offset Entries
1 0 2
show platform fap acl tcam hw
The show platform fap acl tcam hw command displays the TCAM entries configured for each TCAM bank including policy-maps and corresponding traffic match.
This command applies only to DCS-7280(E/R), DCS-7500(E/R) series switches.
Command Mode
EXEC
Command Syntax
show platform fapfap_nameacl tcam hw
Parameters
fap_name - Specifies the switch chip-set name.
Example
This command displays the TCAM entries configured for each TCAM bank including policy maps and corresponding traffic matches.
The show platform fap acl tcam summary command displays for each forwarding ASIC, the number of TCAM entries consumed per ACL type, and in which TCAM bank the entries are installed. A mirroring ACL does not consume TCAM resources unless attached to a mirroring source interface, and a mirroring destination is configured. If the mirroring destination is a GRE tunnel, at least one nexthop entry for the tunnel destination must be resolved before a TCAM entry is installed.
Command Mode
EXEC
Command Syntax
show platform fap acl tcam summary
Example
This command displays the number of TCAM entries consumed per ACL type, the bank installed, and ASIC. Three TCAM entries are consumed across two forwarding ASICs, two for IP ACLs, and one for MAC ACLs.
switch# show platform fap acl tcam summary
========================================================
Arad0:
========================================================
Bank Used Used % Used By
0, 1 2 0 IP Mirroring
Total Number of TCAM lines used is: 4
========================================================
Arad1:
========================================================
Bank Used Used % Used By
2 1 0 Mac Mirroring
show platform trident tcam
The show platform trident tcam command displays the TCAM entries configured for each TCAM group including policy maps and corresponding hits.
This command displays detailed information for the TCAM group.
switch# show platform trident tcam detail
=== TCAM detail for switch Linecard0/0 ===
TCAM group 9 uses 42 entries and can use up to 1238 more.
Mlag control traffic uses 4 entries.
589826 0 hits - MLAG - SrcPort UDP Entry
589827 0 hits - MLAG - DstPort UDP Entry
589828 0 hits - MLAG - SrcPort TCP Entry
589829 0 hits - MLAG - DstPort TCP Entry
CVX traffic reserves 6 entries (0 used).
L3 Control Priority uses 23 entries.
589836 0 hits - URM - SelfIp UDP Entry
589837 0 hits - URM - SelfIp TCP Entry
589848 0 hits - OSPF - unicast
589849 71196 hits - OSPFv2 - Multicast
589850 0 hits - OSPFv3 - Multicast
589851 0 hits - OSPF Auth ESP - Multicast
589852 0 hits - OSPF Auth ESP - Unicast
589853 0 hits - IP packets with GRE type and ISIS protocol
589854 0 hits - RouterL3 Vlan Priority 6,7 Elevator
589855 0 hits - RouterL3 DSCP 48-63 Elevator
589856 0 hits - RouterL3 Priority Elevator
589857 0 hits - NextHopToCpu, Glean
589858 0 hits - L3MC Cpu OIF
IGMP Snooping Flooding reserves 8 entries (6 used).
589864 0 hits - IGMP Snooping Restricted Flooding L3 from local
mlag peer
589865 0 hits - IGMP Snooping Restricted Flooding L3
L4 MicroBfd traffic reserves 1 entries (0 used).
TCAM group 13 uses 99 entries and can use up to 1181 more.
Dot1x MAB traffic uses 1 entries.
851968 0 hits - Dot1xMab Rule
<-------OUTPUT OMITTED FROM EXAMPLE-------->
ck338.22:14:38(config-pmap-qos-policy1)#
show route-map
The show route-map command displays the contents of configured route maps.
Command Mode
EXEC
Command Syntax
show route-map [map_name]
Parameters
no parameter Displays the content of all configured route maps.
map_name Displays the content of the specified route map.
Examples
This command displays the map1 route map.
switch(config)# show route-map map1
route-map map1 permit 10
Description:
Match clauses:
SubRouteMap:
Set clauses:
set as-path prepend last-as 12
set as-path prepend auto auto
This command displays the map route map.
switch> show route-map map
route-map map permit 5
Match clauses:
match as 456
Set clauses:
route-map map permit 10
Match clauses:
match ip next-hop 2.3.4.5
match as-path path_2
Set clauses:
set local-preference 100
system profile
The system profile command creates a new Ternary Content-Addressable Memory (TCAM) profile in the running configuration.
The default system profile and no system profile commands delete non-default TCAM profiles from the running configuration.
DirectFlow allows you to define flows consisting of conditions to match,
and actions to perform, that are a superset of the OpenFlow 1.0
specification. DirectFlow runs alongside the existing L2/L3
forwarding plane, enabling a network architecture that incorporates new
capabilities such as TAP aggregation and custom traffic engineering,
alongside traditional forwarding models. DirectFlow does not require a
controller or any third party integration, as flows can be installed via
the CLI.
DirectFlow exposes the underlying forwarding ASIC's capabilities through a programmable
interface like EAPI or the standard CLI.
DirectFlow works in conjunction with all other aspects of standard Layer 2 or Layer 3
bridging or forwarding, and DirectFlow traffic is subject to the standard packet
processing pipeline within the ASIC. You can think of DirectFlow as a stage in packet
processing that processes traffic after ingress checks and before any egress actions.
DirectFlow enables you to configure flows that consist of matching criteria and actions, and
to modify how traffic is processed, by overriding the L2 lookup decision or rewriting a
MAC address or VLAN for example.
Features like MAC learning, STP state checks, ingress or egress VLAN
membership checks on ports, ACLs, QoS, and others are all respected by
DirectFlow. Traffic that does not match any programmed flow is processed
normally, while traffic that matches programmed flows is now subject to
the actions specified in the flows.
DirectFlow Flows
You can define a relative priority between flows and define idle or hard timeouts for the flow.
DirectFlow also enables you to insert a flow entry that matches on specified criteria,
and define actions to be taken on traffic that matches the specified matching
conditions. You can define flows to match on TCP flags, IPv6 source and destination
addresses, input ports, and more.
DirectFlow enables you to configure
flows that are not visible in the startup or running configurations and
do not persist over a reboot. This feature is designed to be used for
flows that are configured by a custom agent using the EOS SDK or eAPI
and age out (expire) after a specified time period.
For example, if you are using a custom agent that reacts to traffic sent to the CPU (the redirect
to CPU action), and you want to use a flow that will drop all matching traffic for
5 minutes, the agent can program a non-persistent flow that
expires after a hard timeout of 300 seconds.
Using a non-persistent flow for this purpose
ensures that other administrator actions (for example, saving the configuration)
do not result in the flow being resurrected on startup or reverting to
the saved configuration. It also removes the need for the agent to delete
the expired flow.
Note: By default, all DirectFlow flows are persistent. You must use the nopersistent command to configure a non-persistent flow.
Supported Matches
DirectFlow supports all matches on VLAN, ether type, source or destination MAC address, COS,
source or destination IP address, IP protocol, IP TOS, L4 source, destination ports,
ICMP type, and code.
In addition, DirectFlow also allows matching on:
TCP flags
IPv6 source address
IPv6 destination address
Traffic injected from the CPU
Input port
DirectFlow also permits re-using the same
flow on multiple input ports, saving valuable TCAM space.
Supported Actions
DirectFlow supports the following actions:
Setting the source or destination MAC address
VLAN
COS
IP TOS
Transmit queue
Output port list and mirroring traffic pre-modification (ingress mirror) and
post-modification (egress mirror)
Redirect to CPU
The redirect to CPU action is useful in cases in which a custom agent is running on EOS and you
want to trap specific traffic (matching traffic) and send the trapped traffic to the
agent.
DirectFlow Configuration
Consider the following when using DirectFlow.
DirectFlow takes effect ONLY after exiting the
individual flow configuration sub-mode.
Match criteria are connected with Boolean AND
operators. Therefore they must all match for the condition to be true and
action to be taken.
CLI is automatically set to match the
ethertype to IP if IP fields (such as source or
destination address or L4 ports) are chosen as
part of other match/ action commands.
In a single flow, only the following fields
can be matched along with IPv4 or IPv6 source and destination addresses:
VLAN priority
VLAN ID
EtherType
Source interface
Class of Service (CoS)
Commands Used to Enable DirectFlow, Configure
and Display Flows
A number of different commands
are provided for the DirectFlow feature. The different commands enable
you to enter the DirectFlow configuration mode, enable DirectFlow, configure
flows, and display configured flows.
Note: ALL match criteria specified in a flow definition must match in the packet for the actions
specified to be applied to the traffic.
Enter the DirectFlow Configuration Mode
The directflow command places the switch in DirectFlow
configuration mode.
The match (DirectFlow-flow mode) command allows you to
configure a rule or a flow which match on L2, L3, L4 fields of a packet and specify
a certain action to either modify, drop or redirect the packet.
switch(config-directflow-Test-1)# match ethertype ip
switch(config-directflow-Test-1)# match source ip 10.10.10.10
Action Set
The action set (DirectFlow-flow mode) command allows you to
configure a packet to be routed out a layer three interface using a DirectFlow
entry.
switch(config-directflow-Test-1)# action egress mirror ethernet 7
switch(config-directflow-Test-1)# action set destination mac 0000.aaaa.bbbb
Finalize the Flow
DirectFlow flows do not take effect until you exit the configuration sub-mode for the
specified flow. Use the exit command to finalize the flow
and put it into effect.
switch(config)# directflow
switch(config-directflow)# flow redirect-http-cpu
switch(config-directflow-redirect-http=cpu)# match ip protocol tcp
switch(config-directflow-redirect-http-cpu)# match destination port 80
switch(config-directflow-redirect-http-cpu)# action output interface cpu
Configuring a Non-persistent Flow
DirectFlow flows are persistent by default. Use the nopersistent command to configure non-persistent flows.
switch config)# directflow
switch(config-directflow)# flow example-non-persistent
switch(config-directflow-example-non-persistent)# match input interface ethernet 25
switch(config-directflow-example-non-persistent)# action drop
switch(config-directflow-example-non-persistent)# no persistent
switch(config-directflow-example-non-persistent)# timeout hard 300
Display Details for Configured Flows
The detail option of the show directflow flows command enables you to display the
details of configured flows. You can use this command to verify that a
non-persistent flow is deleted after the timeout period configured for the flow has
elapsed.
The following example shows the use of
this command to view the configuration of a non-persistent flow before
the timeout period has elapsed, and a second time, after the timeout
period has expired.
The initial use of the command displays
the flow configuration (before the timeout expires).
The second use of the command displays the
flow details (after the timeout expires). The output shows that the flow
is no longer programmed.
switch(config-directflow)# show directflow flows example-non-persistent detail
Flow example-non-persistent: (Flow not programmed)
persistent: False
priority: 0
hard timeout: 300
idle timeout: 0
match:
ingress interface:
Et25
actions:
drop
matched: 0 packets, 0 bytes
DirectFlow Feature Interactions
DirectFlow flow entries can have one of the following actions:
A set of egress ports for sending a matched packet
Copy to CPU
Redirect to CPU
Drop
No specified action (in this case, the traffic is output normally).
The only exception is the ingress or egress
mirroring action, where the DirectFlow entry causes the packet to be
mirrored.
When the ingress or egress packets are
mirrored, the original traffic is sent out normally.
Bridging Features
DirectFlow entries have precedence over all entries in the MAC table, including
static MAC entries and static MAC drop entries. Packets that do not match
DirectFlow entries are forwarded based on the MAC address table.
VLANs: DirectFlow entries can modify the VLAN of a packet. MAC learning takes
place in the original VLAN for DirectFlow entries that modify the VLAN. The
modified packet will be subject to VLAN membership checks on the egress port. If
a packet has no VLAN tag, DirectFlow assumes it came in on the native VLAN for
the ingress interface. A VLAN override causes the packet to obey the VLAN rules
on the egress port.
Q-in-Q: Q-in-Q is supported as DirectFlow entries match only on the outer
tag.
Counters: All packets that match DirectFlow entries cause interface
counters to increment as usual.
Spanning Tree
DirectFlow runs alongside MSTP, RSTP,
and PVST. DirectFlow entries do not match on packets that ingress an
STP discarding port. DirectFlow entries that cause a packet to be forwarded
out an STP discarding port will result in the packets being dropped on
egress.
When STP is enabled, BPDUs will always
be trapped to the CPU. When STP is disabled, BPDUs will be subject to
DirectFlow entries and not be copied to the CPU by default.
LLDP, LAGs, and LACP
LLDP packets are always trapped to the CPU. DirectFlow entries can never match
LLDP packets.
LAGs are fully supported, and can be part of a match criteria and part of an
output action to an interface.
LACP packets are always trapped to CPU. DirectFlow entries can never match LACP
packets.
sFlow
sFlow is unaffected by DirectFlow.
IGMP Snooping
IGMP control packets are trapped to the
CPU when IGMP Snooping is enabled. DirectFlow entries can match IGMP
Snooping control traffic and override the trap to CPU.
Link-local-multicast packets are flooded
in hardware in the VLAN via a TCAM entry. DirectFlow entries can match
link-local-multicast packets and change the flooding behavior. As DirectFlow
entries have to specify output interfaces or drop, the action will conflict
and so matching DirectFlow entries will get precedence.
When IGMP snooping is enabled, unknown
IPV4 multicast packets are flooded to the multicast-router ports in the
VLAN. If DirectFlow entries match unknown IPV4 multicast packets, they
will override the flooding behavior.
Data packets in groups under IGMP snooping
control are sent to the group members through a MAC table entry. Matching
DirectFlow entries override the MAC table entries.
ACLs
DirectFlow entries are lower priority than any configured Port ACLs (ingress). Packets coming in
on a port that match DirectFlow entries obey any configured ACL on that port, and
will only apply to packets that have a permit action.
DirectFlow entries are higher priority
than any configured RACLs. Packets coming in on an L3 interface that
match DirectFlow entries ignore any RACLs configured on that interface.
DirectFlow entries are lower priority
than any configured Egress ACLs.
Layer Three Features and DirectFlow
DirectFlow runs alongside IP
routing. If a packet is routed out a layer three interface using a DirectFlow
entry, the actions associated with the entry will have to specify the
new source MAC and destination MAC for the packet, as well as the physical
port or LAG. If there are no output ports specified in an entry, packets
that match that entry will be dropped.
Unicast Routing
When unicast routing is enabled, DirectFlow
entries that match take precedence for all packets that would have been
otherwise been routed. The three exceptions are the ingress mirror, egress
mirror and copy-to-CPU actions where the packets will be routed normally
in addition to the action being performed. Routed packets that do not
match DirectFlow entries are forwarding based on the L3 lookup.
Multicast Routing
When multicast routing is enabled, DirectFlow
entries that match take precedence for all packets that would have otherwise
been multicast routed. The packets are not replicated based on the hardware
multicast tables, but are forwarded strictly according to the actions
specified by the DirectFlow entry. The entry can specify a set of output
interfaces, which will result in the packet being replicated based on
the DirectFlow entry.
Displaying DirectFlow Configurations
The show directflow flows command displays the contents of the flow table,
showing each entry with its match rules, actions, and packet counters.
This example shows the status of a default (persistent) flow.
switch(config-directflow)# show directflow flows
Flow Test1:
priority: 0
match:
ingress interface: Ethernet1
ethertype ip
source ip address: 10.10.10.10
actions:
output mirror: Ethernet2
matched: 0 packets, 0 bytes
switch(config-directflow)#
This example shows the status of a non-persistent flow. The flow will be deleted once
5 minutes have elapsed.
switch(config-directflow)# show directflow flows example-non-persistent
Flow example-non-persistent:
persistent: False
priority: 0
hard timeout: 300
idle timeout: 0
match:
ingress interface:
Et25
actions:
drop
matched: 0 packets, 0 bytes
The action drop command configures packets that match an
entry to be dropped.
The no action drop and default action
drop commands remove the statement from the DirectFlow
configuration mode.
Command Mode
Directflow-flow Configuration
Command Syntax
action drop
no action drop
default action drop
Example
This command sets the action for packets from Test-1 to be
dropped.
switch(config-directflow-Test-1)# action drop
switch#
action mirror (DirectFlow-flow
mode)
The action mirror command can be used to ingress or egress
mirror traffic to a mirror destination. This requires a mirror destination to be
setup on the switch. If a packet comes in or goes out an interface that is part of
another mirror session, then the destination for that destination as well as the
DirectFlow destination will receive a copy of the packet.
The no action mirror and default action
mirror commands remove the statement from DirectFlow
configuration mode.
Command Mode
Directflow-flow Configuration
Command Syntax
actionDIRECTIONmirrorINT_NAME
no actionDIRECTIONmirrorINT_NAME
default actionDIRECTIONmirrorINT_NAME
Parameters
DIRECTION transmission direction of traffic to be
mirrored.
ingress mirrors before any rewrites.
egress mirrors after rewrites.
INT_NAME Source interface for the mirroring
session.
ethernete_range Ethernet interfaces specified by
e_range.
port-channel p_range Port channel interfaces specified
by p_range.
Example
This command configures mirror traffic to ethernet
2.
switch(config-directflow)# flow Test1
switch(config-directflow-Test1)# match ethertype ip
switch(config-directflow-Test1)# match source ip 10.10.10.10
switch(config-directflow-Test1)# action egress mirror ethernet 2
switch(config-directflow-Test1)#
action output (DirectFlow-flow
mode)
The action output command configures an Ethernet or port
channel interface as the output of a specified port mirroring session.
The no action output and default action
outputcommands remove the statement from
DirectFlow configuration mode.
Command Mode
Directflow-flow Configuration
Command Syntax
action outputDESTINATION
no action outputDESTINATION
default action outputDESTINATION
Parameters
DESTINATION transmission direction of traffic to be
mirrored.
all mirrors transmitted and received traffic.
flood mirrors received traffic only.
interface ethernete_range Ethernet interfaces specified by
e_range.
interface port-channel p_range Port channel interfaces specified by
p_range.
nexthop vrfvrf_nameip_addr. If the next hop is reachable in the
default VRF, the default VRF does not need to be specified.
Examples
This command configures interface ethernet 7 as
the output for the mirroring
session.
The following commands configure a flow redirecting all traffic from
10.10.1.2 to
e_range next hop assuming an appropriately
configured TCAM
profile.
switch(config-directflow)# flow flow-sip-10_10_1_2-redirect-to-10_30_1_2
switch(config-directflow-Test1)# match ethertype ip
switch(config-directflow-Test1)# match source ip 10.10.1.2
switch(config-directflow-Test1)# action output nexthop 10.30.1.2
switch(config-directflow-Test1)#
action output interface
cpu (DirectFlow-flow mode)
The action output interface cpu command configures the
action (other commands are used to define the traffic matching conditions).
The no action output interface cpu and default
action output commands remove the statement from
DirectFlow configuration mode.
Command Mode
Directflow-flow Configuration
Command Syntax
action outputDESTINATION
no action outputDESTINATION
default action outputDESTINATION
Parameters
DESTINATION transmission direction of traffic to be
mirrored.
all mirrors transmitted and received traffic.
flood mirrors received traffic only.
interface cpu Ethernet interfaces specified by
e_range.
Examples
This command configures interface ethernet 7 as
the output for the mirroring
session.
These commands configure the action to redirect traffic matching the flow to
the CPU and the matching conditions for the flow.
switch (config)# directflow
switch(config-directflow)# flow redirect-http-cpu
switch(config-directflow-redirect-http=cpu)# match ip protocol tcp
switch{config-directflow-redirect-http-cpu)# match destination p cpuort 80
switch(config-directflow-redirect-http-cpu)# action output interface
action set (DirectFlow-flow
mode)
The action set command allows you to configure a packet to
be routed out a layer three interface using a DirectFlow entry. The actions
associated with the entry will have to specify the new source MAC and destination
MAC for the packet, as well as the physical port or LAG. If there are no output
ports specified in an entry, packets that match that entry will be dropped.
The no action set and default action
setcommands remove action set statement from DirectFlow
configuration mode.
Command Mode
Directflow-flow Configuration
Command Syntax
action setCONDITION
no action setCONDITION
default action setCONDITION
Parameters
CONDITION specifies parameter and value. Options include:
cos0 to 7 Cost of service.
destination macmac_addr Dotted hex notation.
ip tos0 to 255 Type of service.
source macmac_addr Dotted hex notation.
traffic-class0 to 7 Dotted hex notation.
vlan0 to 4094 Number of VLAN.
The no action set and default action
set commands require only the CONDITION type without a
specific condition value.
Example
These commands change the destination MAC of the
frame.
switch(config-directflow)# flow Test1
switch(config-directflow-Test1)# action egress mirror ethernet 7
switch(config-directflow-Test1)# action set destination mac 0000.aaaa.bbbb
directflow
The directflow command places the switch in DirectFlow
configuration mode.
The no directflow and default
directflow commands delete the DirectFlow configuration mode
statements from running-config.
DirectFlow configuration mode is not a group change mode;
running-config is changed immediately upon entering commands. The
exit command returns the switch to global
configuration mode.
Command Mode
Global Configuration
Command Syntax
directflow
no directflow
default directflow
Commands Available in DirectFlow-Flow configuration mode:
This command returns the switch to global management
mode.
switch(config-directflow)# exit
switch(config)#
flow (DirectFlow)
The flow command places the switch in flow
configuration mode.
The flow command specifies the name of the flow that
subsequent commands modify and creates a newflow definition if it references a
nonexistent flow. All changes in a flow configuration mode edit
session are pending until the session ends:
The exit command saves pending changes to
running-config and returns the switch to
DirectFlow configuration mode. Changes are also saved
by entering a different configuration mode.
The abort command discards pending changes,
returning the switch to DirectFlow configuration
mode.
The no flow and default flow
commands delete the specified role by removing the role and its statements from
running-config.
Command Mode
DirectFlow Configuration
Command Syntax
flowflow_name
no flowflow_name
default flowflow_name
Parameter
flow_name Name of flow.
Commands Available in DirectFlow-Flow configuration mode:
The match command allows you to configure a rule or a flow
which could match on L2, L3, L4 fields of a packet and specify a certain action to
modify, drop or redirect the packet.
All traffic ingressing on the switch will be matched against the flows installed. In
cases where none of the packets match, normal switching or routing behavior will
take over. When multiple entries match a packet, precedence is given to the entry
that was installed first.
The no match and default match
commands remove the match statement from the configuration
mode.
Command Mode
Directflow-flow Configuration
Command Syntax
matchCONDITION
no matchCONDITION
default matchCONDITION
Parameters
CONDITION specifies criteria for evaluating a route. Options
include:
cos0 to 7 cost of service.
destination ipipv4_sub destination IPv4 subnet. L3 fields valid
only if ethertype is IP (0x0800).
destination mac mac_addr Add to the existing community. Dotted
hex notation.
destination mac mac_addr mask mac_mask Add to the sting community. Dotted hex
notation.
destination port0 to 65535 Fields accepted only if protocol is
TCP|UDP.
ethertype0 to 65535 Layer 4 destination port.
ethertype ARP Layer 4 destination port.
ethertype IP Layer 4 destination port.
icmp code0 to 255 Fields accepted only if protocol is
ICMP.
icmp type0 to 255 Fields accepted only if protocol is
ICMP.
input interface ethernete_num Ethernet interface specified by
e_num.
input interface port-channelp_num Port channel interface specified by
p_num.
ip protocol0 to 255 Type of service.
ip protocol icmp L3 fields valid only if ethertype
is IP (0x0800).
ip protocol tcp L3 fields valid only if ethertype is IP (0x0800).
ip protocol udp L3 fields valid only if ethertype
is IP (0x0800).
ip tos0 to 255 L3 fields valid only if ethertype is IP
(0x0800).
source ipipv4_subnet L3 fields valid only if ethertype is
IP (0x0800).
source macmac_addr Add to the existing community. Dotted
hex notation.
source macmac_addr maskmac_mask Add to the sting community. Dotted hex
notation.
source port0 to 65535 Fields accepted only if protocol is
TCP| UDP.
tcp flag ack Layer 4 destination port.
tcp flag fin Layer 4 destination port.
tcp flag psh Layer 4 destination port.
tcp flag rst Layer 4 destination port.
tcp flag syn Layer 4 destination port.
tcp flag urg Layer 4 destination port.
tcp flag urg Layer 4 destination port.
vlan1 to 4094mask1 to 4095 Number of VLAN.
The no match and default match
commands require only the CONDITION type without a specific
condition value.
Example
This command creates the rules to match on Ethertype IP and Source IP
10.10.10.10.
switch(config-directflow)# flow Test1
switch(config-directflow-Test1)# persistent
switch(config-directflow-Test1)# match ethertype ip
switch(config-directflow-Test1)# match source ip 10.10.10.10
persistent
DirectFlow flows are persistent by default. Once finalized, they appear in the
running configuration, and if saved to startup config they will
persist over a reboot. The no form of the
persistent command prevents the flow from showing up
in running config, ensuring that it will not persist over a
reboot.
Command Mode
Directflow-flow Configuration
Command Syntax
persistent
no persistent
Example
These commands create and enable a non-persistent DirectFlow
flow.
switch(config)# directflow
switch(config-directflow)# flow example-non-persistent
switch(config-directflow-example-non-persistent)# match input interface ethernet 25
switch(config-directflow-example-non-persistent)# action drop
switch(config-directflow-example-non-persistent)# no persistent
switch(config-directflow-example-non-persistent)# timeout hard 300
switch(config-directflow-example-non-persistent)# exit
switch(config-directflow)#
priority (DirectFlow-flow
mode)
The priority command sets the priority for the flow match
rules. Each flow-table entry has an optional priority field, with a higher number
indicating a higher priority. Flows with the same priority may be loaded in any
order, and the order may be changed at any time. If multiple entries match a packet,
precedence is given to the entry that was installed first.
Priority numbers range from 0 to 65535. The default is
0. The higher priority rules match first.
The no priority and default
priority commands remove priority statement from the
DirectFlow configuration mode.
Command Mode
Directflow-flow Configuration
Command Syntax
prioritypriority_value
no priority
default priority
Parameter
priority_value priority xxx.
Value ranges from 0 to 65535. Default is
0.
Example
These commands assign the priority of 150 to flow
Test-1.
The show directflow command displays summary information
for DirectFlow. With the counters or
details options, it displays counters or details for all flows
configured on the switch.
Command Mode
EXEC
Command Syntax
show directflow [counters |
details]
Examples
This command displays summary information for
DirectFlow.
switch# show directflow
DirectFlow configuration: Enabled
Total matched: 0 packets
Total programmed flows: 3 flows
switch#
This command displays counters for all DirectFlow flows configured on the
switch.
The show directflow flows command displays the contents of
the flow table, showing each entry with its match rules, actions, and packet counters.
Including the name of a specific flow limits the output to information about the specified
flow.
Command Mode
EXEC
Command Syntax
show directflow flows [flow_name
[counters | detail]]
Parameters
flow_name name of flow for which to display information. If
no flow name is entered, command displays information for all flows.
counters displays DirectFlow counters for the specified
flow.
detail displays detailed information for the specified
flow.
Examples
This command displays the contents of the flow
table.
switch# show directflow counters
Flow Name Source Matched packets Matched bytes
--------- ------ --------------- -------------
test1 config 0 146
Total matched packets: 1
shutdown (DirectFlow)
The shutdown command, in DirectFlow mode, disables
DirectFlow on the switch. DirectFlow is disabled by default.
The no shutdown command re-enables DirectFlow.
Command Mode
Directflow Configuration
Command Syntax
shutdown
no shutdown
default shutdown
Examples
These commands enable DirectFlow on the
switch.
switch(config)# directflow
switch(config-directflow)# no shutdown
switch(config-directflow)#
This command disables DirectFlow
Flow.
switch(config-directflow-Test1)# shutdown
timeout (DirectFlow-flow
mode)
The timeout command, in DirectFlow mode,
command configures the connection timeout period for connection sessions. The
connection timeout period defines the interval between a users most recently entered
command and an automatic connection shutdown. Automatic connection timeout is
disabled by setting the idle-timeout to zero, which is the default setting.
Command Mode
Directflow-flow Configuration
Command Syntax
timeout [hard | idle]
no timeout
Parameters
idle session idle timeout length.
0 Automatic connection timeout is
disabled.
1-4294967295 Automatic timeout period
(seconds).
hard session hard timeout length.
0 Automatic connection timeout is
disabled.
1-4294967295
Example
These commands enable a hard timeout period of 5
seconds on the
switch.
switch(config)# directflow
switch(config-directflow-Test1)# timeout hard 5
switch(config-directflow-Test1)#
These commands enable DirectFlow on the
switch.
switch(config)# directflow
switch(config-directflow-Test1)# no timeout hard
switch(config-directflow-Test1)#
/Loading%20the%20files%20into%20the%20VMware%20vSphere%20environment.png)
/Selecting%20New%20Virtual%20Machine.png)
The New Virtual Machine dialog appears./New%20Virtual%20Machine%20dialog.png)
/New%20Virtual%20Machine%20dialog%20(naming%20and%20selecting%20the%20location).png)
/New%20Virtual%20Machine%20dialog%20(selecting%20the%20datastore).png)
/New%20Virtual%20Machine%20dialog%20(compatibility%20options).png)
/New%20Virtual%20Machine%20dialog%20(operating%20system%20options).png)
/New%20Virtual%20Machine%20dialog%20(hardware%20configuration%20options).png)
