[mpls-linux-general] ldp_linux operation mode problems

[Igor V. <ch...@fl...>]

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).