Multiprotocol BGP (MP-BGP) Configuration

thank you. i appreciate your help

Hi Rene - why does MP-BGP and MPLS always seem to go hand in hand? Do you need MPLS to run MP-BGP? Are they mutually exclusive?

Hello Gareth

The major benefit of MP-BGP is the fact that it can route IPv4 and IPv6 unicast and multicast addresses. However, it’s connection to MPLS is primarily, and almost exclusively related to the use of MPLS VPN.

An MPLS VPN consists of a set of sites that are interconnected by means of an MPLS provider core network. At each site, there are one or more customer edge (CE) devices, which attach to one or more provider edge (PE) devices. PEs use the MP-BGP to dynamically communicate with each other. It is an integral part of the MPLS VPN architecture. MP-BGP is actually REQUIRED on the network to allow it to function.

I hope this has been helpful!

Laz

diff AS so the route-map to change the NEXTHOP has to be applied outbound not inbound i hv tested it

3 Likes

Hi,
I had worked this lab in IPV4 before but when I got to this I was confused a bit.

You had the following:
Capture

I see that you go into the address-family ipv4 and I am good there but then I see you do the no activate on the ipv6. Here is where I am confused; have yet to find granular details and also checking my kindle book for info as well:

Doyle, Jeff. Routing TCP/IP, Volume II: CCIE Professional Development: CCIE Professional Development: 2 (Kindle Location 15220). Pearson Education. Kindle Edition.

The Kindle books has this in bold at the top:

IPv4 and IPv6 Prefixes over an IPv4 TCP Session

From the title it seems to suggest that IPV4 and/or IPV6 create TCP sessions and you can send IPV6 prefixes as well as IPV4 prefixes over the session regardless of type.

Think of these as just prefixes in essence objects if you will that are being passed over TCP (transport layer) session.

below is a picture I found to help visually explain this from my kindle book as well.
Capture

Let me know if this is correct thinking.

I started thinking… IPV4 is 32 bytes and IPV6 is 128bytes… now I know we are talking about layer 4 which is the transport layer so I guess you just stick the 128byte into the transport layer TCP but then wouldn’t it be called TCP/IPV6 instead of TCP/IP?

I actually have never thought about IPV6 in regards to the OSI model…

Went back and read all the forums post a second time and now after I am on the right track I see that a few others was talking about this as well. Not sure why I didn’t pick it up the first time.

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