Junos OS

 View Only
last person joined: yesterday 

Ask questions and share experiences about Junos OS.
  • 1.  Somehow limit ARP

    Posted 10-18-2022 11:18

    Some time ago we changed from CISCO to JUNIPER MX204. Many top people recommend this solution, so why not.
    And the config is almost similar to vyatta - so it can't be wrong. :) 

    Setup is simple - two physical routers (mx204) connected and between them each vlan in VRRP and one floating IP, which is a gateway for devices in a given vlan.

    Migrate was almost painless, the only thing we are facing now is a huge amount of ARP requests in the network causing lag at the ends and other strange situations.
    Which we have not experienced at CISCO.

    from one medium used vlan in which there are 3 classes /22 and one /20 = ~7100 IPs - not all of them are active 24 hours a day
    We had 250 kBps and 3800 pps traffic only ARP during business hours from 9AM to 10AM (One hour sample only).

    Default arp policer throws numbers like crazy

    admin@r1> show policer | match arp | refresh 5
    __default_arp_policer__                      398845035318           8670941793
    __default_arp_policer__                      398845116376           8670943555
    __default_arp_policer__                      398845133488           8670943927

    so I added separate rules per vlan with limit at 1M on time collecting statistics to match specific values.

    policer arp_nolimit {
     if-exceeding {
       bandwidth-limit 1m;
       burst-size-limit 1m;

    In this I got rid of the suddenly disappearing ARP, but there are still too many of them.

    While the world scans the aforementioned classes for a given IP, one router can ask itself 3 times - from each router. A total of 6 inquiries in 1 second.
    Within 1 minute of these queries, there are already 15 queries - and all this for only one IP. 
    Now from one vlan for the entire subnet, at one minute only for one router these queries are: 18 063 from the second, a little more: 25 844

    Is there an option/method that once asked  IP it will be in the "memory" for X time and when someone asks for it (during this time) again, they will get an answer immediately. And he wasn't sending out an ARP who-has request again. Only after this time did he send out an ARP who-has again and store it.
    The time also could not be too long, so that suddenly after inactivity an active IP appeared, it would be immediately noticed.

    What I currently have set up for ARP is only

        arp {
            aging-timer 240;

    rest is by default.

    Can I count on a little help and show which way to go? :)

    #ARP ,#MX204


    Krystian Trapszo

  • 2.  RE: Somehow limit ARP

    Posted 10-23-2022 13:13
    So, in your example VLAN, you have almost a /19 subnet, totalling 7100 hosts, and that's a midium sized VLAN? Unless you run this as a BNG, this sounds like a stretch far beyond any logic. Creating more VLANs would be one way to go. Are you sure those volumes of scans were present when you had the Cisco router or can this be something new? What about blocking the scan traffic? Perhaps the Cisco didn't cope with the amount of scans and couldn't send ARPs as fast as the MXes do?
    Setting arp passive-learning may improve things a bit:

  • 3.  RE: Somehow limit ARP

    Posted 10-24-2022 06:25

    Hi @fb35523
    Thanks for your answer.

    Yep, that a midium sized VLAN. 
    That is efect of many yers ignoring resizing VLANs, so now we have a  such a corpse in the closet, where he began to cause problems. :)

    Yes. I am sure that volume traffic of scans are the same where we had CISCO.  I suspect that the previous CISCO was a bit of an old type C68xx so due to the lack of resources, he  simply did not accept more and DROP randomly and since it was so imperceptible, no one paid any attention to it.
    It could be as you write that now MX is faster and transfers everything without problem.

    I know that we have to divide it into smaller VLANs and it is happening, but we are trying to do something for now, because it implies problems on LINUX servers, where too many ARP requests (who-has) respond later than usual, and this is sometimes the result of a message from the network stack "No route to host".

    enabling passive-learning, unfortunately, will not help much, because the traffic is distributed between the routers and, as a result, both have a comparable ARP table

    r1 > show arp no-resolve | count
    Count: 7885 lines
    r2 > show arp no-resolve| count
    Count: 7269 lines

    any other sugestion? :)

    Krystian Trapszo