The MPLS-OPS Archive

["M. ELK" <elkou141061@hotmail.com>]

Rajiv & Piotr

Thank's for the clarification .
To summarize , on VRF Red will have :

         10.9.0.0/16     => null0
         10.9.1.0/24     => intf3
         10.9.2.0/24     => intf4
         10.10.0.0/16   =>null0
         10.10.1.0/24   =>intf1
         10.10.2.0/24   =>intf2

and VRF green is exaclty similar .

my wrong guess was that the comand "aggregate-address" as it will 
prevent/block the advertising
the more specific in MP-iBGP it will also prevent/block exporting  the more 
specific to the VRF on
the same PE .

As another (related) point :
assume we have VRF RED ,VRF green ,VRF blue in PE1 .
VRF red advertise 10.10.2.1/32 ,VRF gree 10.10.2.2/32 ,VRF blue advertise
10.10.2.3/32  ,all with RT 1:100 . 10.10.2.0/24 could  be  used as an 
aggregate
we have 254  VRF , VRF 1 ,VRF 2 ....VRF254 in the network .
VRF 1 ,to VRF 254 provide shared service . each advertise a /32 route  say 
with rt:200 .
those 254 route could be aggregated  in 10.10.1.0/24 .
In normal setup  :
VRF red import the 254 routes ,similarly for VRF green and VRF blue .
VRF 1 to VRF 254 will import 3 routes (from VRF green, RED and Blue) .

the requirement is to minimize the memory consumption on the PE's specially 
in PE1 .
we define VRF Dummy

Traffic directiion FROM (any of VRF1 ....VRF254)   TO (VRF green , blue or 
RED)  :

In VRF dummy , we import  rt:100 and advertise the aggregate 10.10.2.0/24
(by : ip route vrf dummy 10.10.2.0/24 null0 , redistribute static ) with 
rt:300 .
each VRF1 to VRF 254 import rt:300 .
the connectivity in this diretion is achieved and VRF1 to VRF254 import just 
one route each instead
of 3 .

In the other direction , ie: FROM (VRF green , blue or RED) TO (any of VRF1 
....VRF254)   :
VRF dummy import rt:200 ie: the 254 routes . and advertise just the 
aggregate 10.10.1.0/24
with rt:400 (by: ip route vrf dummy 10.10.1.0/24 null0 ,redistribute static 
) .
VRF green ,VRF Red and VRF blue import Rt:400 .
In VRF green the aggregate 10.10.1.0/24 will point to null0 (as i understood 
from your msg ) ,
similarly for VRF red and VRF blue and the connectivity is broken in this 
direction .

How to fix it ??

Could it be :
Associate LB100 with VRF dummy and "ip route vrf dummy 10.10.1.0/24 LB100" .
now in VRF green ,Red or blue will have 10.10.1.0/24 with next hop interface 
as LB100 .

my guess that if LB100 recieve a packet with destination not itself the 
action is to do L3
lookup in VRF dummy and by that the connectivity is achieved  .

Could you pls comments on the actual behavior of a loopback address when it 
recieve a packet
with destination is not the LB address itself .

Brgds
Rajiv Asati <rajiva@cisco.com>
>To: "M. ELK" <elkou141061@hotmail.com>
>CC: mpls-ops@mplsrc.com
>Subject: Re: [MPLS-OPS]: Aggregate routes Import & export within VRF's  on 
>the same PE's
>Date: Tue, 27 Jan 2004 13:25:17 -0500
>
>At 08:01 AM 1/27/2004, M. ELK wrote:
>
>>Say at PE1 we have the following config :
>>
>>ip  vrf red
>>rd 1:1
>>import 1:10
>>export 1:20
>>
>>ip route vrf red 10.10.1.0/24 intf1
>>ip route vrf red 10.10.2.0/24 intf2
>>
>>address-family ipv4 vrf red
>>redistribute static
>>aggregate-address 10.10.0.0  255.255.0.0
>>exit-address-family
>>
>>ip  vrf green
>>rd 1:2
>>import 1:20
>>export 1:10
>>
>>ip route vrf green 10.9.1.0/24 intf3
>>ip route vrf green 10.9.2.0/24 intf4
>>
>>address-family ipv4 vrf green
>>redistribute static
>>aggregate-address 10.9.0.0  255.255.0.0
>>exit-address-family
>>
>>
>>1- If we assume that any implementation should not differentiate between 
>>VRF's on different
>>    PE's and VRF's on the same PE's so :
>>    VRF red will have a route 10.9/16 ,and VRF green will have a route 
>>10.10/16 .
>>    is any implem able to do that ?
>>   if yes : say for 10.9/16 in VRF red , what will be the Next_hop 
>>interface ??? .
>
>Before going to the "red" VRF, please keep in mind that 10.9/16 will be 
>installed in the VRF RIB (of green) with the null0 outgoing interface since 
>it is an aggregated route. Of course, the component routes will be present 
>with the valid next-hops.
>So there will be three 10.9.0.0/16 addresses that will get advertised by 
>the BGP and will have following next-hops in the VRF RIB -
>         10.9.0.0/16     => null0
>         10.9.1.0/24     => intf3
>         10.9.2.0/24     => intf4
>
>Hence, the "red" VRF RIB will point to the same.
>
>
>>2- Specific to cisco implementation .
>>    guess the above as configured is not workable ,ie: 10.9/16 will not 
>>show in VRF red
>>    neither 10.10/16 in VRF green , is it correct ?
>
>No.
>Importing/exporting within VRFs is what the extranet application is all 
>about and should work fine.
>
>Cheers,
>Rajiv
>
>>   if yes : assume we added the following
>>   loopback 100 associated with VRF red .
>>   loopback 200 associated with VRF green .
>>   ip route vrf red 10.10./16 LB100
>>   ip route vrf green  10.9/16 LB200
>>
>>   is 10.9/16 will appear in VRF red with next_hop = LB200 ,similiarly
>>   10.10/16 will appear in VRF green with next_hop = LB100 .
>>
>>  say a ping request with source 10.10.1.1 and destination 10.9.1.1 
>>recieved at VRF red ,it will be
>>  routed to LB200 .   LB200 after a L3 lookup in VRF green will direct the 
>>packet to intf3 .
>>  The ping reply with source 10.9.1.1 and destination 10.10.1.1 is 
>>received at VRF green and
>>  routed to LB100 . LB100 after L3 lookup in VRF red will direct the 
>>packet to intf1 and connectivity
>>  between the 2 VRF is achieved .
>>
>>  is the above workable ???
>>  note : i have no access to a test bed to confirm the above .
>>
>>Brgds
>>
>>_________________________________________________________________
>>MSN 8 with e-mail virus protection service: 2 months FREE* 
>>http://join.msn.com/?page=features/virus
>>
>>-------
>>The MPLS-OPS Mailing List
>>Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
>>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
>
>

_________________________________________________________________
Rethink your business approach for the new year with the helpful tips here. 
http://special.msn.com/bcentral/prep04.armx

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml