tcpdump mailing list archives
Re: Request for Geneve DLT type
From: Michael Richardson <mcr () sandelman ca>
Date: Wed, 28 Jan 2015 09:16:34 -0500
Guy Harris <guy () alum mit edu> wrote: >> I'm working on implementing support for Geneve in libpcap, which is >> documented here: http://tools.ietf.org/html/draft-gross-geneve-02 >> >> Geneve is a tunneling protocol than can encapsulate many different >> things - normally this would be Ethernet, IP, or IPv6 but it can be >> anything with an EtherType. I would like for filters that appear after >> the Geneve keyword to apply to the inner payload, i.e. geneve && ip. >> >> Since the inner protocol is no longer the same as the outer wire >> format, the checks that are done on linktype don't really make sense >> at that point. The easiest solution would seem to be to allocate a new >> DLT for Geneve and change to that when processing the inner header, so >> I'm requesting a new type for that purpose. I realize that this is a >> little weird because it's not actually a format that will ever appear >> in pcap files and could also be handled purely internally (similar to >> the is_pppoes variable). However, having implemented it both ways, it >> definitely seems cleaner to have a new type that fits into the >> existing switch statements rather than a bunch on one-off checks. > Having a placeholder DLT_ type that doesn't actually correspond to > anything you get from an interface, and a corresponding LINKTYPE_ value > that won't ever appear in files, definitely doesn't seem at all clean > to me; it's using DLT_/LINKTYPE_ values for a purpose completely > different from the purpose for which they are intended. I wonder if Jesse's proposal might actually make sense, and provide an interesting way to strip layers of encapsulation. i.e. in the MPLS and PPPoE cases, one might want to have a way to peel the outer encapsulation off, leaving only the IP encapsulation. We also had the case earlier where we allocated the DLT type to upper-layer (TCP-after-TLS-mostly) traffic. Expressing filters for matching encapsulated traffic are difficult to write. I don't think we can, for instance match port-80 traffic that is PPPoE from L2TP session 1234, and encapsulated in VLAN 97. What if we actually modelled this as a pipeline of sorts: tcpdump -i eth0 -w - --decapuslate vlanid=97 | tcpdump --pipe l2tp ...| Except that we might also be able to write it as: tcpdump -i eth0 -w - --decapuslate vlanid=97 \| 2tp ... \| ?? What do you think? (Maybe not today) > I will see whether the handling of PPPoE and MPLS can be cleaned up > internally to gencode.c; if so, *that* would be the right way to handle > Geneve. I agree that they should all be handled the same way. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr () sandelman ca http://www.sandelman.ca/ | ruby on rails [ _______________________________________________ tcpdump-workers mailing list tcpdump-workers () lists tcpdump org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Current thread:
- Request for Geneve DLT type Jesse Gross (Jan 27)
- Re: Request for Geneve DLT type Guy Harris (Jan 27)
- Re: Request for Geneve DLT type Jesse Gross (Jan 27)
- Re: Request for Geneve DLT type Michael Richardson (Jan 28)
- Re: Request for Geneve DLT type Guy Harris (Jan 27)