Are you sensing a theme lately? Since we covered the basics of the main IGPs (I'm an enterprise guy, so no IS-IS comments, please.), I thought I'd try to describe the basics of advertising IPv6 routes over BGP. Yet again, we're not going to do any route manipulation or change any of the 948284928 BGP attributes. We're just trying to get routes exchanged.
Configuration
There's no new version of BGP for IPv6 here. It's the standard BGP version 4 that we've all been using for years, but we're going to take advantage of the multiprotocol support (MPBGP, RFC 2858 RFC 4760). We'll get to the differences in a second, but the first thing to do is to set up the BGP process as normal.
Just as with the IGPs covered so far, the router ID needs to be set somehow. Let's just manually set it for now. We'll be routing on behalf of AS 65001.
Router(config)#router bgp 65001
Router(config-router)#bgp router-id 192.0.2.1
Since we're not using that archaic IPv4 any more, we need to disable IPv4 unicast, which is enabled by default when you configure MPBGP.
Router(config-router)#no bgp default ipv4-unicast
All is good so far? Now comes the part that's different from your standard BGPv4 deployment with your ISP. To enable the protocol for IPv6, we need to use the address-family directive. This tells BGP which of the several protocols that you want to use in MPBGP. We'll use IPv6, obviously; the others are well beyond our scope.
Router(config-router)#address-family ipv6
This will take your to the address family config mode which is where you can configure your neighbors and network statements just like you did in more traditional configurations of BGP. A difference here is that you have to activate the neighbor before the address family is enabled for it. Luckily, that's so easy I won't even explain it; I'm confident you can figure out which command does this. Heh. Let's peer with the router at fc00::2 using AS 65002 and advertise fc00:1::/64 to it, shall we?
Router(config-router-af)#neighbor fc00::2 remote-as 65002
Router(config-router-af)#neighbor fc00::2 activate
Router(config-router-af)#network fc00:1::/64
Piece of cake, right?
I've got to note that this is just one way to configure the IPv6 address family under MPBGP; there are other orders of command entry that can be used to get to the same config. That's actually evident if you look at the config after your'e done.
12345678910 router bgp 65001bgp router-id 192.0.2.1no bgp default ipv4-unicastbgp log-neighbor-changesneighbor FC00::2 remote-as 65002!address-family ipv6neighbor FC00::2 activatenetwork FC00:1::/64exit-address-family
You'll see that config items don't land in the order and place that you configured them. The end results are the same.
Checking Our Work
First, let's see if we have a neighbor adjacency. We're all used to running show ip bgp summary, but we're not running IPv4. The equivalent is show bgp ipv6 unicast summary. The whole unicast/multicast thing is beyond both the scope of this article and of my comfortable knowledge. 🙂
12345678910111213141516 Router#show bgp ipv6 unicast summaryBGP router identifier 192.0.2.1, local AS number 65001BGP table version is 3, main routing table version 32 network entries using 304 bytes of memory2 path entries using 152 bytes of memory3/2 BGP path/bestpath attribute entries using 372 bytes of memory1 BGP AS-PATH entries using 24 bytes of memory0 BGP route-map cache entries using 0 bytes of memory0 BGP filter-list cache entries using 0 bytes of memoryBitfield cache entries: current 1 (at peak 1) using 32 bytes of memoryBGP using 884 total bytes of memoryBGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secsNeighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcdFC00::2 4 65002 15 15 3 0 0 00:10:29 1Router#
We can see the neighbor is up and that we have a single prefix from that guy. Let's check out exactly which route that is with the show bgp ipv6 unicast neighbor fc00::2 routes command. That was a mouthful, eh?
1234567891011 Router#show bgp ipv6 unicast neighbors fc00::2 routesBGP table version is 3, local router ID is 192.0.2.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incompleteNetwork Next Hop Metric LocPrf Weight Path*> FC00:2::/64 FC00::2 0 0 65002 iTotal number of prefixes 1Router#
It looks like we have a route to fc00:2::/64 through that neighbor. That's a good thing since we're trying to exchange routes. The next question is whether we are sending any routes to the neighbor. Run show bgp ipv6 unicast neighbor fc00::2 advertised-routes (even more of a mouthful!) to find out.
1234567891011 Router#show bgp ipv6 unicast neighbors fc00::2 advertised-routesBGP table version is 3, local router ID is 192.0.2.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incompleteNetwork Next Hop Metric LocPrf Weight Path*> FC00:1::/64 :: 0 32768 iTotal number of prefixes 1Router#
That looks right. We're advertising the route to fc00:1::/64 just as we configured in our neighbor statement above. We're on a roll!
Finally, let's check the routing table to make sure that route from the neighbor landed there. Run show ipv6 route like we've done with the IGPs, and you should see prefix as a "B" like in the old days of IPv4.
123456789101112131415161718192021 Router#show ipv6 routeIPv6 Routing Table - 6 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGPU - Per-user Static route, M - MIPv6I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summaryO - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2D - EIGRP, EX - EIGRP externalC FC00::/64 [0/0]via ::, FastEthernet0/0L FC00::1/128 [0/0]via ::, FastEthernet0/0C FC00:1::/64 [0/0]via ::, FastEthernet0/1L FC00:1::1/128 [0/0]via ::, FastEthernet0/1B FC00:2::/64 [20/0]via FE80::C001:1FF:FE18:0, FastEthernet0/0L FF00::/8 [0/0]via ::, Null0Router#
Well, there it is. The only thing you may not have see is the concept of address families, but there's not much to that at all.
Send any as-path prepends questions to me.
Thanks a lot for this!,
However, different syntax and even lengths of commands are bearable, but I find it frustrating, that we can't refer peer by name (which we can easily define, while configuring peer) in show bgp ipv6 nei … commands. (Or am I missing something?)
With IPv6 it was ok, most of peer names were well know, but in a new world I find it hard to remember v6 addresses of my 6 BGP peers…
Please note that RFC 4760 obsoletes RFC 2858
Thanks, Brent. Updated to reflect the newer RFC.