07-15-2011 07:37 AM - edited 03-01-2019 02:27 PM
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
08-11-2011 01:01 PM
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.
08-12-2011 08:23 AM
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
08-12-2011 08:57 AM
Got it working, several issues but in the end it is all working now.
mike
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide