Re: [mpls-linux-general] ldp_linux operation mode problems

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Interesting.  After I have chance to finish the ldp-portable/zebra
integration I will work on debugging the differnt modes of operation.

Jim

On Tue, Jun 11, 2002 at 08:51:48PM +0200, Igor Vukomanovic wrote:
> Hello,
> 
> I've tried out several modes of operation for ldp-linux and I'm having some
> rather problematic results.
> The setup I used was:
> 
> LER1---------------------LSR1---------------------LER2
> 192.168.20.200        192.168.20.201                192.168.19.206
>                                  192.168.19.204
> 
> All machines mpls-linux 0.996 patched kernel 2.4.12, ldp-portable CVS (a few
> weeks ago)
> 
> Firstly, when I changed from Downstream Unsolicited to Downstream on Demand
> mode, after adding global and interface, ldp crashes. I browsed through
> mailing list archives and found Amish Verna's message from 2002-04-11, the
> same thing happened to him but there was no reply. Is there a solution to
> this problem?
> 
> Another thing I tried was testing whether ldp really works in Ordered
> control mode, as the default is Ordered, but I found that it is not so. It
> behaves as if it works in Independent mode! Let me explain my test:
> In the setup above, the routing was:
> LER1:
> route add -host 192.168.20.201 gw 192.168.20.201
> route add -host 192.168.19.203 gw 192.168.20.201
> 
> LSR1:
> route add 192.168.20.200 gw 192.168.20.200
> route add 192.168.19.206 gw 192.168.19.206
> route add 192.168.19.203 gw 192.168.19.206
> 
> LER2:
> route add 192.168.19.204  gw 192.168.19.204
> 
> The LDP session was first setup between LSR1 and LER2. After that the LDP
> session was setup between LSR1 and LER1.
> 
> Note that 192.168.19.203 is a *fictional* FEC for which the LER1, when
> working in the Independent mode, should get a label for, from the LSR1.
> But when working in the Ordered mode, the LSR1 *must not* send any labels to
> LER1 for a FEC 192.168.19.203 since LER2, the next hop LSR for that FEC
> (from  LSR1's point of view) didn't yet send labels for that FEC. (It didn't
> send and it won't send because I never added that route in the routing
> table, on purpose).
> But, I noticed a label mapping message originated from LSR1 to LER1 with a
> label for a FEC 192.168.19.203.
> (I grabbed it with Ethereal, and can present it if neccessary).
> 
> The result on LER1:
> 
> voip5:/home/igor# cat /proc/net/mpls_fec
> 40005403 192.168.19.203/32
> 40006003 192.168.20.201/32
> 
> voip5:/home/igor# cat /proc/net/mpls_out
> 40005403 0/0/0 PUSH(gen 21) SET(lec0,192.168.20.201)
> 40006003 102/6222/0 PUSH(gen 24) SET(lec0,192.168.20.201)
> 
> According to RFC3036:
> 
>  " When using LSP ordered control, an LSR may initiate the transmission
>    of a label mapping only for a FEC for which it has a label mapping
>    for the FEC next hop, or for which the LSR is the egress.  For each
>    FEC for which the LSR is not the egress and no mapping exists, the
>    LSR MUST wait until a label from a downstream LSR is received before
>    mapping the FEC and passing corresponding labels to upstream LSRs."
> 
> Is LSR1 the Egress for a FEC 192.168.19.203?
> 
> According to RFC3036:
> 
>  "  An LSR may act as an egress LSR, with respect to a particular FEC,
>     under any of the following conditions:
>       1. The FEC refers to the LSR itself (including one of its directly
>          attached interfaces).
>       2. The next hop router for the FEC is outside of the Label
>          Switching Network.
>       3. FEC elements are reachable by crossing a routing domain
>          boundary, such as another area for OSPF summary networks, or
>          another autonomous system for OSPF AS externals and BGP routes"
> 
> Obviously none of the 1,2, or 3 applies. Therefore the LSR1 is not the
> egress for that particular FEC, and it didn't yet receive the mapping from
> the FEC next hop. It shouldn't have sent the label mapping message.
> 
> According to the RFC, the fact that LSR1 works in Unsolicited label
> distribution mode, doesn't change above facts; It only means the LSR1 is
> responsible for sending labels upstream to the LER1, (doesn't wait for the
> label request from LER1); In Downstream on Demand mode, the LER1 would be
> responsible for those labels (by sending label request messages to LSR1).
> 
> Sincerely,
> 
> Igor Vukomanovic
> 
> P.S.
> Some additional info :
> On LSR1, the result was also OK :
> 
> voip4:/# cat /proc/net/mpls_out
> 40004402 72/4560/0 PUSH(gen 17) SET(eth0,192.168.19.206)
> 40004803 38/2681/0 PUSH(gen 18) SET(lec0,192.168.20.200)
> 
> voip4:/# cat /proc/net/mpls_fec
> 40004402 192.168.19.206/32
> 40004803 192.168.20.200/32
> 
> However, on LER2 there were no out labels or fec's. I guess this is the
> known problem of one-way LSP Morvan Daniel Muller and some other people
> encountered. However, if I add:
> 
> route add -host 192.168.20.200 gw 192.168.19.204
> 
> on LER2, it would create an out label for the FEC 192.168.20.200 ! (still no
> labels for 192.168.19.204 though).
> 
> (Just a piece of curious information).
> 
> 
> _______________________________________________________________
> 
> Multimillion Dollar Computer Inventory
> Live Webcast Auctions Thru Aug. 2002 - http://www.cowanalexander.com/calendar
> 
> 
> 
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general

-- 
James R. Leu