[quagga-users 14567] Re: iBGP not propagating v6 route problem (again)

Hi,

On 20/12/2016 21:54, Mark Kamichoff wrote:
> On Mon, Dec 19, 2016 at 10:04:30AM +0000, Paul Thornton wrote:
>> The reason I think this may be slightly different to the problems some of us
>> are reporting is that in the past, 'show ip bgp neigh x advertised-routes'
>> claimed that the router was advertising them - in this case, it doesn't (but
>> 'show ip bgp x' does claim it is):
> Actually, not different for me.  Here's a bug I opened awhile back:
>
> https://bugzilla.quagga.net/show_bug.cgi?id=870
>
> (just started commenting on it again the other day)
>
> "show ip bgp nei x advertised-routes" does not show the advertisement
> for me, either.

I just read through that bug report - and it looks like I'm seeing 
almost exactly the same thing, except for me it is a route learned from 
a peer that the box isn't passing on.  So we have your case (network 
statement) and mine (learned route from elsewhere) - it does seem that 
it is the iBGP advertising that is at fault.

I also have a consistently >0 OutQ on the peers that are not being sent 
the prefix.

The nexthop cache, however, looks sane:

suitcase.as8676.net# show ip bgp nexthop detail
Current BGP nexthop cache:
  217.65.160.126 valid [IGP metric 0], #paths 0
   gate 217.65.163.97
   Last update: Mon Dec 19 09:53:51 2016

  217.65.160.127 valid [IGP metric 0], #paths 0
   gate 217.65.163.97
   Last update: Mon Dec 19 09:53:51 2016

  217.65.163.106 valid [IGP metric 1], #paths 0
   if ix0
   Last update: Mon Dec 19 09:53:51 2016

  217.65.163.110 valid [IGP metric 1], #paths 0
   if ix1
   Last update: Mon Dec 19 09:53:50 2016

  2001:1420::7e valid [IGP metric 0], #paths 0
   gate 2001:1420:16:2::1
   Last update: Mon Dec 19 11:55:37 2016

  2001:1420::7f valid [IGP metric 0], #paths 0
   gate 2001:1420:16:2::1
   Last update: Mon Dec 19 09:53:50 2016

  2001:1420:16:2::1 valid [IGP metric 1], #paths 1
   if em0
   Last update: Mon Dec 19 11:55:38 2016

  2001:1420:16:3::1 valid [IGP metric 1], #paths 0
   if ix0
   Last update: Mon Dec 19 11:40:23 2016

suitcase.as8676.net#
suitcase.as8676.net# show ipv6 route  2001:1420:16:2::1
Routing entry for 2001:1420:16:2::/64
   Known via "connected", distance 0, metric 1, tag 0, vrf 0, best, fib
   >* directly connected, em0

suitcase.as8676.net# show ipv6 route  2001:1420::7f
Routing entry for 2001:1420::7f/128
   Known via "static", distance 1, metric 0, tag 0, vrf 0, best, fib
   >* 2001:1420:16:2::1, via em0

suitcase.as8676.net# show ipv6 route  2001:1420:16:3::1
Routing entry for 2001:1420:16:3::/127
   Known via "connected", distance 0, metric 1, tag 0, vrf 0, best, fib
   >* directly connected, ix0

I also have bgp debugging enabled.  This is what I see in the log when 
the iBGP peer is brought up - no sign of any attempt to actually send an 
update to the iBGP peer.  I'm not sure about that 'NH unresolved' 
message - it may or may not be related.

2016/12/19 11:55:39 BGP: %ADJCHANGE: neighbor 2001:1420::7e Up
2016/12/19 11:55:39 BGP: 2001:1420::7e rcvd UPDATE w/ attr: , origin i, 
mp_nexthop 2001:1420::7e, localpref 100, path
2016/12/19 11:55:39 BGP: 2001:1420::7e rcvd ::/0
2016/12/19 11:55:39 BGP: bgp_update_main(0.0.0.0): NH unresolved
2016/12/19 11:55:39 BGP: parse nexthop update(2001:1420:16:2::1/128): 
metric=0, #nexthop=0
2016/12/19 11:55:39 BGP: parse nexthop update(2001:1420:16:2::1/128): 
metric=1, #nexthop=1
2016/12/19 11:55:39 BGP: Zebra send: IPv6 route add ::/0 nexthop 
2001:1420:16:2::1 metric 0 tag 0
2016/12/19 11:55:58 BGP: 2001:1420:16:3::1 send UPDATE ::/0

I do have this currently and reliably broken on a lab environment 
router, so can do additional debugging etc. if someone wants to make 
suggestions.

Paul.

-- 
Paul Thornton