The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter contains the following sections:
The Border Gateway Protocol (BGP) control plane feature enables the Cisco Nexus 1000V to exchange the VXLAN information collected on the VSM-VTEP flood list across VSMs. The Cisco Nexus 1000V supports BGP peering between 16 VSMs to allow VXLAN segments to reach across servers. BGP runs on the VSM and can exchange VXLAN information with the BGP on any other Cisco Nexus 1000V. The Cisco Nexus 1000V can also be used as a route reflector to exchange VTEP list between VSMs.
The BGP control plane feature extends the unicast-only mode to a multi-VSM environment using a L2VPN EVPN address family. The VTEP information is not exchanged with the VSMs that are running the old version. They will continue to work in multicast mode (VXLAN 1.0) or unicast-only mode in a single Cisco Nexus 1000V (VXLAN 1.5).
The BGP control plane has the following prerequisites:
The VSM must be running the latest release. The VTEP information is not exchanged with VSMs that are running older release. They will continue to work in multicast mode or unicast only mode in a single Cisco Nexus 1000V.
On the control0 interface, an IP address is configured for BGP peering.
The Switch must have a valid NEXUS_1000V_ADVANCED_PACKAGE license (version 3.0) is installed.
You must configure a BGP routing process and BGP peers.
You must enable BGP before you can configure BGP.
Ensure that you are in the correct VDC.
switch# configure terminal switch(config)# feature bgp switch(config)# interface control0 switch(config-if)# ip address 14.17.199.1/24 switch(config-if)# vrf context default switch(config-if)# ip route 0.0.0.0/0 14.17.199.254 switch(config-if)# exit switch(config)# show feature Feature Name Instance State ----------------------------- -------- -------- bgp 1 enabled
You can create a BGP instance and assign a router ID to the BGP instance. Cisco NX-OS supports 2-byte or 4-byte autonomous system (AS) numbers in plain-text notation or as.dot notation.
This example shows how to enable BGP with the l2vpn evpn address family and manually add one network to advertise:
switch# configure terminal switch(config)# router bgp 64496 switch(config-router)# router-id 192.169.67.11 switch(config-router)# address-family l2vpn evpn switch(config-router-af)# copy running-config startup-config
You can restart a BGP instance and clear all peer sessions for the instance.
Command or Action | Purpose |
---|
You can shut down the BGP protocol and gracefully disable BGP and retain the configuration.
Command or Action | Purpose |
---|
You can configure a BGP peer within a BGP process. Each BGP peer has an associated keepalive timer and hold timers. You can set these timers either globally or for each BGP peer. A peer configuration overrides a global configuration.
![]() Note | You must configure the address family under neighbor configuration mode for each peer. |
This example shows how to configure a BGP peer:
switch# configure terminal switch(config)# router bgp 64496 switch(config-router)# neighbor 192.0.2.1 remote-as 64497 switch(config-router)# password password1 switch(config-router-neighbor)# description Peer Router B switch(config-router-neighbor)# address-family l2vpn evpn switch(config-router-neighbor-af)# send-community extended switch(config-router-neighbor-af)# copy running-config startup-config
The Cisco Nexus 1000V implements three types of peer templates:
You can use BGP session templates to simplify the BGP configuration for multiple BGP peers with similar configuration needs. BGP templates allow you to reuse common configuration blocks. You configure BGP templates first and then apply these templates to BGP peers.
With BGP session templates, you can configure session attributes such as inheritance, passwords, timers, and security.
A peer-session template can inherit from one other peer-session template. You can configure the second template to inherit from a third template. The first template also inherits this third template. This indirect inheritance can continue for up to seven peer-session templates.
Any attributes configured for the neighbor take priority over any attributes inherited by that neighbor from a BGP template.
![]() Note | When editing a template, you can use the no form of a command at either the peer or template level to explicitly override a setting in a template. You must use the default form of the command to reset that attribute to the default state. |
This example shows how to configure a BGP peer-session template and apply it to a BGP peer:
switch# configure terminal switch(config)# router bgp 65536 switch(config-router)# template peer-session BaseSession switch(config-router-stmp)# timers 30 90 switch(config-router-stmp)# exit switch(config-router)# neighbor 192.168.1.2 remote-as 65536 switch(config-router-neighbor)# inherit peer-session BaseSession switch(config-router-neighbor)# description Peer Router A switch(config-router-neighbor)# copy running-config startup-config
You can configure a peer-policy template to define attributes for a particular address family. You assign a preference to each peer-policy template and these templates are inherited in the order specified, for up to five peer-policy templates in a neighbor address family.
The Cisco Nexus 1000V evaluates multiple peer policies for an address family by using the preference value. The lowest preference value is evaluated first. Any attributes configured for the neighbor take priority over any attributes inherited by that neighbor from a BGP template.
Peer-policy templates can configure address family-specific attributes such as AS-path filter lists, prefix lists, route reflection, and soft reconfiguration.
![]() Note | When editing a template, you can use the no form of a command at either the peer or template level to explicitly override a setting in a template. You must use the default form of the command to reset that attribute to the default state. |
This example shows how to configure a BGP peer-policy template and apply it to a BGP peer:
switch# configure terminal switch(config)# router bgp 65536 switch(config-router)# template peer-session BasePolicy switch(config-router-ptmp)# maximum-prefix 20 switch(config-router-ptmp)# exit switch(config-router)# neighbor 192.168.1.1 remote-as 65536 switch(config-router-neighbor)# address-family l2vpn evpn switch(config-router-neighbor-af)# inherit peer-policy BasePolicy switch(config-router-neighbor-af)# copy running-config startup-config
You can configure BGP peer templates to combine session and policy attributes in one reusable configuration block. Peer templates can also inherit peer-session or peer-policy templates. Any attributes configured for the neighbor take priority over any attributes inherited by that neighbor from a BGP template. You configure only one peer template for a neighbor, but that peer template can inherit peer-session and peer-policy templates.
Peer templates support session and address family attributes, such as eBGP multihop time-to-live, maximum prefix, next-hop self, and timers.
![]() Note | When editing a template, you can use the no form of a command at either the peer or template level to explicitly override a setting in a template. You must use the default form of the command to reset that attribute to the default state. |
This example shows how to configure a BGP peer template and apply it to a BGP peer:
switch# configure terminal switch(config)# router bgp 65536 switch(config-router)# template peer BasePeer switch(config-router-neighbor)# inherit peer-session BaseSession switch(config-router-neighbor-af)# inherit peer-policy BasePolicy 1 switch(config-router-neighbor-af)# exit switch(config-router-neighbor)# exit switch(config-router)# neighbor 192.168.1.2 remote-as 65536 switch(config-router-neighbor)# inherit peer BasePeer switch(config-router-neighbor)# copy running-config startup-config
You can reduce the Internal BGP (iBGP) mesh by using a route reflector configuration where route reflectors pass learned routes to neighbors so that all iBGP peers do not need to be fully meshed.
The figure below shows a simple iBGP configuration with four meshed iBGP speakers (routers A, B, C, and D.) Without these route reflectors, when router A receives a route from an external neighbor, it advertises the route to all three iBGP neighbors.
When you configure an iBGP peer to be a route reflector, it becomes responsible for passing iBGP learned routes to a set of iBGP neighbors.
In the figure, router B is the route reflector. When the route reflector receives routes advertised from router A, it advertises (reflects) the routes to routers C and D. Router A no longer has to advertise to both routers C and D.
The route reflector and its client peers form a cluster. You do not have to configure all iBGP peers to act as client peers of the route reflector. You must configure any nonclient peer as fully meshed to guarantee that complete BGP updates reach all peers.
You can configure iBGP peers as route reflector clients to the local BGP speaker, which acts as the route reflector. Together, a route reflector and its clients form a cluster. A cluster of clients usually has a single route reflector. In such instances, the cluster is identified by the router ID of the route reflector. To increase redundancy and avoid a single point of failure in the network, you can configure a cluster with more than one route reflector. You must configure all route reflectors in the cluster with the same 4-byte cluster ID so that a route reflector can recognize updates from route reflectors in the same cluster.
This example shows how to configure the router as a route reflector and add one neighbor as a client:
switch(config)# configure terminal switch(config)# router bgp 65536 switch(config-router)# neighbor 192.0.2.10 remote-as 65536 switch(config-router-neighbor)# address-family l2vpn evpn switch(config-router-neighbor-af)# route-reflector-client switch(config-router-neighbor-af)# copy running-config startup-config
To display the BGP Control Plane configuration, use one of the following commands:
Command | Purpose |
show bgp session |
Displays the BGP sessions. |
show bgp l2vpn evpn summary |
Displays the BGP peers, status, and number of prefixes received from the peers. |
show bgp l2vpn evpn |
Displays the VTEPs that are learned through the BGP. |
show bgp l2vpn evpn rd |
Displays the detailed output for a specific segment ID or RD. |
show bgp convergence |
Displays the BGP convergence time. |
show bgp l2vpn evpn evi all vtep |
Displays the VTEP list for a specific VXLAN segment ID or all segments. |
show bgp l2vpn evpn evi id vtep VTEP IP address |
Displays the VTEP list for a specific VXLAN segment ID or all segments. |
show bridge-domain vteps |
Displays the bridge domain-to-VTEP mappings that are maintained by the VSM and are pushed to all VEMs. Remote Cisco Nexus 1000V VTEPs that are learned through BGP are designated with the Remote keyword. |
This example shows how to display the BGP sessions:
vsm# show bgp session Total peers 1, established peers 1 ASN 65000 VRF default, local ASN 65000 peers 1, established peers 1, local router-id 1.1.1.1 State: I-Idle, A-Active, O-Open, E-Established, C-Closing, S-Shutdown Neighbor ASN Flaps LastUpDn|LastRead|LastWrit St Port(L/R) Notif(S/R) 14.17.199.2 65000 0 00:04:05|00:00:04|00:00:04 E 61467/179 0/0
This example shows how to display BGP peers, status, and number of prefixes received from the peers:
vsm# show bgp l2vpn evpn summary BGP summary information for VRF default, address family L2VPN EVPN BGP router identifier 172.23.181.67, local AS number 1 BGP table version is 10, L2VPN EVPN config peers 1, capable peers 1 4 network entries and 4 paths using 484 bytes of memory BGP attribute entries [3/384], BGP AS path entries [0/0] BGP community entries [0/0], BGP clusterlist entries [0/0] Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 172.23.181.68 4 1 19 28 10 0 0 00:13:01 1 .
TThis example shows how to display the VTEPs that are learned through the BGP:
vsm# show bgp l2vpn evpn BGP routing table information for VRF default, address family L2VPN EVPN BGP table version is 10, local router ID is 172.23.181.67 Status: s-suppressed, x-deleted, S-stale, d-dampened, h-history, *-valid, >-best Path type: i-internal, e-external, c-confed, l-local, a-aggregate, r-redist Origin codes: i - IGP, e - EGP, ? - incomplete, | - multipath Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 172.23.181.67:5000 (EVI 5000) # RD = <Router-id>:<segment-id> *>l[3]:[5000]:[4]:[192.168.69.3]/88 #Local VTEP 192.168.69.3 0.0.0.0 100 32768 i *>i[3]:[5000]:[4]:[192.168.69.104]/88 #VTEP 192.168.69.104 that are learned from peer 172.23.181.68 172.23.181.68 100 0 i
This example shows how to display the detailed output for a specific segment ID or RD:
vsm# show bgp l2vpn evpn rd 172.23.181.67:5000 BGP routing table information for VRF default, address family L2VPN EVPN BGP table version is 10, local router ID is 172.23.181.67 Status: s-suppressed, x-deleted, S-stale, d-dampened, h-history, *-valid, >-best Path type: i-internal, e-external, c-confed, l-local, a-aggregate, r-redist Origin codes: i - IGP, e - EGP, ? - incomplete, | - multipath Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 172.23.181.67:5000 (EVI 5000) BGP routing table entry for [3]:[5000]:[4]:[192.168.69.3]/88, version 4 Paths: (1 available, best #1) Flags: (0x00000a) on xmit-list, is not in l2rib/evpn Path type: local, path is valid, is best path AS-Path: NONE, path locally originated 0.0.0.0 (metric 0) from 0.0.0.0 (0.0.0.0) Origin IGP, MED not set, localpref 100, weight 32768 Extcommunity: RT:1:5000 Advertised to peers: 172.23.181.68 BGP routing table entry for [3]:[5000]:[4]:[192.168.69.104]/88, version 10 Paths: (1 available, best #1) Flags: (0x00001a) on xmit-list, is in l2rib/evpn Path type: internal, path is valid, is best path Imported from 172.23.181.68:5000:[3]:[5000]:[4]:[192.168.69.104]/88 AS-Path: NONE, path sourced internal to AS 172.23.181.68 (metric 0) from 172.23.181.68 (172.23.181.68) Origin IGP, MED not set, localpref 100, weight 0 Extcommunity: RT:1:5000 Not advertised to any peer
This example shows how to display the BGP convergence time:
vsm# show bgp convergence Global settings: BGP start time 01:46:06 Config processing completed 0.280000 after start BGP out of wait mode 0.280000 after start Information for VRF default Initial-bestpath timeout: 300 sec, configured 0 sec First peer up 00:00:24 after start Bestpath timer not running IPv4 Unicast: First bestpath signalled 00:00:06 after start First bestpath completed 00:00:06 after start L2VPN EVPN: First bestpath signalled 00:00:06 after start First bestpath completed 00:00:06 after start #First Convergence event.
This example shows how to display the VTEP list for a specific VXLAN segment id or all segments:
vsm# show bgp l2vpn evpn evi all vtep BGP routing table information for VRF default, address family L2VPN EVPN BGP table version is 17, local router ID is 192.168.66.10 Status: s-suppressed, x-deleted, S-stale, d-dampened, h-history, *-valid, >-best Path type: i-internal, e-external, c-confed, l-local, a-aggregate, r-redist Origin codes: i - IGP, e - EGP, ? - incomplete, | - multipath Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 192.168.66.10:5000 (EVI 5000) *>i66.100.0.1 192.168.66.100 100 0 i *>l192.168.69.101 0.0.0.0 100 32768 i *>i192.168.69.201 192.168.67.10 100 0 i
This example shows how to display the VTEP list for a specific VXLAN segment id or all segments:
BGP routing table information for VRF default, address family L2VPN EVPN Route Distinguisher: 192.168.66.10:5000 (EVI 5000) BGP routing table entry for [3]:[5000]:[4]:[192.168.69.101]/88, version 2 Paths: (1 available, best #1) Flags: (0x00000a) on xmit-list, is not in l2rib/evpn Path type: local, path is valid, is best path AS-Path: NONE, path locally originated 0.0.0.0 (metric 0) from 0.0.0.0 (0.0.0.0) Origin IGP, MED not set, localpref 100, weight 32768 Extcommunity: RT:1:5000 Advertised to peers: 192.168.66.100 192.168.67.10
This example shows how to display the bridge domain-to-VTEP mappings that are maintained by the VSM and are pushed to all VEMs:
vsm# show bridge-domain vteps D: Designated VTEP I:Forwarding Publish Incapable VTEP Note: (*) Denotes active gateway module Bridge-domain: vxlan-5000 VTEP Table Version: 13 Port Module VTEP-IP Address VTEP-Flags ------------------------------------------------------------------------------ Veth5 3 192.168.69.101 (D) Remote - 66.100.0.1 (DI) Remote - 192.168.69.201 (DI)
Feature Name | Releases | Feature Information |
---|---|---|
BGP Control Plane |
5.2(1)SV3(1.1) |
BGP Control Plane was introduced. |