Wireshark · Wireshark-dev: Re: [Wireshark-dev] Overview of MPLS PW bugs

[Francesco Fondelli <francesco.fondelli@xxxxxxxxx>]

Hi Jaap,

the pw_eth_heuristic is too strong, it does not take into
consideration locally-assigned MAC addresses and multicast (as noted
in some bugs by Guy Harris and Michael Mann). Patches are welcome :-)

That said, I think the current situation is a good trade-off.

Ethernet PWs *without* CW use to be common back in ~2000. At that time
someone thought "Hey, IEEE will never allocate Ethernet MAC addresses
starting with 4 o 6... we already have transit routers that perform
load balance if 1st nibble is 4 or 6 if you want strict packet
ordering just put 0 or 1, that's it, you have a pseudo-wire" :-)

I do not have numbers but I think today the majority of Ethernet PW
out there are making use of the CW and Wireshark default behavior
should be based on this. RFC 7325 is an enlightening and comprehensive
documentation about MPLS forwarding. In Section 2.4.1 it says:

2.4.1.  Pseudowire Control Word

   Within the core of a network, some form of multipath is almost
   certain to be used.  Multipath techniques deployed today are likely
   to be looking beneath the label stack for an opportunity to hash on
   IP addresses.

   A pseudowire encapsulated at a network edge must have a means to
   prevent reordering within the core if the pseudowire will be crossing
   a network core, or any part of a network topology where multipath is
   used (see [RFC4385] and [RFC4928]).

   Not supporting the ability to encapsulate a pseudowire with a Control
   Word may lock a product out from consideration.  A pseudowire
   capability without Control Word support might be sufficient for
   applications that are strictly both intra-metro and low bandwidth.
   However, a provider with other applications will very likely not
   tolerate having equipment that can only support a subset of their
   pseudowire needs.

The not edulcorated version reads "Ethernet PW without control word is
a pain in the ass, do not use it".

Hope this helps
ciao
fra

PS
an other improvement could be to add logic to signalling dissectors
(e.g. LDP, BGP) in order to add explicit label-to-dissector bindings.
This would be useful only in case signalling and data plane are
captured together. Therefore, I guess this is not common and it isn't
worth it.

On Sat, Jan 7, 2017 at 6:39 PM, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
>
> Introduction
>
> There has been a steady stream of MPLS PW related comments and bugs over time,
> and things haven't improved enough, apparently. This text tries to give some
> insight in the issues so that possible solutions cover all cases involved.
>
> Background
>
> Multi Protocol Label Switching (MPLS) is highly optimized for speed. That is
> speed of processing of network frames, getting frames forwarded as efficiently
> as possible while handling pushing and popping labels at the predefined network
> boundaries. Pseudo Wire (PW) tries to make the network connection so that it can
> be seen as a literal replacement for a wire, or a circuit switched connection.
> To do so optionally a control word if prefixed before transport across the MPLS
> network.
>
> These two combined allow a highly efficient and high bandwidth mesh of point-to-
> point connections. So much so that the protocols carry little, if any,
> information related to the type of data transported. This is especially true for
> the MPLS label stack and the PW control word. Only a label number is assigned,
> it is up to the endpoints between which frames are exchanged using this
> (bottom-of-stack) label to decide (out of band) what format this data is in.
> Also the presence of a control word is mutually agreed upon out of band. Usually
> these are statically configured in the MPLS edge routers.
>
> This fact complicates matter for a man-in-the-middle observer, like Wireshark.
> Without the knowledge of the out-of-band agreed communication settings it takes
> guesswork to decide what these are and thus how to interpret these frames.
>
> Wireshark does try by means of heuristic analysis of the frame contents to
> determine the makeup of each MPLS frame, and sets up the dissection of the inner
> parts. Since there is so little to go on, heuristic analysis is error prone.
> Often the user has to be involved, using other knowledge, to set the correct
> dissection parameters.
>
> MPLS RFC's
>
> if you read the various RFCs on MPLS it becomes clear that other have struggled
> with these matters also. See for instance RFC 4928, 4385 and 4448, and all RFCs
> referenced from them.
>
> Bug history
>
> Combing through Bugzilla and the source code repository a collection of MPLS
> related bugs and changes can be found. Here we try to list them in a
> chronological order.
>
> Remove MPLS preference that doubled for Decode As.
> https://code.wireshark.org/review/#/c/7899/
>
> Bug 11271: Dissecting engine stops after MPLS shims
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11271
>
> https://code.wireshark.org/review/#/c/8912/
> MPLS: always display payload when no 'Decode As' preference is set
>
> Bug 11949: Wireshark 2.0.1 MPLS dissector not decoding payload when control word
> is present in pseudowire
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11949
>
> Only use nibble logic to determine MPLS payload
> https://code.wireshark.org/review/#/c/12961/
>
> Bug 13039: Ethernet-over-MPLS heuristic treats some "Ethernet without control
> word" packets as "Ethernet *with* control word"
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13039
>
> Add MPLS preference to potentially ignore Ethernet Control Word.
> https://code.wireshark.org/review/#/c/18466/1
>
> Bug 13295: Ethernet-over-MPLS heuristic treats some "Ethernet with control word"
> packets as "Ethernet *without* control word"
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13295
>
> Bug 13301: Ethernet-over-MPLS heuristic treats "eth-over-mpls" packets (without
> control word) where eth destination starts with 6x or 4x as being
> "ipv6-over-mpls" and "ipv4-over-mpls" respectively
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13301
>
> Conclusion
>
> There is non at the moment, other than that it takes work to develop an all
> encompassing solution, which will probably be a tradeoff. Properly documenting
> these will have to be part of the solution, so that this can be referenced when
> the (inevitable) follow up questions/bugs come up.
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe