SV: [c-nsp] MPLS: Route Leaking Between Different VRFs ondifferent PE's

E.T.Metz at telecom.tno.nl E.T.Metz at telecom.tno.nl
Thu Aug 11 08:24:57 EDT 2005


All BGP routes in the VRF seem to be internal (distance 200 and
"internal"). In general iBGP routes are not re-advertised by a BGP
speaker to its iBGP peers, the exception being the route reflector. So
it seems you are experiencing normal BGP behavior here.

You should see all desired routes routes in the MGMT VRF if you apply
the export logic to all VRFs (all PEs) of a customer VPN (e.g. "A"), as
also indicated earlier by Clinton.

[in the odd case you have iBGP between PE and CE I would suggest
replacing this by eBGP or another protocol. using iBGP is possible (eg
by making the CE a RR-client of the PE) but not a recommended practice I
would think]

cheers,
	eduard

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of 
> Danielsen.Peter Christian PED
> Sent: woensdag 10 augustus 2005 21:55
> To: cisco-nsp at puck.nether.net
> Subject: VS: SV: [c-nsp] MPLS: Route Leaking Between 
> Different VRFs ondifferent PE's
> 
>  > 
> > I can not learn routes learnd from the CE .... 
> > 10.9.133.128/25 is a CE announced route .. All route are 
> > announced/learned with BGP... 
> > 
> > R2#sh ip bgp vpnv4 vrf VRF-B 10.9.133.49/32 BGP routing table 
> > entry for 6834:10030:10.9.133.49/32, version 116453
> > Paths: (1 available, best #1, table VRF-B)
> >   Advertised to update-groups:
> >      1
> >   Local
> >     0.0.0.0 from 0.0.0.0 (195.50.59.12)
> >       Origin incomplete, metric 0, localpref 100, weight 
> > 32768, valid, sourced, best
> >       Extended Community: RT:1:2 RT:1:3
> > 
> > 
> > R2#sh ip bgp vpnv4 vrf VRF-B 10.9.133.32/30 BGP routing table 
> > entry for 1:2:10.9.133.32/30, version 115598
> > Paths: (2 available, best #2, table VRF-B)
> >   Not advertised to any peer
> >   Local
> >     195.50.59.9 (metric 20) from 195.50.59.8 (195.50.59.8)
> >       Origin incomplete, metric 0, localpref 100, valid, internal
> >       Extended Community: RT:1:2
> >       Originator: 195.50.59.9, Cluster list: 195.50.59.8
> >   Local
> >     195.50.59.9 (metric 20) from 195.50.59.9 (195.50.59.9)
> >       Origin incomplete, metric 0, localpref 100, valid, 
> > internal, best
> >       Extended Community: RT:1:2
> > 
> > R2#sh ip bgp vpnv4 vrf VRF-B 10.9.133.128/25 BGP routing 
> > table entry for 1:2:10.9.133.128/25, version 115552
> > Paths: (2 available, best #2, table VRF-B)
> >   Not advertised to any peer
> >   65001
> >     195.50.59.8 (metric 30) from 195.50.59.8 (195.50.59.8)
> >       Origin incomplete, metric 0, localpref 100, valid, internal
> >       Extended Community: RT:1:2
> >   65001
> >     195.50.59.9 (metric 20) from 195.50.59.9 (195.50.59.9)
> >       Origin incomplete, metric 0, localpref 100, valid, 
> > internal, best
> >       Extended Community: RT:1:2
> > 
> > .-/Peter
> > 
> > > -----Oprindelig meddelelse-----
> > > Fra: Clinton Work [mailto:clinton at scripty.com]
> > > Sendt: 10. august 2005 15:41
> > > Til: Danielsen.Peter Christian PED
> > > Emne: Re: SV: [c-nsp] MPLS: Route Leaking Between 
> Different VRFs on 
> > > different PE's
> > > 
> > > 
> > > To be clear, you can only export routes learned from the CE or 
> > > directly connected in the VRF. Is the 10.9.133.32 route 
> > learned from 
> > > the CE in VRF-B or from another PE which has a site in VRF-B?
> > > 
> > > What do these commands show?
> > > show ip bgp vpnv4 vrf vrf-b 10.9.133.49/32 show ip bgp 
> > vpnv4 vrf vrf-b 
> > > 10.9.133.32/30
> > > 
> > > 
> > > Danielsen.Peter Christian PED wrote:
> > > >  
> > > > Thanks .. Tried that, it particular works,
> > > > 
> > > > If the export map I attach to the VRF on PE1 I kan only 
> > see direct 
> > > > connecet interface's and not route's annonunced into the
> > > VRF for a CE
> > > > route..
> > > > 
> > > > Route Show in VRF-B
> > > >      10.0.0.0/8 is variably subnetted, 5 subnets, 4 masks
> > > > B       10.9.133.128/25 [200/0] via 10.50.59.9, 00:06:46
> > > > B       10.9.133.36/30 [200/0] via 10.50.59.8, 00:06:46
> > > > B       10.9.133.32/30 [200/0] via 10.50.59.9, 00:06:46
> > > > B       10.9.133.40/29 [200/0] via 10.50.59.9, 00:06:46
> > > > C       10.9.133.49/32 is directly connected, Loopback10
> > > > 
> > > > Routes show in Management VRF.
> > > >      10.0.0.0/30 is subnetted, 1 subnets
> > > > B       10.9.133.49 is directly connected, 00:00:27, Loopback10
> > > > 
> > > > Access-list / Route map
> > > >  route-map VRF-B permit 10
> > > >  match ip address 16
> > > >  set extcommunity rt  1:3 additive
> > > > !
> > > >  access-list 16 permit 10.9.133.49
> > > >  access-list 16 permit 10.9.133.128 0.0.0.127 access-list
> > > 16  permit
> > > > 10.9.133.32 0.0.0.3
> > > >  
> > > >  Any ider
> > > >  
> > > >  ./-Peter
> > > >  
> > > > 
> > > >>>-----Oprindelig meddelelse-----
> > > >>>Fra: Clinton Work [mailto:clinton at scripty.com]
> > > >>>Sendt: 9. august 2005 20:26
> > > >>>Til: Danielsen.Peter Christian PED
> > > >>>Cc: cisco-nsp at puck.nether.net
> > > >>>Emne: Re: [c-nsp] MPLS: Route Leaking Between 
> Different VRFs on 
> > > >>>different PE's
> > > >>>
> > > >>>
> > > >>>You want to do the following for each customer VRF.
> > > >>>
> > > >>>ip vrf VRF-B
> > > >>>  desc Customer B
> > > >>>  rd 1:2
> > > >>>  export map B-MGMT
> > > >>>  route-target export 1:2
> > > >>>  route-target import 1:2
> > > >>>  route-target import 1:3      # for mgmt routes
> > > >>>
> > > >>>route-map B-MGMT permit 10
> > > >>>  match ip address <acl for customer mgmt routes>
> > > >>>  set extcommunity rt  1:3 additive
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>Danielsen.Peter Christian PED wrote:
> > > >>>
> > > >>>>Hi .. 
> > > >>>>
> > > >>>>I have tre different VRFs VRF-A, VRF-B and VRF-C, VRF-C is my 
> > > >>>>management VRF, I need to attach a export map on VRF-A and
> > > >>>
> > > >>>VRF-B, so I
> > > >>>
> > > >>>>can control witch networks will be leaked over in my
> > > >>>
> > > >>>management VRF-C ..
> > > >>>
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > ______________________________________________________________
> > > _________________________
> > > > www.kmd.dk   www.kundenet.kmd.dk   www.eboks.dk   
> > > www.civitas.dk   www.netborger.dk www.organisator.dk
> > > > 
> > > > Hvis du har modtaget denne mail ved en fejl vil jeg gerne,
> > > at du informerer mig og sletter den.
> > > > KMD skaber it-services, der fremmer effektivitet hos det
> > > offentlige, erhvervslivet og borgerne.
> > > > 
> > > > If you received this e-mail by mistake, please notify me
> > > and delete it. Thank you.
> > > > Our mission is to enhance the efficiency of the public
> > > sector and improve its service of the general public. 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > 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/
> > > 
> > > --
> > > ===================================================
> > > Clinton Work	clinton at scripty.com
> > > Calgary, AB
> > > 
> 
> 
> 
> 
> ______________________________________________________________
> _________________________
> www.kmd.dk   www.kundenet.kmd.dk   www.eboks.dk   
> www.civitas.dk   www.netborger.dk www.organisator.dk
> 
> Hvis du har modtaget denne mail ved en fejl vil jeg gerne, at 
> du informerer mig og sletter den.
> KMD skaber it-services, der fremmer effektivitet hos det 
> offentlige, erhvervslivet og borgerne.
> 
> If you received this e-mail by mistake, please notify me and 
> delete it. Thank you.
> Our mission is to enhance the efficiency of the public sector 
> and improve its service of the general public. 
> 
> 
> _______________________________________________
> 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