From: Pavel Bykov (slidersv@gmail.com)
Date: Fri Nov 07 2008 - 16:32:45 ARST
Ok, I just had to lab it out. I wen with simplest topology and would
continue on to expand it to introduce RR, if all worked. But it didn't.
Topology was R1---R3---R2, with R3 being the hub, mpls, mp-mpbgp and all the
basics. I used "haloween loopbacks" to emulate VRFs with different RTs but
same RDs and overlapping address space. I also used normal loopbacks, Lo10
on R1 and Lo20 on R2 in the same VRF, which emulated non-overlapping address
space.
First, the config (very straightforward)
R1 (spoke):
ip vrf TESTRD
rd 6:6
route-target both 1:1
!
interface Loopback10
ip vrf forwarding TESTRD
ip address 10.0.0.1 255.255.255.0
!
interface Loopback666
ip vrf forwarding TESTRD
ip address 6.6.6.6 255.255.255.255
!
router bgp 1
bgp router-id 172.16.0.1
bgp log-neighbor-changes
neighbor 172.16.0.3 remote-as 1
neighbor 172.16.0.3 update-source Loopback0
!
address-family ipv4 vrf TESTRD
network 6.6.6.6 mask 255.255.255.255
network 10.0.0.0 mask 255.255.255.0
!
address-family vpnv4
neighbor 172.16.0.3 activate
neighbor 172.16.0.3 send-community extended
!
---------------------------------------------
R2 (spoke):
!
ip vrf TESTRD
rd 6:6
route-target both 2:2
!
interface Loopback20
ip vrf forwarding TESTRD
ip address 20.0.0.1 255.255.255.0
!
interface Loopback666
ip vrf forwarding TESTRD
ip address 6.6.6.6 255.255.255.255
!
router bgp 1
bgp router-id 172.16.0.2
bgp log-neighbor-changes
neighbor 172.16.0.3 remote-as 1
neighbor 172.16.0.3 update-source Loopback0
!
address-family ipv4 vrf TESTRD
network 6.6.6.6 mask 255.255.255.255
network 20.0.0.0 mask 255.255.255.0
!
address-family vpnv4
neighbor 172.16.0.3 activate
neighbor 172.16.0.3 send-community extended
!
---------------------------------------------
R3 (Hub):
!
ip vrf TOR1
rd 1:1
route-target both 1:1
!
ip vrf TOR2
rd 2:2
route-target both 2:2
!
interface Loopback111
ip vrf forwarding TOR1
ip address 1.1.1.1 255.255.255.255
!
interface Loopback222
ip vrf forwarding TOR2
ip address 2.2.2.2 255.255.255.255
!
router bgp 1
bgp router-id 172.16.0.3
bgp log-neighbor-changes
neighbor 172.16.0.1 remote-as 1
neighbor 172.16.0.1 update-source Loopback0
neighbor 172.16.0.2 remote-as 1
neighbor 172.16.0.2 update-source Loopback0
maximum-paths 2
!
address-family ipv4 vrf TOR2
network 2.2.2.2 mask 255.255.255.255
exit-address-family
!
address-family ipv4 vrf TOR1
network 1.1.1.1 mask 255.255.255.255
exit-address-family
!
address-family vpnv4
neighbor 172.16.0.1 activate
neighbor 172.16.0.1 send-community extended
neighbor 172.16.0.2 activate
neighbor 172.16.0.2 send-community extended
exit-address-family
!
--------------------------------------------------
And now for the output. First, the pings:
R3#ping vrf TOR1 10.0.0.1
!!!!!
R3#ping vrf TOR2 20.0.0.1
!!!!!
R3#ping vrf TOR1 6.6.6.6
!!!!!
R3#ping vrf TOR2 6.6.6.6
.....
And now the VPNv4 routes, which explain it all:
R3#show ip bgp vpnv4 all
BGP table version is 11, local router ID is 172.16.0.3
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf TOR1)
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*>i6.6.6.6/32 172.16.0.1 0 100 0 i
*>i10.0.0.0/24 172.16.0.1 0 100 0 i
Route Distinguisher: 2:2 (default for vrf TOR2)
*> 2.2.2.2/32 0.0.0.0 0 32768 i
*>i20.0.0.0/24 172.16.0.2 0 100 0 i
Route Distinguisher: 6:6
* i6.6.6.6/32 172.16.0.2 0 100 0 i
*>i 172.16.0.1 0 100 0 i
*>i10.0.0.0/24 172.16.0.1 0 100 0 i
*>i20.0.0.0/24 172.16.0.2 0 100 0 i
Because BGP adds routing information to VRFs only after deciding on the best
path in VPNv4 table, the information is getting added only to one of the
local VRFs. Originally, I thought it would be added to VRF anyway and the
final decision would be made inside VRF. Now it all falls in correct places.
I tried to trick the system by assigning RD of 6:6 on R3 to VRF TOR2. That
had effect, that 6.6.6.6/32 was in both VRFs.. or so it seemed at first, but
with the detailed output it wasn't getting added to the VRF, but was under
output of "show ip bgp vpnv4 all". But even if it would be added, Next_hop
could cause problems.
On newer IOSes (i tried this on old IOSs) there is "maximum-paths" command
under address-family vpnv4, which i suspect might have influence on the
issue by selecting both locations as best and therefore importing them into
VRFs, and assigning the correct MPLS tag, because that is all we need in the
end.
Well, at least now the situation is clear :) I like questions like that.
On Fri, Nov 7, 2008 at 1:40 PM, Marko Milivojevic <markom@markom.info>wrote:
> > If you have two same VPNv4 addresses (overlapping
> > address space and same RDs on system A and system B) and they arrived on
> > system C, VPNv4 prefixes will be same, but other attributes will not.
> After
> > receiving VPNv4 information system C uses RT to decide to which VRF
> update
> > belongs to.
>
> It can actually create quite serious problems if you are using route
> reflectors in the network (which most of carriers do). In that
> scenario, RR's will be advertising only one of those VPN networks -
> the one that they consider to be the best. You will entirely lose
> connectivity to the other one from PE's peering with RR. Not at all
> desired :-).
>
> This is not black and white science :-).
>
> --
> Marko
> CCIE #18427 (SP)
> My network blog: http://cisco.markom.info/
>
-- Pavel Bykov ------------------------------------------------- Stop the braindumps! http://www.stopbraindumps.com/Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Mon Dec 01 2008 - 08:18:29 ARST