IOS XE 15.5
IOS XR 5.3
The topology for this demo:
In previous posts we took a look P2P pseudowires using the "xconnect" style configuration. This is considered to be "legacy" and not really scalable. The newer technique is using the "L2VPN Protocol CLI". We'll take a look at the initial setup with both the "xconnect" and "l2vpn" configuration models and then just the "l2vpn" technique. During my testing of these features, any "xconnect" feature tested has a "l2vpn" counterpart. You will also see that the "xconnect" technique doesn't scale, mainly due to the fact we're tying the "pseudowire" directly to the interface. In my testing, an "xconnect" at the physical port level, GigabitEthernet 2 for instance, will not accept the "xconnect" syntax on a subinterface while also having the "xconnect" on the main interface. How is this issue resolved, the "service instance" capability used for EFP. The "service instance" decouples the "layer 2" functionality from the interface and maps it to an "xconnect" context that provides much greater scale.
So you may ask, why even use the "xconnect" technique? Well, I don't have a reason to use it unless that is all you know. if so, so be it, the pseudowire between PEs will still get built. Normally you will add functionality through a "pw-class" or "template type pseudowire" that will add capabilities like the "control word" or "sequencing". We'll focus on those later. In our first base configuration, we'll take a look a basic setup where R1 will use the "xconnect" technique and R6 will use the "l2vpn" technique with a service instance. From R6's perspective, the "service instance" is the "Ethernet Flow Point" configuration, which will allow the interface to be multiplexed for different services. We will try to do the same thing on R1, we'll take a look those results, and fix them by migrating to the "l2vpn" technique.
R1
interface GigabitEthernet2
xconnect 192.168.1.6 100 encapsulation mpls
R6
interface GigabitEthernet2
service instance 100 ethernet
encapsulation default
!
interface pseudowire100
encapsulation mpls
neighbor 192.168.1.1 100
!
l2vpn xconnect context PORT
member GigabitEthernet2 service-instance 100
member pseudowire100
As you can see, R6 is a bit more to configure than R1. The trade off for scale is huge though. There is a ton of debug output. Most of it just provisioning info that isn't useful. I won't bore you with debug outputs as they are the same ones from previous posts. But we will check out the verification!
R1
R1#sh xc 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 ac Gi2:8(Ethernet) UP mpls 192.168.1.6:100 UP
R1#show mpls l2transport binding
Destination Address: 192.168.1.6,VC ID: 100
Local Label: 125
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV: CC Type: CW [1], RA [2], TTL [3]
CV Type: LSPV [2]
Remote Label: 32
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV: CC Type: CW [1], RA [2], TTL [3]
CV Type: LSPV [2]
R1#sh l2vpn atom vc
Service
Interface Peer ID VC ID Type Name Status
--------- --------------- ---------- ------ ------------------------ ----------
pw100005 192.168.1.6 100 p2p Gi2-8 UP
As you can see from the above outputs, the PW or pseudowire is up and operational. There are some outputs above you may question, like the ones under the l2transport bindings, I'll cover those in another post that focuses specifically on VCCV. The main thing to take away from this is the fact that we are looking at a main interface attachment circuit. From R1, we can't take advantage of the subinterface.
R1(config)#int g2.1000
R1(config-subif)#en
R1(config-subif)#encapsulation do
R1(config-subif)#encapsulation dot1Q 1000
R1(config-subif)#xc
R1(config-subif)#xconnect ?
% Unrecognized command
R1(config-subif)#xconnect
As you can see, it doesn't work. If I was to take the "xconnect" off the main interface, it would. You can multiplex subinterfaces, as long as each subinterface is mapped to a separate pseudowire, you should be ok. We aren't going to do that. I want to verify that R13 and R10 both have an EIGRP adjacency, and that each router can propagate a route to the other.
R10
interface Loopback100
ip address 192.168.100.10 255.255.255.0
!
router eigrp 100
network 172.16.100.0 0.0.0.255
network 192.168.100.0
R13
interface Loopback100
ip address 192.168.101.13 255.255.255.0
!
router eigrp 100
network 172.16.100.0 0.0.0.255
network 192.168.101.0
R10#sh ip route eigrp
192.168.101.0/24 is variably subnetted, 2 subnets, 2 masks
D 192.168.101.0/24
[90/130816] via 172.16.100.13, 00:03:39, GigabitEthernet1
So as you can see, I have a route. Let's look at the adjacency.
R10#sh ip eigrp nei
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.100.13 Gi1 11 00:32:47 5 100 0 15
All that is great, but let's verify the SP core.
R1#sh mpls l2transport vc detail | in labels
MPLS VC labels: local 125, remote 32
R1#sh mpls forwarding-table labels 125
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
125 No Label l2ckt(8) 150419 Gi2 point2point
Let's ping mpls and ensure that our LSP is complete.
R1#ping mpls ipv4 192.168.1.6 255.255.255.255
Sending 5, 72-byte MPLS Echos to 192.168.1.6/32,
timeout is 2 seconds, send interval is 0 msec:
Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/11 ms
Total Time Elapsed 25 ms
OK, now that we have tackled that. We know the LSP and pseudowire are working since R10 and R13 are exchanging EIGRP routes with each other. Let's go ahead and migrate R1 to use the "l2vpn" technique. By migrating to the newer "l2vpn" technique we gain the leverage of "Ethernet Flow Point" at the interface level. This will greatly increase our scalability in the future since we aren't tying a service to the interface. The interface is just how customer traffic enters the SP network. The real power comes from the service mappings, where use the "context", whether "xconnect" or "vfi", this allows us to decouple the pseudowire from the interface, and leverage the service instance to match the traffic, the service instance is mapped to the "context" which is then used to bridge the data to the remote PE.
R1
interface GigabitEthernet2
service instance 100 ethernet
encapsulation default
!
interface pseudowire100
encapsulation mpls
neighbor 192.168.1.6 100
!
l2vpn xconnect context PORT
member pseudowire100
member GigabitEthernet2 service-instance 100
R1#show l2vpn atom vc
Service
Interface Peer ID VC ID Type Name Status
--------- ------- ----- ----------- ------
pw100 192.168.1.6 100 p2p PORT UP
R1#show l2vpn atom vc detail | in label
Last label FSM state change time: 00:05:49
Output interface: Gi1.115, imposed label stack {24504 32}
SSO Descriptor: 192.168.1.6/100, local label: 105
Local label indicates that R1 will allocate label 105 for the l2ckt which will have a next hop of P2P
R1#show mpls forwarding-table labels 105
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
105 No Label l2ckt(8) 20973 Gi2 point2point
The "imposed label stack" is 24504 and 32, 24504 is used to reach 192.168.1.6 and 32 is the local label that R6 allocated to the l2ckt with a next hop of P2P. On R1, you'll see that local label 108 is allocated for the 192.168.1.6/32 prefix with an outgoing label of 24504 towards XR5.
R1#show mpls forwarding-table labels 108
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
108 24208 192.168.1.6/32 0 Gi1.112 10.1.12.12
24504 192.168.1.6/32 0 Gi1.115 10.1.15.15
R6#sh mpls forwarding-table labels 32
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
32 No Label l2ckt(1) 47489 Gi2 point2point
More important than being able to get the pseudowire up is to make sure you can verify all is well. The reason being, in this lab, we only have one P2P L2VPN created. In a real network, there could be hundreds or more. Being able to verify that a particular service instance. One thing I have used in production with this technique is the "description" capability under the "service instance" on the interface. This can be useful if leveraged.
R6
interface GigabitEthernet2
service instance 100 ethernet
description Customer_TEST_PW_R6_TO_R1
As we move forward with L2 VPNs, we will solely work with the "l2vpn" syntax. There isn't a reason, beyond a lack of support in software, that we would need to leverage the "xconnect" configuration.
No comments:
Post a Comment