Re: [mpls-linux-general] Mpls installation problems with the new version.

[James R. L. <jl...@mi...>]

> > Handling of packets with TTL <= 1 is broken right now.  The result is that the
> > packet gets dropped.  I think I know how I'm going to handle it:
> > 
> > Check if this is the botton of the stack, if not drop the packet.
> > Check the protocol associated with the ILM, if it is not IP, drop it.
> > If it is IP, generate an ICMP message, and forward it along the LSP, the
> > egress can deal with the ICMP message.
> > 
> > There is probably a special case where it is the egress of the LSP that
> > finds a TTL <= 1 that needs to be handled differntly.  Besides that,
> > does this sound like the right behavior?
> 
> Sounds good for me.
> 
> I tested ethereal in the middle of a lsp (no edge router) and there it
> works well.
> Do you have a idea, if there is a chance to monitor the edge routers
> correctly too?

For this to work correctly I would have to make a complete copy of the
packet and modify the copy, not the original. This would be slow, so I
don't want to do it as part of the normal path.  If people would really
like to see "correct" MPLS packets at the LERs maybe I can figure out
a way to tell if someone else has a handle to the packet and change the path
accordingly.

If you would like a detailed description of why it workes the way it
does I can walk you through the code.

> I defined a wrong outgoing lable on a edge router, and I saw two things:
> a) Ping is still working, but why? If mpls didn't know the incoming
> label, it pops the label off and tries to find a working label in the
> outgoing labels? Or is the label poped off and forwarded by normal ip?

I haven't done any negative testing recently, I will try your test tonight.
It shouldn't have worked.

> b) Tracerout stops at the middle of the lsp (3 PCs). Why it is not
> forwarded like the pings?

*shrug* Let me figure out what the ping _worked_ first :-)

Jim

-- 
James R. Leu