ARP issues when using ldpd(8) and mpw(4)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

ARP issues when using ldpd(8) and mpw(4)

Adrian Close-2
Hi,

I'm having some issues getting an mpw(4) MPLS "pseudowire" setup working
reliably and it seems to come down to ARP issues between my "PE" and "P"
boxes that occur when ldpd(8) thinks the pseudowire l2vpn tunnels are
actually up.

My setup looks something like:

   [cust L2] - [em0]PE1[em1] -- [em0]P1[em1] -- [em1]P2[em0] --
[em1][PE2][em0] - [cust L2]

... the idea being to provide a layer 2 circuit between the "cust L2"
ports, over an MPLS network, which I've configured along the lines of
Claudio's "Demystifying MPLS" paper and Renato's "VPLS basic test
setup", using LDP and OSPF.  This all works fine, except when it doesn't:

So for example, when the ARP entry on the PE1 box for P1's em0 IP
address times out (or is manually deleted), PE1 sends out ARP requests
not for that IP address, but for the loopback address of its pseudowire
peer PE2.

It generally does this for about 40 seconds, and then finally sends an
ARP request for the correct IP, which is answered straight away and
things work again until next time.

If ldpd(8) thinks the l2vpn tunnels are down ("ldpctl show l2vpn
pseudowires"), ARP requests are sent normally and work as expected.


I've tried this with 6.2 and 6.3 releases with the same result. Does
anyone have any ideas on how I can get ARP to behave reliably in this
scenario?

Thanks,

Adrian Close

Reply | Threaded
Open this post in threaded view
|

Re: ARP issues when using ldpd(8) and mpw(4)

Adrian Close-2
Hi all,

Just replying to myself for the sake of completeness and anyone else
searching the list archive.

Le 06/04/2018 10:55, Adrian Close a écrit :
> I'm having some issues getting an mpw(4) MPLS "pseudowire" setup
> working reliably and it seems to come down to ARP issues between my
> "PE" and "P" boxes that occur when ldpd(8) thinks the pseudowire l2vpn
> tunnels are actually up
This is now fixed in the current snapshot, thanks to dlg@.

Adrian