Helping out someone in #ipv6 on FreeNode today, they had issues with getting ospf6d to redistribute the default IPv6 route. They were configured to redistribute static, connected and kernel, but for one reason or another the default route wasn’t getting picked up and shared. Luckily they were also running the zebra daemon, so I recommended that they manually configure the default route in the zebra config, and lo’ everything magically worked! So if you are running into the same issue with Quagga’s OPSFv3 and getting a default IPv6 route redistributed, make sure you’ve added the route within Zebra.
One of the things learned in my time at previous job, was the interoperability between IPv6 routing protocols and platforms. I ran into a quirk when deploying some Quagga boxes (0.99.x version) talking OSPFv3 with some Brocade routers running NetIron 5.x. The issue was that if MTU wasn’t specifically configured on the Brocade interface facing the Quagga box, OSPFv3 wouldn’t properly negotiate and was pretty much useless. However setting the MTU on the Brocade interface to 1500 fixed this. It is possible that this would also work with jumbo frame MTU settings, however the machines weren’t getting configured or deployed for that. Just something to look out for in the lab or production, if OSPFv3 appears configured correctly everywhere, but won’t establish. Quagga’s BGP had no issue with communicating properly with a Brocade router that didn’t specify MTU on its interface, it was only OSPFv3 that appeared to be affected.
So you have your ASN and just got your PI (Provider-Independent Address Allocation) straight from an RIR, or perhaps a LoA (Letter of Authority) to announce some PA (Provider-Assigned Address Allocation) space from your ISP. You’ll need to start getting that announced out there to your peers, customers and transits. So lets use some documentation prefixes and ASNs and sort out a basic working config. I’ll base the examples on my experience with Brocade NetIron software on XMRs, which can translate over to Quagga or Cisco IOS with a few tweaks.
Assuming you are familiar with BGP4+ with IPv4, IPv6 is not so different or any more complex when getting started. Lets start off with some numbers:
Upstream ISP ASN: 64500
Your ASN: 64501
Specific /126 configured on interfaces out of allocated /64: 2001:db8:0:1::/126
PA allocation to announce: 2001:db8:1234::/48
Start off with making certain that you’ve configured IPv6 on your upstream facing interface, and they’ve configured your side, and you can ping each other over the link. The upstream provider’s configuration can be done as so:
isp#conf t isp#(config)ipv6 prefix-list as64501-ipv6-filter seq 1 permit 2001:db8:1234::/48 isp#(config)router bgp isp#(config-bgp)nei 2001:db8:0:1::2 remote-as 64501 isp#(config-bgp)nei 2001:db8:0:1::2 desc Customer_Name isp#(config-bgp)no nei 2001:db8:0:1::2 activate isp#(config-bgp)add ipv6 uni isp#(config-bgp-af)nei 2001:db8:0:1::2 activate isp#(config-bgp-af)nei 2001:db8:0:1::2 filter-list as64501-ipv6-filter in isp#(config-bgp-af)exit isp#wr mem
So the breakdown of these steps is:
- enter configuration mode on router
- build a filter to restrict what the customer (you) are allowed to announce (seq optional but required for multiple entries in list)
- enter BGP configuration mode
- create a specific session using target/destination IPv6 address and ASN of customer
- optionally add a description of the session perhaps to track who it is more clearly
- you don’t want IPv4 routes going out or coming in over the session, IPv6 routes only
- change address-family for IPv6 specific BGP settings
- activate sending and learning IPv6 routes over the session
- apply the filter for accepting INBOUND routes from you/customer
- exit & then write out the config
On the customer side it is similar but not exact:
you#conf t you#(config)ipv6 prefix-list outbound-ipv6-filter seq 1 permit 2001:db8:1234::/48 you#(config)router bgp you#(config-bgp)nei 2001:db8:0:1::1 remote-as 64500 you#(config-bgp)nei 2001:db8:0:1::1 desc ISP_Name you#(config-bgp)no nei 2001:db8:0:1::1 activate you#(config-bgp)add ipv6 uni you#(config-bgp-af)network 2001:db8:1234::/48 you#(config-bgp-af)nei 2001:db8:0:1::1 activate you#(config-bgp-af)nei 2001:db8:0:1::1 filter-list outbound-ipv6-filter out you#(config-bgp-af)exit you#wr mem
The differences being:
1) outbound filter list on your session to the ISP
2) network statement for the allocation to be announced by BGP
You’ll also need some sort of anchor route so BGP knows to announce the route. This can be either a local null-route or static-route for the covering prefix, or an IP out of the prefix configured on an interface. So once BGP is configured, and establishes between both routers, the ISP side should see something similar to:
isp#sh ipv6 bgp nei 2001:db8:0:1::2 routes There are 1 accepted routes from neighbor 2001:db8:0:1::2 Searching for matching routes, use ^C to quit... Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH m:NOT-INSTALLED-MULTIPATH S:SUPPRESSED F:FILTERED s:STALE Prefix Next Hop Metric LocPrf Weight Status 1 2001:db8:1234::/48 2001:db8:0:1::2 1 140 0 E AS_PATH: 64501
And that should be it. You can obviously play around with peer-groups, route-maps, etc. Communities should work as long as your ISP offers them, so be sure to ask. Ideally there is at least a blackhole community in place. That should allow you to announce a specific range or IP that you want to have null-routed upstream in cases of abuse or attacks. That filter could look like either of the following, depending on how specific they allow you to announce:
ipv6 prefix-list as64501-ipv6-filter seq 1 permit 2001:db8:1234::/48 le 64
ipv6 prefix-list as64501-ipv6-filter seq 1 permit 2001:db8:1234::/48 le 128
With the obvious requirement that the BGP sessions would need to be configured as blackhole community enabled on both sides.