IOS XE 15.5
IOS XR 5.3
The topology for this demo:
In the previous post, we configured manual NPE pseudowires, which works in our little lab to test out the configuration, but in a large SP network with 100s of NPEs, that is not going to happen. So we implement BGP AD with LDP signaling to provide the scalability required for large environments. Since our deployment is rather small, I don't bother with BGP configuration scaling techniques, just a couple of neighbor statements where needed to get functionality working.
We've taken a look at VPLS with BGP AD in prior posts, so the BGP configuration there is what we'll use here. We'll be activating the "l2vpn vpls" address family and this is what we'll enable the propagation of NLRI between the NPEs so that the SP Access where the UPEs sit will be able to advertise and learn information from the NPEs and provide end to end connectivity. We'll start with the NPE configuration and work our way out to the customer. I didn't configure it that way, I started on the Customer, then the UPE, then the NPEs, then the went back to make sure it was working. It was my way of proving each step and the order of operations were followed. It also allows me to see the minimum required level of configuration needed to get the function working.
NPEs
R4
template type pseudowire HVPLS
encapsulation mpls
sequencing both
control-word include
signaling protocol ldp
!
interface pseudowire34100
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.3 34100
signaling protocol ldp
!
l2vpn vfi context VPLS_100
vpn id 100
autodiscovery bgp signaling ldp
route-target export 100:50693
route-target import 100:50693
no auto-route-target
!
bridge-domain 100
member vfi VPLS_100
member pseudowire34100
!
router bgp 50693
bgp log-neighbor-changes
neighbor 192.168.1.2 remote-as 50693
neighbor 192.168.1.2 update-source Loopback0
neighbor 192.168.1.5 remote-as 50693
neighbor 192.168.1.5 update-source Loopback0
!
address-family l2vpn vpls
neighbor 192.168.1.2 activate
neighbor 192.168.1.2 prefix-length-size 2
neighbor 192.168.1.5 activate
neighbor 192.168.1.5 prefix-length-size 2
R5
template type pseudowire HVPLS
encapsulation mpls
sequencing both
control-word include
signaling protocol ldp
!
interface pseudowire56100
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.6 56100
signaling protocol ldp
!
l2vpn vfi context VPLS_100
vpn id 100
autodiscovery bgp signaling ldp
route-target export 100:50693
route-target import 100:50693
!
bridge-domain 100
member vfi VPLS_100
member pseudowire56100
!
router bgp 50693
bgp log-neighbor-changes
neighbor 192.168.1.2 remote-as 50693
neighbor 192.168.1.2 update-source Loopback0
neighbor 192.168.1.4 remote-as 50693
neighbor 192.168.1.4 update-source Loopback0
!
address-family l2vpn vpls
neighbor 192.168.1.2 activate
neighbor 192.168.1.2 prefix-length-size 2
neighbor 192.168.1.4 activate
neighbor 192.168.1.4 prefix-length-size 2
R2
template type pseudowire HVPLS
encapsulation mpls
sequencing both
control-word include
signaling protocol ldp
!
interface pseudowire12100
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.1 12100
signaling protocol ldp
!
l2vpn vfi context VPLS_100
vpn id 100
autodiscovery bgp signaling ldp
route-target export 100:50693
route-target import 100:50693
no auto-route-target
!
bridge-domain 100
member vfi VPLS_100
member pseudowire12100
!
router bgp 50693
bgp log-neighbor-changes
neighbor 192.168.1.4 remote-as 50693
neighbor 192.168.1.4 update-source Loopback0
neighbor 192.168.1.5 remote-as 50693
neighbor 192.168.1.5 update-source Loopback0
!
address-family l2vpn vpls
neighbor 192.168.1.4 activate
neighbor 192.168.1.4 prefix-length-size 2
neighbor 192.168.1.5 activate
neighbor 192.168.1.5 prefix-length-size 2
UPE Configuration
R3
template type pseudowire HVPLS
encapsulation mpls
sequencing both
control-word include
signaling protocol ldp
!
interface pseudowire34100
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.4 34100
signaling protocol ldp
!
l2vpn xconnect context VPLS_100
member GigabitEthernet2 service-instance 100
member pseudowire34100
R6
template type pseudowire HVPLS
encapsulation mpls
sequencing both
control-word include
signaling protocol ldp
!
interface pseudowire56100
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.5 56100
signaling protocol ldp
!
l2vpn xconnect context VPLS_100
member GigabitEthernet2 service-instance 100
member pseudowire56100
R1
template type pseudowire HVPLS
encapsulation mpls
sequencing both
control-word include
signaling protocol ldp
!
interface pseudowire12100
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.2 12100
signaling protocol ldp
!
l2vpn xconnect context VPLS_100
member GigabitEthernet2 service-instance 100
member pseudowire12100
Now that we have everything configured, in my testing, it took on average 2-4 minutes for BGP to run best path and propagate information.
We'll verify the VPLS part and make sure all is well with BGP.
R3
R3#sh xc all | in 100
UP pri ac Gi2:100(Eth VLAN) UP mpls 192.168.1.4:34100 UP
R3#sh l2vpn service xconnect all | in 100
VPWS name: VPLS_100, State: UP
Gi2 Gi2:100(Eth VLAN) 0 UP UP
pw34100 192.168.1.4:34100(MPLS) 0 UP UP
We can see that the UPE configuration is good and that the peering to R4 is operational.
NPE Verification:
R4
R4#sh l2vpn service vfi name VPLS_100 | b Interface
Interface Group Encapsulation Prio St XC St
--------- ----- ------------- ---- -- -----
VPLS name: VPLS_100, State: UP
pw100002 VPLS_100(VFI) 0 UP UP
pw100005 core_pw 192.168.1.5:100(MPLS) 0 UP UP
pw100003 core_pw 192.168.1.2:100(MPLS) 0 UP UP
pw34100 core_pw 192.168.1.3:34100(MPLS) 0 UP UP
We can see that the l2vpn service is up and operational, this output and the next are centric to the VPLS aspect, this one specifically highlights all parts of the service, pseudowires to the other NPEs and the UPE. pw100002 specifically points to the operational status of the VFI instance.
R4#show l2vpn vfi name VPLS_100
Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No
VFI name: VPLS_100, state: up, type: multipoint, signaling: LDP
VPN ID: 100, VPLS-ID: 50693:100
RD: 50693:100, RT: 100:50693,
Bridge-Domain 100 attachment circuits:
Pseudo-port interface: pseudowire100002
Interface Peer Address VC ID Discovered Router ID S
pseudowire100005 192.168.1.5 100 192.168.1.5 Y
pseudowire100003 192.168.1.2 100 192.168.1.2 Y
pseudowire34100 192.168.1.3 34100 n/a N
Like the previous output, vfi centric, however this is more specific to the actual forwarding of traffic on the NPE, we see 3 different psuedowires, 2 to the other NPEs and 1 to the UPE, you'll see that split horizon is enabled on the NPE facing pseudowires. You'll also see the "Discovered Router ID", this is an indication that BGP AD is being used, you normally won't see that, you'll see the pseudowire info and the VC-ID used to reach that remote device, here we see that R5 and R2 show up. but R3 we see the "n/a", meaning that R3 is statically assigned and not running BGP AD.
R4#sh bgp l2vpn vpls all summary
BGP router identifier 192.168.1.4, local AS number 50693
BGP table version is 7, main routing table version 7
3 network entries using 792 bytes of memory
3 path entries using 408 bytes of memory
2/2 BGP path/bestpath attribute entries using 496 bytes of memory
1 BGP extended community entries using 40 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1736 total bytes of memory
BGP activity 4/1 prefixes, 4/1 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.2 4 50693 139 139 7 0 0 02:02:10 1
192.168.1.5 4 50693 125 128 7 0 0 01:50:17 1
We see that we have connectivity to R2 and R5, and we're learning 1 pfx from each, however this isn't a "prefix" so to speak, but rather a MAC from that router.
R4#sh bgp l2vpn vpls all
BGP table version is 7, local router ID is 192.168.1.4
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: 50693:100
*>i 50693:100:192.168.1.2/96
192.168.1.2 0 100 0 ?
*> 50693:100:192.168.1.4/96
0.0.0.0 32768 ?
*>i 50693:100:192.168.1.5/96
192.168.1.5 0 100 0 ?
We can see that we have /96 prefixes learned, the RD:RID of the remote device, this is a good sign of solid propagation of MAC learned from the remote peer.
R4#sh bgp l2vpn vpls all 192.168.1.2
BGP routing table entry for 50693:100:192.168.1.2/96, version 2
Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)
Not advertised to any peer
Refresh Epoch 1
Local
192.168.1.2 (metric 4) from 192.168.1.2 (192.168.1.2)
Origin incomplete, metric 0, localpref 100, valid, internal, best, AGI version(1090519043)
Extended Community: RT:100:50693 L2VPN AGI:50693:100
mpls labels in/out 16777215/16777215
rx pathid: 0, tx pathid: 0x0
We take a deeper look at what R2 has advertised to us, we see the AGI info is the same as the RT and RD, all of these values must match in order for R4 to learn the routes. Another thing to take note on is that the "mpls labels" are 16777215, which simply means max value or not used. BGP signaling for VPLS doesn't exchange labels, it exchanges details on how the label should be derived. The quickest way to find that out is to look at the atom DB.
R4#show l2vpn atom vc pseudowire 100003 detail | in label
Last label FSM state change time: 02:52:05
Output interface: Gi1.154, imposed label stack {24510 33}
SSO Descriptor: 192.168.1.2/100, local label: 51
This output shows that label 51 is allocated for the p2p pseudowire.
R4#show mpls forwarding-table labels 51
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
51 No Label l2ckt(8) 0 none point2point
This output shows that label 24510 is used to reach the next hop, which at the moment, hasn't incremented the "label switched" portion, which is no big deal.
R4#show mpls forwarding-table labels 40
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
40 527 192.168.1.2/32 7884 Gi1.45 10.4.5.5
24510 192.168.1.2/32 0 Gi1.154 10.15.4.15
R4#sh bridge-domain 100
Bridge-domain 100 (3 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
vfi VPLS_100 neighbor 192.168.1.3 34100
vfi VPLS_100 neighbor 192.168.1.2 100
vfi VPLS_100 neighbor 192.168.1.5 100
AED MAC address Policy Tag Age Pseudoport
1 FFFF.FFFF.FFFF flood static 0 OLIST_PTR:0xe7fa6c70
0 000C.29BA.0E21 forward dynamic 297 VPLS_100.1004016
0 000C.2994.B818 forward dynamic 298 VPLS_100.1004019
0 000C.2990.89E9 forward dynamic 296 VPLS_100.1004017
This output shows that we have dynamically learned about 3 UPEs who have forwarded data into the NPE core. WE see the three peers, 2 of them being NPE peers, the other is the UPE peer. Since R2 and R5 were learned dynamically, there "VC-ID" is 100 and not statically defined like R3 is.
Customer verification:
R7
R7#sh ip eigrp nei
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
8 192.168.100.10 Gi1.100 14 02:56:22 257 1542 0 462
9 192.168.100.13 Gi1.100 10 02:57:58 334 2004 0 495
All is well!
Thanks for stopping by!
Rob Riker, CCIE #50693
No comments:
Post a Comment