cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
441
Views
0
Helpful
1
Replies

H-vpls N-Pe-redundancy configured but no macs being forwarded

DaddyGoat
Level 1
Level 1

Summary

I am attempting H-vpls n-pe redudantcy (https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l2_vpns/configuration/xe-16/mp-l2-vpns-xe-16-book/h-vpls-n-pe-redundancy-for-mpls-access.html). I have my control plane up / xconnects up but my macs are not being forwarded from my UPE to N-PE bridge-domain or the other UPE. I also have split-horizon disabled from N-PE going to U-PE on both ends however the Macs are not being shared. Wiresharks captures are not showing any l2traffic when I attempt to ping end-to-end. I also tried a few debugs trying to catch any errors or events in my logs but no luck in identifying why my traffic is not being forwarded from UPE to N-PE.

Procedure

1. Traffic comes from AID_J_Parts_department via a tagged sub interface to Gi 1 on the West-UPE service instance 700
2. Mac is stored in bridge-domain 700.
3. Xconnect forwards traffic via vfi to R3 and R4 with R3 being the active PE and R4 standby
4. Mpls is done with ldp neighbors R1 and R2
5. R1 Forwards traffic via vfi to East UPE gi2
6. East UPE forwards traffic from R1 to AID_BH_Parts_department

 

Here are some troubleshooting I did below.

AID_J_Parts_Dept#show run int gi 0/0.700
Building configuration...
 
Current configuration : 121 bytes
!
interface GigabitEthernet0/0.700
 encapsulation dot1Q 700
 ip address 192.168.1.1 255.255.255.0
 ip ospf 1 area 0
end
 
AID_J_Parts_Dept#show int gi 0/0.700 | inc bia
  Hardware is iGbE, address is 5254.0005.4e3d (bia 5254.0005.4e3d)
 
West-UPE#show run int gi 1
 
interface GigabitEthernet1
 no ip address
 negotiation auto
 cdp enable
 no mop enabled
 no mop sysid
 service instance 700 ethernet
  encapsulation dot1q 700
  bridge-domain 700 split-horizon group 1
 !
end
 
West-UPE#show run int gi 2
Building configuration...
 
Current configuration : 574 bytes
!
interface GigabitEthernet2
 description AID Mgmt
 no ip address
 negotiation auto
 cdp enable
 no mop enabled
 no mop sysid
 service instance 3 ethernet
  description AID Mgmt
  encapsulation dot1q 3
 !
 service instance 100 ethernet
  description ISP-mgmt
  encapsulation dot1q 100
  rewrite ingress tag pop 1 symmetric
  bridge-domain 100
 !
 service instance 700 ethernet
  description AID Parts Department
  encapsulation dot1q 700
  rewrite ingress tag pop 1 symmetric
 
West-UPE#show run | s xconnect
 description L2-xconnect-Loop
l2vpn xconnect context Parts_Department_700
 member GigabitEthernet2 service-instance 700 
 member 30.30.30.30 700 encapsulation mpls group pwred priority 9
 member 40.40.40.40 700 encapsulation mpls group pwred priority 10
 
West-UPE#show isis neighbors 
 
Tag 1:
System Id       Type Interface     IP Address      State Holdtime Circuit Id
R3              L1   BD100         34.34.34.3      UP    26       West-UPE.01        
R3              L2   BD100         34.34.34.3      UP    21       West-UPE.01        
R4              L1   BD100         34.34.34.4      UP    25       West-UPE.01        
R4              L2   BD100         34.34.34.4      UP    25       West-UPE.01        
 
 
West-UPE#show bridge-domain 700
Bridge-domain 700 (1 ports in all)
State: UP                    Mac learning: Enabled
Aging-Timer: 21600 second(s)
Maximum address limit: 65536
1 ports belonging to split-horizon group 1
    GigabitEthernet1 service instance 700 (split-horizon group 1)
   AED MAC address    Policy  Tag       Age  Pseudoport
   0   5254.0005.4E3D forward dynamic   21590 GigabitEthernet1.EFP700
 
 
R3#show mpls l2transport vc 700
 
Local intf     Local circuit              Dest address    VC ID      Status
-------------  -------------------------- --------------- ---------- ----------
VFI Parts_Department_700  \
               vfi                        1.1.1.1         700        UP        
VFI Parts_Department_700  \
               vfi                        10.10.10.10     700        UP        
VFI Parts_Department_700  \
               vfi                        20.20.20.20     700        STANDBY   
VFI Parts_Department_700  \
               vfi                        40.40.40.40     700        UP        
 

I also included the Yaml of the lab I am working on in CML and a snapshot. Any guidance or tips will be greatly appreciated.

1 Accepted Solution

Accepted Solutions

DaddyGoat
Level 1
Level 1

I found a solution in case others encountered the same issue.

The issue was the placement of the x-connect with the command l2vpn x-connect context.


I believe the cisco docs I referenced in the earlier post have an error in the placement of the x-connect.

 

 




The xconnect is not facing the N-PES but instead on the UPE facing the customer side. It looks like the x-connect forwards the mac-address to the bridge-domain on the NPEs who then referenced the vfi and forward it to its peers

No macs will show on the upe in this solution. They instead are on the N-PES.

Heres the command facing the CPE on the UPE
interface GigabitEthernet1
no ip address
negotiation auto
no mop enabled
no mop sysid
service instance 700 ethernet
encapsulation dot1q 700
rewrite ingress tag pop 1 symmetric

Here's the correct x-connect statement on the UPE with the member facing the CPE and the member ip address facing PE 3 and PE4 in the diagram above.
l2vpn xconnect context Parts_Department_700
remote link failure notification
member GigabitEthernet1 service-instance 700
member 30.30.30.30 700 encapsulation mpls group pwred priority 9
member 40.40.40.40 700 encapsulation mpls group pwred priority 10

Here's the configs on the NPE

NPE config
l2vpn vfi context Parts_Department_700
vpn id 700
member 20.20.20.20 encapsulation mpls (Sends targeted hello to PE2)
member 40.40.40.40 encapsulation mpls (Sends targeted hello to PE4)
member 10.10.10.10 encapsulation mpls (Sends targeted hello to PE1)
bridge-domain 700
member vfi Parts_Department_700 (tells the PE to foward mac to UPE. Automatically disables split-horizon to UPE)
member 1.1.1.1 700 encapsulation mpls (tells the PE who is the UPE to foward the mac in bridge-domain 700 to)

Don't forget to create the bridge which is needed on the PE to store the macs

Also cisco docs don't reference your interfaces between your UPE and NPE connections will be layer 2. Since they are layer 2 they wont have any ip addresses. You can instead create a bdi interface tag it with a dot1q and put an ip address on it. Make sure its in the same subnet as your NPEs (think management vlan scenario) then have then form an igp and mpls neighborship. This ensure you have a lsp path between your upes through your core network. Repeat this for your other devices. 

Troubleshooting can be done like this.

On your upe you should have 2 x-connect connections. One will always be UP UP (active x-connect) the other (IA segment 1 SB segment 2). 
See example below

West-UPE#show xconnect peer 40.40.40.40 vcid 700
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
------+---------------------------------+--+---------------------------------+--
IA pri ac Gi1:700(Eth VLAN) UP mpls 40.40.40.40:700 SB

Once you see this your x-connect are up. Check your bridge-domains on your NPEs they should have mac-addresses from their respective upe and if your mpls / vfi peer are setup they will be exchange macs. Example of how your bridge-domain on PEs is below.
R3#show bridge-domain 700
Bridge-domain 700 (4 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
Maximum address limit: 65536
vfi Parts_Department_700 neighbor 10.10.10.10 700
vfi Parts_Department_700 neighbor 40.40.40.40 700
vfi Parts_Department_700 neighbor 20.20.20.20 700
vfi Parts_Department_700 neighbor 1.1.1.1 700
AED MAC address Policy Tag Age Pseudoport
0 5254.0019.0BB2 forward dynamic 298 Parts_Department_700.404010 (CPE-1 mac)
0 5254.001A.9796 forward dynamic 297 Parts_Department_700.404013 (CPE-2 mac)




You should now have reachable between CPES. If not make sure you have the command rewrite ingress tag pop 1 symmetric on every interface your packet will travel. 

Finally, to test if you have redundancy you can simulate a scenario where a PE goes down. Start a ping between the CPES ensure it is successfully reaching end to end. Then check the x-connect status between UPEs and their respective PEs. One x-connect will be in standby (SB) (use the command show x-connect peer ip address vcid #). Shutdown the x-connect that is active by shutting down all the interfaces. Check the upe x-connect status and you'll see the standby x-connect turns up. Your CPE should be able to ping the other cpe again. You can even stimulate a total loss of a PE with the command interface rang gig1-4,loo0. You should see a very quick automatic switchover. The amazing thing about this feature too is if you no shut the interfaces on the PE you shut down (stimulating the PE recovering ) the x-connect will detect this and switch to the x-connect with the lowest number.

 

View solution in original post

1 Reply 1

DaddyGoat
Level 1
Level 1

I found a solution in case others encountered the same issue.

The issue was the placement of the x-connect with the command l2vpn x-connect context.


I believe the cisco docs I referenced in the earlier post have an error in the placement of the x-connect.

 

 




The xconnect is not facing the N-PES but instead on the UPE facing the customer side. It looks like the x-connect forwards the mac-address to the bridge-domain on the NPEs who then referenced the vfi and forward it to its peers

No macs will show on the upe in this solution. They instead are on the N-PES.

Heres the command facing the CPE on the UPE
interface GigabitEthernet1
no ip address
negotiation auto
no mop enabled
no mop sysid
service instance 700 ethernet
encapsulation dot1q 700
rewrite ingress tag pop 1 symmetric

Here's the correct x-connect statement on the UPE with the member facing the CPE and the member ip address facing PE 3 and PE4 in the diagram above.
l2vpn xconnect context Parts_Department_700
remote link failure notification
member GigabitEthernet1 service-instance 700
member 30.30.30.30 700 encapsulation mpls group pwred priority 9
member 40.40.40.40 700 encapsulation mpls group pwred priority 10

Here's the configs on the NPE

NPE config
l2vpn vfi context Parts_Department_700
vpn id 700
member 20.20.20.20 encapsulation mpls (Sends targeted hello to PE2)
member 40.40.40.40 encapsulation mpls (Sends targeted hello to PE4)
member 10.10.10.10 encapsulation mpls (Sends targeted hello to PE1)
bridge-domain 700
member vfi Parts_Department_700 (tells the PE to foward mac to UPE. Automatically disables split-horizon to UPE)
member 1.1.1.1 700 encapsulation mpls (tells the PE who is the UPE to foward the mac in bridge-domain 700 to)

Don't forget to create the bridge which is needed on the PE to store the macs

Also cisco docs don't reference your interfaces between your UPE and NPE connections will be layer 2. Since they are layer 2 they wont have any ip addresses. You can instead create a bdi interface tag it with a dot1q and put an ip address on it. Make sure its in the same subnet as your NPEs (think management vlan scenario) then have then form an igp and mpls neighborship. This ensure you have a lsp path between your upes through your core network. Repeat this for your other devices. 

Troubleshooting can be done like this.

On your upe you should have 2 x-connect connections. One will always be UP UP (active x-connect) the other (IA segment 1 SB segment 2). 
See example below

West-UPE#show xconnect peer 40.40.40.40 vcid 700
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
------+---------------------------------+--+---------------------------------+--
IA pri ac Gi1:700(Eth VLAN) UP mpls 40.40.40.40:700 SB

Once you see this your x-connect are up. Check your bridge-domains on your NPEs they should have mac-addresses from their respective upe and if your mpls / vfi peer are setup they will be exchange macs. Example of how your bridge-domain on PEs is below.
R3#show bridge-domain 700
Bridge-domain 700 (4 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
Maximum address limit: 65536
vfi Parts_Department_700 neighbor 10.10.10.10 700
vfi Parts_Department_700 neighbor 40.40.40.40 700
vfi Parts_Department_700 neighbor 20.20.20.20 700
vfi Parts_Department_700 neighbor 1.1.1.1 700
AED MAC address Policy Tag Age Pseudoport
0 5254.0019.0BB2 forward dynamic 298 Parts_Department_700.404010 (CPE-1 mac)
0 5254.001A.9796 forward dynamic 297 Parts_Department_700.404013 (CPE-2 mac)




You should now have reachable between CPES. If not make sure you have the command rewrite ingress tag pop 1 symmetric on every interface your packet will travel. 

Finally, to test if you have redundancy you can simulate a scenario where a PE goes down. Start a ping between the CPES ensure it is successfully reaching end to end. Then check the x-connect status between UPEs and their respective PEs. One x-connect will be in standby (SB) (use the command show x-connect peer ip address vcid #). Shutdown the x-connect that is active by shutting down all the interfaces. Check the upe x-connect status and you'll see the standby x-connect turns up. Your CPE should be able to ping the other cpe again. You can even stimulate a total loss of a PE with the command interface rang gig1-4,loo0. You should see a very quick automatic switchover. The amazing thing about this feature too is if you no shut the interfaces on the PE you shut down (stimulating the PE recovering ) the x-connect will detect this and switch to the x-connect with the lowest number.