The MPLS-OPS Archive

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

Miguel

It is clear .
What U are asking is to consolidate the several e-BGP into a single MP-eBGP 
.
ASBR2 will associate the VPN Prefix recieved  by the MP-eBGP to a specific 
VRF (say VRFa' ) by
watching the next-hop IP address (say IPa).
ASBR2 will find out which VRF to associate by finding a VRF where their is 
an interface
(Ia' with address IPa' ) which is directly connected to IPa .

ASBR2 will install the IP4 prefix  in VRFa' as static route pointing to 
Ia/IPa . and auto such prefix
will be exported by MP-iBGP within AS2 .


i guess all the trick is the "Association" rule used by ASBR2 .
Why not use other simpler "Association" rule such as advertising extra BGP 
attribute .
(say new attribute to carry VPN ID or use the community attribute )
example :
we config VRFa' by special new command say "Associate Community A " .
when ASBR2 recieve a VPN Prefix over the MP-eBGP with community "A" it will 
auto install
it as static address in VRFa' .

Also we need to think about the fall-back , ie: if interface Ia' is down 
what is the requested
action from ASBR2 ?
Abort the association and now we have no connectivity between the 2 parts of 
VPN A .
or
return to the usual procedure (without association) bypassing the FW .

If the interface between VRFa in ASBR1 and VRFa' is Ethernet so ASBR2 have 
no way to
find out if IA is down and we have a black hole .

My guess , that the extra e-bgp is small price to pay for this special 
requirement . i also guess
that the manufacturer will never implement such requirement (they will 
suggest upgrade
to biger box to keep with the issue of many e-bgp session ) .

U indicated that the issue U faced with e-BGP is "re-establishment of BGP 
sessions" .
Do U mean when such condition happened (re-initialization "N" number of 
e-BGP ) , are U facing
long convergence time or the box themself (ASBR1 or ASBR2) crash/unstable  
(BGP session get
reseted ..etc ) due to the sharp increase in the CPU load or both .

Brgds
>From: Miguel Cros Cecilia <miguel.cros@gmail.com>
>Reply-To: Miguel Cros Cecilia <miguel.cros@gmail.com>
>To: "M. ELK" <elkou141061@hotmail.com>
>CC: mpls-ops@mplsrc.com
>Subject: Re: [MPLS-OPS]: Inter-AS Provider Option A+Option B
>Date: Sun, 29 May 2005 21:20:58 +0200
>
>It is more or less as you proposed, but the difference is that we need to
>ex-change
>all the VPN prefixes through the MP-eBGP session. Not e-BGP sessions per
>VRF.
>
>Trying to avoid distraction, I don't reflect in the diagrams the IP box
>(Firewalls, BW Managers) that
>are in the IP paths (individual interfaces per VRF).
>
>What we have deployed right now:
>* One eBGP session per VRF (Option A).
>* Control Plane Path is the same that Forwarding Plane. (between ASBR's)
>
>  +------------+ +-------------+
>  |ASBR/PE1 | | ASBR/PE2|
>  | | | |
>  | +---+ +---+ |
>  | | V0|<-------eBGP-------->| V0| |
>  | +---+ +---+ |
>  | | V1|<-------eBGP-------->| V1| |
>  | +---+ +---+ |
>  | | V2|<-------eBGP-------->| V2| |
>  | +---+ +---+ |
>  | ...| |... |
>  | +---+ +---+ |
>  | |V99|<-------eBGP-------->|V99| |
>  | +---+ +---+ |
>  | | | |
>  +------------+ +-------------+
>
>What we needed:
>* Only one MP-eBGP session (Option B).
>* Control Plane Path can be different that the Forwarding Plane. (between
>ASBR's)
>By default: The data forwarding will go through the MPLS Path. A common
>interface
>between the ASBR for all the VRF.
>But: For specific VRF (match RT) we'll change the Data forwarding to
>interfaces
>dedicated to individual VRF. (set ip next-hop).
>
>
>  +-----------------------------+
>  | Route-map/Policy-Statements |
>  |change the IP Next-Hop to |
>  ----|the VRF dedicated interface |
>  | +-----------------------------+
>  | |
>  | |
>  | |
>  | |
>  v .....MP-eBGP....... v
>  +------------+/ MPLS Path \+-------------+
>  |ASBR/PE1 +=====================+ ASBR/PE2|
>  | | | |
>  | +---+ +---+ |
>  | | V0|---------------------| V0| |
>  | +---+ +---+ |
>  | | V1|---------------------| V1| |
>  | +---+ +---+ |
>  | | V2----------------------| V2| |
>  | +---+ +---+ |
>  | ...| |... |
>  | +---+ +---+ |
>  | |V99|---------------------|V99| |
>  | +---+ +---+ |
>  | | | |
>  +------------+ +-------------+
>
>[1]
>Examining one prefix advertised by MP-eBGP from ASBR/PE1 to ASBR/PE2
><RDa:pa, RTa, IPa, La>
>RDa:pa is the VPN prefix
>RTa represents the Route-Target(s)
>IPa Next-Hop IP (here the IP of ASBR/PE1)
>La MPLS Label
>
>[2]
>With the route-map/policy-statement matching Route-Target, we would change
>the Next-HOP IP to <IPb>
>which is an IP Local to the ASBR/PE2 in the VRF Va.
>What we are asking the vendors is that when IP Next-HOP change from MPLS
>path to IP Path to suppress the received Label (La) from ASBR/PE1.
>
>[3]
>When this prefix has to be announced to RR (AS2) a new label would be
>created
><RDa:pa, RTa, IPl2a, Lb>
>RDa:pa is the VPN prefix
>RTa represents the Route-Target(s)
>IPl2a Next-Hop IP (here the ASBR/PE2 Loopback)
>Lb MPLS Label
>
>
>
>  +---------+RDa:pa,RTa,IPa,La+---------+
>  | |---------------->| |RDa:pa,RTa,IPl2,Lb
>  | |IPa | |-------+
>  | ASBR | | ASBR | |
>  | PE1 | | PE2 | |
>  | | | | |
>  | +--|IPb |------- | |
>  | |Va|-----------------|VRF va| | |
>  +---------+ +---------+ +-----+
>  | |
>  | RR |
>  | AS2 |
>  +-----+
>
>
>Regarding Manufacturer replies, we are providing additional info, but still
>waiting for a response.
>
>Some times they say:
>* you are the first customer to ask for this.
>* other they say that other customers have already asked.
>
>With this e-mail I wanted to check if someone shares the need, because I
>think
>it would help to "convince" the manufacturers to implement it.
>
>I hope I clarified with this second e-mail the topology.
>
>
>On 5/29/05, M. ELK <elkou141061@hotmail.com> wrote:
> >
> > Miguel
> >
> > Not very clear how U could achieve this .
> > If Possible , pls explain in little bit details how routing and data
> > forwarding should work.
> > If possible , pls post the reply of manufacturer on the validity of this
> > request .
> >
> > As far as i understood :
> >
> > the MP-eBGP is labeled , ie: a Label is advertised for each VPN IPv4
> > Prefix
> > by the ASBR so How U could change the next-hop address ??
> > U could change the default next-hop address only if U are going to
> > advertise
> > the same label recieved for the same VPN prefix .ex: The case of RR in
> > option C where the label advertised in Mp-eBGP is the label recieved in
> > MP-iBGP for the same VPN prefix .
> >
> > Why not :
> > Say VRF A , is the VRF where U want an IP path .
> > U config VRF A in the ASBR and assign an interface or sub-interface as
> > option A .
> > U disable the deafult filtering on the ASBR MP-iBGP (now all VPN IPV4 
>are
> > imported ).
> > U apply filter on the MP-eBGP to prevent VPN prefix of VRF A to be
> > advertised .
> >
> > ASBR1--------------Mp-eBGP-----ASBR2
> > | |
> > |---e-BGP for VRF A-- FW------|
> >
> >
> >
> > Brgds
> > >From: Miguel Cros Cecilia <miguel.cros@gmail.com>
> > >Reply-To: Miguel Cros Cecilia <miguel.cros@gmail.com>
> > >To: mpls-ops@mplsrc.com
> > >Subject: [MPLS-OPS]: Inter-AS Provider Option A+Option B
> > >Date: Sat, 28 May 2005 15:34:08 +0200
> > >
> > >We use internally in our network Multi-AS/Inter-AS Option A and also in
> > >other areas of our network we use Option B. When the number of VRF
> > >increases, Option A starts to manifest its limitations, specially in 
>the
> > >re-establishment of BGP sessions, when we have some device failure.
> > >
> > >We would prefer to configure Option B, because we'd need only an 
>MP-eBGP
> > >session, but the problem is that for specific VRF's we need to deploy 
>FW
> > in
> > >between the PE/ASBR.
> > >
> > >
> > >So the purpose of these E-mail is just to know if anyone makes sense 
>the
> > >proposal that we are making to our router vendors (Cisco/Juniper):
> > >
> > >Lets use Option B for signally all the VRF's prefixes, but through
> > >route-maps/policy-statements associated to the MP-eBGP session, let us
> > >allow
> > >to change selectively (only for specific VRF) the forwarding path to
> > >interfaces assigned to individual VRF's.
> > >
> > >Some of VRF traffic would follow the MPLS path (Option B) and other 
>would
> > >go
> > >through the IP path.
> > >The framework is there. There are even command to set the IP next-hop,
> > but
> > >it doesn't work because it seems not to be designed for this scenario.
> > >
> > >The advantages would be having the scalability of Option B, and the
> > >flexibility of Option A, that allows the use of only IP devices (FW,
> > >Bandwidth Mgmt,etc).
> > >
> > >
> > >Regards
> >
> > _________________________________________________________________
> > Express yourself instantly with MSN Messenger! Download today it's FREE!
> > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> >
> >

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.com/

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