Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?
Hi, If you use the MX as subscriber access dhcp server/relay it will populate the host routes(access-internal) and arp entries automatically upon dhcp negotiation. In that setup usually the ethernet interface(segment) is unnumbered and only /32 host routes to subscribers are installed - no network route with rsvl next-hop in PFE. Traffic to unused IP address space would be silently dropped. Best Regards, Krasi On Fri, 1 Feb 2019 at 01:32, Clarke Morledge wrote: > Thank you for the input thus far, folks. > > Let me explain just a bit more about what I am dealing with. Because we > get so much garbage scanning, if the scanner tries to hit an IP address, > that does not have an ARP resolution, it really clutters up traffic > unnecessarily. A simple case from my lab illustrates some of the > difficulty. > > Here I am sending a single transit packet, passing through my MX, destined > to an IP that will not resolve. Since the MX has nowhere immediately to > send the packet, the RE spits out a bunch of ARP requests: > > 17:30:35.095861 ARP, Request who-has 192.168.10.21 tell 192.168.10.8, > length 46 > 17:30:35.713821 ARP, Request who-has 192.168.10.21 tell 192.168.10.8, > length 46 > 17:30:36.613849 ARP, Request who-has 192.168.10.21 tell 192.168.10.8, > length 46 > 17:30:37.513831 ARP, Request who-has 192.168.10.21 tell 192.168.10.8, > length 46 > 17:30:38.313831 ARP, Request who-has 192.168.10.21 tell 192.168.10.8, > length 46 > > Correspondingly, rtsockmon -tn logs this: > > [17:30:35:099.939] kernel Proute add inet 192.168.10.21 > tid=36 plen=32 type=dest flags=0x180 nh=hold nhflags=0x1 nhidx=1290 > rt_nhiflist = 0 altfwdnhidx=0 filtidx=0 lr_id = 0 featureid=0 > rt_mcast_nhiflist=-1610628420 > [17:30:35:101.376] kernel Pnexthopadd inet nh=hold > flags=0x1 uflags=0x0 idx=1290 ifidx=421 filteridx=0 lr_id =0 > [17:30:39:013.595] kernel Proute delete inet 192.168.10.21 > tid=36 plen=32 type=dest flags=0x180 nh=hold nhflags=0x1 nhidx=1290 > rt_nhiflist = 0 altfwdnhidx=0 filtidx=0 lr_id = 0 featureid=0 > rt_mcast_nhiflist=-1610628420 > [17:30:39:013.710] kernel Pnexthopdelete inet nh=hold > flags=0x5 uflags=0x0 idx=1290 ifidx=421 filteridx=0 lr_id =0 > > In a real world case, we have generally observed a fairly even > distribution of scanning attempts on non-resolving IPs, across an entire > subnet, over time. So, let's say you have an unused class C, being scanned > at the rate of 4 IPs per second, such that every address gets scanned once > a minute. Assuming that each incoming transit packet kicks off 5 ARP > requests (1 initial, plus 4 retries), as I saw above, that would trigger > somewhere over 1200 ARP requests a minute, or about 20 ARP packets a > second. > > That is a fairly moderate amplification type of attack. > > In a DHCP-serviced subnet, like a /20 with some 4000 available host IPs, > we might have only 3000 being used at any one time, but we want to give > enough headroom to accommodate fluctuations in DHCP usage. But that leaves > those 1000 remaining, unused IPs unintentionally triggering lots of > unnecessary ARP traffic. > > Specifically, what would be nice, is if there was a way to manipulate that > ARP retry mechanism, from 4 retries, down to 2, to cut down on the noise. > So far, I have not found a knob in Junos on the MX to do this. > > Am I missing something? > > 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] ARP resolution algorithm? Storage of MX transit packets?
On Fri, 1 Feb 2019 at 01:32, Clarke Morledge wrote: > Specifically, what would be nice, is if there was a way to manipulate that > ARP retry mechanism, from 4 retries, down to 2, to cut down on the noise. > So far, I have not found a knob in Junos on the MX to do this. > Am I missing something? I don't think you are. You have not described the practical problem you are facing, which may help people with proposing a solution. What practical consequences you have with the unnecessary ARP traffic? Some options to consider. 1. arp-new-hold-limit (Max no. of new unresolved nexthops) May be interesting to explore setting this to a very low number. 2. arp sponge or static arp entries for non-existing host If you have mechanism to know which addresses are currently not in use I tried to check for hidden commands to change the actual ARP resolution retry count, but found nothing: I, [2019-02-01T07:23:24.407919 #16301] INFO -- : Found: 'arp-cpu-threshold' I, [2019-02-01T07:23:27.424754 #16301] INFO -- : Found: 'arp-reply-bump-priority' I, [2019-02-01T07:23:30.600803 #16301] INFO -- : Found: 'arp-request-bump-priority' I, [2019-02-01T07:23:46.780875 #16301] INFO -- : Found: 'no-proxy-arp-overwrite' I, [2019-02-01T07:23:53.618055 #16301] INFO -- : Found: 'proxy-arp-reply-for-default' Last three ones seem like interesting options to explore as well: % sysctl -a | grep inet.arp_cache net.link.ether.inet.arp_cache_size: 12 net.link.ether.inet.arp_cache_perm_size: 0 net.link.ether.inet.arp_cache_size_threshold: 0 net.link.ether.inet.arp_cache_timeout_size: 11 net.link.ether.inet.arp_cache_rearp_size: 0 net.link.ether.inet.arp_cache_retry_size: 1 If you are running subscriber services and DHCP is guaranteed, you should be able to just disable ARP, as you can populate ARP cache from DHCP in subscriber environment. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?
Thank you for the input thus far, folks. Let me explain just a bit more about what I am dealing with. Because we get so much garbage scanning, if the scanner tries to hit an IP address, that does not have an ARP resolution, it really clutters up traffic unnecessarily. A simple case from my lab illustrates some of the difficulty. Here I am sending a single transit packet, passing through my MX, destined to an IP that will not resolve. Since the MX has nowhere immediately to send the packet, the RE spits out a bunch of ARP requests: 17:30:35.095861 ARP, Request who-has 192.168.10.21 tell 192.168.10.8, length 46 17:30:35.713821 ARP, Request who-has 192.168.10.21 tell 192.168.10.8, length 46 17:30:36.613849 ARP, Request who-has 192.168.10.21 tell 192.168.10.8, length 46 17:30:37.513831 ARP, Request who-has 192.168.10.21 tell 192.168.10.8, length 46 17:30:38.313831 ARP, Request who-has 192.168.10.21 tell 192.168.10.8, length 46 Correspondingly, rtsockmon -tn logs this: [17:30:35:099.939] kernel Proute add inet 192.168.10.21 tid=36 plen=32 type=dest flags=0x180 nh=hold nhflags=0x1 nhidx=1290 rt_nhiflist = 0 altfwdnhidx=0 filtidx=0 lr_id = 0 featureid=0 rt_mcast_nhiflist=-1610628420 [17:30:35:101.376] kernel Pnexthopadd inet nh=hold flags=0x1 uflags=0x0 idx=1290 ifidx=421 filteridx=0 lr_id =0 [17:30:39:013.595] kernel Proute delete inet 192.168.10.21 tid=36 plen=32 type=dest flags=0x180 nh=hold nhflags=0x1 nhidx=1290 rt_nhiflist = 0 altfwdnhidx=0 filtidx=0 lr_id = 0 featureid=0 rt_mcast_nhiflist=-1610628420 [17:30:39:013.710] kernel Pnexthopdelete inet nh=hold flags=0x5 uflags=0x0 idx=1290 ifidx=421 filteridx=0 lr_id =0 In a real world case, we have generally observed a fairly even distribution of scanning attempts on non-resolving IPs, across an entire subnet, over time. So, let's say you have an unused class C, being scanned at the rate of 4 IPs per second, such that every address gets scanned once a minute. Assuming that each incoming transit packet kicks off 5 ARP requests (1 initial, plus 4 retries), as I saw above, that would trigger somewhere over 1200 ARP requests a minute, or about 20 ARP packets a second. That is a fairly moderate amplification type of attack. In a DHCP-serviced subnet, like a /20 with some 4000 available host IPs, we might have only 3000 being used at any one time, but we want to give enough headroom to accommodate fluctuations in DHCP usage. But that leaves those 1000 remaining, unused IPs unintentionally triggering lots of unnecessary ARP traffic. Specifically, what would be nice, is if there was a way to manipulate that ARP retry mechanism, from 4 retries, down to 2, to cut down on the noise. So far, I have not found a knob in Junos on the MX to do this. Am I missing something? 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] ARP resolution algorithm? Storage of MX transit packets?
On Thu, 31 Jan 2019 at 18:45, Krasimir Avramski wrote: > At least It will not flood ARPs under segment network probes. > > In the past these punts were throttled in the PFE . This was done with > default values of 66 pps per segment with an upper merit of 500 per PFE. You > would had seen the following entry in the syslog: "NH: resolutions from iif > 90 throttled". I don't think during punt that there is IP network (FIB entry) specific punt limit for transit packet needing resolution, that would be quite expensive. But certainly when DADDR is under resolution, it is no longer punted at all, but just dropped in HW. > I haven't seen these messages recently? - I do not know how NH rsvl punt > policers are integrated with DDoS arp/resolve system. I don't know either if it's before or after ddos or if they are completely gone now that ddos is there. From my POV we don't need them anywhere as DDoS is reasonable generic solution. I could check from the HW, but it's rather chore to navigate. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?
At least It will not flood ARPs under segment network probes.
In the past these punts were throttled in the PFE . This was done with
default values of 66 pps per segment with an upper merit of 500 per PFE.
You would had seen the following entry in the syslog: "NH: resolutions from
iif 90 throttled".
I haven't seen these messages recently? - I do not know how NH rsvl punt
policers are integrated with DDoS arp/resolve system.
Best Regards,
Krasi
On Thu, 31 Jan 2019 at 18:12, Saku Ytti wrote:
> On Thu, 31 Jan 2019 at 16:22, Krasimir Avramski wrote:
>
> > Yes, you can for ipv4/ipv6:
> >
> https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/arp-learning-neighor-discovery-disabling.html
> >
> > With the ability to set static ARP/ND you definitely could offload host
> route programming to external system.
>
> Cool. Have you tried it? In my trivial test it does not disable punting:
>
> y...@r24.labxtx01.us.bb-re1# run show route forwarding-table table
> default destination 192.0.2.0/24
> Routing table: default.inet
> Internet:
> DestinationType RtRef Next hop Type IndexNhRef Netif
> 192.0.2.0/24 intf 0rslv 825 1 ae0.0
> 192.0.2.0/32 dest 0 192.0.2.0 recv 797 1 ae0.0
>
> {master}[edit interfaces ae0 unit 0 family inet]
> y...@r24.labxtx01.us.bb-re1# set no-neighbor-learn
>
> {master}[edit interfaces ae0 unit 0 family inet]
> y...@r24.labxtx01.us.bb-re1# commit
> re1:
> configuration check succeeds
> re0:
> commit complete
> re1:
> commit complete
>
> {master}[edit interfaces ae0 unit 0 family inet]
> y...@r24.labxtx01.us.bb-re1# run show route forwarding-table table
> default destination 192.0.2.0/24
> Routing table: default.inet
> Internet:
> DestinationType RtRef Next hop Type IndexNhRef Netif
> 192.0.2.0/24 intf 0rslv 825 1 ae0.0
> 192.0.2.0/32 dest 0 192.0.2.0 recv 797 1 ae0.0
>
>
> It did disable resolution though, but it's not really attractive to me
> without disabling punting.
>
> --
> ++ytti
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?
On Thu, 31 Jan 2019 at 16:22, Krasimir Avramski wrote:
> Yes, you can for ipv4/ipv6:
> https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/arp-learning-neighor-discovery-disabling.html
>
> With the ability to set static ARP/ND you definitely could offload host route
> programming to external system.
Cool. Have you tried it? In my trivial test it does not disable punting:
y...@r24.labxtx01.us.bb-re1# run show route forwarding-table table
default destination 192.0.2.0/24
Routing table: default.inet
Internet:
DestinationType RtRef Next hop Type IndexNhRef Netif
192.0.2.0/24 intf 0rslv 825 1 ae0.0
192.0.2.0/32 dest 0 192.0.2.0 recv 797 1 ae0.0
{master}[edit interfaces ae0 unit 0 family inet]
y...@r24.labxtx01.us.bb-re1# set no-neighbor-learn
{master}[edit interfaces ae0 unit 0 family inet]
y...@r24.labxtx01.us.bb-re1# commit
re1:
configuration check succeeds
re0:
commit complete
re1:
commit complete
{master}[edit interfaces ae0 unit 0 family inet]
y...@r24.labxtx01.us.bb-re1# run show route forwarding-table table
default destination 192.0.2.0/24
Routing table: default.inet
Internet:
DestinationType RtRef Next hop Type IndexNhRef Netif
192.0.2.0/24 intf 0rslv 825 1 ae0.0
192.0.2.0/32 dest 0 192.0.2.0 recv 797 1 ae0.0
It did disable resolution though, but it's not really attractive to me
without disabling punting.
--
++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?
Hi, I don't think you can turn it off in JunOS. So they'd have to change > code anyhow, at which point, I'd rather take translation than static > config. > Yes, you can for ipv4/ipv6: https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/arp-learning-neighor-discovery-disabling.html With the ability to set static ARP/ND you definitely could offload host route programming to external system. Best Regards, Krasi ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?
> Can you do static ARP entries on JunOS?
Yes. Lightly redacted example:
family inet {
address a.b.c.193/30 {
arp a.b.c.194 mac 78:e3:b5:05:24:18;
}
}
Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?
hey,
Huawei VRP has magic feature to enable periodic ARP for static route,
so that static route is not installed if far_end does not resolve or
stops resolving. Cisco and Juniper do not.
So does Nokia SROS:
[no] static-route {ip-prefix/prefix-length | ip-prefix netmask }
[validate-next-hop]
validate-next-hop:
This configuration option tracks the state of the next-hop in the IPv4
ARP cache or IPv6 Neighbor Cache. When the next-hop is not reachable and
is removed from the ARP or Neighbor Cache, the next-hop will no longer
be considered valid. When the next-hop is again reachable and present in
the ARP/Neighbor Cache, the static route will be considered valid.
Note: This feature is supported for directly connected next-hops only,
and is exclusive with indirect routes.
--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?
Hi, On Thu, Jan 31, 2019 at 10:00:59AM +0100, Robert Raszuk wrote: > + also including static routes. That's why as some of you for sure remember > static to multiaccess interfaces say /8 without giving explicit next hop > are very dangerous ;) Yes, of course. Any sort of "indirect" routes crossing a multiaccess network. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?
On Thu, 31 Jan 2019 at 10:57, Gert Doering wrote: > I think Robert is talking about router-to-router LANs, where you have > "prior knowledge" in your FIB. > > Like, OSPF neighbours, or BGP next-hops pointing to LAN adjacencies - so > the router could go out and start the ARP process the moment it learns > "I have a next-hop in BGP pointing to :". Yeah even this is driven by traffic, you BGP wanting to send packet causes it to be resolved. Heck this does not cause ARP: ip route 1.2.3.0 255.255.255.0 This route gets installed and stays installed regardless if far end will resolve or not. And far end wont be resolved until something wants to go to far_end or wants to go to 1.2.3.0/24 Huawei VRP has magic feature to enable periodic ARP for static route, so that static route is not installed if far_end does not resolve or stops resolving. Cisco and Juniper do not. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?
Spot on Gert ! + also including static routes. That's why as some of you for sure remember static to multiaccess interfaces say /8 without giving explicit next hop are very dangerous ;) On Thu, Jan 31, 2019, 09:57 Gert Doering Hi, > > On Thu, Jan 31, 2019 at 10:51:01AM +0200, Saku Ytti wrote: > > On Thu, 31 Jan 2019 at 10:34, Robert Raszuk wrote: > > > > > As mentioned on the other thread decent routers should resolve peer's > IP to mac when creating FIB adj and building rewrite entries. > > > There is no "first packet" notion nor any ARPing driven by packet > reception. This should apply to p2p adj as well as p2mp - classic LANs. > > > > > Are you guys saying that say MXes don't do that ? > > > > I'm not sure what you are saying. I must misunderstand, but are you > > saying once I configure /8 LAN, router ARPs all of them periodically > > until the end of time, retaining unresolved, resolved cache for each > > of /8? Which router does this? > > I think Robert is talking about router-to-router LANs, where you have > "prior knowledge" in your FIB. > > Like, OSPF neighbours, or BGP next-hops pointing to LAN adjacencies - so > the router could go out and start the ARP process the moment it learns > "I have a next-hop in BGP pointing to :". > > (I think it would be a great thing to have, especially including a > feedback mechanism "ARP / ND failed, this next-hop is invalid!" to BGP - > solve a number of blackhole problems with indirect BGP routes) > > getr > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > g...@greenie.muc.de > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?
Hi, On Thu, Jan 31, 2019 at 10:51:01AM +0200, Saku Ytti wrote: > On Thu, 31 Jan 2019 at 10:34, Robert Raszuk wrote: > > > As mentioned on the other thread decent routers should resolve peer's IP to > > mac when creating FIB adj and building rewrite entries. > > There is no "first packet" notion nor any ARPing driven by packet > > reception. This should apply to p2p adj as well as p2mp - classic LANs. > > > Are you guys saying that say MXes don't do that ? > > I'm not sure what you are saying. I must misunderstand, but are you > saying once I configure /8 LAN, router ARPs all of them periodically > until the end of time, retaining unresolved, resolved cache for each > of /8? Which router does this? I think Robert is talking about router-to-router LANs, where you have "prior knowledge" in your FIB. Like, OSPF neighbours, or BGP next-hops pointing to LAN adjacencies - so the router could go out and start the ARP process the moment it learns "I have a next-hop in BGP pointing to :". (I think it would be a great thing to have, especially including a feedback mechanism "ARP / ND failed, this next-hop is invalid!" to BGP - solve a number of blackhole problems with indirect BGP routes) getr -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?
We are talking about transit - right ? So regardless of subnet mask you know your next hop IP from control plane. Then you creating adj in FIB/CEF without waiting for any packet to arrive. End hosts on directly connected LANs are different but my impression was that we are discussing case of transit. Thx On Thu, Jan 31, 2019, 09:51 Saku Ytti On Thu, 31 Jan 2019 at 10:34, Robert Raszuk wrote: > > > As mentioned on the other thread decent routers should resolve peer's IP > to mac when creating FIB adj and building rewrite entries. > > There is no "first packet" notion nor any ARPing driven by packet > reception. This should apply to p2p adj as well as p2mp - classic LANs. > > > Are you guys saying that say MXes don't do that ? > > I'm not sure what you are saying. I must misunderstand, but are you > saying once I configure /8 LAN, router ARPs all of them periodically > until the end of time, retaining unresolved, resolved cache for each > of /8? Which router does this? > > At least routers I've worked with punt traffic destined to unresolved > addresses and then build HW adjacency. No traffic to given /32, not > adjacency, no knowledge of DMAC. > > > -- > ++ytti > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?
On Thu, 31 Jan 2019 at 10:34, Robert Raszuk wrote: > As mentioned on the other thread decent routers should resolve peer's IP to > mac when creating FIB adj and building rewrite entries. > There is no "first packet" notion nor any ARPing driven by packet reception. > This should apply to p2p adj as well as p2mp - classic LANs. > Are you guys saying that say MXes don't do that ? I'm not sure what you are saying. I must misunderstand, but are you saying once I configure /8 LAN, router ARPs all of them periodically until the end of time, retaining unresolved, resolved cache for each of /8? Which router does this? At least routers I've worked with punt traffic destined to unresolved addresses and then build HW adjacency. No traffic to given /32, not adjacency, no knowledge of DMAC. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?
Hi, On Thu, Jan 31, 2019 at 10:33:20AM +0200, Saku Ytti wrote: > And while I'm asking for things that won't happen. Give us > 'point-to-point' ethernet. If you configure 'point-to-point' keyword > in interface, it'll just use all-zero MACs or some reserved MAC and > never punts for ARP. There are shops who don't have L2 aggregation > anywhere at all, and most of us don't have any of it in backbone > infra. Indeed, that would be nice to have. (But there are so many other things I would want to have first that I can't get either that I'm not having high hopes) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?
As mentioned on the other thread decent routers should resolve peer's IP to mac when creating FIB adj and building rewrite entries. There is no "first packet" notion nor any ARPing driven by packet reception. This should apply to p2p adj as well as p2mp - classic LANs. Are you guys saying that say MXes don't do that ? Thx, R. On Thu, Jan 31, 2019, 09:26 Gert Doering Hi, > > On Thu, Jan 31, 2019 at 10:10:32AM +0200, Saku Ytti wrote: > > I wish some vendor would implement static DIP=>DADDR resolution, there > > Can you do static ARP entries on JunOS? You can do that on Cisco - while > not exactly what you might have had in mind, it would be theoretically > possible to have management system turn off ARP resolution for certain > VLANs and put static ARP entries into the config. > > (I had to use it in the past due to ARP and ND bugs at peering routers, > so I know "it works for a small number of entries" - no idea if it would > scale, or whether Cisco properly programs static ARP into HW right > away, or just uses it for lookups when punting) > > gert > > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > g...@greenie.muc.de > ___ > 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] ARP resolution algorithm? Storage of MX transit packets?
On Thu, 31 Jan 2019 at 10:26, Gert Doering wrote: > Can you do static ARP entries on JunOS? You can do that on Cisco - while > not exactly what you might have had in mind, it would be theoretically > possible to have management system turn off ARP resolution for certain > VLANs and put static ARP entries into the config. I don't think you can turn it off in JunOS. So they'd have to change code anyhow, at which point, I'd rather take translation than static config. > (I had to use it in the past due to ARP and ND bugs at peering routers, > so I know "it works for a small number of entries" - no idea if it would > scale, or whether Cisco properly programs static ARP into HW right > away, or just uses it for lookups when punting) It does get programmed into HW adjacency. And while I'm asking for things that won't happen. Give us 'point-to-point' ethernet. If you configure 'point-to-point' keyword in interface, it'll just use all-zero MACs or some reserved MAC and never punts for ARP. There are shops who don't have L2 aggregation anywhere at all, and most of us don't have any of it in backbone infra. Should be very easy change, maybe phase2, drop DMAC+SMAC entirely, giving us 3 free MPLS label at same MTU as edge, so we dont need overspeed to handle 1GE of edge traffic at small size. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?
Hi, On Thu, Jan 31, 2019 at 10:10:32AM +0200, Saku Ytti wrote: > I wish some vendor would implement static DIP=>DADDR resolution, there Can you do static ARP entries on JunOS? You can do that on Cisco - while not exactly what you might have had in mind, it would be theoretically possible to have management system turn off ARP resolution for certain VLANs and put static ARP entries into the config. (I had to use it in the past due to ARP and ND bugs at peering routers, so I know "it works for a small number of entries" - no idea if it would scale, or whether Cisco properly programs static ARP into HW right away, or just uses it for lookups when punting) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?
Hey Clarke, On Thu, 31 Jan 2019 at 02:19, Clarke Morledge wrote: > I am trying to wrap my head around how the MX handles ARP resolution, > and how it stores packets waiting to be transmitted, while waiting for ARP > to resolve. This might answer some of your questions http://blog.ip.fi/2014/02/junos-and-arp-glean.html > In the event an ARP request is generated, and no response is received > within x(???) seconds, it looks like another request is sent out, or more, > perhaps? If no response ever comes back, after some period of time, I > presume the router will drop the transit packet. First transit packet being punted the hardware programs the adjacency into a one which will drop subsequent packets. However programming is not instantaneous, so if burst of packets come in, they honour the original adjacency which will cause them to be punted. The first packet being punted triggers the RE resolution process, and what it does and how many times it tries is decoupled from the amount of packets that are trying to transit. > So, where is this transit packet being held, while it is waiting for the > ARP reply to come back (if it even does come back)? How is the packet > being stored? Are the packets stored via a hash in separate queues, of > some sort, so that other transit traffic is not getting blocked? This is good question. I believe it is not stored in HW at all, only in control-plane. > What is strange is that if there is a string of transit packets coming in, > that have no corresponding ARP entry in the cache available, the way the > RE sends out ARP requests does not exactly correspond to the order of > transmit packets, as they come into the PFE. I would have expected a > FIFO-like mechanism, but this does not seem to be the case. It is necessarily non-lock step due to delays needed to reinform hardware. > Off the Wire, Just Before Traffic Enters the MX: > > 21:51:16.158064 IP 185.254.123.12.46185 > 100.64.101.189.3588: > 21:51:16.297351 IP 92.63.194.38.47423 > 100.64.101.25.55126: > 21:51:16.301438 IP 185.53.91.24.55823 > 100.64.101.88.5038: > 21:51:16.385521 IP 185.176.27.34.58908 > 100.64.101.215.1288: > 21:51:16.449858 IP 92.53.90.143.44499 > 100.64.101.192.282: > 21:51:16.462591 IP 92.53.90.143.44499 > 100.64.101.181.282: > 21:51:16.470221 IP 185.143.221.106.58528 > 100.64.101.1.4040: > 21:51:16.492806 IP 92.63.194.38.47423 > 100.64.101.35.55126: > 21:51:16.500132 IP 92.63.194.38.47423 > 100.64.101.58.55126: > > ARP Requests Coming Out of the RE: > > 21:51:16.158515 ARP, Request who-has 100.64.101.189 tell 100.64.101.3 > 21:51:16.227443 ARP, Request who-has 100.64.101.50 tell 100.64.101.3 # you > dont have corresponding packet, so I assume this is retry of older punt > 21:51:16.227985 ARP, Request who-has 100.64.101.158 tell 100.64.101.3 # same > 21:51:16.297828 ARP, Request who-has 100.64.101.25 tell 100.64.101.3 # > order preserved in relation to 189 > 21:51:16.327204 ARP, Request who-has 100.64.101.59 tell 100.64.101.3 # again > no packet seen above > 21:51:16.327664 ARP, Request who-has 100.64.101.65 tell 100.64.101.3 # again > no packet seen above > 21:51:16.427452 ARP, Request who-has 100.64.101.2 tell 100.64.101.3 # .. > 21:51:16.428282 ARP, Request who-has 100.64.101.9 tell 100.64.101.3 # .. > 21:51:16.473085 ARP, Request who-has 100.64.101.1 tell 100.64.101.3 # .. > 21:51:16.527447 ARP, Request who-has 100.64.101.7 tell 100.64.101.3 # .. > 21:51:16.528278 ARP, Request who-has 100.64.101.88 tell 100.64.101.3 # order > preserved in relation to 189, 25 I see nothing odd there. As an interesting side note, when JNPR implemented 'ddos-protection' which is great feature, market-leading really. They totally broke ARP. For around 3 years when ever glean packet needed punting, instead of having special 'glean/resolve' classification it was classified by what it was. So say I was ddossing 100.64.101.50 (non-existing host) with BGP packet, instead of causing 'glean/resolve' packets to be rate-limited, I was causing BGP packets to be ratelimited, and you had _no recourse_, I could bring down your BGP as I wish and not be subject to our Lo0 filtering. I wish some vendor would implement static DIP=>DADDR resolution, there are many applications, such as VM only LANs, where you anyhow generate MAC programmatically, you could generate it deterministically from DIP and inform router about this, so then you'd never need to glean/resolve punt in this interface. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
