BGP resolvable issue

[Arvin Gan]

Hi Ondrej,
   Thanks for your info :)
Thanks
Arvin

-----Original Message-----
From: Ondrej Zajicek <santiago at crfreenet.org> 
Sent: Tuesday, August 21, 2018 9:00 PM
To: Arvin Gan <AGan at advaoptical.com>
Cc: bird-users at network.cz
Subject: Re: BGP resolvable issue

On Tue, Aug 21, 2018 at 01:43:58AM +0000, Arvin Gan wrote:
> Ping, anyone known it ?:)
> 
> Thanks
> Arvin
> 
> From: Arvin Gan
> Sent: Monday, August 13, 2018 5:42 PM
> To: bird-users at network.cz
> Subject: BGP resolvable issue
> 
> Hi all,

>    In RFC4271, If the NEXT_HOP attribute of a BGP route depicts an 
> address that is not resolvable, or if it would become unresolvable if 
> the route was installed in the routing table, the BGP route MUST be 
> excluded from  the Phase 2 decision function. Actually, BGP protocol 
> is implemented this option. I notice that  resolvable is checked with 
> "rt->attrs->dest == RTD_UNICAST" , that mean the check is depend on 
> the reachability of route for NEXT_HOP.  However, NEXT_HOP is a host 
> address, not  a subnet address, the resolvable checking in VRF is 
> depending on ARP/NDP result for NEXT_HOP, if NEXT_HOP cannot be 
> resolved for MAC, it should be  unresolved.

Hi

IMHO resolvability condition is completely unrelated to ARP/NDP. See RFC
4271 9.1.2.2, host route is resolved in the same way as regular route.
NEXT_HOP is one IP address, but resolvability check does longest-matching prefix match to find matching prefix.

--
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."