[j-nsp] ARP resolution algorithm? Storage of MX transit packets?
robert at raszuk.net
Thu Jan 31 04:00:59 EST 2019
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 <gert at greenie.muc.de wrote:
> On Thu, Jan 31, 2019 at 10:51:01AM +0200, Saku Ytti wrote:
> > On Thu, 31 Jan 2019 at 10:34, Robert Raszuk <robert at raszuk.net> 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 <lan interface>:<ip>".
> (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)
> "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
> it myself till I met a computer with a sense of humor."
> Robert A. Heinlein, The Moon is a Harsh
> Gert Doering - Munich, Germany
> gert at greenie.muc.de
More information about the juniper-nsp