Multiprotocol BGP (MP-BGP) Configuration

Lessons Discussion
41

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
42

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
43

Hello Bruce

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

Thanks again!

Laz

44

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.

45

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

46

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 !!

47

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

48

Hi Laz,

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

Thanks,
Shashi

1 Like
49

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
50

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
51

Hi John

i had exactly the same problem with this lab, usins IOS 7200 on GNS, i tried your solution and it works perfectly, thx ; )

1 Like
52

Hi Laz… I configured as your scenario and my routing table can’t install as the best route even if i configure next hop, and the next hop ip’s alrdy correct but any idea why can’t i install ?

53

Hello Min

Can you let us know more specifically where your problem lies? Which scenario have you implemented, the one from the lesson? And if so, which one? Can you tell us which prefix specifically you are having trouble with?

Let us know more and we’ll be able to help you further.

I hope this has been helpful!

Laz

54

I had the same issue with Min. After NextHop change with route-map; it showed in BGP table but not injected into Routing table.
As @zz.alnajjar post , changed to outbound configuration and it solved.

55

Hello Ike

Rene responds to the issue thoroughly here in this post:

I hope this has been helpful!

Laz

56

Yes, Thank you Lazaros, this is helpful, in & out now looks clear to me.

1 Like
57

Hi,
Is there a more detailed walkthrough of how EVPN / MP-BGP works? I want to get a better understanding of how it operates.

Thanks

58

Hello Shashank

If you want to go more in-depth into these technologies, one of the best ways to do so is to take a look at Cisco documentation. The following links should give you a good start:

I hope this has been helpful!

Laz

59

Are BGPv4 and MP-BGP different versions of BGP? From my current understanding, If you use certain functionality like AFIs for ipv4/ipv6 then the Cisco router will just send BGP packets that are MP-BGP(i.e. have extra fields that BGPv4 doesn’t have.)

60

Hello Justin

It’s important that we clarify some terms. BGPv4 is the latest and current version of BGP and is defined in RFC 4271 which was published in 2006. The v4 designation doesn’t have anything to do with IPv4.

Now this latest version of BGP is capable of carrying a wide range of IPv4 and IPv6 address families. This new capability includes various mutiprotocol extensions. This new capability of handling multiple protocols is called multiprotocol BGP or MP-BGP.

Sor BGPv4 is the current version of BGP while MP-BGP describes the capabilities of BGP to support these multiprotocol extensions.

Whenever you use features that include these multiprotocol extensions, then MP-BGP is being used. If you don’t you won’t see these extensions in the packets, but you’re still using BGPv4. Does that make sense?

I hope this has been helpful!

Laz