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
_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users
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
_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users