How is ARP resolution done between L2transport interfaces through xconnect session?

[Vadym Belyayev]

Hello guys,

I am trying to understand how ARP resolution works at an intermediate router which builds xconnect point-to-point session between a router that sends untagged traffic on one side and another one sending tagged traffic on the other.. Both edge routers cannot resolve ARP to ping each other..

The config I took from the cisco website from this article

http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-routers/116453-technote-ios-xr-l2vpn-00.html

3.1.2 Subinterfaces and VLAN Manipulation

I have the following topology attached

The config is:

R1---gi0/0/0/0-----------untagged---------------gi0/0/0/0---R2---git0/0/0/1-------------tagged------------------gi0/0/0/0---R3

It should work like this:

1) R1 sends untagged frame to R2

2) R2 should check the tcam to find the corresponding subinterface or interface to match the frame

3) When R2 finds that this subint corresponds to xconnect session:

l2vpn
 xconnect group test
  p2p p2pGrupo
   interface GigabitEthernet0/0/0/0.1
   interface GigabitEthernet0/0/0/1.2

4) R2 should then tag the frame with ID of 2 and send it to R3

encapsulation dot1q 2
 rewrite ingress tag pop 1 symmetric

5) When the answer is coming back from R3, it is coming tagged, the R2 based on "rewrite ingress tag pop 1 symmetric" shoul pop the tag and send it untagged to R1... But this does not happen..

6) When pinging from R1 to R3 o viceverca, both of these routers never get an ARP reply and therefore cannot build a L2 frame

7) Before I had the xconnect session in Down state (because I did the lab the same way it was on Cisco website, but I think there is an error there. I built an xconnect session on R2 between R2´s Gi0/0/0/0 interface and G0/0/0/1.2 subint.. It did not establish the xconnect session.. Dont know why. After I configured xconnect between 2 subinterfaces, the xconnect session worked, but the frames still don´t go through..

Any advice on this issue?

R1

interface GigabitEthernet0/0/0/0
 cdp
 ipv4 address 10.1.1.1 255.255.255.0

R2

interface GigabitEthernet0/0/0/0
!
interface GigabitEthernet0/0/0/0.1 l2transport
!
interface GigabitEthernet0/0/0/1
!
interface GigabitEthernet0/0/0/1.2 l2transport
 encapsulation dot1q 2
 rewrite ingress tag pop 1 symmetric
!
l2vpn
 xconnect group test
  p2p p2pGrupo
   interface GigabitEthernet0/0/0/0.1
   interface GigabitEthernet0/0/0/1.2

R3

interface GigabitEthernet0/0/0/1
!
interface GigabitEthernet0/0/0/1.2
 ipv4 address 10.1.1.2 255.255.255.0
 encapsulation dot1q 2

[Aleksandar Vidakovic]

hi Vadym,

you have two choices to fix this on R2:

[1] declare GigabitEthernet0/0/0/0 as l2transport and put it into p2p p2pGrupo (instead of the .1 sub-interface)

[2] specify encapsulation untagged on GigabitEthernet0/0/0/0.1

hope this helps,

Aleksandar

[Vadym Belyayev]

Alesk,

Thanks for your reply.

I tried it previously and I had this result

XConnect                   Segment 1                       Segment 2
Group      Name       ST   Description            ST       Description            ST
------------------------   -----------------------------   -----------------------------
test       p2pGrupo   DN   Gi0/0/0/0              DN       Gi0/0/0/1.2            DN
---------------------------------------------------------------------------------------

My xconnect was down and I thought I could not do xconnect between a physical interface and subinterface.

Configuring it like this

interface GigabitEthernet0/0/0/0

interface GigabitEthernet0/0/0/0.1 l2transport

encapsulation untagged

Does not work either...

[Aleksandar Vidakovic]

Can you attach the output of "sh l2vpn xconnect group <name> xc-name <name> private"?

[takao.nakamaru]

Sorry to intrude, we have a similar question (again regarding arp resolution between L2 interfaces) but for a different topology for which we try to find the expected behaviour of ASR9k.

In our setup we have dual Asr9k / mlacp, connecting the DSLAMs / switches. For a particular service the subscribers traffic is DHCPv4 / IPoE (but without sessions or BNG functionality) and all DSLAM interfaces participate in a single bridge-domain. For redundancy each switch is connected to both ASR9K and using mlacp the path though one ASR9K is active (on per switch basis)

We try to find a setup that ensures the following:
That we offer redundancy (this is why we plan to have VRRP and Mlacp between the ASR9k_A, ASR9K_B)
Make sure that no direct L2 connectivity is offered between the DSLAM through the ASR9k_A and ASR9K_B.

============================================================================================================================================

In each ASR9k use a bridge domain and have split-horizon activated on the DSLAM facing interfaces. We plan to create an xconnect between the 2 ASR9K (for VRRP and ARP traffic)

We were wondering about the arp behaviour over this xconnect circuit (no split horizon for the xconnect).

Specifically if for VRRP the master is ASR9K_A and due connectivity problem in the interface ASR9k_A <=> SW_B the link ASR9k_B <=> SW_B is active for SW_B

- For upstream traffic in SW_B, the arp requests will need to be answered by the VRRP master (ASR9K_A) so ASR9K_B will have to forward this request through the xconnect to ASR9K_A

- For downstream towards SW_B, traffic arrives at ASR9K_A and using ARP, ASR9K_A must find the correspoing MAC address Again this ARP request will have to forwarded over the xconnect (since the interface ASR9k_A <=> SW_B is down)

With this setup we expect to have redundancy but we no longer have L2 isolation between DSLAMs /switches  (through the xconnect all broadcast will be forwarded between Switches SW_A and SW_B)

Is there a way to overcome this problem (have ARP Resolution working but also ensure L2 isolation between subscribers) We are thinking interworking ipv4 for the xconnect circuit but we are not sure about its behavior for ARP requests. (Also we cannot use a separate L3 interface per Switches / DSLAMs since we need a single DHCP pool for all DSLAMs)

[Aleksandar Vidakovic]

hi Takao,

if you want to run VRRP between the two asr9k, you should let the VRRP hello packets be exchanged through the access network. I would eliminate  the xconnect and MCLAG from your topology. I would instead convert all the four DSLAM-facing links into l2transport and configure a bridge domain with BVI on both asr9k. You can then run VRRP on BVI.

If your ARP scale exceeds 128k, please make sure to follow the best practices from this document:

https://supportforums.cisco.com/document/12766486/troubleshooting-arp-asr9000-routers

I hope this helps.

regards,

/Aleksandar

[Vadym Belyayev]

Sorry, I have been extremele busy lately, dedicating all my time to another project..One of these days I will get back to l2vpn lab and post the output