IOS XE 15.5
IOS XR 5.3
The topology for this demo:
In this post we will continue on with our manual VPLS configuration using slightly older syntax, the "l2 vfi" variant and not the "l2vpn vfi context" variant. Is there a difference, not really, it really comes down to where you are placing the syntax, the bridge domain is placed at the AC level and the vfi is placed globally. The l2 vfi calls the bridge domain and maps it to the neighbor connections. Very similar to the other variant where we configure the l2vpn vfi context. We will roll this out on R1, R5 and R6. We'll also have R13, R9 and R10 configured with EIGRP to form adjacencies once the VPLS is up and running.
So let's take a look at the configuration breakdown, the service instance is used to map the incoming frames to the bridge domain that calls on the bridge domain. The bridge domain in this case is configured under the interface, the value issued to the bridge domain is configured and then needs to match.
The l2 vfi manual configuration is very similar to the l2vpn vfi context syntax, this way calls the bridge domain and sets the peering information. You can see the "vpn id" is configured, until it is configured, no additional configuration we'll be available. The bridge domain is called upon, which facilitates the mapping of inbound/outbound frames to/from the VFI to the interface where the service instance is placed. Then the neighbor statements are configured. As you can see, very basic, but until these fundamental pieces are covered, advanced configuration won't make sense.
R1
interface g2
service instance 600 ethernet
encapsulation dot1q 600
bridge-domain 600
!
l2 vfi BRIDGE manual
vpn id 600
bridge-domain 600
neighbor 192.168.1.6 encapsulation mpls
neighbor 192.168.1.5 encapsulation mpls
R5
interface g2
service instance 600 ethernet
encapsulation dot1q 600
bridge-domain 600
!
l2 vfi BRIDGE manual
vpn id 600
bridge-domain 600
neighbor 192.168.1.6 encapsulation mpls
neighbor 192.168.1.1 encapsulation mpls
R6
interface g2
service instance 600 ethernet
encapsulation dot1q 600
bridge-domain 600
!
l2 vfi BRIDGE manual
vpn id 600
bridge-domain 600
neighbor 192.168.1.5 encapsulation mpls
neighbor 192.168.1.1 encapsulation mpls
So now that we have all the PEs configured, we'll need to verify the pieces to it.
R5#sh l2vpn atom vc | in 600|400
pw100006 192.168.1.1 600 vfi BRIDGE UP
pw4001 192.168.1.1 4001 p2p 2PE_2CE_2AC_400 UP
pw4002 192.168.1.1 4002 p2p 2PE_2CE_2AC_400 STANDBY
pw100007 192.168.1.6 600 vfi BRIDGE UP
One thing I want to point out that isn't obvious right now, IOS reserves VPLS pseudowire IDs starting at 100000. You can't configure a manual PW with a "100000" value. I knew this, so I intentionally configured EPL/EVPL pws with a lower value. As you can see, pw100006/7 are used to reach R1 and R6 respectively and have the "BRIDGE" name next to them, which is the l2 vfi name given.
R5#show bridge-domain 600
Bridge-domain 600 (3 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
GigabitEthernet2 service instance 600
vfi BRIDGE neighbor 192.168.1.1 600
vfi BRIDGE neighbor 192.168.1.6 600
AED MAC address Policy Tag Age Pseudoport
0 000C.2994.B818 forward dynamic 298 BRIDGE.1004024
1 FFFF.FFFF.FFFF flood static 0 OLIST_PTR:0xe7fd6870
0 000C.2990.89E9 forward dynamic 297 BRIDGE.1004023
0 000C.29BB.45EF forward dynamic 297 GigabitEthernet2.EFP600
We have learned 3 MAC address, 2 of them are from remote peers, IDd with BRIDGE and the G2.EFP600 is local to R5. The MAC learned from G2.EFP600 is R9s interface MAC.
To be fair, VPLS adds dynamic and LAN capabilities to what we have covered with EPL/EVPL. The PWs are just mapped to a bridge domain that allows flooding of MAC addresses. There is a scaling issue that is inherited with this since all the PEs need to be fully meshed with each other. H-VPLS lightens the Full Mesh requirement and acts like a BGP Route Reflector, not exactly, but loosely.
R5#show l2vpn atom vc vcid 600 detail | in label
Last label FSM state change time: 01:31:31
Output interface: Gi1.45, imposed label stack {39 44}
SSO Descriptor: 192.168.1.1/600, local label: 537
R5#show mpls forwarding-table labels 526
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
526 39 192.168.1.1/32 9838325 Gi1.45 10.4.5.4
24609 192.168.1.1/32 19417288 Gi1.165 10.16.5.16
R5#show mpls forwarding-table labels 537
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
537 No Label l2ckt(32) 155738 none point2point
Label 39 is used to reach R1. Label 537 is used by the PW to reach R1 via the tLDP session. Label 44 is used by R1 to reach R5.
R5#show l2vpn atom vc vcid 600 detail | in label
Last label FSM state change time: 01:31:31
Output interface: Gi1.56, imposed label stack {25}
SSO Descriptor: 192.168.1.6/600, local label: 538
R5#show mpls forwarding-table labels 538
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
538 No Label l2ckt(33) 150927 none point2point
Label 25 is used by R6 to reach R5 over the tLDP PW connection. Label 538 is used by R5 to reach R6 over the tLDP PW connection. Since R5 and R6 are directly connected, LDP labels are not used, as implicit null is advertised (no label).
We have verified the PE configuration is working, now let's check out the CE configuration.
R13#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.60.10 Gi2.600 11 01:40:10 227 1362 0 190
7 192.168.60.9 Gi2.600 11 01:40:26 5 100 0 35
There are multiple EIGRP paths in the RIB. I won't add them in as there are routes in the RIB from previous posts. Nice thing is we still have connectivity!
Thanks for stopping by!
Rob Riker, CCIE #50693
No comments:
Post a Comment