[j-nsp] ARP resolution algorithm? Storage of MX transit packets?

[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 <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)

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                             gert at greenie.muc.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20190131/ffde0348/attachment-0001.sig>