If you can be sure of your cabling then I would recommend implementing spanning-tree bpdufilter on the interface towards the firewall since you have already configured the interface as an edge port. This does not provide any loop protection, but the ASA (non-5505 as indicated) is incapable of creating a L2 loop and your stated goal is to remove BPDU's from the interface.
Configuring root-guard on the interface will not be useful since the ASA can never send any BPDU, and especially not a superior BPDU. If you do not choose to configure BPDU filtering, then BPDU-Guard should be configured either by default (spanning-tree portfast bpduguard default) or specifically on the interface. This will prevent any other spanning-tree capable device from being connected to that interface.
Further, if you do not have an untagged (native) interface on the firewall, allowing the native vlan on the trunk is not required and your allowed vlan list could be shortened to exclude 99. Also you could set the interface to not negotiate the access/trunking mode with switchport nonegotiate and remove the configured access vlan.
Can Ethernet frames, with the length field used, still contain e.g. an IP packet?
Yes, you're asking about IP over 802.3 SNAP frames, which is covered in RFC 1042.
A 802.3 SNAP IPv4 frame looks like this...
+----+----+----+----+----+----+----+----+---------+-----+
| DA | SA | L | DS | SS | CL | OI | ET | Payload | FCS |
+----+----+----+----+----+----+----+----+---------+-----+
DA: Destination Mac Addr (6 Bytes)SA: Source Mac Addr (6 Bytes)L: Length (2-Bytes); (Length <= 0x05DC hex, or 1500 decimal)DS: DSAP (1-Byte); (DSAP == 0xAA hex, or 170 decimal)SS: SSAP (1-Byte); (SSAP == 0xAA hex, or 170 decimal)CL: Control (1-Byte); (Control == 0x03 hex, or 3 decimal)OI: Organizationally Unique Identifier (3-Bytes); (OUI == 0x000000 hex, or 0 decimal)ET: Ethertype (2-Bytes); (Ethertype == 0x0800 hex, or 2048 decimal)Payload: Ethernet Payload (Ethernet Payload <= 1492 Bytes); this payload size includes the size of the IPv4 header.FCS: Frame Checksum (4-Bytes)
If yes, how can a router or PC detect this?
By "detect this", I assume you mean IP over 802.3 SNAP; the SNAP frame is first distinguished from an Ether II / ARPA frame because Type / Length <= 0x05DC hex. Then the router looks at the other fields specified above...
Computers have to be explicitly configured with SNAP encapsulation, to include a lower-than normal MTU (IP MTU <= 1492 bytes). While it's theoretically possible to include 802.3 SNAP IPv4 in the broadcast domain as Ethernet II (ARPA), most people would think you're crazy to do so.
And what will a router typically do with a frame using length instead of Ethertype?
There aren't many 802.3 IP SNAP networks left... Cisco IOS used to process IPv4 over SNAP in the punt path; but I haven't looked at this in depth in a long time.
To test with recent Cisco IOS, I attempted to ping one of my Cisco 3560 switches (debug ip icmp enabled) with an 802.3 SNAP IPv4 frame, but the switch just gave me dumb looks...
[mpenning@tsunami ~]$ sudo python
Python 2.7.3 (default, Jan 2 2013, 13:56:14)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from scapy.all import SNAP, Dot3, LLC, IP, ICMP
>>> from scapy.all import srp1
>>> pak = Dot3(dst="64:ae:de:ad:be:ef", src="80:ee:73:20:00:00") / LLC() / SNAP() / IP(src="10.0.0.5", dst="10.0.0.1") / ICMP()
>>> pak
<Dot3 dst=64:ae:de:ad:be:ef src=80:ee:73:20:00:00 |
<LLC dsap=0xaa ssap=0xaa ctrl=3 |<SNAP code=0x800 |
<IP frag=0 proto=icmp dst=10.0.0.1 |<ICMP |>>>>>
>>> srp1(pak)
Begin emission:
Finished to send 1 packets.
...................^C
Received 19 packets, got 0 answers, remaining 1 packets
Christian said: The background for this question is this: I would like to implement a proprietary protocol on top of 802.3 MAC frames and use the length field. So, what will using the length field imply for other hard- and software? E.g. will it be safe to send such frames to cots systems, which will not know about my protocol inside.
I personally would discourage you from implementing a private ethernet protocol; people did this kind of thing all the time twenty or thirty years ago, but it's increasingly rare to find custom protocols today.
Why? It just doesn't make sense for the exactly the reason you're asking. Practically the entire world uses "something" on top of IPv4 or IPv6.
- UDP is available if you want a "connectionless" service
- TCP or SCTP are good choices for "connection-oriented" services
What happens if you build your own protocol?
It's hard to talk to anything else, even on the same ethernet broadcast domain... because other things invariably are using IP and ethertype (RFC 894) frames.
You've got no routing (i.e. the capability to send traffic across multiple ethernet broadcast domains, such as the networks people build between cities and countries); this also means you could be doing stuff like bridging across the internet, which requires building IP tunnels.
Do you want network services? Guess what you get to build:
- Want file transfers? Build your own FTP or TFTP
- Want name resolution? Build your own DNS
- Want network errors and monitoring? Build your own ICMP protocols
- Want security? Build your own firewalls, encryption, and PKI (ick)
- Want to talk to other computers? Build kernel drivers for those operating systems (see below)
Speaking broadly, custom ethernet protocols require a kernel driver for all operating systems in question; do you really want to build and distribute a kernel driver? If you use IP it's simpler, because you can have services listening on top of an existing IP kernel driver; just bind to a port number and leverage the built-in IP kernel drivers.
However, building with IP comes at the cost of using Ethernet II (ARPA) encapsulation (i.e. no length field in the ethernet frame).
Maybe you still want to use your own custom ethernet protocol; at least by now you understand more about the associated tradeoffs.
Best Answer
An EtherType/Length value up to 1500 (0x05dc) indicates the frame's payload length. The values 1501-1535 (0x05dd-0x05ff) are undefined, real Ethertype values start at 1536 (0x600).
The receiving switch is probably ignoring the rest of the frame and since the supposed FCS doesn't match, it drops the error frame.
You'll need to use a larger value and take care that your private EtherType doesn't collide with anything already in use.