IOS XE 15.5
IOS XR 5.3
The topology for this demo:
In the last post we took at port mode, or Ethernet mode for EoMPLS which allowed only one subnet to be bridged over the MPLS core. We'll take a look at the VLAN or subinterface variation now. This follows a very similar construct, the difference is that on the PE and the CE we configure 802.1Q Subinterfaes as the AC or attachment circuit. This is common where we need to configure multiple customers on a single interface. When we map the AC configuration to a PW statement, that ties the two together over the core and get's us reachability. We'll configure this with the 2 different methods, the older "xconnect" style and then the newer "L2VPN Protocol CLI" style.
On the connection from R3 to R6 we will configure R8 and R10 for reachability. We'll more than likely only use the L2VPN protocol CLI moving forward, where it make sense anyways.
Let's get the interfaces setup first on the PE side, then the CE side.
R3
interface GigabitEthernet3.108
encapsulation dot1Q 108
R6
interface GigabitEthernet2.108
encapsulation dot1Q 108
R8
interface GigabitEthernet1.108
encapsulation dot1Q 108
ip address 10.10.8.8 255.255.255.0
R10
interface GigabitEthernet1.108
encapsulation dot1Q 108
ip address 10.10.8.10 255.255.255.0
Now for R3's legacy xconnect configuration.
R3
pseudowire-class VLAN
encapsulation mpls
interface GigabitEthernet3.108
encapsulation dot1Q 108
xconnect 192.168.1.6 108 encapsulation mpls pw-class VLAN
The "pseudowire-class" is basically a template that you can map to multiple AToM circuits. As you can see under the G3.108 interface, it's very similar to the last post with the exception of the pw-class at the end.
R6
interface pseudowire108
encapsulation mpls
neighbor 192.168.1.3 108
l2vpn xconnect context VLAN
member pseudowire108
member GigabitEthernet2.108
The pseudowire interface is obviously a logical interface to place AToM configuration under, like encapsulation, the neighbor and the VC-ID. The "L2VPN Protocol CLI" is also shown creating a "context" or broadcast domain that ties the pseudowire and AC interface together. After 3-5 minutes of waiting, the console gives us this output:
%LDP-5-NBRCHG: LDP Neighbor 192.168.1.3:0 (3) is UP
So we know it's working. Let's check some verification to make sure.
R6#show l2vpn atom vc vcid 108
Service
Interface Peer ID VC ID Type Name Status
--------- --------------- ---------- ------ ------------------------ ----------
pw108 192.168.1.3 108 p2p VLAN UP
R6#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 mpls 192.168.1.3:108 UP ac Gi2.108:108(Eth VLAN) UP
As you can see from the outputs above, the (Eth VLAN) indicates that we now have an EVC or Ethernet Virtual Circuit.
Let's see R3s side, since we have 2 PWs now.
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 ac Gi2:8(Ethernet) UP mpls 192.168.1.5:79 UP
UP pri ac Gi3.108:108(Eth VLAN) UP mpls 192.168.1.6:108 UP
Focus on the bolded portion, one is a Port based PW the other is a VLAN based PW.
Let's see if R8 and R10 can find each other!
R8#ping 10.10.8.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.8.10, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
R8#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.10.8.8 - 000c.29c9.1f5c ARPA GigabitEthernet1.108
Internet 10.10.8.10 0 000c.2994.b818 ARPA GigabitEthernet1.108
Ok, we see that not only does the ping work, but we see an ARP entry for R10 on R8. Since this is almost the exact same setup as the last post, Port based versus VLAN based in this post, I won't drag you through the same verification of label bindings.
Thanks for stopping by!
Rob Riker, CCIE #50693
No comments:
Post a Comment