IOS XE 15.5
IOS XR 5.3
The topology for this demo:
In the previous post we took a look at VPLS BGP Auto Discovery using LDP. We took a look at in an E-LAN rollout, or MP2MP or any to any. Now we'll take a look at changing the AD method to BGP and see how this is different. The rollout we'll look at is E-TREE in style where R3 is the "Hub" and R5, R6 and XR1 are the spokes. There are a few unique parts to the configuration and we'll see those as we go.
Before we get into the "how you configure this" view, let's take a design view first. The reason being is that depending on the customers business driver, whether it's compliance driven, merger/acquisition or some other driver, it is important to understand the reason why you would choose MP2MP over P2MP. With E-LAN is very similar to a vanilla rollout of L3 VPN, where all PEs send all routes learned to everyone else. E-TREE is similar to Central Service L3 VPN, where the central services PE sends and receives info from the spoke PEs and the spoke PEs send all their info to just the hub PE and receive only info from the hub PE. This will explicit dictate which CE sites will be able to communicate with each other.
From a technical perspective, we are disabling the "auto-route-target" capability in XE and specifying what Route Targer import/export policies to permit/deny traffic. You may have experience with L3 VPN and the concept of a VRF, where in L3 VN the RT import/export policy dictates what RT values are received/sent based on matching the policy. L2 VPN doesn't use the concept of a VRF since we aren't defining a routing domain with L2VPN. We are building a bridging domain to propagate MAC info from one PE to another. So you might wonder why the RT is even important, I thought the same thing the first time I read about it, even going as far as ripping apart the RFC to see where the VRF came into play. This logic of thinking was misguided and convoluted with the L3 VPN mindset.
So what does the Route Target do here? Simple, in its simplest form an RT is an extended community. And what protocol uses extended communities? Well BGP of course. So when we are configuring the VFI with the necessary configuration to support BGP as the AD signalling protocol, there are important pieces that are required to enable the RT policies to be able to do their job. And to make it a bit more interesting, we don't configure the RT info under BGP, we configure it under the "l2vpn vfi" configuration mode. In the simplest form, the RT acts an identifier for BGP to use to identify a PE in a VPLS network. Let's take a look at how it is configured and that should put the 2 together.
The first thing I did was attempt to go under the existing VPLS vfi and change the signalling protocol from LDP to BGP. I got the following error:
R3(config-vfi)#autodiscovery bgp signaling bgp
% VFI auto-discovery signaling protocol changes are not allowed. Delete the VFI and reconfigure.
So the next step was to create a new VFI and call it "E-TREE". Below is the configuration for R3 which is also the "hub". I'll list the "spoke" configuration below that.
R3
l2vpn vfi context E_TREE
vpn id 50693
autodiscovery bgp signaling bgp
ve id 3
ve range 11
route-target import 50693:11
route-target import 50693:5
route-target import 50693:6
route-target export 50693:3
no auto-route-target
So let's breakdown the above configuration line by line.
The name of the vfi context is arbitrary, I chose "E-TREE" as that is the deployment method.
The vpn id has be manually identified, I chose a unique number.
Since this post is about BGP signalling, we obviously need to have that selected as our configuration.
The "ve-id" is the new term here, indicating the VPLS Endpoint ID, in this case it's "3" for R3. This configuration helps build the identifier 50693:3 which is what match in the RT policies
The "ve range 11" is another new term. This command basically states that up to 11 labels can be allocated, 1 each up to 11 PWs. We'll breakdown the VE range a bit later. It gets into some interesting parts and pieces so needs some clarification.
The "route-target" import/export values are also new. You'll notice that we have 3 import and 1 export, we're importing XR1 (50693:11), R5 (50693:5), R6 (50693:6).
The "no auto-route-target" is also used, which disables the auto generation of the info and is replaced with the manually configured route targets.
Now, on to the spokes PEs.
R5
l2vpn vfi context E_TREE
vpn id 50693
autodiscovery bgp signaling bgp
ve id 5
ve range 11
route-target import 50693:3
route-target export 50693:5
no auto-route-target
R6
l2vpn vfi context E_TREE
vpn id 50693
autodiscovery bgp signaling bgp
ve id 6
ve range 11
route-target import 50693:3
route-target export 50693:6
no auto-route-target
XR
bridge group E_TREE
bridge-domain E_TREE
interface GigabitEthernet0/0/0/2.100
!
vfi E_TREE
vpn-id 50693
autodiscovery bgp
route-target import 50693:3
route-target export 50693:11
signaling-protocol bgp
ve-id 11
ve-range 11
OK, now we can jump into the BGP configuration. We'll see the RR configuration on XR5 first and then we'll see the spokes.
XR5
router bgp 1
address-family l2vpn vpls-vpws
!
neighbor 192.168.1.3
remote-as 1
update-source Loopback0
address-family l2vpn vpls-vpws
route-reflector-client
Signalling ldp disable
!
!
neighbor 192.168.1.5
remote-as 1
update-source Loopback0
address-family l2vpn vpls-vpws
route-reflector-client
Signalling ldp disable
!
!
neighbor 192.168.1.6
remote-as 1
update-source Loopback0
address-family l2vpn vpls-vpws
route-reflector-client
Signalling ldp disable
!
!
neighbor 192.168.1.11
remote-as 1
update-source Loopback0
address-family l2vpn vpls-vpws
route-reflector-client
Signalling ldp disable
R3, R5 and R6
router bgp 1
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 192.168.1.15 remote-as 1
neighbor 192.168.1.15 transport connection-mode active
neighbor 192.168.1.15 update-source Loopback0
!
address-family ipv4
exit-address-family
!
address-family l2vpn vpls
neighbor 192.168.1.15 activate
neighbor 192.168.1.15 suppress-signaling-protocol ldp
exit-address-family
XR1
router bgp 1
address-family l2vpn vpls-vpws
!
neighbor 192.168.1.15
remote-as 1
update-source Loopback0
session-open-mode active-only
address-family l2vpn vpls-vpws
Signalling ldp disable
Alright, now that we have configured all the routers appropriately, we need to verify on R3, the hub, that R3 is learning BGP updates from R5 and R6. XR1 won't advertise anything.
R3#show bgp l2vpn vpls all
BGP table version is 21, local router ID is 192.168.1.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:50693
*> 1:50693:VEID-3:Blk-1/136
0.0.0.0 32768 ?
*>i 1:50693:VEID-5:Blk-1/136
192.168.1.5 0 100 0 ?
*>i 1:50693:VEID-6:Blk-1/136
192.168.1.6 0 100 0 ?
Let's take a deeper look at the contents of the update from R6
R3#show bgp l2vpn vpls rd 1:50693 ve-id 6 block-offset 1
BGP routing table entry for 1:50693:VEID-6:Blk-1/136, version 21
Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)
Not advertised to any peer
Refresh Epoch 1
Local
192.168.1.6 (metric 4) from 192.168.1.15 (192.168.1.15)
Origin incomplete, metric 0, localpref 100, valid, internal, best
AGI version(0), VE Block Size(11) Label Base(626)
Extended Community: RT:50693:6 L2VPN L2:0x0:MTU-1500
Originator: 192.168.1.6, Cluster list: 192.168.1.15
mpls labels in/out exp-null/626
rx pathid: 0, tx pathid: 0x0
As you can see from the Orange output, we have some new fields that need to be examined. The label values were not exchanged in the traditional manner, this is because there are no peer to peer sessions between PEs. There needs to be an automatic and deterministic way to compute local and remote labels, since each PW requires a different set of labels. Label 626 part of the peers label base or block. The virtual block size or VBS is 11, there can be up to 11 local labels allocated to support this VPLS instance, pretty much a maximum of 11 dynamic PWs.
We can now verify the CE side, which you will be able to see has taken on a hub and spoke style design. When you use the import and export route target option as it's needed for E-TREE designs, you selectively determine how the PEs will receive and send update information. Below it is obvious that R8 can reach both R9 and R10, but R9 can't reach R10 or vice-versa.
R8
R8#sh ospfv3 1 nei
OSPFv3 1 address-family ipv6 (router-id 172.16.8.8)
Neighbor ID Pri State Dead Time Interface ID Interface
172.16.9.9 1 FULL/DROTHER 00:00:39 12 GigabitEthernet1.100
172.16.10.10 1 FULL/DR 00:00:31 13 GigabitEthernet1.100
R9
R9#sh ospfv3 1 nei
OSPFv3 1 address-family ipv6 (router-id 172.16.9.9)
Neighbor ID Pri State Dead Time Interface ID Interface
172.16.8.8 1 FULL/BDR 00:00:33 12 GigabitEthernet1.100
R10
R10#sh ospfv3 1 nei
OSPFv3 1 address-family ipv6 (router-id 172.16.10.10)
Neighbor ID Pri State Dead Time Interface ID Interface
172.16.8.8 1 FULL/BDR 00:00:37 12 GigabitEthernet1.100
As you can see, the CEs will only learn what the PEs allow them to, which is dictated by the RT policies.
Thanks for stopping by!
Rob Riker, CCIE #50693
Hi rob ,
ReplyDeletecould u please share whole topology configuration , so that i can do lab one by one .