The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Oct> msg00096



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

MPLS/BGP routing question

  • From: Jieyun Jessica Yu <Jieyun.Yu@cosinecom.com>
  • Date: Mon, 9 Oct 2000 07:42:51 -0700
  • Cc: Bala Rajagopalan <braja@tellium.com>, curtis@avici.com, Eric Gray <EGray@zaffire.com>, Michel Redondo Ferrero <mredondo@idecnet.com>

Title: RE: MPLS/BGP routing question

Robert Raszuk said:

>2. Satoru Matsushima said:

>> When a LSP of PE to PE broken, BGP has no way of LSP broken.
>> I think this is one of most seriously problem of BGP/MPLS VPN.

>Not true when we are talking about prefix based LSPs. If you are using
>prefix based LSPs they will disappear only if ip route to bgp next hop
>will disappear what in turn will cause bgp route withdrawn (invalid bgp
>next hop) at a periodic scanner. If there is no route - you will not be
>able to route anyway - no miracles here.

I think the black-hole senario Satoru described can happen in prefix based LSPs. The BGP next hop is learned via IGP so if for some reason the IGP is up but the mpls tunnel fail to established, the blackhole would happen. In this case, the RR will still pass the route to the PE via IBGP because it has no idea te LSP is broken and the PE will still install routes from the RR since the bgp next hop learned via IGP is there.

The question is how likely this will happen in operation. For that, Eric and Satoru had an exchange which I will include below.

This is sort of similar to the situation of Route Server (RS) serving at the NAPs where FDDI or gigaE were used. NAP is a facility where ISPs routers connect directly via a common media such as FDDI in elary days or others and exchange routing information via BGP. To improve scalability, instead of having all ISP routers BGP peer with each other (full mesh peering), a RS is used to pass the information so each ISP router just needs to peer with the RS. The problem encountered was that somehow the layer2 connection lost between a pair of routers while the RS won't know (if can since it is not in the data pass) it and still passing routes between them. As a result, it causes traffic blackholing. When I was involved in RS operation, it happened more than what anticipated. So it is hard to say definitely this is not going to (or goig to) happen in the MPLS VPN situation until we have more operational experiences.

                                                           --Jessica


The exchange between Eric R. and Satoru:

on 00.9.30 0:32 AM, Eric Rosen at erosen@cisco.com wrote:

>
> Matsushima> When a  LSP of PE to  PE broken, BGP  has no way of  LSP broken.
> Matsushima> Then, BGP keep  up of VPN routes and VPN  traffic going to black
> Matsushima> hole, until LSP available.
>
> Matsushima> As a result,  VPN customer can not back up  their traffic to any
> Matsushima> link.
>
> Matsushima> I think this is one of most seriously problem of BGP/MPLS VPN.
>
> The  situation you  are worried  about is  where there  is  IGP connectivity
> between the edges,  but for some reason labeled packets  cannot make it from
> one edge to another.

Yes, exactly.

> I guess we don't really see this as a realistic failure
> scenario.  Sure, buggy software could cause this, but there's a million ways
> in which buggy software could cause undetected packet loss.
>

I think that LSP failure was caused by not only buggy software but also
oparation failure.
For example, i) erase a interface as LDP ID ;-< , ii) routes summarization
failure on ospf area,...

IMO, BGP which on PE should has some way to know of LSP failure.
This is for customer.

--
Satoru Matsushima