[j-nsp] Junos Arp Expiration Timer Behavior & Active Flows
robert at raszuk.net
Sat Jan 12 12:24:22 EST 2019
> as opposed to normal ARP behaviour where ARP is only
> resolved where there is a packet going to 203.0.113.1.
In correctly constructed ISP grade routers FIB data plane is build
regardless of packets going
through the router or not. So it is actually control plane driven to build
MAC rewrites at the FIB
adj. level regardless if your hardware supports flat or hierarchical FIB.
/* Of course this may not be the case for flow based routers like SRX or
some x86 cheap hacks, but
those should be just a minor exception. */
PS. Did you ever wonder why it is recommended to type in next hop address
static route pointing to say a class C LAN ? Well if you would not give the
nh and instead
say just specify the outbound interface poor router when building the MAC
have to try to resolve IP to MAC for all 254 possible hosts on it :)
On Sat, Jan 12, 2019 at 6:00 PM Alexander Arseniev via juniper-nsp <
juniper-nsp at puck.nether.net> wrote:
> Few more ARP tidbits for You:
> 1/ JUNOS learns ARP not only from responses but from requests as well -
> this is according to RFC 826 "Packet reception" chapter (ARP opcode is
> examined AFTER the xlation table is updated). Therefore, You may see
> that ARP entry for the remote node is regularly refreshed on local node
> without any ARP requests being sent out from that local node. This could
> happen if the ARP randomized aging timers or clocks are different - and
> they normally are if only by a small amount.
> 2/ changing ARP aging-time does not take effect immediately, You need to
> wait until current entry ages out or clear it with CLI command.
> 3/ if You configure a static /32 route to with destination == nexthop -
> like set routing-options static route 203.0.113.1/32 next-hop
> 203.0.113.1, which is a valid route in JUNOS and 203.0.113.1 must be
> directly connected - then the ARP entry for 203.0.113.1 is maintained by
> JUNOS in accordance with configured (or default) ARP aging timers
> without any traffic going to 203.0.113.1 as opposed to normal ARP
> behaviour where ARP is only resolved where there is a packet going to
> On 11/01/2019 16:50, Clarke Morledge wrote:
> > According to KB19396, "the Address Resolution Protocol (ARP)
> > expiration timer does not refresh even if there is an active traffic
> > flow in the router. This is the default behavior of all routers
> > running Junos OS." The default timer is 20 minutes. I have confirmed
> > this behavior on the MX platform.
> > This does not seem very intuitive, as it suggests that a Junos device
> > at L3 would stop in the middle of an active flow, to send an ARP
> > request to try to refresh its ARP cache, potentially causing some
> > unnecessary queuing of traffic, while the Junos device waits for ARP
> > resolution. For an active flow, the ARP response should come back
> > quick, but still it seems unnecessary.
> > I would have thought that the ARP cache would only start to decrement
> > the expiration timer, when the device was not seeing any traffic
> > to/from ARP entry host.
> > KB19396 goes onto say, "When the ARP timer reaches 20 (+/- 25%)
> > minutes, the router will initiate an ARP request for that entry to
> > check that the host is still alive." I can see that when the ARP timer
> > is started initially, that it starts the expiration countdown, at this
> > (+/- 25%) value, and not exactly at, say, 20 minutes, which is the
> > default timer value.
> > A couple of questions:
> > (a) Is this default behavior across all Junos platforms, including MX,
> > SRX, and EX?
> > (b) Is there any other caveat as to when the Junos device will send
> > out the ARP request, at the end of expiration period?
> > Clarke Morledge
> > College of William and Mary
> > Information Technology - Network Engineering
> > Jones Hall (Room 18)
> > 200 Ukrop Way
> > Williamsburg VA 23187
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> juniper-nsp mailing list juniper-nsp at puck.nether.net
More information about the juniper-nsp