Trouble with IPv6 setup on Quagga

Mailman List Mirror (Read Only)
1

Hello everyone

I am having trouble with Quagga in setting up IPv6 BGP. So far it was
failing with external providers. Just now I gave it a try to setup BGP
session (IPv6 only) within our ASN between two routers.

From our other end router I see there is no acconcement, while I see blocks

being announced via Quagga. Also strange enough is that the number of
blocks I account - they all come as "withdrawl routes" on other router as
soon as Quagga is turned on.

E.g this is what I see on Quagga:

node4# show bgp ipv6 summary
BGP router identifier 199.116.78.28, local AS number 54456
RIB entries 18741, using 1757 KiB of memory
Peers 1, using 4560 bytes of memory

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
2607:1b00:10:a::1
                4 54456 6865 5 0 0 0 00:00:05 9798

Total number of neighbors 1
node4#

So BGP session is up. Next if I check advertised routes, it goes like:

node4# show bgp ipv6 neighbors 2607:1b00:10:a::1 advertised-routes
BGP table version is 0, local router ID is 199.116.78.28
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network Next Hop Metric LocPrf Weight Path
*> 2607:1b00:d1::/48
                    :: 0 100 32768 i
*> 2607:1b00:d2::/48
                    :: 0 100 32768 i

Total number of prefixes 2
node4#

I don't see these routes in other router at all.

Here's what my Quagga bgpd.conf looks like:

hostname node4
timers bgp 4 16

router bgp 54456
bgp router-id 199.116.78.28
redistribute connected metric 1
redistribute static metric 1
neighbor 2607:1b00:10:a::1 remote-as 54456
neighbor 2607:1b00:10:a::1 next-hop-self

address-family ipv6
network 2607:1b00:d1::/48
network 2607:1b00:d2::/48
neighbor 2607:1b00:10:a::1 activate
exit-address-family

Was wondering if someone can point in me right direction since both of
these prefixes are (annnounced and ?) withdrawn as soon as I restart Quagga.

Thanks.

2

I am having trouble with Quagga in setting up IPv6 BGP. So far it was
failing with external providers. Just now I gave it a try to setup BGP
session (IPv6 only) within our ASN between two routers.

From our other end router I see there is no acconcement, while I see blocks
being announced via Quagga. Also strange enough is that the number of
blocks I account - they all come as "withdrawl routes" on other router as
soon as Quagga is turned on.

I recall some issues with the value of the next-hop in the BGP messages in the past. Haven't been around Quagga in recent times, don't know if this is still the case. If possible you might want to catch a BGP packet with tcpdump and verify the value in there makes sense to the other side.

Got bitten by this before and took me ages to figure out the other side was dropping my updates because the next-hop couldn't be resolved.

Marco

3

Hi Anurag,

node4# show bgp ipv6 neighbors 2607:1b00:10:a::1 advertised-routes
BGP table version is 0, local router ID is 199.116.78.28
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network Next Hop Metric LocPrf Weight Path
*> 2607:1b00:d1::/48
                    :: 0 100 32768 i
*> 2607:1b00:d2::/48
                    :: 0 100 32768 i

Total number of prefixes 2

TH: That next-hop does look suspect. If they're on the same subnet, try
disabling next-hop-self. It will just use link-local addressing on the
foreign side, should the next hop be unreachable.

It could be that with next-hop-self configured and no IPv6 address on lo,
this isn't working correctly. Do you have a global address on lo?

Here's what my Quagga bgpd.conf looks like:

hostname node4
timers bgp 4 16

router bgp 54456
bgp router-id 199.116.78.28
redistribute connected metric 1
redistribute static metric 1

TH: One thing you should add for sanity:

no bgp default ipv4-unicast

Otherwise Quagga will default to advertising IPv4 address family via IPv6
neighbors.

'bgp network import-check' is also useful to ensure Quagga behaves in the
same way as a Cisco/Juniper router when it comes to advertisements (this
goes for both address families).

neighbor 2607:1b00:10:a::1 remote-as 54456
neighbor 2607:1b00:10:a::1 next-hop-self

address-family ipv6
network 2607:1b00:d1::/48
network 2607:1b00:d2::/48
neighbor 2607:1b00:10:a::1 activate
exit-address-family

TH: This looks fine otherwise.

Tom

4

Specifying "next-hop-self" in the general BGP router config section is
equivalent to specifying it purely for IPv4 routes; you need to specify next-
hop-self in the IPv6 address-family section.

Regards,
Oliver

5

And you might want to disable ("no neighbor ... activate") for the
default-protocol (IPv4) as otherwise Quagga tries to advertise IPv4 over
the same session as well - which you usually wouldn't want to.
I've seen cases where both sides ran Quagga and wondered where all the
(unfiltered) IPv4-routes came from :slight_smile:

Regards,
Stefan

6

Most likely the trouble you're having is bgpd being unable to reference
zebra RIB via socket.

Make sure zebra is running and that your next-hop is visible as directly
connected when doing 'sh ipv6 route' under zebra vty.

James

7

I am having trouble with Quagga in setting up IPv6 BGP. So far it was
failing with external providers. Just now I gave it a try to setup BGP
session (IPv6 only) within our ASN between two routers.

From our other end router I see there is no acconcement, while I see blocks
being announced via Quagga. Also strange enough is that the number of
blocks I account - they all come as "withdrawl routes" on other router as
soon as Quagga is turned on.

I recall some issues with the value of the next-hop in the BGP messages in the past. Haven't been around Quagga in recent times, don't know if this is still the case. If possible you might want to catch a BGP packet with tcpdump and verify the value in there makes sense to the other side.

We were having those issue with quagga-0.99.15 and cisco routers; haven't tested recent versions.

We used a route map to fix the ipv6 next hop for outbound announcements in quagga.

Got bitten by this before and took me ages to figure out the other side was dropping my updates because the next-hop couldn't be resolved.

Marco

Regards,

Vicky Shrestha

8

Hello everyone

Just quick update - Yes it was issue with older version of Quagga + for
some strange reason things don't work unless I restart zebra after
restarting bgpd.

Thanks for help everyone. Really appreciate it.