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@lab-mx80# show route 192.168.83.6/32 qualified-next-hop demux0.84; jbates@lab-mx80# activate route 192.168.83.6/32 [edit routing-options static] jbates@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@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@lab-mx80# run clear arp hostname 192.168.83.6 192.168.83.6 deleted <nothing on wireshark capture> [edit routing-options static] jbates@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@lab-mx80# run show arp no-resolve | match 192.168.83.6 [edit routing-options static] [edit routing-options static] jbates@lab-mx80# deactivate route 192.168.83.6/32 [edit routing-options static] jbates@lab-mx80# commit commit complete [edit routing-options static] jbates@lab-mx80# activate route 192.168.83.6/32 [edit routing-options static] jbates@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@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 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
