BGP by default, only has the IPv4 unicast family activated so you can advertise IPv4 unicast prefixes, that’s it. By enabling other address families, you can advertise things like multicast routes or VPN routes. BGP doesn’t use multicast addresses itself, it will always use a TCP session between two neighbors, that’s it.
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?
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!
diff AS so the route-map to change the NEXTHOP has to be applied outbound not inbound i hv tested it
I had worked this lab in IPV4 before but when I got to this I was confused a bit.
You had the following:
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.
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.
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.
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)#
i solved it
R1(config-router-af)#no neighbor 2001:db8:0:12::2 remote-as 2 activate
nice to knit you
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!!
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 *
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!
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?
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?
Yes it makes sense. Thank you!
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?
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!
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.
Thanks for pointing that out, I’ll let Rene know.
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.