[c-nsp] multi-vrf CE - importing and exporting via ibgp witha RR PE

Oliver Boehmer (oboehmer) oboehmer at cisco.com
Fri Feb 24 02:09:01 EST 2006


Anton,

first of all: We don't support iBGP as PE-CE routing protocol. You might
be able to get it to work (with some tricks with the next-hop), but it's
not supported. Your problem might actually be attributed to this (a
"debug ip bgp update" on the CE should tell you if the routes are
received, and if they are, why they are dropped).

Regarding your question: We are working on being able to set the
router-id per vrf (not yet released, I think), not sure if this would
help.

Why are they not showing in ".. received-routes"? Possibly because we
drop them too early to show them there.. Not sure. I think we also don't
show prefixes which fail the AS-path loop detection check in
"received-routes", could be the same thing.

	oli



Anton Smith <> wrote on Friday, February 24, 2006 3:58 AM:

> Hi again,
> 
> I've just realised (with some help) that it is probably the
> originator-id/router-id loop prevention mechanism causing the problem
> I described earlier.
> 
> So now my question becomes: how do I set different router-ids for
> different VRFs - and, why don't the routes show in neighbor x.x.x.x
> received-routes with soft reconfig turned on?
> 
> Regards,
> Anton
> 
>
========================================================================
==
> 
> 
> Hi all,
> 
> Imagine the following setup:
> 
> 
> --- CE --- PE --- VPN-ipv4 core
> 
> The =s represent vlans.
> 
> The PE has a VRF configured on it that contains at least two
> interfaces (the two vlans between CE and PE). IBGP sessions are
> configured between the CE and PE, and the PE has route reflection
> enabled. 
> 
> Humour me and imagine that I want the two vrfs on the CE to route
> traffic to each other via the VPN rather than leaking routes to each
> other locally.
> 
> The problem is that the two vrfs on the CE receive all routes from the
> PE from the rest of the VPN, and install them, but *NOT* routes from
> each other. Keep in mind that I have route reflection running on the
> PE and it is working (other 'normal' CE hanging off the PE are able to
> exchange routes using IBGP).
> 
> Routes from each VRF on the CE are successfully being advertised to
> the PE, and are being installed in the VPN's routing table. I have
> also checked that they are being advertised correctly to each vrf on
> the CE from the PE. I.e. the PE is advertising 10.13.0.0/24 to vrf 2
> (via it's IBGP session with 10.0.0.0) and 10.13.1.0/24 to vrf 1 (via
> it's IBGP session with 10.0.0.2).
> 
> I can't see anything different about the routes whatsoever. The PE
> strips extended communities inbound, and actually I'm not sure if I
> need the route-target export/import statements on the CE, since it
> should be straight ipv4 (although I do notice that it is sticking
> route target extended communities on the routes it sends to the PE).
> 
> I have turned on soft reconfiguration, and run:
> show ip bgp vpnv4 vrf vrf2 neighbors 10.0.0.3 received-routes - but I
> still don't see anything that originated from the other vrf.
> 
> Is there something obvious that I am missing here? Any help would be
> much appreciated (and yes, I appreciate that what I am trying to do
> is a little bit strange but as I mentioned earlier, please humour me).
> 
> Regards,
> Anton
> 
> There are two vrfs are configured on the CE, like so:
> 
> ip vrf vrf1
>   rd 100:1
>   route-target export 1:1
>   route-target import 1:1
> !
> ip vrf vrf2
>   rd 200:2
>   route-target export 1:2
>   route-target import 1:2
> 
> interface GigabitEthernet0/0.130
>   description vrf 1 LAN interface
>   encapsulation dot1Q 130
>   ip vrf forwarding vrf1
>   ip address 10.13.0.1 255.255.255.0
> 
> interface GigabitEthernet0/0.131
>   description vrf 2 LAN interface
>   encapsulation dot1Q 131
>   ip vrf forwarding vrf2
>   ip address 10.13.1.1 255.255.255.0
> 
> interface GigabitEthernet0/1.274
>   description vrf 1 WAN interface
>   encapsulation dot1Q 274
>   ip vrf forwarding vrf1
>   ip address 10.0.0.0 255.255.255.254
> 
> interface GigabitEthernet0/1.292
>   description vrf 2 WAN interface
>   encapsulation dot1Q 292
>   ip vrf forwarding vrf2
>   ip address 10.0.0.2 255.255.255.254
> 
> router bgp XXXXX
> bgp router-id x.x.x.x
> bgp log-neighbor-changes
> 
> address-family ipv4 vrf vrf1
>   redistribute connected
>   redistribute static
>   neighbor 10.0.0.1 remote-as XXXXX
>   neighbor 10.0.0.1 activate
>   neighbor 10.0.0.1 send-community
>   no auto-summary
>   exit-address-family
> 
> 
> address-family ipv4 vrf vrf2
>   redistribute connected
>   redistribute static
>   neighbor 10.0.0.3 remote-as XXXXX
>   neighbor 10.0.0.3 activate
>   neighbor 10.0.0.3 send-community
>   no auto-summary
>   exit-address-family
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



More information about the cisco-nsp mailing list