cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1775
Views
0
Helpful
3
Replies

IPV6 MP-BGP

Michael Johnson
Level 1
Level 1

I am trying to configure MP-BGP to advertise V6 prefixes via a V4 peering session. I was able to make this work

utilizing a non VRF configuration and address families. The solution requires dual stack configuration on the peering interface for V6

prefix next hop reachability, it also required a route map setting the V6 next hop attribute.

I would like to get this to work using a multi VRF configuration, my testing is via GNS3 using the 7200 platform and 12.2(33) service provider IOS.

When I configure this scenario the AFI capabilities are exchange as expected and the BGP update is received with the V6 prefix and correct next hop.

My problem is that the route is not installed and teh following messages are received:

*Jul 14 15:06:36.682: BGP(1): 1.1.1.2 rcv UPDATE w/ attr: nexthop 2001:1::2, origin i, metric 0, originator 0.0.0.0,
merged path 65001, AS_PATH 65001, community , extended community , SSA attribute
*Jul 14 15:06:36.694: BGPSSA ssacount is 0
*Jul 14 15:06:36.694: BGP(1): 1.1.1.2 rcv UPDATE about 2001:101::/64 -- DENIED due to: non-connected MP_REACH NEXTHOP;
*Jul 14 15:06:36.698: BGP: 1.1.1.2 Modifying prefix 2001:101::/64 from 1 -> 5 address

The problem is that the next hop is connected and available? So the reason for the route install failure is incorrect, thoughts?  related bug number  CSCtq26829

Also, I found this on the web, similar issue but not quite the same? According to this site this capability should work and may have some advantages

(http://ccie-in-3-months.blogspot.com/)

I realize I am using GNS3 and it may not react exactly the same as in a live network however I was hoping someone has done this before or could confirm it does or does not work.

mike

3 Replies 3

plumbis
Level 7
Level 7

Michael,

The bug you mentioned is XR only, so won't effect you running 12.2.33 code.

More importantly, what version of 12.2.33 are you running, including rebuild (SRD4, SRE3, ect)?

My first guess is that when you are doing peering in one AFI to send routes for another AFI the next hop on the prefixes is invalid and you have to apply an inbound route-map to set the next hop to be something valid for that protocol. An IPv6 route with an IPv4 next hop doesn't make much sense.

I am running  12.2(33)SRE4,

My config includes an inbound route-map that sets the appropriate next hop and is dual stack on the peering interface. In fact I have this working in a non vrf configuration no problems, it's the vrf configuration that now compalins with a config that works in non-vrf configuration.

Mike

Got it working, several issues but in the end it is all working now.

mike