Mailing List Archive: iBGP not propagating v6 route problem (again)

iBGP not propagating v6 route problem (again)

Dec 19, 2016, 2:04 AM

Post #1 of 7 (1045 views)

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

Re: iBGP not propagating v6 route problem (again) [ In reply to ]

prox at prolixium

Dec 20, 2016, 1:54 PM

Post #2 of 7 (1043 views)

Permalink

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.

> 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

As was pointed out in a comment for bug #870, check out the OutQ there.
It's !0, which might be related. bgpd thinks its advertising the
prefixes, but it isn't.

Also, check "show ip bgp nexthop detail" on that box and see if the
expected nexthop / outgoing interface is listed. For me, it's not.

- Mark

--
Mark Kamichoff
prox@prolixium.com
http://www.prolixium.com/

_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: iBGP not propagating v6 route problem (again) [ In reply to ]

paul at prt

Dec 21, 2016, 2:44 PM

Post #3 of 7 (1037 views)

Permalink

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

_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: iBGP not propagating v6 route problem (again) [ In reply to ]

prox at prolixium

Dec 21, 2016, 4:26 PM

Post #4 of 7 (1036 views)

Permalink

On Wed, Dec 21, 2016 at 10:44:34PM +0000, Paul Thornton wrote:
> > https://bugzilla.quagga.net/show_bug.cgi?id=870
>
> [..snip..]
>
> 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'm now seeing your exact issue where bgpd is not passing on a route
that's learned elsewhere, too.

> I also have a consistently >0 OutQ on the peers that are not being sent the
> prefix.
>
> The nexthop cache, however, looks sane:

Interesting, maybe that's a red herring.

> 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

My logs are similar - no help here.

> 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.

Same here! Although, I'm wondering if I restart bgpd enough, it'll go
away. I have a feeling it's something circumstantial but this is pure
speculation.

- Mark

--
Mark Kamichoff
prox@prolixium.com
http://www.prolixium.com/

_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: iBGP not propagating v6 route problem (again) [ In reply to ]

paul at prt

Dec 27, 2016, 11:18 AM

Post #5 of 7 (1024 views)

Permalink

On 22/12/2016 00:26, Mark Kamichoff wrote:
> On Wed, Dec 21, 2016 at 10:44:34PM +0000, Paul Thornton wrote:
>>> https://bugzilla.quagga.net/show_bug.cgi?id=870
>>
>> [..snip..]
>>
>> 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'm now seeing your exact issue where bgpd is not passing on a route
> that's learned elsewhere, too.

Another data point on this issue.

I've just downgraded to Quagga 0.99.23.1 on my lab router, and the
problem goes away, with the config the same and everything else
unchanged. I am now receiving the v6 prefixes and passing them on as
expected.

So this appears to be some kind of regression. I'll gradually upgrade
until it breaks again.

Paul.

_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: iBGP not propagating v6 route problem (again) [ In reply to ]

scott at sl

Jan 7, 2017, 5:09 PM

Post #6 of 7 (991 views)

Permalink

On 2016-12-21.22:44, Paul Thornton wrote:
> 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've recently had the same problem reported against quagga 1.1.0 in
Debian[0].

Did you ever get a resolution to this issue without downgrading?

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850226

--
Regards,
Scott.

Re: iBGP not propagating v6 route problem (again) [ In reply to ]

mike at sentex

Jan 9, 2017, 7:22 AM

Post #7 of 7 (986 views)

Permalink

On 1/7/2017 8:09 PM, Scott Leggett wrote:

>
> I've recently had the same problem reported against quagga 1.1.0 in
> Debian[0].
>
> Did you ever get a resolution to this issue without downgrading?
>
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850226

No such luck for me on this issue. Also unresolved is the issue that
seems to crop up when you have a lot of ebgp peers, some of those routes
do not propagate via ibgp.

https://lists.quagga.net/pipermail/quagga-users/2016-November/014527.html

---Mike

--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/

_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Mailing List Archive

Mailing List Archive

Attached Files: