IOS XE 15.5
IOS XR 5.3
The topology for this demo:
In this post we will take a look at VPLS or Virtual Private LAN Service. This takes what we have previously covered in AToM or EPL/EVPL/QinQ and expands on it. The concept of a pseudowire and the service instance are ported over from the P2P style of AToM to the MP2MP style of VPLS. The main difference being the VPLS emulates/acts like a LAN segment commonly found in an Enterprise network. This enables a customer with multiple sites to connect to a common L2 Ethernet based service like VPLS or E-LAN and have connectivity to all other sites joined to that same service.
There are a few things that we need to cover in regards to VPLS before we hit the configuration. I didn't go into a ton of detail in P2P L2 Services but I will here just to bring you up to speed on the concepts/terms so that you'll be able to take what you already know from AToM/E-Line to VPLS/E-LAN.
Basically VPLS is a full mesh of pseudowires. Each PE has a connected to every other PE in an N*N-1/2. Basically if you have 4 PEs, Each PE will be connected to all other PEs, Just like you would have in iBGP full mesh of connections. So there are a few terms we need to hit before we move on.
Service instance - Basically this is the configuration that goes at the interface level that is used to abstract the Service from the interface, where with AToM you would configure the xconnect at the interface level. The service instance allows you to specify the SI-ID or # you will call later from the bridge domain.
L2VPN VFI - The virtual forwarding instance is a logical construct used to "aggregate" the pseudowires under a common entity. The VFI also has a VPN ID number that is used for signaling between the PEs. The PWs are aggregated or bound to the VFI similar in to how you would bundle GigE interfaces to an Etherchannel or T1s to a Multilink PPP interface. There is no aggregation of bandwidth or redundancy so it's not 1 for 1 but more of the grouping of interfaces.
Bridge-Domain - This is the "Broadcast" domain if you will that is used to connect the different PEs to each other. This VLAN like behavior is where the CAM table is built for each BD, each PW connection into the BD is another "port" attached to the BD. There is a broadcast capability for flooding capabilities and a split horizon concept. The SH concept in you won't send a frame out the interface it was received in on, it's assumed the destination isn't where the traffic came from. Since there is a CAM table function, and a flooding function, it's implied that MAC address flooding does take place and that's true, the CE interface MAC connecting to the VPLS service is learned and propagated to all the PEs participating. That also implies that there is an upper limit to how many MACs can be learned per PE/Bridge Domain.
Ethernet Flow Point - The Service instance described earlier is what this enables. The type of traffic/port/VLAN/QinQ/or VLAN Acrobatics are configured under the service instance and based on where traffic is received and handled is what the EFP takes care of by mapping the inbound traffic to the appropriate L2 forwarding service. We'll take a much deeper look at PW capabilities and EVC rewrite functions later.
Pseudowire - This is a logical construct like it's above counterparts used to map the encapsulation and the neighbor that we will be connecting to, only one neighbor can be defined, together to be called by the VFI later on.
So a quick recap, the "service instance" is configured under the interface and dictates the type of service to be implemented (Port/VLAN/QinQ/ETC). The "pseudowire" is configured globally with "interface pseudowire 100". The "pseudowire" is called by the "VFI". The "Bridge domain" is the VLAN that binds all of this together, the interface level service instance and the VFI are both referenced under the bridge domain configuration and this is where you will see the "VPLS" component come live.
We'll go ahead can get this configured on R3, R5, R6 and XR1. XR1 is done to show that is supported in the control plane and that's about it. The CSRs (R3, 5 and 6) support VPLS in the control plane and data plane.
R3
interface GigabitEthernet3
no ip address
service instance 1356 ethernet
encapsulation default
interface pseudowire35
encapsulation mpls
neighbor 192.168.1.5 35
interface pseudowire36
encapsulation mpls
neighbor 192.168.1.6 36
interface pseudowire311
encapsulation mpls
neighbor 192.168.1.11 311
l2vpn vfi context VPLS
vpn id 1356
member pseudowire311
member pseudowire36
member pseudowire35
bridge-domain 1356
member GigabitEthernet3 service-instance 1356
member vfi VPLS
So the above config is the order in which I configured and have had success getting VPLS up and running. Set the Service Instance under the interface (encap default says to accept anything - Port Based config). The interface pseudowires specify who you will connect to and the encapsulation being used, MPLS in this case. The l2vpn vfi is the "VPLS" configuration, binds the PWs together with the VPN ID being it's identifier. The Bridge domain is the broadcast domain. Since VPLS is a collection of PWs like AToM or EPL, it can be verified as such. The remaining devices below.
R5
interface GigabitEthernet2
no ip address
service instance 1356 ethernet
encapsulation default
interface pseudowire35
encapsulation mpls
neighbor 192.168.1.3 35
interface pseudowire56
encapsulation mpls
neighbor 192.168.1.6 56
l2vpn vfi context VPLS
vpn id 1356
member pseudowire56
member pseudowire35
member 192.168.1.11 511 encapsulation mpls
bridge-domain 1356
member GigabitEthernet2 service-instance 1356
member vfi VPLS
As you can see above, you can mix and match the configuration almost interchangeably as you see fit. Kind of a mix of old and new configs.
R6
interface GigabitEthernet2
no ip address
service instance 1356 ethernet
encapsulation default
l2vpn vfi context VPLS
vpn id 1356
member 192.168.1.11 611 encapsulation mpls
member 192.168.1.5 56 encapsulation mpls
member 192.168.1.3 36 encapsulation mpls
bridge-domain 1356
member GigabitEthernet2 service-instance 1356
member vfi VPLS
I ended up not even using the PW configuration here as a separate syntax, More or less just testing functionality out.
XR1
interface GigabitEthernet0/0/0/2
l2transport
l2vpn !
!
bridge group VPLS
bridge-domain VPLS
interface GigabitEthernet0/0/0/2
!
vfi VPLS
neighbor 192.168.1.3 pw-id 311
!
neighbor 192.168.1.5 pw-id 511
!
neighbor 192.168.1.6 pw-id 611
XR's syntax is very similar, the main difference you'll see is that with the interface, you have to specify the role the interface will play. In this case it's layer 2 transport. In EPL, this configuration, l2transport at the physical interface level is all that was supported. I will test functionality out with l2transport under a sibinterface, which has to be configured separately.
The PW configuration, like on R6s is completely configured under the L2 VPN configuration mode.
So at this point the entire lab is configured, mind you I had to remove the previous configuration for EPLs. Verification time on the PE side first.
R3
R3#show l2vpn vfi
Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No
VFI name: VPLS, state: up, type: multipoint, signaling: LDP
VPN ID: 1356
Bridge-Domain 1356 attachment circuits:
Pseudo-port interface: pseudowire100017
Interface Peer Address VC ID S
pseudowire311 192.168.1.11 311 Y
pseudowire36 192.168.1.6 36 Y
pseudowire35 192.168.1.5 35 Y
R3#show xconnect all
Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State
UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware
XC ST Segment 1 S1 Segment 2 S2
------+---------------------------------+--+---------------------------------+--
UP pri vfi VPLS UP mpls 192.168.1.11:311 UP
UP pri vfi VPLS UP mpls 192.168.1.6:36 UP
UP pri vfi VPLS UP mpls 192.168.1.5:35 UP
UP pri bd 1356 UP vfi VPLS UP
Regardless of how you verify it, you pretty much can see that the output gives you similar outputs.
R3#show xconnect all detail
Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State
UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware
XC ST Segment 1 S1 Segment 2 S2
------+---------------------------------+--+---------------------------------+--
UP pri vfi VPLS UP mpls 192.168.1.11:311 UP
Local VC label 309
Remote VC label 24111
UP pri vfi VPLS UP mpls 192.168.1.6:36 UP
Local VC label 312
Remote VC label 611
UP pri vfi VPLS UP mpls 192.168.1.5:35 UP
Local VC label 310
Remote VC label 500
UP pri bd 1356 UP vfi VPLS UP
R3#show l2vpn atom vc vcid 35 detail
pseudowire35 is up, VC status is up PW type: Ethernet
Create time: 04:21:44, last status change time: 04:17:10
Last label FSM state change time: 04:17:10
Destination address: 192.168.1.5 VC ID: 35
Output interface: Gi1.34, imposed label stack {403 500}
Preferred path: not configured
Default path: active
Next hop: 10.3.4.4
Member of vfi service VPLS
Bridge-Domain id: 1356
Service id: 0xe6000005
Signaling protocol: LDP, peer 192.168.1.5:0 up
Targeted Hello: 192.168.1.3(LDP Id) -> 192.168.1.5, LDP is UP
The outputs from the other routers look almost identical. Lets check out XR1 for some change of pace.
RP/0/0/CPU0:XR1#show l2vpn bridge-domain
Thu Nov 24 02:52:14.316 UTC
Legend: pp = Partially Programmed.
Bridge group: VPLS, bridge-domain: VPLS, id: 0, state: up, ShgId: 0, MSTi: 0
Aging: 300 s, MAC limit: 4000, Action: none, Notification: syslog
Filter MAC addresses: 0
ACs: 1 (1 up), VFIs: 1, PWs: 3 (3 up), PBBs: 0 (0 up)
List of ACs:
Gi0/0/0/2, state: up, Static MAC addresses: 0
List of Access PWs:
List of VFIs:
VFI VPLS (up)
Neighbor 192.168.1.3 pw-id 311, state: up, Static MAC addresses: 0
Neighbor 192.168.1.5 pw-id 511, state: up, Static MAC addresses: 0
Neighbor 192.168.1.6 pw-id 611, state: up, Static MAC addresses: 0
RP/0/0/CPU0:XR1#show l2vpn bridge-domain neighbor 192.168.1.6 detail
Thu Nov 24 02:52:34.155 UTC
Legend: pp = Partially Programmed.
Bridge group: VPLS, bridge-domain: VPLS, id: 0, state: up, ShgId: 0, MSTi: 0
Coupled state: disabled
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: 23/11/2016 23:17:33 (03:35:00 ago)
No status change since creation
ACs: 1 (1 up), VFIs: 1, PWs: 1 (1 up), PBBs: 0 (0 up)
List of Access PWs:
List of VFIs:
VFI VPLS (up)
PW: neighbor 192.168.1.6, PW ID 611, state is up ( established )
PW class not set, XC ID 0xff000005
Encapsulation MPLS, protocol LDP
Source address 192.168.1.11
PW type Ethernet, control word disabled, interworking none
Sequencing not set
PW Status TLV in use
MPLS Local Remote
------------ ------------------------------ -------------------------
Label 24115 613
Group ID 0x0 0x0
Interface VPLS unknown
MTU 1500 1500
Control word disabled disabled
PW type Ethernet Ethernet
VCCV CV type 0x2 0x2
(LSP ping verification) (LSP ping verification)
VCCV CC type 0x6 0x6
(router alert label) (router alert label)
(TTL expiry) (TTL expiry)
------------ ------------------------------ -------------------------
Incoming Status (PW Status TLV):
Status code: 0x0 (Up) in Notification message
MIB cpwVcIndex: 4278190085
Create time: 23/11/2016 23:17:33 (03:35:00 ago)
Last time status changed: 23/11/2016 23:41:25 (03:11:08 ago)
Last time PW went down: 23/11/2016 23:39:55 (03:12:38 ago)
MAC withdraw messages: sent 0, received 0
Static MAC addresses:
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0
Storm control drop counters:
packets: broadcast 0, multicast 0, unknown unicast 0
bytes: broadcast 0, multicast 0, unknown unicast 0
DHCPv4 snooping: disabled
IGMP Snooping profile: none
MLD Snooping profile: none
VFI Statistics:
drops: illegal VLAN 0, illegal length 0
Now let's check a PE to see what the bridge domain is doing.
R3#show bridge-domain
Bridge-domain 1356 (4 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
GigabitEthernet3 service instance 1356
vfi VPLS neighbor 192.168.1.5 35
vfi VPLS neighbor 192.168.1.6 36
vfi VPLS neighbor 192.168.1.11 311
AED MAC address Policy Tag Age Pseudoport
0 000C.2994.B818 forward dynamic 296 VPLS.100401e
0 000C.29BB.45EF forward dynamic 299 VPLS.100401d
1 FFFF.FFFF.FFFF flood static 0 OLIST_PTR:0xe7f86020
0 000C.29C9.1F5C forward dynamic 295 GigabitEthernet3.EFP1356
The outputs above indicate that traffic is active and forwarding. I actually have OSPFv2/v3 configured on the CE side so this table will never age out. Just like a regular switch you can see that the CAM table as an aging timer, you can see the associated service instance tied to the VFI. I kept the numbering the same, 1356, for simplifying verification.
Now to see the CE side.
R8#sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
10.1.100.9 1 FULL/BDR 00:00:39 10.1.100.9 GigabitEthernet1
10.1.100.10 1 FULL/DR 00:00:35 10.1.100.10 GigabitEthernet1
R8#sh ospfv3 nei
OSPFv3 1 address-family ipv6 (router-id 10.1.100.8)
Neighbor ID Pri State Dead Time Interface ID Interface
10.1.100.9 1 FULL/BDR 00:00:37 7 GigabitEthernet1
10.1.100.10 1 FULL/DROTHER 00:00:33 7 GigabitEthernet1
R8#sh ipv6 route ospf
IPv6 Routing Table - default - 7 entries
[snip]
O FC00:9::9/128 [110/1]
via FE80::20C:29FF:FEBB:45EF, GigabitEthernet1
O FC00:10::10/128 [110/1]
via FE80::20C:29FF:FE94:B818, GigabitEthernet1
As you can see I have learned routes from R9 and R10. Let's try pinging those addresses.
R8#ping FC00:9::9
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FC00:9::9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/15/30 ms
R8#ping FC00:10::10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FC00:10::10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/16/30 ms
Awesome! We have reachability, now if I was to trace to those addresses you'll see that we're only 1 hop away.
R8#traceroute FC00:9::9
Type escape sequence to abort.
Tracing the route to FC00:9::9
1 2001:1:100::9 20 msec 2 msec 1 msec
R13
R13#sh ospfv3 interface brief
Interface PID Area AF Cost State Nbrs F/C
Gi1 1 0 ipv6 1 DR 0/0
R13#sh ospfv3 neighbor
R13#
As you can see on R13, who is connected to XR1, doesn't form any adjacencies. This is due to the dataplane not working on XRv. I haven't tested this on XRv9K yet, but I do have the intention to do that. Stay tuned.
Now let's take a look at the control plane from a debug output. We'll take a look at if from the L2VPN VFI FSM event standpoint first.
R5
debug l2vpn vfi fsm event
From R3
XC VFI VC[VPLS/pw35]: Processing client Update message
XC VFI VC[VPLS/pw35]: Circuit attributes from client:
XC VFI VC[VPLS/pw35]: Payload encap: Ethernet
XC VFI VC[VPLS/pw35]: Update VC type not needed
XC VFI VC[VPLS/pw35]: Processing client Update message
XC VFI VC[VPLS/pw35]: Circuit attributes from client:
XC VFI VC[VPLS/pw35]: Payload encap: Ethernet
XC VFI VC[VPLS/pw35]: VLAN ID: 0
XC VFI VC[VPLS/pw35]: Loadbalance mode: None
XC VFI VC[VPLS/pw35]: Loadbalance Flow class: none
XC VFI VC[VPLS/pw35]: Update VC type not needed
XC VFI VC[VPLS/pw35]: Processing client Update message
XC VFI VC[VPLS/pw35]: Circuit attributes from client:
XC VFI VC[VPLS/pw35]: i/f: 4003
XC VFI VC[VPLS/pw35]: Status: UP (0x1)
XC VFI VC[VPLS/pw35]: Payload encap: Ethernet
XC VFI VC[VPLS/pw35]: Circuit Encap: Ethernet
XC VFI VC[VPLS/pw35]: VCCV CC: 0x6
XC VFI VC[VPLS/pw35]: Segment type: AToM
XC VFI VC[VPLS/pw35]: Control Word: yes
XC VFI VC[VPLS/pw35]: Fast Switchover: no
XC VFI VC[VPLS/pw35]: MTU: 1500
XC VFI VC[VPLS/pw35]: I/F Str: pw35
XC VFI VC[VPLS/pw35]: Circuit string: 192.168.1.3:35
XC VFI VC[pw100003]: Num pws up for bd_id 54C pw_count 2
XC VFI VC[VPLS/pw35]: client update received for bd_id 54C all_up 0 pw up count 2
XC VFI VC[VPLS/pw35]: Update VC type not needed
XC VFI VC[VPLS/pw35]: VFI-PW segment bind occured
XC VFI VC[VPLS/pw35]: VFI-PW segment bind occured
The bolded portions, the payload is Ethernet based on the service instance and the encapsulation is default, VLAN ID being "0". Status is up and the payload and circuit encap are both Ethernet. VCCV CC is 0x6 meaning IPv6. The MTU is 1500 and the peer is 192.168.1.3:35 meaning R3 and a PW ID of 35.
From R6
XC VFI VC[VPLS/pw56]: Processing client Update message
XC VFI VC[VPLS/pw56]: Circuit attributes from client:
XC VFI VC[VPLS/pw56]: Payload encap: Ethernet
XC VFI VC[VPLS/pw56]: Update VC type not needed
XC VFI VC[VPLS/pw56]: Processing client Update message
XC VFI VC[VPLS/pw56]: Circuit attributes from client:
XC VFI VC[VPLS/pw56]: Payload encap: Ethernet
XC VFI VC[VPLS/pw56]: VLAN ID: 0
XC VFI VC[VPLS/pw56]: Loadbalance mode: None
XC VFI VC[VPLS/pw56]: Loadbalance Flow class: none
XC VFI VC[VPLS/pw56]: Update VC type not needed
XC VFI VC[VPLS/pw56]: Processing client Update message
XC VFI VC[VPLS/pw56]: Circuit attributes from client:
XC VFI VC[VPLS/pw56]: i/f: 4004
XC VFI VC[VPLS/pw56]: Status: UP (0x1)
XC VFI VC[VPLS/pw56]: Payload encap: Ethernet
XC VFI VC[VPLS/pw56]: Circuit Encap: Ethernet
XC VFI VC[VPLS/pw56]: VCCV CC: 0x6
XC VFI VC[VPLS/pw56]: Segment type: AToM
XC VFI VC[VPLS/pw56]: Control Word: yes
XC VFI VC[VPLS/pw56]: Fast Switchover: no
XC VFI VC[VPLS/pw56]: MTU: 1500
XC VFI VC[VPLS/pw56]: I/F Str: pw56
XC VFI VC[VPLS/pw56]: Circuit string: 192.168.1.6:56
XC VFI VC[pw100003]: Num pws up for bd_id 54C pw_count 3
XC VFI VC[VPLS/pw56]: client update received for bd_id 54C all_up 1 pw up count 3
XC VFI VC[VPLS/pw56]: Update VC type not needed
XC VFI VC[VPLS/pw56]: VFI-PW segment bind occured
XC VFI VC[VPLS/pw56]: VFI-PW segment bind occured
It's pretty easy to identify where the traffic is coming from with the pwxx output in there.
Same as above, the all is the identical except the peer is R6 with PW ID of 56.
The next output is from ATOM LDP, I only bounced the R3 VFI this time.
R5
debug mpls l2transport signaling event
debug mpls l2transport signaling message detail
R5#show debug
AToM LDP event debugging is on
AToM LDP message detail debugging is on
AToM LDP[192.168.1.3]: Received label withdraw msg, id 90774, GR instance 4 - 1
AToM LDP[192.168.1.3]: VC Type 5, c-bit, mtu 0
AToM LDP[192.168.1.3]: VC ID 35, label 308
AToM LDP[192.168.1.3]: Group 0
AToM LDP[192.168.1.3]: Sending label release msg - 2
AToM LDP[192.168.1.3]: VC Type 5, c-bit, mtu 0
AToM LDP[192.168.1.3]: VC ID 35, label 308
AToM LDP[192.168.1.3]: Group 0
AToM LDP[192.168.1.3]: Received label mapping msg, id 90778, GR instance 4 - 3
AToM LDP[192.168.1.3]: VC Type 5, c-bit, mtu 1500
AToM LDP[192.168.1.3]: VC ID 35, label 304
AToM LDP[192.168.1.3]: Group 0
AToM LDP[192.168.1.3]: Status 0x28 [PW Status]
AToM LDP[192.168.1.3]: PW Status 0x0(0x1) [UP]
The first 2 bolded lines indicate that the R3 was removing the configuration, R3 had the bridge-domain shutdown which is why the withdraw is sent from 192.168.1.3.
The third bolded line is an update from R3 stating that the bridge-domain is now up, The VC Type is 5 and the c bit is there, meaning that the AC is Ethernet (VC Type 5) and the control word is being sent. The MTU is identified and you see the VC ID of 35 and the label applied is 304, meaning R3 assigned label 304 for that connection.
R3
R3#show mpls l2transport vc 35 detail
Local interface: VFI VPLS vfi up
Interworking type is Ethernet
Destination address: 192.168.1.5, VC ID: 35, VC status: up
Output interface: Gi1.34, imposed label stack {403 500}
Label 500 was assigned by R5 for the connection to R3. Label 403 was assigned by LDP to get from R3 to R5
R3#show mpls l2transport vc 35 detail | in labels
MPLS VC labels: local 322, remote 500
Label 322 is the local label applied by R3 for the L2ckt, there is no outgoing label as 403 is assigned fro that.
R3#sh mpls forwarding-table
318 403 192.168.1.5/32 890252 Gi1.34 10.3.4.4
R5#show l2vpn atom vc vcid 35 detail
pseudowire35 is up, VC status is up PW type: Ethernet
Create time: 18:53:52, last status change time: 00:47:47
Last label FSM state change time: 00:47:47
Destination address: 192.168.1.3 VC ID: 35
Output interface: Gi1.45, imposed label stack {402 322}
R5#show mpls forwarding-table 192.168.1.3
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
516 402 192.168.1.3/32 4799307 Gi1.45 10.4.5.4
Thanks for stopping by!
Rob Riker, CCIE #50693
No comments:
Post a Comment