Chapter 15. Enhancements in BGP
The following topics are covered in this chapter:
Link-State Distribution using Border Gateway Protocol (BGP)
BGP for Tunnel setup
Provider Backbone Bridging with Ethernet VPN (PBB-EVPN)
This chapter serves as an introduction to some of the new features and enhancements that have been developed in recent years in BGP. During the course of this book, you have seen how BGP can be used in various environments, such as enterprise, service providers, and even data centers. Some new features developed in BGP extended the capability of BGP in the SDN world and also provides the organizations with the capability to use BGP for overlay-based features. This chapter provides an introduction to such features and helps direct the future of networking and possibilities with BGP.
Link-State Distribution Using BGP
Over the past few decades, there has been a massive change on how networks behave and how organizations manage the networks. The networking industry has seen a change from process switching of packets to hardware switching. With new developments happening across the networking industry, the focus has now turned to software defined networks (SDN), where the network can be programmatically controlled by a centralized controller.
Resource Reservation Protocol for Traffic Engineering (RSVP-TE) has been used for path computation purposes, but it has its own limitations. RSVP-TE does not provide optimal path computation and faces the bin-packing problem with Multi-Area or Multi-AS TE. The bin-packing problem is a classic problem, which deals with the distribution of traffic along available paths so that the available paths are efficiently utilized. The TE head-end router has limited visibility only in its domain—that is, the local Interior Gateway Protocol (IGP) area or local autonomous system (AS). To overcome such challenges, it makes more sense to move the label switch path (LSP) path computation control over to a central controller, which has visibility to the entire domain. This further allows for more efficient path calculation.
Because of the previously stated challenges, there has been a growing interest in providing an abstracted view of networks that enables higher-level applications to provide useful functionalities to businesses and users. The Application Layer Traffic Optimization (ALTO) servers, defined in RFC 5693, and Path Computation Elements (PCE), defined in RFC 4655, are examples of such components that provide network abstractions. An ALTO server hosts the ALTO service, which directs the resource consumer on which resource provider to select to optimize performance while improving resource consumption. PCE is an entity that is capable of computing paths in a network based on a network graph by applying computational constraints during computation, such as in case of TE LSP. These components, while external to the network, require network state information on a real-time basis. Specifically, they require link-state database information of each IGP node (Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS)) from the entire network.
Even in Segment Routing, a centralized path controller can prevent traffic steering problems. This is done by calculating the paths at the controller and then signaling it to the head-end node.
An ALTO server needs to have L3 topology, BGP or IGP, to compute the network distance between various endpoints. Likewise, the PCE server needs similar information for computing traffic engineering tunnels. Although topology information may be acquired by peering with both BGP and IGP, the IGP feed may not be viable in practice because of different administration control of the network operation, and IGP peering may not provide full visibility into all areas of the IGP.
Figure 15-1 displays a topology with PCE as a central controller. The PCE is being used to calculate optimal paths for TE in an Inter-Area TE deployment. For PCE to calculate optimal paths, PCE requires the complete topology and resource information database, usually known as Traffic Engineering Database (TED). The TED requires the topology from each domain along with the resources such as bandwidth, available bandwidth, link metric, TE metric, and so on from each domain.
Now, if the method of passively peering the PCE/ALTO controller with a node using IGP is chosen, the following problems could be faced:
IGP can be very chatty. This can cause the controller to consume a lot of resources and time to process those chatty updates.
In a distributed network environment, where the network is spanned across geographical boundaries, it becomes a challenge on where to place the controller.
RFC 7752 describes another mechanism via BGP, a.k.a. BGP for Link-State Distribution (BGP-LS), to distribute the IGP topology information to other BGP speakers using a BGP network layer reachability information (NLRI). In this method, the link-state data (and other related IGP states) are encoded into BGP NLRI to disseminate link-state information using BGP. The aforementioned application servers may then peer with BGP to collect both IGP and BGP topology information.
Figure 15-2 describes a typical deployment scenario of a network that utilizes BGP LS. The IGP network consists of many IGP nodes. The IGP network is divided into three areas. Each node receives the full link-state of every other node within its own area. To provide connectivity between different areas, there are nodes called the Area Border Routers (ABR) that belong to multiple areas. ABRs summarize the link-state information of a given area and send the summary to the node in the rest of the areas.
BGP is configured on at least one node in each IGP area. The IGP running on that node provides the link-state of all nodes that it knows of (within its own area) to BGP. This way, there is at least one BGP speaker that learns the link-state of all nodes of a given area.
The BGP speakers are in the same AS. For providing the required connectivity between the BGP speakers, all the BGP speakers connect to a route reflector (RR) and each sends its own information to the RR. Therefore, the RR accumulates the link-state information from the entire network. The external element, such as PCE, then simply connects to the RR and extracts the required link-state information.
Before getting into the details of BGP-LS NLRI, it is necessary to understand the difference between IGP and BGP. IGP updates are sent using BGP and thus a conversion mechanism takes place to achieve the task. IGP provides a hop-by-hop connectivity between a relatively small number of nodes in the network, typically within an AS, including nodes that run BGP. It is designed to instantaneously react to underlying network topology changes to minimize data loss. The focus of an IGP is fast convergence during network changes and loop-free routing. BGP, on the other hand, provides connectivity between the ASs, thereby connecting the entire network. Therefore, BGP is optimized to transport massive routing state.
IGP and BGP use different routing algorithms. IGP (IS-IS and OSPF) uses link-state routing where each node constantly floods its one-hop connectivity information (the “link-state”) to all nodes in an area as link-state advertisements (LSA) or LSPs. With link-state routing protocols, every node learns the one-hop connectivity information of every other node within the area and independently constructs the full network topology of the area by running the Dijkstra Algorithm. The LSAs are flooded after a network event to provide fast convergence, and each node may receive a very large number of LSAs in a short time.
In contrast, BGP is oblivious to physical links and receives from its immediate neighbors (although the neighbors could be multiple hops away) the prefixes each of them can “reach.” BGP computes the best path (information from a neighbor) for each prefix, and then advertises that prefix as reachable. The BGP best-path algorithm scales linearly with the number of prefixes. Moreover, BGP uses various throttling mechanisms to improve scalability or decrease CPU usage.
Note
In this chapter, the word IGP is used exclusively in context to link-state routing protocols (OSPF or IS-IS).
The IGP primarily contains two pieces of information: localized network topology and reachability information.
To convert this information or send the information over to BGP, RFC 7752 defines two new components for BGP: BGP-LS NLRI and BGP-LS Path Attributes.
To exchange the BGP-LS information among the BGP peers, a new address-family was introduced named link-state. This address-family is used to form the peering with BGP speakers in different IGP areas and also with the PCE/ALTO servers.
BGP-LS NLRI
There are four BGP-LS NLRIs defined in RFC 7752:
Type 1: Node NLRI
Type 2: Link NLRI
Type 3: IPv4 Topology Prefix NLRI
Type 4: IPv6 Topology Prefix NLRI
Thus, BGP-LS carries information for three primary objects: Nodes, Links and IP Prefix (which is used for IP reachability information). BGP uses AFI 16388 and SAFI 71 for all non-VPN link, node, and prefix information and uses AFI 16388 and SAFI 72 for VPN-based link, node, and prefix information.
The Node NLRI (Type 1) consists of Node Identifier and Node Descriptor fields. Typically, the OSPF Router ID or IS-IS System ID is carried in the Node Description field. Figure 15-3 displays the BGP-LS Node NLRI.
The Link NLRI (Type 2) is used to uniquely identify a link in the network. The link NLRI consists of the following:
Link Identifier
Local Node Descriptor: Used to identify the local end of the link
Remote Node Descriptor: Used to identify the remote end of the link
Link Descriptor: A set of Type/Length/Value (TLV) triplets used to uniquely identify a link among multiple parallel links.
Figure 15-4 displays the BGP-LS Link NLRI.
Both the Local and Remote Node Descriptors contain three fields: Type, Length, and Node Descriptor Sub-TLVs. The Node Descriptor Sub-TLVs consists of various code points as follows:
Autonomous System: 4 bytes
BGP-LS Identifier: 4 bytes
OSPF Area-Id: 4 bytes
OSPF Router-Id: Variable length
IP Topology Prefix NLRI (Type 3) consists of three major fields: Identifier, Local Node Descriptor, and Prefix Descriptor. The Prefix Descriptor field is also a set of Type/Length/Value (TLV) triplets. The Prefix Descriptor TLVs uniquely identifies an IPv4 originated by a node. Figure 15-5 displays the BGP-LS Prefix NLRI.
The IPv6 topology prefix NLRI (Type 4) consists of three major fields: Identifier, Local Node Descriptor, and Prefix Descriptor. The Prefix Descriptor field is also a set of Type/Length/Value (TLV) triplets. The Prefix Descriptor TLVs uniquely identifies the IPv6 prefix originated by a node. The format of the TLV is the same as IP Topology Prefix NLRI, as shown in Figure 15-5.
BGP-LS Path Attributes
The BGP-LS Path attribute is an optional, nontransitive BGP attribute used to carry necessary attributes to characterize the link, node, and prefix parameters and attributes. The BPG-LS Path attributes are categorized into two categories:
Node Attributes: Encoded with a Node NLRI. The following Node Attribute TLVs are defined:
Multi-Topology Id
Node Flag Bits
Opaque Node Attribute
Node Name
IS-IS Area Id
IPv4 Router-Id (local node)
IPv6 Router-Id (local node)
Link Attributes: Encoded with Link NLRI. The TLVs can carry information sourced from any of the extensions for the IGP (IS-IS or OSPF). The following Link Attributes are defined:
IPv4/IPv6 Router-Id (local as well as remote node)
IGP metric
Administrative group
Maximum link bandwidth
Maximum reservable bandwidth
Unreserved bandwidth
TE default metric
Link protection type
MPLS protocol mask
Shared risk link group
Opaque link attribute
Link name
BGP-LS Configuration
At the time of this writing, BGP-LS is supported only on the IOS XR platform starting with the 5.1.1 release. Configuring BGP-LS is a simple two-step process.
Step 1. Enable IGP to distribute information to BGP-LS.
Step 2. Configure BGP to form peering over link-state address-family with BGP speakers.
IGP Distribution
Configure IGP to distribute link-state information to BGP-LS by using the command distribute bgp-ls [throttle time-in-seconds] for OSPF or the command distribute bgp-ls [level 1-2] [throttle time-in-seconds] for IS-IS. The throttle command is used to set the timer during successive LSA updates.
BGP Link-State Session Initiation
To configure BGP to exchange BGP-LS information with PCE/ALTO servers or other BGP speakers in other IGP domains (areas), the link-state address-family is enabled using the command address-family link-state link-state. After the address-family is enabled, the BGP peers can then be configured for the link-state address-family to exchange BGP-LS information.
Figure 15-6 is used to explain the BGP-LS functionality further. In this topology, there are four routers in an IS-IS Level-2 domain. R2 is peering with PCE, which is installed on Cisco’s Open SDN Controller (OSC).
Example 15-1 illustrates the configuration of router R2 for IS-IS and BGP-LS. The IS-IS is enabled for distributing IGP information to BGP-LS. Under the BGP configuration, address-family link-state is enabled first and then the neighbor is configured for that address-family.
Example 15-1 BGP-LS Configuration
R2
router isis SDN
is-type level-2-only
net 49.0100.0000.0000.0002.00
distribute bgp-ls level 2
address-family ipv4 unicast
!
interface Loopback0
address-family ipv4 unicast
!
!
interface GigabitEthernet0/0/0/0
point-to-point
address-family ipv4 unicast
!
!
interface GigabitEthernet0/0/0/1
point-to-point
address-family ipv4 unicast
!
!
router bgp 100
bgp router-id 192.168.2.2
address-family link-state link-state
!
neighbor 172.16.1.150
remote-as 100
address-family link-state link-state
After the configuration is done, the BGP peering is not established unless the Cisco OSC is configured to peer with router R2. Example 15-2 illustrates the configuration to enable BGP and configuring BGP peering with R2 on OSC.
Example 15-2 BGP Configuration on OSC
! Configuration on OSC to define the local IP address and the Local AS Number
! to be used by BGP-LS
<module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
<type
xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:rib-impl
</type>
<name>example-bgp-rib</name>
<bgp-rib-id
xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">172.16.1.150
</bgp-rib-id>
<local-as
xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">100
</local-as>
</module>
! The below config module is used to define the settings of a BGP peer.
<module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
<type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
x:bgp-peer</type>
<name>example-bgp-peer</name>
<host xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
172.16.1.100
</host>
<holdtimer
xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">180
</holdtimer>
<rib xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
<type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:cfg">
x:rib</type>
<name>example-bgp-rib</name>
</rib>
<peer-registry
xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
<type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
x:bgp-peer-registry</type>
<name>global-bgp-peer-registry</name>
</peer-registry>
<advertized-table
xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
<type
xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
x:bgp-table-type</type>
<name>ipv4-unicast</name>
</advertized-table>
<advertized-table
xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
<type
xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
x:bgp-table-type</type>
<name>linkstate</name>
</advertized-table>
</module>
After the configuration has been done on the OSC, the BGP session is established between the OSC and R2. The BGP session is viewed using the command show bgp link-state link-state summary. Example 15-3 displays the output of the BGP-LS session between XR2 and OSC. Notice that there are 0 prefixes received. This is because the OSC is not advertising any link-state prefixes.
Example 15-3 Verifying BGP-LS Session
RP/0/0/CPU0:R2# show bgp link-state link-state summary
BGP router identifier 192.168.2.2, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 244
BGP main routing table version 244
BGP NSR Initial initsync version 66 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
Speaker 244 244 244 244 244 0
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
172.16.1.150 0 100 992 1006 244 0 0 16:30:15 0
Although R2 has not received prefixes from the OSC server, the BGP-LS table is populated locally on R2 from the information learned from IGP. To view the local IGP information in the BGP-LS table, use the command show bgp link-state link-state. This command displays three sets of IGP information in the form of routes: node attribute routes, link attribute routes, and prefixes attribute routes. Example 15-4 displays the BGP-LS prefixes on R2. The output [V] denotes the Node Descriptor, [E] denotes the Link Descriptor, and [T] denotes the Prefix Descriptor.
RP/0/0/CPU0:R2# show bgp link-state link-state
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Prefix codes: E link, V node, T IP reacheable route, u/U unknown
I Identifier, N local node, R remote node, L link, P prefix
L1/L2 ISIS level-1/level-2, O OSPF, D direct, S static
a area-ID, l link-ID, t topology-ID, s ISO-ID,
c confed-ID/ASN, b bgp-identifier, r router-ID,
i if-address, n nbr-address, o OSPF Route-type, p IP-prefix
d designated router address
Network Next Hop Metric LocPrf Weight Path
*> [V][L2][I0x0][N[c100][b192.168.2.2][s0000.0000.0001.00]]/328
0.0.0.0 0 i
*> [V][L2][I0x0][N[c100][b192.168.2.2][s0000.0000.0002.00]]/328
0.0.0.0 0 i
*> [V][L2][I0x0][N[c100][b192.168.2.2][s0000.0000.0003.00]]/328
0.0.0.0 0 i
*> [V][L2][I0x0][N[c100][b192.168.2.2][s0000.0000.0004.00]]/328
0.0.0.0 0 i
*> [E][L2][I0x0][N[c100][b192.168.2.2][s0000.0000.0001.00]][R[c100][b192.168.2.2]
[s0000.0000.0003.00]][L[i10.1.13.1][n10.1.13.3]]/696
0.0.0.0 0 i
*> [E][L2][I0x0][N[c100][b192.168.2.2][s0000.0000.0001.00]][R[c100][b192.168.2.2]
[s0000.0000.0004.00]][L[i10.1.14.1][n10.1.14.4]]/696
0.0.0.0 0 i
*> [E][L2][I0x0][N[c100][b192.168.2.2][s0000.0000.0002.00]][R[c100][b192.168.2.2]
[s0000.0000.0003.00]][L[i10.1.23.2][n10.1.23.3]]/696
0.0.0.0 0 i
*> [E][L2][I0x0][N[c100][b192.168.2.2][s0000.0000.0002.00]][R[c100][b192.168.2.2]
[s0000.0000.0004.00]][L[i10.1.24.2][n10.1.24.4]]/696
0.0.0.0 0 i
! Output omitted for brevity
*> [T][L2][I0x0][N[c100][b192.168.2.2][s0000.0000.0003.00]][P[p10.1.23.0/24]]/392
0.0.0.0 0 i
*> [T][L2][I0x0][N[c100][b192.168.2.2][s0000.0000.0004.00]][P[p10.1.14.0/24]]/392
0.0.0.0 0 i
*> [T][L2][I0x0][N[c100][b192.168.2.2][s0000.0000.0004.00]][P[p10.1.24.0/24]]/392
0.0.0.0 0 i
Along with PCE-P, OSC server also has a BGP-LS Manager feature installed. OSC uses the preceding BGP-LS table to build a link-state topology in the BGPLS Manager. Figure 15-7 displays the BGP-LS Manager view of the IGP topology. Notice that the exact topology is displayed in the OSC’s BGPLS Manager, which was being used for this example. If any of the four nodes are clicked, the OSC can display more information about the node and the links on the nodes.
After examining Example 15-4, it is easy to determine which prefixes are node attributes, link attributes, and prefix attributes based on the prefix codes denoted at the beginning of each route. What cannot be figured from the preceding output is what the other field means. The other piece of information is actually the link-state information from each node, link, and prefix in the IGP domain.
Examine the output in Example 15-5 for the Node Descriptor route. The output shows that the Node-name is R1, the IS-IS area is 49.0100, and the local TE Router-ID is 192.168.1.1.
Example 15-5 Node Descriptor Prefix
RP/0/0/CPU0:R2# show bgp link-state link-state
[V][L2][I0x0][N[c100][b192.168.2.2][s0000.0000.0001.00]]/328
BGP routing table entry for
[V][L2][I0x0][N[c100][b192.168.2.2][s0000.0000.0001.00]]/328
Versions:
Process bRIB/RIB SendTblVer
Speaker 159 159
Last Modified: Apr 14 17:58:40.068 for 1d18h
Paths: (1 available, best #1)
Advertised to update-groups (with more than one peer):
0.2
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.2
Local
0.0.0.0 from 0.0.0.0 (192.168.2.2)
Origin IGP, localpref 100, valid, redistributed, best, group-best
Received Path ID 0, Local Path ID 1, version 159
Link-state: Node-name: XR1, ISIS area: 49.01.00, Local TE Router-ID:
192.168.1.1
The prefix also contains a lot of information that is very useful. Following is the breakdown of the Node Descriptor prefix.
[V]: Node Descriptor route
[L2]: IS-IS Level-2 node
[s0000.0000.0001.00]: ISO System ID is 0000.0000.0001.00
Now, let’s examine the Link Descriptor prefix. Example 15-6 displays the details of the Link Descriptor prefix. The Link Descriptor prefix gives more details about the link and TE attributes, such as local TE router-id, max. link bandwidth, max. reserved link bandwidth, max. unreserved link bandwidth, and TE default metric.
Example 15-6 Link Descriptor Prefix
RP/0/0/CPU0:R2# show bgp link-state link-state
[E][L2][I0x0][N[c100][b192.168.2.2][s0000.0000.0001.00]][R[c100][b192.168.2.2]
[s0000.0000.0004.00]][L[i10.1.14.4][n10.1.14.1]]/696
BGP routing table entry for [E][L2][I0x0][N[c100][b192.168.2.2][s0000.0000.0001.00]]
[R[c100][b192.168.2.2]
[s0000.0000.0004.00]][L[i10.1.14.4][n10.1.14.1]]/696
Versions:
Process bRIB/RIB SendTblVer
Speaker 382 382
Last Modified: Apr 16 15:09:26.068 for 00:07:17
Paths: (1 available, best #1)
Advertised to peers (in unique update groups):
172.16.1.150
Path #1: Received by speaker 0
Advertised to peers (in unique update groups):
172.16.1.100
Local
0.0.0.0 from 0.0.0.0 (192.168.2.2)
Origin IGP, localpref 100, valid, redistributed, best, group-best
Received Path ID 0, Local Path ID 1, version 382
Link-state: Local TE Router-ID: 192.168.1.1, Remote TE Router-ID:
192.168.4.4 admin-group: 0x00000000, max-link-bw (kbits/sec): 1000000
max-reserv-link-bw (kbits/sec): 0, max-unreserv-link-bw (kbits/sec):
0 0 0 0 0 0 0 0 TE-default-metric: 10, metric: 10
The Link Descriptor prefix also contains other information, such as the following:
[E]: Link Descriptor route
[s0000.0000.0001.00]][R[c100][b192.168.2.2][s0000.0000.0004.00]]: Describes half-link between ISO node 0000.0000.0001, which is the local node, and 0000.0000.0004.00, which is the remote node.
[L[i10.1.14.1][n10.1.14.4]]: Describes that the local link address is 10.1.14.1 and the remote end IP is 10.1.14.4.
The command show bgp link-state link-state bgp-ls-prefix can be run for other Link Descriptor prefixes in the table to fetch the information on other side of the link.
For understanding the Prefix Descriptor route, examine the output of Example 15-7. The output primarily displays the metric of the IGP prefix, in this case 10.
Example 15-7 Prefix Descriptor Route in BGP-LS Table
RP/0/0/CPU0:R2# show bgp link-state link-state
[T][L2][I0x0][N[c100][b192.168.2.2][s0000.0000.0003.00]][P[p10.1.23.0/24]]/392
BGP routing table entry for
[T][L2][I0x0][N[c100][b192.168.2.2][s0000.0000.0003.00]][P[p10.1.23.0/24]]/392
Versions:
Process bRIB/RIB SendTblVer
Speaker 393 393
Last Modified: Apr 16 15:09:26.068 for 1d06h
Paths: (1 available, best #1)
Advertised to peers (in unique update groups):
172.16.1.150
Path #1: Received by speaker 0
Advertised to peers (in unique update groups):
172.16.1.100
Local
0.0.0.0 from 0.0.0.0 (192.168.2.2)
Origin IGP, localpref 100, valid, redistributed, best, group-best
Received Path ID 0, Local Path ID 1, version 393
Link-state: Metric: 10
But otherwise, the Prefix Descriptor prefix in itself, contains more information as listed.
[T]: Prefix Descriptor route
[s0000.0000.0003.00]][P[p10.1.23.0/24]]: Tells that the prefix 10.1.23.0/24 is being advertised by a node with ISO ID 0000.0000.0003.00 with IGP metric 10.
By evaluating all the prefixes in the BGP-LS table, a complete IGP topology can be built. Based on the IGP topology and the TE related information, PCE-P can be used to build LSPs on the fly from the OSC server web portal.
BGP for Tunnel Setup
The networking industry is getting transformed very rapidly with the newer technologies and features being innovated every day. The current focus is directed at cloud technologies; most of the newer features being innovated are dependent on tunneling of packets. Tunneling allows for packets to transit an underlay network by adding network headers strictly for the purpose of forwarding packets on the underlay network. In essence, the encapsulated packets are transported on an overlay network.
Packet encapsulation occurs by one transport edge device and is decapsulated at the remote transport edge device. This is similar to the existing tunneling mechanism such as GRE.
RFC 5512 defines a mechanism for using BGP to signal tunnel encapsulation information between the BGP speakers. Using BGP provides an opportunity for development and innovation of various new overlay mechanisms for existing, as well as future technologies. BGP tunnels can be used as alternatives for MPLS service based on BGP, such as MPLS L2VPN, and so on, because BGP is scalable and proven for control plane signaling. The BGP tunneling mechanism helps in cost optimization by getting rid of the following:
Core MPLS control plane
Internet and customer prefixes from ISP core
Under the BGP tunneling mechanism, the BGP database carries tunnel endpoints and identifiers. This helps BGP-based dynamic tunneling mechanism work on both Intra-domain as well as Inter-domain. The BGP tunnels could provide convergence below 100 ms.
The tunnel encapsulation is carried out with an address-family identifier (AFI) value of 1 or 2 based on IPv4 or IPv6 and SAFI value of 7, which is also known as the encapsulation subaddress family identifier (SAFI). The BGP NLRI consists of the IP address of the originator of the update. The encapsulation information is carried out in a new attribute called the BGP tunnel encapsulation attribute. The BGP tunnel encapsulation attribute contains the encapsulation protocol as well as any additional information that is required by the specified encapsulation protocol. Figure 15-8 displays the format of the BGP tunnel encapsulation attribute. The Tunnel Type field specifies the type of tunnel encapsulation to be carried over in the BGP NLRI. The value field actually comprises multiple sub-TLVs. Each sub-TLV consists of three fields: 1-octet type, 1-octet length, and zero or more octets of value.
Table 15-1 lists the protocols that have been defined under various RFCs that can be specified under the BGP tunnel encapsulation attribute.
Table 15-2 lists the BGP tunnel encapsulation attribute sub-TLVs.
Provider Backbone Bridging: Ethernet VPN (PBB-EVPN)
Virtual Private Wire Service (VPWS) is used to build a topology of point-to-point connections that connect end customer sites over an IP/Multiprotocol Label Switching (MPLS) network. VPWS enables the sharing of a provider’s core network infrastructure between IP and Layer 2 VPN services, reducing the cost of providing those services. Virtual Private LAN Service (VPLS) as defined in RFC 4664, 4761, and 4762, is a proven and widely deployed technology by service providers. However, the existing solution has a number of challenges when it comes to redundancy and multicast optimization.
A limitation of current implementations is that VPLS can only support multihoming with active/standby resiliency model, for example, as described in draft-ietf-bess-vpls-multihoming. Flexible multihoming with all-active attachment circuits (ACs) cannot be supported without adding considerable complexity to the data plane.
In the area of multicast optimization, draft-ietf-l2vpn-vpls-mcast, describes how Label Switched Multicast (LSM) Distribution Trees (MDTs) can be used in conjunction with VPLS. However, this solution is limited to point-to-multipoint (P2MP) MDTs, because there’s no easy way for leveraging multipoint-to-multipoint (MP2MP) MDTs with VPLS. The lack of MP2MP support may create scalability issues for multicast-intensive applications.
The current solution for VPLS, as defined in RFC 4664, relies on establishing a full mesh of pseudowires (PWs) among participating provider edges (PE), and data-plane learning for the purpose of building the media access control (MAC) forwarding tables. This learning is performed on traffic received over both the attachment circuits as well as the PWs. Supporting an all-active multihoming solution with current VPLS is subject to three fundamental problems:
Formation of forwarding loops
Duplicate delivery of flooded frames
MAC Forwarding Table instability
Customers are looking for an L2VPN solution that can deliver the following:
PE node redundancy with load-balancing based on L2/L3/L4 flows from customer edge (CE) to PE.
Flow-based multipathing of traffic from PE to core, and vice versa.
Geo-redundant PE nodes with optimum unicast forwarding.
Flexible Redundancy grouping (PE1 and PE2 can be used for dual-homing one set of CEs, and PE2 and PE3 can be used for dual-homing different set of CEs, thus PE2 supporting multiple redundancy groups).
Ethernet VPN (EVPN) is a next-generation solution for Ethernet services. It relies on BGP control plane for segment/MAC learning reachability among PEs. It uses simple principles such as that of L3VPNs. The EVPN solution provides services for both point-to-point as well as point-to-multiple L2VPN deployments. Figure 15-9 depicts the EVPN solution architecture. EVPN-VPWS provides E-LINE (point-to-point) services, whereas EVPN and Provider Backbone Bridging EVPN (PBB-EVPN) provide E-LAN services.
EVPN, in simple terms, can be described as treating customer MACs as routable addresses and distributing them in BGP over MPLS core, thereby avoiding any data-plane MAC learning over MPLS core. The MAC addresses are distributed over MPLS core using BGP with a label identifying the service instance. Receiving PE devices inject these routable MAC addresses into their L2 routing information base (RIBs) and forwarding information base (FIBs) along with their associated adjacencies.
Distributing of MAC address over BGP results in following benefits:
Ability to associate a MAC address with Equal Cost Paths to multiple PE devices, even though the IGP paths to these PE devices are not Equal Cost
Ability to use BGP policy routing to prefer one path over another for a given MAC in case of Active/Standby multihoming scenarios
Ability to use BGP policy routing to have the same preference among multiple paths for a given MAC in case of Active/Active multihoming scenarios
Ability to do optimum forwarding of L2 unicast packets for both single-homed and multihomed devices of a given customer simultaneously
Ability to represent a single customer by a single MPLS label in contrast to using a set of N labels (N PWs)
Note
This section primarily focuses on the PBB-EVPN solution.
In the case of PBB-EVPN, the PE devices receive 802.1Q frames from the attachment circuit (AC), encapsulation them into PBB header and forward the frames over IP/MPLS core. On the egress PE, the PBB header is removed following the MPLS disposition, and the original 802.1Q frame is delivered to the customer device.
The PE nodes perform the following functions:
Learn customer MAC (C-MAC) addresses over the attachment circuits in the data plane, per normal bridge operation.
Learn remote C-MAC to backbone MAC (B-MAC) bindings in the data plane from traffic ingress from the core.
Advertise local B-MAC address reachability information in BGP to all other PE nodes in the same set of service instances. Note that every PE has a set of local B-MAC addresses that uniquely identify the device.
Build a forwarding table from remote BGP advertisements received associating remote B-MAC addresses with remote PE IP addresses.
EVPN NLRI and Routes
EVPN defines a new BGP NLRI, which is used to advertise different types of routes. EVPN also defines the new route attributes. The EVPN BGP NLRI is carried in BGP with an AFI value of 25 and a SAFI value of 70. Before two devices can exchange EVPN NLRIs, they must signal their capability to do so by using BGP capabilities advertisement.
The PBB-EVPN NLRI consists of three fields:
Route Type (1 byte)
Length (1 byte)
Route Type Specific (variable length)
The value of the Route Type field can be one of the following:
0x01: Ethernet Auto-Discovery Route
0x02: MAC Advertisement Route
0x03: Inclusive Multicast Route
0x04: Ethernet Segment Route
0x05: Selective Multicast Auto-Discovery Route
0x06: Leaf Auto-Discovery Route
The various Route Types fields and their usage are described next:
Ethernet Auto-Discovery Route: Used for MAC mass-withdraw, aliasing, split-horizon filtering.
MAC Advertisement Route: Used for advertising MAC address reachability and IP/MAC bindings.
Inclusive Multicast Route: Used for multicast tunnel endpoint discovery.
Ethernet Segment Route: Used for redundancy group discovery and Designated Forwarder (DF) election.
Along with the BGP NLRI, EVPN also involves E-VPN Route Distinguisher (RD). Two different BGP RDs are required for an EVPN solution: VPN RD and Segment RD.
Note
Presently, Route Type 0x05 and 0x06 are not supported on Cisco platforms. BGP drops unsupported Route Types and does not propagate it to neighbors.
Two different BGP RDs are required for EVPN: VPN RD and Segment RD.
VPN RD: VPN RD is the RD assigned to each EVPN instance on a PE. The RD is unique across all EVPN instances supported on the PE. This is achieved using Type 1 RD defined in RFC 4364. The value field is composed of the IP address of the PE followed by a unique number. The number may be generated by the PE or in the default single VLAN EVPN case, may be the 12-bit VLAN Id, with the remaining 4 bits set to 0.
Segment RD: The segment RD uniquely identifies the PE and does not change on a per EVPN instance basis. The value is achieved by again using Type 1 RD in which the value field is composed of an IP address of the PE with the remaining bits all set to 0.
The EVPN instance route target (RT) can either be configured manually or derived automatically.
EVPN Extended Community
There are four different extended communities for the EVPN routes:
Ethernet Segment Identifier (ESI) MPLS Label Extended Community
Ethernet Segment (ES)-Import Extended Community
MAC Mobility Extended Community
Default Gateway Extended Community
ESI MPLS Label Extended Community is a new transitive extended community which is advertised along with Ethernet autodiscovery route. This extended community carries properties associated with Ethernet Segment Identifier (ESI). The purpose of this extended community is to encode split-horizon label for Ethernet segment and indicate redundancy mode (Single-Active vs. All-Active).
ES-Import Extended Community is a new transitive extended community that includes all PEs in a redundancy group. This extended community is advertised along with Ethernet Segment route. It is used to limit the scope of Ethernet segment routes.
MAC Mobility Extended Community is a new transitive extended community that is advertised with MAC advertisement routes. It indicates that a MAC address has moved from one segment to another across PEs. In other words, the MAC address that was previously advertised by another PE has moved and is now reachable via the advertising PE.
Default Gateway Extended Community is a new transitive extended community advertised with MAC advertisement routes, used to indicate the MAC/IP bindings of a gateway.
EVPN Configuration and Verification
The Cisco EVPN and PBB-EVPN solution is presently supported on the ASR9000 platform and on the ASR1000 series router running IOS XE as a route reflector for L2VPN EVPN address-family.
Examine the topology in Figure 15-10. There are two PE routers, PE1 and PE2, connected via router RR-P. The PE routers are running IGP (OSPF/IS-IS) and MPLS within the core.
Example 15-8 illustrates the basic minimal configuration to provision a PBB-EVPN circuit between two PE routers. Notice that there are two bridge-domains created: one bridge-domain for the core and one bridge-domain for the edge. The edge bridge-domain named PBB-EDGE-1001 is the one associated with the attachment circuit. The command pbb edge i-sid service-id core-bridge core-bridge-name configures the bridge domain as PBB edge with the service identifier and the assigned core bridge domain. This completes the basic configuration for EVPN.
Next, establish BGP peering with the remote PE device or with the route reflector over address-family l2vpn evpn, which is used for exchanging EVPN routes via BGP. The address-family l2vpn evpn is used both for autodiscovery and the signaling mechanism for EVPN.
Example 15-8 L2VPN EVPN Configuration on IOS XR
! EVPN Configuration on PE1
interface Loopback0
ipv4 address 192.168.1.1 255.255.255.255
!
interface GigabitEthernet0/0/0/0
!
interface GigabitEthernet0/0/0/0.2 l2transport
encapsulation dot1q 2
!
interface GigabitEthernet0/0/0/1
ipv4 address 10.1.14.1 255.255.255.0
!
l2vpn
router-id 192.168.1.1
bridge group 1
bridge-domain PBB-CORE-1001
pbb core
evpn evi 1001
!
!
bridge-domain PBB-EDGE-1001
interface GigabitEthernet0/0/0/0.2
!
pbb edge i-sid 1001 core-bridge PBB-CORE-1001
!
mpls ldp
router-id 192.168.1.1
address-family ipv4
neighbor 192.168.2.2 targeted
!
interface GigabitEthernet0/0/0/1
!
router bgp 100
bgp router-id 192.168.1.1
address-family ipv4 unicast
network 101.101.101.101/32
!
address-family l2vpn evpn
!
neighbor 192.168.2.2
remote-as 100
update-source Loopback0
address-family l2vpn evpn
Similar configuration is performed on the PE2 router with AC connected toward the CE2. After the configuration is done, the BGP L2VPN EVPN session is established and the EVPN routers are exchanged. Because there are four types of routes in EVPN, each route is represented in a different format. The four formats are as follows:
Ethernet Auto-Discovery Route: [Type][ESI][ETag]
MAC Advertisement Route: [Type][ESI][ETag][MAC Addr Len][MAC Addr] [IP Addr Len][IP Addr]
Inclusive Multicast Route: [Type][ETag][Router IP Addr Len][Router IP Addr]
Ethernet Segment Route: [Type][ESI]
Use the command show bgp l2vpn evpn summary to view the L2VPN EVPN peerings on the router. Use the command show bgp l2vpn evpn to view the locally originated as well as remotely learned EVPN routes. Example 15-9 displays the established BGP session for L2VPN EVPN address-family and also displays the local as well as EVPN routes exchanged from the remote PE router. Notice that the RD for all the prefixes has been automatically assigned in ip-address:ESI format. In the output, the local RD is 192.168.1.1:1001, whereas the RD learned from the remote PE router is 192.168.2.2:1001.
Example 15-9 BGP L2VPN EVPN Table
IOS XR
! L2VPN EVPN BGP Session Output
RP/0/RSP0/CPU0:PE1# show bgp l2vpn evpn summary
Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
Speaker 45 45 45 45 45 0
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
192.168.2.2 0 100 35373 1001 45 0 0 15:29:31 2
! PBB-EVPN Prefixes
RP/0/RSP0/CPU0:PE1# show bgp l2vpn evpn
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 192.168.1.1:1001 (default for vrf PBB-CORE-1001)
*>i[2][0][48][5087.891c.30a7][0]/104
192.168.2.2 100 0 i
*> [2][0][48][5087.8968.266f][0]/104
0.0.0.0 0 i
*> [3][1001][32][192.168.1.1]/80
0.0.0.0 0 i
*>i[3][1001][32][192.168.2.2]/80
192.168.2.2 100 0 i
Route Distinguisher: 192.168.2.2:1001
*>i[2][0][48][5087.891c.30a7][0]/104
192.168.2.2 100 0 i
*>i[3][1001][32][192.168.2.2]/80
192.168.2.2 100 0 i
Processed 6 prefixes, 6 paths
For the forwarding to work properly, ensure that both the core as well as the edge bridge domains are up, and the PBB is showing in up status. This is verified by using the command show l2vpn bridge-domain [detail]. The show l2vpn bridge-domain displays both the core as well as the edge bridge domain status, the status of PBBs, and the AC attached to the bridge domain (edge) along with its status. This command also lists the ACs that are part of the edge bridge domain.
The command show l2vpn bridge-domain detail displays more detailed information related to both the core and the edge bridge domain, such as the packet counters for both imposition and disposition, PBB lists, and more detailed information of the ACs. The detail command output is useful when performing troubleshooting related to traffic forwarding issues. The output can be used to match the counters of the packets with that of the controller counters for the AC. Example 15-10 displays the output of the command show l2vpn bridge-domain [detail].
Example 15-10 show l2vpn bridge-domain Command Output
IOS XR
RP/0/RSP0/CPU0:PE1# show l2vpn bridge-domain
Legend: pp = Partially Programmed.
Bridge group: 1, bridge-domain: PBB-CORE-1001, id: 0, state: up, ShgId: 0, MSTi: 0
Type: pbb-core
Number of associated pbb-edge BDs: 1
Aging: 300 s, MAC limit: 4000, Action: none, Notification: syslog
Filter MAC addresses: 0
ACs: 0 (0 up), VFIs: 0, PWs: 0 (0 up), PBBs: 1 (1 up)
List of PBBs:
PBB Core, state: up
List of ACs:
List of Access PWs:
List of VFIs:
Bridge group: 1, bridge-domain: PBB-EDGE-1001, id: 1, state: up, ShgId: 0, MSTi: 0
Type: pbb-edge, I-SID: 1001
Aging: 300 s, MAC limit: 4000, Action: none, Notification: syslog
Filter MAC addresses: 0
ACs: 1 (1 up), VFIs: 0, PWs: 0 (0 up), PBBs: 1 (1 up)
List of PBBs:
PBB Edge, state: up, Static MAC addresses: 0
List of ACs:
Gi0/0/0/0.2, state: up, Static MAC addresses: 0
List of Access PWs:
List of VFIs:
! Detailed Output
RP/0/RSP0/CPU0:PE1# show l2vpn bridge-domain detail
Legend: pp = Partially Programmed.
Bridge group: 1, bridge-domain: PBB-CORE-1001, id: 0, state: up, ShgId: 0, MSTi: 0
Coupled state: disabled
Type: pbb-core
Number of associated pbb-edge BDs: 1
EVPN:
EVI: 1001
Route Distinguisher: (auto) 192.168.1.1:1001
Imposition Statistics:
Packet Count: 40320109
Byte Count : 5467529444
Disposition Statistics:
Packet Count: 40000053
Byte Count : 5440004624
AS Number: 100
MAC learning: enabled
MAC withdraw: enabled
MAC withdraw for Access PW: enabled
MAC withdraw sent on: bridge port up
MAC withdraw relaying (access to access): disabled
Flooding:
Broadcast & Multicast: enabled
Unknown unicast: enabled
MAC aging time: 300 s, Type: inactivity
MAC limit: 4000, Action: none, Notification: syslog
MAC limit reached: no
MAC port down flush: enabled
MAC Secure: disabled, Logging: disabled
Split Horizon Group: none
Dynamic ARP Inspection: disabled, Logging: disabled
IP Source Guard: disabled, Logging: disabled
DHCPv4 snooping: disabled
IGMP Snooping: enabled
IGMP Snooping profile: none
MLD Snooping profile: none
Storm Control: disabled
Bridge MTU: 1500
MIB cvplsConfigIndex: 1
Filter MAC addresses:
P2MP PW: disabled
Create time: 22/04/2016 17:10:13 (1w0d ago)
No status change since creation
ACs: 0 (0 up), VFIs: 0, PWs: 0 (0 up), PBBs: 1 (1 up)
List of PBBs:
PBB Core, state is up
XC ID 0x80000001
MAC learning: enabled
Flooding:
Broadcast & Multicast: enabled
Unknown unicast: enabled
MAC aging time: 300 s, Type: inactivity
MAC limit: 4000, Action: none, Notification: syslog
MAC limit reached: no
MAC port down flush: enabled
Split Horizon Group: none
DHCPv4 snooping: disabled
IGMP Snooping: enabled
IGMP Snooping profile: none
MLD Snooping profile: none
MMRP Flood Optimization: disabled
Storm Control: bridge-domain policer
List of ACs:
List of Access PWs:
List of VFIs:
Bridge group: 1, bridge-domain: PBB-EDGE-1001, id: 1, state: up, ShgId: 0, MSTi: 0
Coupled state: disabled
Type: pbb-edge, I-SID: 1001
Core-bridge: PBB-CORE-1001 (State: Bridge Up)
MIRP-lite: supported, enabled
Format: MVRP PDU with Vlan 0
MAC learning: enabled
MAC withdraw: enabled
MAC withdraw for Access PW: enabled
MAC withdraw sent on: bridge port up
MAC withdraw relaying (access to access): disabled
Flooding:
Broadcast & Multicast: enabled
Unknown unicast: enabled
MAC aging time: 300 s, Type: inactivity
MAC limit: 4000, Action: none, Notification: syslog
MAC limit reached: no
MAC port down flush: enabled
MAC Secure: disabled, Logging: disabled
Split Horizon Group: none
Dynamic ARP Inspection: disabled, Logging: disabled
IP Source Guard: disabled, Logging: disabled
DHCPv4 snooping: disabled
IGMP Snooping: enabled
IGMP Snooping profile: none
MLD Snooping profile: none
Storm Control: disabled
Bridge MTU: 1500
MIB cvplsConfigIndex: 2
Filter MAC addresses:
P2MP PW: disabled
Create time: 22/04/2016 17:10:13 (1w0d ago)
No status change since creation
ACs: 1 (1 up), VFIs: 0, PWs: 0 (0 up), PBBs: 1 (1 up)
List of PBBs:
PBB Edge, state is up
XC ID 0x80000002
MAC learning: enabled
Flooding:
Broadcast & Multicast: enabled
Unknown unicast: enabled
MAC aging time: 300 s, Type: inactivity
MAC limit: 4000, Action: none, Notification: syslog
MAC limit reached: no
MAC port down flush: enabled
MAC Secure: disabled, Logging: disabled, Accept-Shutdown: disabled
Split Horizon Group: none
DHCPv4 snooping: disabled
IGMP Snooping: enabled
IGMP Snooping profile: none
MLD Snooping profile: none
Storm Control: bridge-domain policer
Statistics:
packets: received 40000053 (unicast 40000047), sent 40320130
bytes: received 4720003670 (unicast 4720003170), sent 4741768910
MAC move: 0
List of ACs:
AC: GigabitEthernet0/0/0/0.2, state is up
Type VLAN; Num Ranges: 1
VLAN ranges: [2, 2]
MTU 1504; XC ID 0x1080001; interworking none
MAC learning: enabled
Flooding:
Broadcast & Multicast: enabled
Unknown unicast: enabled
MAC aging time: 300 s, Type: inactivity
MAC limit: 4000, Action: none, Notification: syslog
MAC limit reached: no
MAC port down flush: enabled
MAC Secure: disabled, Logging: disabled
Split Horizon Group: none
Dynamic ARP Inspection: disabled, Logging: disabled
IP Source Guard: disabled, Logging: disabled
DHCPv4 snooping: disabled
IGMP Snooping: enabled
IGMP Snooping profile: none
MLD Snooping profile: none
Storm Control: bridge-domain policer
Static MAC addresses:
Statistics:
packets: received 40345017 (multicast 344833, broadcast 36,
unknown unicast 36, unicast 40000117), sent 40000156
bytes: received 4743466070 (multicast 23448644, broadcast 2304,
unknown unicast 2304, unicast 4720013158), sent 4720015662
MAC move: 0
Storm control drop counters:
packets: broadcast 0, multicast 0, unknown unicast 0
bytes: broadcast 0, multicast 0, unknown unicast 0
Dynamic ARP inspection drop counters:
packets: 0, bytes: 0
IP source guard drop counters:
packets: 0, bytes: 0
List of Access PWs:
List of VFIs:
The PBB-EVPN solution relies on two MAC addresses: B-MAC and C-MAC. The B-MAC on each PE is viewed by using the command show l2vpn pbb backbone-source-mac. This command displays the chassis MAC and the backbone MAC address. When the packet from the AC is supposed to be forwarded, it is encapsulated into B-MAC and forwarded across the MPLS backbone. To view the customer MAC address learned across the MPLS cloud, use the command show l2vpn forwarding bridge-domain mac-address [location rack/slot/cpu]. This command displays the MAC address of the source as well as the destination. It also displays the BMAC and S-BMAC as well as the MAC address of the source and the destination CE router.
Example 15-11 displays both the B-MAC and the customer learned MAC. The MAC 5087.891c.30a7 is the backbone MAC of PE2, whereas 5087.8968.266f is the backbone MAC of PE1. The MAC address 001c.577f.7f01 is the MAC address of the interface connecting the PE1 on the CE1 router. The MAC address 001c.577f.7f42 belongs to VLAN 2 on PE1, and the MAC address 001e.f78d.49c1 belongs to VLAN 2 on CE2 learned across the PBB-EVPN circuit.
Example 15-11 EVPN MAC Addresses
! Output from PE1 (EVPN Backbone MAC)
RP/0/RSP0/CPU0:PE1# show l2vpn pbb backbone-source-mac
Backbone Source MAC: 5087.8968.266f
Chassis MAC : 5087.8968.266f
! EVPN Customer MAC
RP/0/RSP0/CPU0:PE1# show l2vpn forwarding bridge-domain mac-address loc 0/0/CPU0
To Resynchronize MAC table from the Network Processors, use the command...
l2vpn resynchronize forwarding mac-address-table location <r/s/i>
Mac Address Type Learned from/Filtered on LC learned Resync Age Mapped to
----------------------------------------------------------------------------------
5087.891c.30a7 BMAC BD id: 0 N/A N/A N/A
5087.8968.266f S-BMAC BD id: 0 N/A N/A N/A
001c.577f.7f01 dynamic Gi0/0/0/0.2 0/0/CPU0 0d 0h 0m 16s N/A
001c.577f.7f42 dynamic Gi0/0/0/0.2 0/0/CPU0 0d 0h 0m 17s N/A
001e.f78d.49c1 dynamic BD id: 1 0/0/CPU0 0d 0h 0m 17s 5087.891c.30a7
! Output from PE2 (EVPN Backbone MAC)
RP/0/RSP0/CPU0:PE2# show l2vpn pbb backbone-source-mac
Backbone Source MAC: 5087.891c.30a7
Chassis MAC : 5087.891c.30a7
The PBB core allocates two labels for forwarding across the MPLS core. One label is for unicast and the other for multicast. The two labels are viewed by using the command show evpn evi [detail]. This command not only displays the label information but other EVPN related information, such as RD and RT. Example 15-12 displays the output of the command show evpn evi detail. In the output, label 24013 is the unicast label, and 24014 is the multicast label.
Example 15-12 Verifying EVPN EVI and Label Information
RP/0/RSP0/CPU0:PE1# show evpn evi detail
EVI Bridge Domain Type
---------- ---------------------------- -------
1001 PBB-CORE-1001 PBB
Unicast Label : 24013
Multicast Label: 24014
Flow Label: N
RD Config: none
RD Auto : (auto) 192.168.1.1:1001
RT Auto : 100:1001
Route Targets in Use Type
------------------------------ -------
100:1001 Import
100:1001 Export
65535 ES:GLOBAL BD
Unicast Label : 0
Multicast Label: 0
Flow Label: N
RD Config: none
RD Auto : (auto) 192.168.1.1:0
RT Auto : none
Route Targets in Use Type
------------------------------ -------
After the labeling information is received, the forwarding counters are verified using the command show mpls forwarding. This command displays the packets forwarded beside a particular Forwarding Equivalence Class (FEC), which in this case is the unicast and the multicast labels allocated for the PBB core. Example 15-13 displays the output of the command show mpls forwarding.
Example 15-13 Verifying Labels in MPLS Forwarding Table
RP/0/RSP0/CPU0:PE1# show mpls forwarding | include BD
24013 Pop No ID BD=0 PE point2point 3230574768
24014 Pop No ID BD=0 PEIM point2point 606
Summary
BGP is a mature protocol and has been in the field for a very long time. But over the years, the scope of BGP has expanded due to its capability to extend its flexibility to the development of new features.
This chapter examined various features that rely on BGP for their functioning. It discussed BGP for link-state distribution. Using BGP-LS, modern day SDN controllers can use the information to build the IGP topology on the fly and help the network administrators to manage their network and make deployment of features like Traffic Engineering (TE) easier.
The chapter then explained how BGP is used for tunnel signaling and its role in solutions such as Virtual Extensible LAN (VxLAN) BGP EVPN and other solutions that require tunnel functionality. Finally, the chapter covered provider backbone bridging for the Ethernet VPN (PBB-EVPN) solution. This solution provides many benefits, such as the following:
PE node redundancy with load-balancing based on L2/L3/L4 flows.
Flow-based multipathing of traffic from PE to core, and vice versa.
Geo-redundant PE nodes with optimum unicast forwarding.
PBB-EVPN works across the MPLS core with the edge router running BGP and exchanging EVPN routes.
Additional functionality will continue to be added to BGP in the future, reinforcing the concepts and initial architecture of BGP when first developed.
References
RFC 7752, North-Bound distribution of Link-State and TE information using BGP, H. Gredler, Ed., J. Medved, S. Previdi, A. Farrel, S. Ray, IETF, https://tools.ietf.org/html/rfc7752, March 2016.
RFC 5693, ALTO Problem Statement, J. Seedorf, E. Burger, IETF, https://tools.ietf.org/html/rfc5693, October 2009.
RFC 4655, PCE Based Architecture, A. Farrel, J.P. Vasseur, IETF, https://tools.ietf.org/html/rfc4655, August 2006.
RFC 5512, The BGP Encapsulation SAFI and the BGP Tunnel Encapsulation Attribute, P. Mohapatra, E. Rosen. IETF, https://tools.ietf.org/html/rfc5512, April 2009.
Cisco. Cisco IOS Software Configuration Guides. http://www.cisco.com