IOS XE 15.5
IOS XR 5.3
The topology for this demo:
In this post we will be taking a look at the next generation of P2P pseudowire configuration with the newer "L2VPN Protocol CLI" that is replacing the legacy "xcconnect'' style of configuration. The irony of it is that both style of configuration pretty much do the same thing, but the newer "L2VPN Protocol CLI" allows for much more granular configuration and greater scale at the SP edge. Previously we took a look at the individual "xconnect" style and, even though I could have crammed all three posts into one, I think it would have detracted from the specifics of each post.
The main reason is the reliance on the actual interface level configuration that is required to get "xconnect" configurations to work as expected. This means that if I had a customer that required a dedicated interface for an EPL, that means one port would be solely tied up for the customers use and not available elsewhere. This isn't an interface level restriction but more an xconnect/L2 VPN limitation in my testing. So, we moved away from that style of configuration and onto the EVC/EFP configuration.
So the idea of EVC is basically to multiplex an interface and to disconnect the interface from the actual service. The interface is simply where the "service instance" get's applied, similar in fashion to a VRF does but doesn't have the same affect. The service instance is what gives EVC it's ability to take an interface and decouple the services that interfaces is forwarding for. So I don't have to configure 802.1Q or QinQ specific configurations at the interface level, rather the service instance is where those "services" get configured and applied to allowing an EPL/EVPL and QinQ EVPL to co-exist all at the same time on the same interface.
Encapsulation default means that any traffic received will be accepted, encapsulation dot1q 101 means that if the inner tag is 101, that traffic will be received, encapsulation dot1q 102 second-dot1q 200 means that inner tag 102 will be stripped off and outer tag 200 will be maintained end to end in the SP core.
R3
interface GigabitEthernet3
no ip address
negotiation auto
no keepalive
service instance 100 ethernet
encapsulation default
!
service instance 101 ethernet
encapsulation dot1q 101
!
service instance 102 ethernet
encapsulation dot1q 102 second-dot1q 200
R6
interface GigabitEthernet2
no ip address
negotiation auto
no keepalive
service instance 100 ethernet
encapsulation default
!
service instance 101 ethernet
encapsulation dot1q 101
!
service instance 102 ethernet
encapsulation dot1q 102 second-dot1q 200
This concludes the interface configuration, The next step is the interface "pseudowire" configuration that sets the encapsulation, sets the neighbor and sets the VC ID.
R3
interface pseudowire100
encapsulation mpls
neighbor 192.168.1.6 100
interface pseudowire101
encapsulation mpls
neighbor 192.168.1.6 101
interface pseudowire102
encapsulation mpls
neighbor 192.168.1.6 102
R6
interface pseudowire100
encapsulation mpls
neighbor 192.168.1.3 100
interface pseudowire101
encapsulation mpls
neighbor 192.168.1.3 101
interface pseudowire102
encapsulation mpls
neighbor 192.168.1.3 102
You can't do much with this setup other than what is available under the pseudowire configuration mode.
Now we have to bind this all together. We'll leverage the "l2vpn xconnect context" configuration mode.
R3
l2vpn xconnect context PORT
member pseudowire100
member GigabitEthernet3
l2vpn xconnect context QinQ
member GigabitEthernet3 service-instance 102
member pseudowire102
l2vpn xconnect context VLAN
member GigabitEthernet3 service-instance 101
member pseudowire101
You may notice that for the PORT context, there isn't a service instance attached, this is due to the fact this is a port level configuration. The encapsulation is default which means it doesn't need anything more specific for differentiating the service. In a real world rollout, you're typically not going to dedicate an entire port to a customer, but you absolutely can.
Now let's take a look at the details.
R3#show xconnect all
XC ST Segment 1 S1 Segment 2 S2
------+---------------------------------+--+---------------------------------+--
UP pri mpls 192.168.1.6:100 UP ac Gi3:9(Ethernet) UP
UP pri ac Gi3:102/200(Eth VLAN) UP mpls 192.168.1.6:102 UP
UP pri ac Gi3:101(Eth VLAN) UP mpls 192.168.1.6:101 UP
R3#show l2vpn atom vc
Service
Interface Peer ID VC ID Type Name Status
--------- --------------- ---------- ------ ------------------------ ----------
pw100 192.168.1.6 100 p2p PORT UP
pw101 192.168.1.6 101 p2p VLAN UP
pw102 192.168.1.6 102 p2p QinQ UP
R3#show mpls l2transport vc
Local intf Local circuit Dest address VC ID Status
------------- -------------------------- --------------- ---------- ----------
Gi3 Ethernet 192.168.1.6 100 UP
Gi3 Eth VLAN 101 192.168.1.6 101 UP
Gi3 Eth VLAN 102/200 192.168.1.6 102 UP
Regardless of which flavor of verification you use, you get pretty much the same output. Let's more specific on each one.
R3#show xconnect peer 192.168.1.6 vcid 100 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 ac Gi3:9(Ethernet) UP mpls 192.168.1.6:100 UP
Interworking: none Local VC label 322
Remote VC label 602
R3#show xconnect peer 192.168.1.6 vcid 101 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 ac Gi3:101(Eth VLAN) UP mpls 192.168.1.6:101 UP
Interworking: ethernet Local VC label 326
Remote VC label 603
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 ac Gi3:102/200(Eth VLAN) UP mpls 192.168.1.6:102 UP
Interworking: ethernet Local VC label 305
Remote VC label 604
You can see in the bolded portions that each PW has it's own label bindings indicating that each has a different LSP through the network. Discussed in detail later, we'll see how we can use MPLS TE to determine the path the L2 VPN takes in the core.
IOS XR also supports this style configuration, but only port mode works, shown below.
IOS
interface GigabitEthernet2
service instance 90 ethernet
encapsulation default
interface pseudowire90
encapsulation mpls
neighbor 192.168.1.11 90
l2vpn xconnect context XR_2_IOS
member GigabitEthernet2
member pseudowire90
XR
l2vpn
xconnect group XR_2_IOS
p2p PORT
interface GigabitEthernet0/0/0/2
neighbor ipv4 192.168.1.3 pw-id 90
RP/0/0/CPU0:XR1#show l2vpn xconnect
Wed Nov 23 17:17:23.589 UTC
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed
XConnect Segment 1 Segment 2
Group Name ST Description ST Description ST
------------------------ ----------------------------- -----------------------------
XR_2_IOS PORT UP Gi0/0/0/2 UP 192.168.1.3 90 UP
R3#show mpls l2transport vc
Local intf Local circuit Dest address VC ID Status
------------- -------------------------- --------------- ---------- ----------
Gi3 Ethernet 192.168.1.6 100 UP
Gi3 Eth VLAN 101 192.168.1.6 101 UP
Gi3 Eth VLAN 102/200 192.168.1.6 102 UP
Gi2 Ethernet 192.168.1.11 90 UP
R3#show xconnect peer 192.168.1.11 vcid 90 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 ac Gi2:8(Ethernet) UP mpls 192.168.1.11:90 UP
Interworking: none Local VC label 307
Remote VC label 24113
So as you can see the configuration isn't very difficult, a bit labor intensive if you have multiple PWs to configure.
Let's do some CE side verification.
R8#ping 10.1.108.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.108.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R8#ping 10.1.101.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.101.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R8#ping 10.1.102.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.102.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
This is some really cool stuff that can be used to scale very easily in the Provider core.
Thanks for stopping by!
Rob Riker, CCIE #50693
No comments:
Post a Comment