The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2005-May> msg00055



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: Inter-AS Provider Option A+Option B

  • From: Miguel Cros Cecilia <miguel.cros@gmail.com>
  • Date: Sun, 29 May 2005 21:20:58 +0200
  • Cc: mpls-ops@mplsrc.com
  • DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=nPpF3yiMoOIDPb+MqxG5PVQwhqduM0tWuktv/ATUvZcHbXFoHRiDivkALLN2r7pxcZ46ueN4x1/0eD6+dcV3mYgXwlELf0EGw1kFkn09bm87PtrGu13xdy++tIdUveCM7w4M8DSJZzQuivwEZnFQfgBfR4C6sDsQ1+JeejmCVwU=
  • Resent-Date: Sun, 29 May 2005 16:08:35 -0400
  • X-Scanned-By: MIMEDefang 2.45

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/