Re: [j-nsp] Junos Arp Expiration Timer Behavior & Active Flows
Thanks, Brian. Unfortunately, the MX policer is not granular enough to trim down the unwanted traffic enough, in one particular use case that I am dealing with. Excessive ARPs can easily overwhelm some downstream hosts, some more than others. Clarke Morledge College of William and Mary ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos Arp Expiration Timer Behavior & Active Flows
I put a policier on the upstream connection firewall of the sort
policer traceroute-limit {
if-exceeding {
bandwidth-limit 2k;
burst-size-limit 1500;
}
then discard;
}
You might want to tweak this some. I can't remember why I chose these
values.
This tends to take care of most of the ARP problems. Academia is a
normal target for network researchers with little regard for others
networks.
Brian Nelson
--
Supervisor
Computing Systems Support
Dept of Computer Science
On 01/17/2019 10:48 AM, Clarke Morledge wrote:
> Thank you for the responses folks.
>
> I am trying to figure out a way to cut down on ARP traffic, particularly
> resulting from continued sweeps/scans running across our IP space from the
> InterWebs, particularly for IPs that are currently not in use.
>
> Simply jacking up the ARP aging-timer is not a completely trustworthy
> solution, since if you change the MAC address for a downstream host, the
> upstream router has to timeout its ARP entry before it learns the new
> downstream MAC... assuming the new downstream MAC does not do an ARP
> request of its own, right away.
>
> Has anyone worked with the ARP Cache Protection feature, release in 16.1?
> I was hoping to try to get this to work for me, but I am having a
> difficult time wrapping my head around the arp-new-hold-limit knob, and
> how it is supposed to work.
>
> https://www.juniper.net/documentation/en_US/junos/topics/example/example-arp-cache-protection-configuring.html
>
> It seems like the feature is designed more to protect the router from DDoS
> attacks, and not so much protecting downstream nodes from bogus ARP
> traffic.
>
> 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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos Arp Expiration Timer Behavior & Active Flows
Thank you for the responses folks. I am trying to figure out a way to cut down on ARP traffic, particularly resulting from continued sweeps/scans running across our IP space from the InterWebs, particularly for IPs that are currently not in use. Simply jacking up the ARP aging-timer is not a completely trustworthy solution, since if you change the MAC address for a downstream host, the upstream router has to timeout its ARP entry before it learns the new downstream MAC... assuming the new downstream MAC does not do an ARP request of its own, right away. Has anyone worked with the ARP Cache Protection feature, release in 16.1? I was hoping to try to get this to work for me, but I am having a difficult time wrapping my head around the arp-new-hold-limit knob, and how it is supposed to work. https://www.juniper.net/documentation/en_US/junos/topics/example/example-arp-cache-protection-configuring.html It seems like the feature is designed more to protect the router from DDoS attacks, and not so much protecting downstream nodes from bogus ARP traffic. 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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos Arp Expiration Timer Behavior & Active Flows
>From what I understand the router will not delete the arp entry immediately after it expired so it will not queue/drop the packet Take a look on this output where the arp is expired you the entry is kept without expiration time for few seconds until the other side answer to the arp nitzan@ROUTER> show arp no-resolve expiration-time | match 10.10.3.58 00:02:ff:10:44:7c 10.10.3.58 ae0.21 none 1 nitzan@ROUTER> show arp no-resolve expiration-time | match 10.10.3.58 00:02:ff:10:44:7c 10.10.3.58 ae0.21none nitzan@ROUTER> show arp no-resolve expiration-time | match 10.10.3.58 00:02:ff:10:44:7c 10.10.3.58 ae0.21none 90 Nitzan On Fri, Jan 11, 2019 at 6:51 PM 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@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos Arp Expiration Timer Behavior & Active Flows
On 11-Jan-19 17:50, Clarke Morledge wrote: A couple of questions: (a) Is this default behavior across all Junos platforms, including MX, SRX, and EX? I would expect so. What is also possible in this case is to configure huge arp timeout: set system arp interfaces xe-1/1/0 aging-timer ? Possible completions: Change the ARP aging time value (1..60 minutes) that's 400+ days. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos Arp Expiration Timer Behavior & Active Flows
Hi Alex, > 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. */ Thx, R. PS. Did you ever wonder why it is recommended to type in next hop address when adding 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 rewrites would 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@puck.nether.net> wrote: > Hello, > > 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 > 203.0.113.1. > > HTH > > Thx > Alex > > 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@puck.nether.net > > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos Arp Expiration Timer Behavior & Active Flows
Hello, 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 203.0.113.1. HTH Thx Alex 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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
