Hi Ondrej, Thanks for your info :) Thanks Arvin -----Original Message----- From: Ondrej Zajicek <[email protected]> Sent: Tuesday, August 21, 2018 9:00 PM To: Arvin Gan <[email protected]> Cc: [email protected] 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: [email protected] > 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: [email protected]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
