[quagga-users 14562] iBGP not propagating v6 route problem (again)

Hi all

I am not certain if I am seeing the iBGP route issue here, or if it is 
something else.

I needed a full BGP feed in a test lab for something, so ran up a 
machine (FreeBSD 10.3 if it matters) with Quagga 1.1.0.

This router ("suitcase") has 2x iBGP sessions for v4, and 2x sessions 
for v6 to get a full table.  This router then provides transit on v4 and 
v6 to the testing environment.  So far, so good.

All works as expected with v4 - routes are announced in both directions, 
and we see the test prefixes arrive in the global routing table; traffic 
passes, test environment useful.

With v6, we don't see this.  The routes are present in BGP on the 
suitcase router, and BGP claims is is advertising them to the rest of 
our production network ... but it isn't.

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

suitcase.as8676.net# show ipv6 bgp sum
BGP router identifier 217.65.163.126, local AS number 8676
RIB entries 65667, using 7182 KiB of memory
Peers 8, using 71 KiB of memory

Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  
State/PfxRcd
2001:1420::7e   4  8676   15681       5        0    0    1 00:02:46    34382
2001:1420::7f   4  8676   15680       5        0    0    1 00:02:49    34380
2001:1420:16:3::1
                 4 48152      12   15654        0    0   10 
00:02:34        1
2001:1420:16:4::1
                 4 48152       0       0        0    0    0 never    
Idle (Admin)

Total number of neighbors 4

So we have a full table from our iBGP neighbours and learn one route 
from the test environment.  So far, so good.

suitcase.as8676.net# show ipv6 bgp 2a0b:3d00::/32
BGP routing table entry for 2a0b:3d00::/32
Paths: (1 available, best #1, table Default-IP-Routing-Table)
   Advertised to non peer-group peers:
   2001:1420::7e 2001:1420::7f
   48152, (aggregated by 48152 185.173.76.255)
     2001:1420:16:3::1 from 2001:1420:16:3::1 (185.173.76.255)
     (fe80::32b6:4fff:fe3b:6a96)
       Origin IGP, localpref 2000, valid, external, best
       Community: 8676:199 8676:200
       Last update: Mon Dec 19 09:55:41 2016

And this route has a valid next hop and it claims to be advertising it 
to the world.  Except it isn't...

suitcase.as8676.net# show ipv6 bgp nei 2001:1420::7f advertised-routes
BGP table version is 0, local router ID is 217.65.163.126
Status codes: s suppressed, d damped, h history, * valid, > best, = 
multipath,
               i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

    Network          Next Hop            Metric LocPrf Weight Path

suitcase.as8676.net# show ipv6 bgp nei 2001:1420::7e advertised-routes
BGP table version is 0, local router ID is 217.65.163.126
Status codes: s suppressed, d damped, h history, * valid, > best, = 
multipath,
               i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

    Network          Next Hop            Metric LocPrf Weight Path

Nothing is announced.  And it isn't just a CLI issue here - checking up 
at the other end, we don't have a path for this:

core2.thn.as8676.net# show ipv6 bgp 2a0b:3d00::/32
% Network not in table

If this is the "IPv6 isn't properly working within iBGP" problem, then 
this being a test environment, I can do extensive debugging on it and 
hopefully get some idea what the root cause is.

If it isn't, does anyone have any ideas?

Paul.

-- 
Paul Thornton