[j-nsp] Junos 12.3 MX-80 arp on unnumbered interface buggy

Jack Bates jbates at brightok.net
Sat May 18 01:07:04 EDT 2013


As you can see below. The first clear arp hostname I do, it immediately re-requests the arp.
It's like a reset. If the request fails or if I issue the clear arp hostname command a
second time, the arp entry is deleted. The router will not issue any more arps unless I
delete and readd the static host route, or if a arp request comes from the client. When an arp entry
expires, it also issues an arp request to refresh it.

While I was working with a demux in this case, I also changed it to talking directly
on the unnumbered interface without demux. Same results. Also, client packets aren't enough to re-establish
the arp entry. It MUST be an arp request from the client. If arp was already cached on the client,
pings would timeout. Once the router's arp entry was deleted on the client, the client sends an arp
request and the router automatically cached the client when it does an arp response.

Overall, it does work. You can clear the entry once if need be. Just don't do it twice. Odds are, if
the client isn't online when the arp cache times out and refreshes, the client will probably issue an arp
request itself upon coming back online (though no guarantees).

I haven't tried older codes. Currently running this through support, as it looks like a hack done to
the code (based on the refresh on the first clear) rather than proper arp handling. It's problematic for
layouts that have manually configured statics spread across unnumbered vlans. Untested yet, but it could also have issues
with dhcp clients that you can't insert the dhcp mac into the table due to the clients doing proxy-arp for
data traffic, but not for dhcp (ie, you have to arp to get the proxy-arp address). Since the dhcp server
still puts a host route in the table, I suspect the rules apply the same as above, just with dynamic routes.

jbates at lab-mx80# show route 192.168.83.6/32
qualified-next-hop demux0.84;


jbates at lab-mx80# activate route 192.168.83.6/32

[edit routing-options static]
jbates at lab-mx80# commit
commit complete

<wireshark on client>
11204	20694.267999	JuniperN_0b:fb:c0	Broadcast	ARP	60	Who has 192.168.83.6?  Tell
192.168.83.1
11205	20694.268025	Dell_8a:94:5a	JuniperN_0b:fb:c0	ARP	42	192.168.83.6 is at
d4:be:d9:8a:94:5a

jbates at lab-mx80# run clear arp hostname 192.168.83.6

<wireshark on client>
11301	20883.937639	JuniperN_0b:fb:c0	Broadcast	ARP	60	Who has 192.168.83.6?  Tell
192.168.83.1
11302	20883.937659	Dell_8a:94:5a	JuniperN_0b:fb:c0	ARP	42	192.168.83.6 is at
d4:be:d9:8a:94:5a

[edit routing-options static]
jbates at lab-mx80# run clear arp hostname 192.168.83.6
192.168.83.6     deleted

<nothing on wireshark capture>

[edit routing-options static]
jbates at lab-mx80# run ping 192.168.83.6
PING 192.168.83.6 (192.168.83.6): 56 data bytes
^C
--- 192.168.83.6 ping statistics ---
8 packets transmitted, 0 packets received, 100% packet loss

[edit routing-options static]
jbates at lab-mx80# run show arp no-resolve | match 192.168.83.6

[edit routing-options static]

[edit routing-options static]
jbates at lab-mx80# deactivate route 192.168.83.6/32

[edit routing-options static]
jbates at lab-mx80# commit
commit complete

[edit routing-options static]
jbates at lab-mx80# activate route 192.168.83.6/32

[edit routing-options static]
jbates at lab-mx80# commit
commit complete

<wireshark on client>
11402	21067.146859	JuniperN_0b:fb:c0	Broadcast	ARP	60	Who has 192.168.83.6?  Tell
192.168.83.1
11403	21067.146880	Dell_8a:94:5a	JuniperN_0b:fb:c0	ARP	42	192.168.83.6 is at
d4:be:d9:8a:94:5a

[edit routing-options static]
jbates at lab-mx80# run show arp no-resolve | match 192.168.83.6
d4:be:d9:8a:94:5a 192.168.83.6    demux0.84            none





More information about the juniper-nsp mailing list