Ethereal-dev: [Ethereal-dev] in need of an idea to support l2 tunneling over mpls

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Aamer Akhter" <aakhter@xxxxxxxxx>
Date: Sun, 17 Mar 2002 20:38:07 -0500
Hello,

draft-martini-l2circuit-encap-mpls specifies a method to tunnel layer 2
frames/cells across an mpls environment. The format of these packets poses a
problem for protocol analysers because the label value specifies the meaning
of the packet not the packet it self.

Currently packet-mpls does the handoff in this manner:

    ipvers = (tvb_get_guint8(tvb, offset) >> 4) & 0x0F;
    if (ipvers == 6) {
        call_dissector(ipv6_handle, next_tvb, pinfo, tree);
    } else {
        call_dissector(ipv4_handle, next_tvb, pinfo, tree);
    }

By changing it to:
    ipvers = (tvb_get_guint8(tvb, offset) >> 4) & 0x0F;
    if (ipvers == 6) {
      call_dissector(ipv6_handle, next_tvb, pinfo, tree);
    } else if (ipvers == 4 ){
      call_dissector(ipv4_handle, next_tvb, pinfo, tree);
    } else {
      call_dissector(find_dissector("eth"), next_tvb,pinfo, tree);
    }

We can get it to mostly work for Ethernet Over Mpls (except for the poor
packets whose destination starts of 4 or 6), but there is no guarentee that
it's that kind of packet even the above is finger crossing at best, and is no
answer for frame-relay or ATM over mpls.

I am thinking that leaving the above change in is better than nothing and
modifying the 'Decode as' user selectable option to include 'MPLS encaped'
along with 'link', 'network' and 'transport'.

What are your thoughts about this? Is there a better way of solving the
problem. Keep in mind that this problem is not going to be specific to MPLS
but UTI will also have a similar problem.

--
 Aamer Akhter / aa@xxxxxxxxx
 NSITE - cisco Systems