Re: [mpls-linux-general] tcpdump bug?

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

On Wed, Apr 24, 2002 at 11:06:30PM +0200, Daniel Gregorio Catalan wrote:
> Hi, now I'm making a network with 6 MPLS-Linux routers and I have made two
> different LSPs with 'mplsadm'. The net is working properly, and the routes
> are ok. I make ping from one LER to the other LER, in order to have
> different destinations to test the different LSPs and ping works properly.
> 
> And I am capturing the packets with Ethereal (tcpdump) and, in one LSP, the
> packets in one and other way (ping request and reply) are MPLS, BUT in the
> other LSP, seems that the packets are not MPLS they are all normal IP
> packets.
> 
> In the LSP that packets are showed as MPLS packets, I can see the 'famous'
> tcpdump-MPLS-Linux bug in the received packets (when I run Ethereal in the
> LER).
> However in the other LSP appear the bogus IP packets that receives the LER,
> too, but the sendings are not MPLS and I don't know if it is because of the
> bug or other problem.

Are you sure they are going via IP?  Turn off IP forwarding on one of the
LSRs (echo 0 > /proc/sys/net/ipv4/ip_forward).

On your LERs, what FECs are you binding to the LSPs?  What are the IPs on
the outgoing interfaces?

> Other question, can someone tell me how MPLS fragments the packets in a MPLS
> Tunnel, when because of the size of the label stack (there are too many
> labels), the packet's size exceeds the MTU?. I guess that there will be
> something that does it but I don't know how MPLS does because in an MPLS
> network the LSRs are working as switches so they can't fragment packets (Is
> this correct or I am wrong?)

MPLS doesn't fragment, it needs to present a minimized MTU to the IPv4 layer.
If the resulting packet is bigger then the outgoing interface it should be
dropped (this isn't in mpls-linux yet).

Jim

> 
> Thanks,Dani.
> 
> 
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general

-- 
James R. Leu