Multiprotocol BGP (MP-BGP) Configuration

Hello Brian,

With MP-BGP, there’s basically two things:

  • The session itself, established through IPv4 or IPv6 and TCP is the transport protocol.
  • The stuff we advertise…different address families: IPv4 unicast, IPv6 unicast, IPv6 unicast, IPv6 multicast, VPN routes, etc.

It’s best to see the stuff that we advertise as “objects” or something. Once a session is established, you can advertise whatever you want. It’s possible to have an IPv4 neighbor adjacency and advertise IPv6 prefixes or the other way around, an IPv6 neighbor adjacency and advertise IPv4 prefixes. It also makes sense…it’s better to have a single neighbor adjacency and advertise anything you need through that single session.

Technically, when you use IPv6 you can call it TCP/IPv6.

Rene

1 Like

Hi Rene
i receive configuration error

R1(config-router)#address-family ipv4
R1(config-router-af)#no neighbor 2001:db8:0:12::2 activate
% Specify remote-as or peer-group commands first
R1(config-router-af)#

Hi Rene
i solved it

R1(config-router-af)#no neighbor 2001:db8:0:12::2 remote-as 2 activate

1 Like

thank you
nice to knit you

1 Like

I came here looking for this information.

It doesn’t make sense to set the route-map for “in” bound traffic…

Can someone clarify if the keyword “out” was supposed to be used instead?

It makes sense to create the route-map that sets the IPv6 next-hop address for outbound traffic destined for 192.168.12.2?

Please explain Rene!!

Hi Brandon,

Both options are possible. This sentence is confusing though:

Both routers will now advertise their IPv6 address as the next hop for all prefixes that are advertised.

This isn’t correct since we fix the issue inbound, the routers still have no next hop to advertise. I just changed this sentence.

Let me explain this in detail. We can see what R1 advertises to R2:

R1#show ip bgp ipv6 unicast neighbors 192.168.12.2 advertised-routes 
BGP table version is 4, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>   2001:DB8::1/128  ::                       0         32768 i

Total number of prefixes 1

When R2 receives this prefix, there is no valid next hop, so it shows up like this:

*  2001:DB8::1/128  ::FFFF:192.168.12.1

To fix this, you have two options:

  • Fix it inbound on R1 with an inbound route-map like I did.
  • Fix it outbound on R2 with an outbound route-map.

This also applies the other way around for prefixes that R2 advertises to R1.

Both options work. Here’s an example of an outbound route-map:

R1(config)#route-map IPV6_MY_NEXT_HOP permit 10
R1(config-route-map)#set ipv6 next-hop 2001:DB8:0:12::1

R1(config)#router bgp 1
R1(config-router)#address-family ipv6
R1(config-router-af)#no neighbor 192.168.12.2 route-map IPV6_NEXT_HOP in
R1(config-router-af)#neighbor 192.168.12.2 route-map IPV6_MY_NEXT_HOP out

Delete the inbound route-map on R2:

R2(config)#router bgp 2
R2(config-router)#address-family ipv6
R2(config-router-af)#no neighbor 192.168.12.1 route-map IPV6_NEXT_HOP in

Reset BGP to speed things up:

R1#clear ip bgp *

Check R2:

R2#show ip bgp ipv6 unicast
BGP table version is 3, local router ID is 192.168.12.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>   2001:DB8::1/128  2001:DB8:0:12::1
                                                0             0 1 i
 *>   2001:DB8::2/128  ::                       0         32768 i

R2 has the correct next hop but this time we fixed it from the source (R1).

Both options work, I agree it might be “cleaner” to fix it outbound on R1 but both are valid options.

I hope this helps!

Rene

1 Like

Thanks for replying back.

I am probably thinking too hard about this, but if the next-hop IPv6 address is changed on R1 for ingress traffic, how does R2 learn that information so it can add the new next-hop address?

Hi Brandon,

With the inbound route-map, the only thing we change here is the next hop we use for the prefix so we know how to route. Let me explain:

Before the inbound route-map:

  • R1 advertises the 2001:DB8::1/128 prefix to R2.
  • R2 receives the 2001:DB8::1/128 prefix but can’t use it because it doesn’t know a next hop.

After the inbound route-map:

  • R1 advertises the 2001:DB8::1/128 prefix to R2.
  • R2 receives the 2001:DB8::1/128 prefix and changes the next hop information to the next hop address we specify in the route-map
  • R2 wants to route a packet to 2001:DB8::1/128. It checks its routing table for a matching entry, finds 2001:DB8::1/128 and uses 2001:DB8:0:12::1 as the next hop.
  • Mission completed

With the outbound route-map, it’s different. In that case, R1 adds the correct next hop to the prefix and advertises it to R2. R2 then learns the prefix with the correct next hop that it can use.

Does that make sense?

Rene

1 Like

Yes it makes sense. Thank you!

1 Like

Hi
I which case the iv4 bgp peering to advertise ipv6 prefixes would be valid or useful?
Isn´t better to just use ipv6 bgp peering and problem solved?

Hello Rafael

Yes, you’re right you could simply use IPv6 peering, however, the example itself shows how you can do it using IPv4 for neighbor peering. This may be the case where IPv6 has not yet been been adopted on the network between the routers, while you want to maintain IPv6 addresses behind each router.

Because there are so many combinations and situations found within networks today, every situation must be addressed, so this is just another example where certain restrictions exist, and you have to work around them.

I hope this has been helpful!

Laz

1 Like

Multiprotocol Reachable Network Layer Reachability Information (MP_UNREACH_NLRI) in the lesson should have Unreachable as the second word. It doesn’t match the acronym. There is also MP_REACH_NLRI in the RFC for (more or less) the opposite function.

1 Like

Hello Bruce

Thanks for pointing that out, I’ll let Rene know.

Thanks again!

Laz

Hi Rene,

I was trying to configure ipv6 bgp relation and advertise ipv4 routes on them, but was not happening. Can you please take a look at below config and suggest of any wrong/missing config?

               R1 <---------------------> R2

R1#sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.0.1     YES manual up                    up
Loopback1                  172.16.1.1      YES manual up                    up 

R1#sh ipv6 int br
FastEthernet0/0        [up/up]
    FE80::C801:2BFF:FE7C:8
    FD00:0:0:1000::1
R1#sh runn | sec bgp
router bgp 1
 bgp log-neighbor-changes
 neighbor FD00:0:0:1000::2 remote-as 2
 !
 address-family ipv4
  network 172.16.1.1 mask 255.255.255.255
  neighbor FD00:0:0:1000::2 activate
 exit-address-family

R2#sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.0.2     YES manual up                    up
Loopback1                  172.16.2.2      YES manual up                    up

R2#sh ipv6 int br
FastEthernet0/0        [up/up]
    FE80::C802:2BFF:FED8:8
    FD00:0:0:1000::2

R2#sh runn | s bgp
router bgp 2
 bgp log-neighbor-changes
 neighbor FD00:0:0:1000::1 remote-as 1
 !
 address-family ipv4
  network 172.16.2.2 mask 255.255.255.255
  neighbor FD00:0:0:1000::1 activate
 exit-address-family

R2#sh ip bgp summ
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
FD00:0:0:1000::1
                4            1      30      31        2    0    0 00:24:19        0

R2#sh ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 ***>  172.16.2.2/32    0.0.0.0                  0         32768 i**

R2#sh ip bgp neighbors FD00:0:0:1000::1 advertised-routes
**Total number of prefixes 0**

As you can see above even though R2 has 172.16.2.2/32 route in its table its not advertising to neighbor R1.

Hello Shashidhar

In order for BGP to successfully advertise a route to its BGP neighbor, it must be in the local routing table, and it must match the subnet mask exactly. Now the route to 172.16.2.2 is in your routing table since it is a directly connected route. However, in the network command you are using /32. Although I don’t see it in your post, I suspect that you used a subnet mask of /24 in the configuration of the loopback address? If that is the case, then BGP will not advertise the network. Ensure that your subnet mask for the loopback interface, and the subnet mask used in the BGP network command are the same.

I hope this has been helpful!

Laz

Hi Laz,

Sorry I forgot to mention the route for the loopback 172.16.2.2. I’m using a /32 subnet for that, please see the route:

R2#sh ip route 172.16.2.2
Routing entry for 172.16.2.2/32
Known via “connected”, distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:* directly connected, via Loopback1
Route metric is 0, traffic share count is 1

But the route is not getting advertised !!

Hello Shashidhar

I went in and labbed this up for myself and I got the same results as you. Digging a little deeper, it seems that what you and I experienced is normal behaviour :thinking:.

I did a debug on BGP updates on R2 (debug ip bgp updates) and then cleared the BGP peering (clear ip bgp *). The resulting syslog message I get is:

*Mar 27 06:03:59.624: BGP(0): Can't advertise 2.2.2.2/32 to FD00:0:0:1000::1 with NEXT_HOP 253.0.0.0

In my case, my loopback address on R2 is 2.2.2.2. From the above you can see that it can’t advertise this address because it has problems determining the next hop IP address to share with its BGP neighbor.

Now what it’s trying to do is encode the next hop IP address, but it is failing, because the next hop IP address is IPv6. Ideally, the next hop address should be of the same type as the prefix. In this case, the next hop IP should be the IPv4 address of the interface on R2, but it’s not working. Why? Simply because IOS doesn’t support it. :face_with_raised_eyebrow:

Digging deeper (and with help from @ReneMolenaar), I have found that some operating systems support the encoding of a different version IP address, and some don’t. In this case Cisco IOS doesn’t support this, but Nexus NX-OS does.

Furthermore, this is described in RFC 5549 where it states that:

By default, if a particular BGP session is running over IPvx (where
IPvx is IPv4 or IPv6), and if the BGP speaker sending an update is
putting its own address in as the next hop, then the next hop address
SHOULD be specified as an IPvx address, using the encoding rules
specified in the AFI/SAFI definition of the NLRI being updated. This
default behavior may be overridden by policy.

When a next hop address needs to be passed along unchanged (e.g., as
a Route Reflector (RR) would do), its encoding MUST NOT be changed.
If a particular RR client cannot handle that encoding (as determined
by the BGP Capability Advertisement), then the NLRI in question
cannot be distributed to that client. For sound routing in certain
scenarios, this will require that all the RR clients be able to
handle whatever encodings any of them may generate.

Now we’re not using an RR in this case, but the concept is the same.

One of the things I really like about this forum is that it is an opportunity for me to learn. I love digging deeper to understand why things are the way they are. Thanks for giving me another opportunity to do that!!

I hope this has been helpful!

Laz

Hi Laz,

Thanks for spending considerable time on this and helping me understand the underlying concept.

Thanks,
Shashi

1 Like

Hi Rene,

I’ve replicated this lab using another topology used for an IPv6 BGP filter.
I have not used any route-map to set the next-hop but it seem work correctly…can you help me to understand why?
( I’ve edited the prefix-list SMALL_NET on R2 to allow the route in this lab )

R1#show ip bgp ipv6 unicast
...
 *>  2001:DB8::1/128  ::                       0         32768 i
 *   2001:DB8::2/128  ::FFFF:2.2.2.2           0             0 2 i
 *>                   2001:DB8:0:12::2

R2#show ip bgp ipv6 unicast
 *   2001:DB8::1/128  ::FFFF:1.1.1.1           0             0 1 i
 *>                   2001:DB8:0:12::1
                                                0             0 1 i
 *>  2001:DB8::2/128  ::                       0         32768 i

R1#show run | section bgp
router bgp 1
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 2
 neighbor 2.2.2.2 ebgp-multihop 2
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2001:DB8:0:12::2 remote-as 2
 !
 address-family ipv4
  neighbor 2.2.2.2 activate
  no neighbor 2001:DB8:0:12::2 activate
 exit-address-family
 !
 address-family ipv6
  network 2001:DB8::1/128
  network 2001:DB8:0:1::/64
  network 2001:DB8:0:11::/64
  network 2001:DB8:0:111::/64
  network 2001:DB8:0:1111::/96
  neighbor 2.2.2.2 activate
  neighbor 2001:DB8:0:12::2 activate
  neighbor 2001:DB8:0:12::2 route-map PREPEND out
 exit-address-family
R2#show run | section bgp
router bgp 2
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 ebgp-multihop 2
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 2001:DB8:0:12::1 remote-as 1
 !
 address-family ipv4
  neighbor 1.1.1.1 activate
  no neighbor 2001:DB8:0:12::1 activate
 exit-address-family
 !
 address-family ipv6
  network 2001:DB8::2/128
  neighbor 1.1.1.1 activate
  neighbor 2001:DB8:0:12::1 activate
  neighbor 2001:DB8:0:12::1 prefix-list SMALL_NET in
  neighbor 2001:DB8:0:12::1 route-map MY_FILTER in
  neighbor 2001:DB8:0:12::1 filter-list 11 in
 exit-address-family


R1#show running-config | section route-map
  neighbor 2001:DB8:0:12::2 route-map PREPEND out
route-map SET_MED permit 10
 set metric 2323
route-map PREPEND permit 10
 match ipv6 address prefix-list FIRST_LO
 set as-path prepend 11
route-map PREPEND permit 20
R1#show running-config | section prefix-list
ipv6 prefix-list FIRST_LO seq 5 permit 2001:DB8:0:1::/64

R2#show running-config | section route-map
  neighbor 2001:DB8:0:12::1 route-map MY_FILTER in
route-map MY_FILTER deny 10
 match ipv6 address THIRD_LOOPBACK
route-map MY_FILTER permit 20
R2#show run | section access-list
ip as-path access-list 11 permit ^1$
ipv6 access-list THIRD_LOOPBACK
 permit ipv6 2001:DB8:0:11::/64 any

R2#show running-config | section prefix-list
  neighbor 2001:DB8:0:12::1 prefix-list SMALL_NET in
ipv6 prefix-list SMALL_NET seq 2 permit 2001:DB8::1/128
ipv6 prefix-list SMALL_NET seq 5 permit 2001::/16 le 64

Hello Giovanni

In your configurations, you have created a neighbor adjacency for BGP using both the IPv4 and IPv6 addresses: On R1 you have:

neighbor 2.2.2.2 remote-as 2
neighbor 2001:DB8:0:12::2 remote-as 2

And you have the counterpart configuration on R2. This results in a BGP table with the following:

R1#show ip bgp ipv6 unicast
...
 *>  2001:DB8::1/128  ::                       0         32768 i
 *   2001:DB8::2/128  ::FFFF:2.2.2.2           0             0 2 i
 *>                   2001:DB8:0:12::2

You have two next hop addresses for the 2001:DB8::2/128 prefix. The first is FFFF:2.2.2.2 which is meaningless, and is based on the IPv4 next hop address, and the other is 2001:DB8:0:12::2 which is obtained using the IPv6 neighbor adjacency created. So this one is used and is used successfully.

In the lesson, there was no IPv6 adjacency, and the route map was used to modify the next hop to an IPv6 address.

I hope this has been helpful!

Laz

1 Like