Re: [Idr] Link Local Next Hop Handling for BGP

[Gyan Mishra <[e-mail]>]

Jeffrey

On Wed, Nov 10, 2021 at 6:14 AM Jeffrey Haas <[e-mail]> wrote:

> Gyan,
>
> On Sun, Nov 07, 2021 at 11:54:25PM -0500, Gyan Mishra wrote:
> > Some history with IPv6 and why with all routing protocols the next hop is
> > set to LL is due to on-link nature of direct adjacency and  ND process
> > ICMPv6 ND NS/NA process where the ICMPv6 packets are sent with source
> > address is Link Local w/ Destination Solicit Node Multicast or target
> > address DAD process.
> >
> > For directly adjacent neighbors on a P2P link the  Link local cache is
> > built first then the GUI. In my experience I have not run into any issues
> > where the LL cache was not built and the GUI was which would break
> > forwarding.
> >
> > I would think that is a router bug as that is rare and should never
> happen.
>
> To add speculation, consider the case of a third-party nexthop.  In such
> cases, having the link-local means you can avoid some of the churn where
> the
> ND cache wasn't in sync for a nexthop you've learned for a host you may not
> have exchanged any traffic with.
>

Gyan>  Understood the motivation.  Would that be moreso router to router
peering or  DC NVO3 overlay extension BGP to host VM scenario or both.

>
> > I have deployed  implementations where we have hardcoded the LL to be
> more
> > intuitive then the default EUI64  MAC based address default and that has
> > worked well setting the LL to the GUI address.  Caveat in hardcoding the
> LL
> > on each interface is you cannot write into the 50 bits all 0s in the
> fe80::
> > prefix so the IID portion that is hardcoded have to make sure its
> fe80::(64
> > bits) or it breaks ND process.  Making the next hop intuitive is really
> > nice as it makes it easier for operations to identify the neighbor device
> > in troubleshooting then looking at a EUI64 next hop.
>
> Once upon a time, Linux used to encode its interface ID for ipv6 link local
> in those "must be zero" bits in its data structures.  I've not read that
> source in years so it may have changed. :-)
>
>    Gyan> RFC 4291 states the 54 bits proceeding the fe80:: must be 0's.  I
have seen not having that 0 break ND and a nightmare to troubleshoot

2.5.6 <https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.6>.
Link-Local IPv6 Unicast Addresses

   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

   Link-Local addresses are designed to be used for addressing on a
   single link for purposes such as automatic address configuration,
   neighbor discovery, or when no routers are present.

   Routers must not forward any packets with Link-Local source or
   destination addresses to other links.



> > As far as using LL for IGP on all p2p links in a DC that works very well
> &
> > does simplify deployment.  Cisco has a knob "ipv6-enable" which enables
> > processing of IPv6 packets without an IPv6 address configured.  Juniper
> has
> > a similar knob.  From an operations perspective this does yield issues
> with
> > hop by hop ping & trace as the LL is only locally reachable.
>
> My memory is RFC 8335 was intended to address some of this.
>
> Gyan> Excellent!
>


> -- Jeff
>


-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*