I’ve been trying to get a PFSense firewall running openBGPd to advertise a IPv4 route over IPv6 peering and IPv6 next hop to a Cumulus Linux switch (3.1 currently). I have come across a few unexpected things which I was hoping somebody could clear up for me.
Firstly, from what I can gather openBGPd doesn’t support RFC5549 and so it won’t automagically send a IPv6 address as a valid nexthop for an IPv4 route. However, as long as the openBGPd IPv4 nexthop is on the same subnet as the Cumulus switch, I can successfully peer using a IPv6 BGP session and advertise a IPv4 route, using the IPv4 nexthop from PFSense.
After doing a bit more research, I was hoping to maybe be able to use route maps in Quagga on the Cumulus Linux switch to manipulate the incoming route and add a IPv6 nexthop address via the “set ipv6 next-hop peer-address” command. This is where things start to get interesting. Firstly, using that command, I start getting errors in the Quagga log saying “DENIED due to: martian or self next-hop”, on trying to hunt through the Quagga source to work out why this wasn’t working, it became apparent that this line is not in the Cumulus Quagga git repo. In fact, the only place I managed to find it was here:
Committed by Donald Sharp from Cumulus Networks?
So I’m a little confused why the version of Quagga shipping with Cumulus Linux is different to your git repo and also why adding the IPv6 peer-address results in this error, as the comments in the code in the above link suggest that IPv6 link local address shouldn’t trigger it. Any ideas?
So accepting that I wasn’t getting anywhere with the “set ipv6 next-hop peer-address” route-map, I then tried configuring a IPv6 global address on the interface on the switch and created a route-map containing “set ipv6 next-hop global xx::xx”. This gets applied without any errors, but unfortunately doesn’t actually change/add the nexthop on the incoming route. I’m guessing that there must also be an attribute on the route which also needs updating to reflect that it can support IPv6 nexthop?
So I think after this I am left with two questions:
1. Is what I am trying to do possible in anyway?
2. Are there any thoughts on fixing the route-map behaviour to try and achieve what I’m trying to do?