What is Slow Protocols

I somehow never thought about how the LACP protocol works. I know what he is doing, what is needed, and how his messages are transmitted never interested.

But some time ago, I caught sight of a traffic dump between two routers, where there were just LACP requests. I ran briefly through it and my eye caught on an unfamiliar word - Slow-Protocols.
Surprisingly, I practically did not find information about this standard in Russian. There are only references to the fact that this is part of the 802.3 standard.

Meanwhile, the thing is interesting, especially since it covers not only LACP.
That's what I wanted to arrange a short educational program under the cut and tell me more about what problems can be caught under certain conditions.


So, there is a class of protocols that are designed to control various aspects of Ethernet, in other words, Flow Control. They are part of the 802.3 standard and are divided into two types:

• Fast . They should work out instantly to prevent performance degradation and interruption in the provision of services in general. As a rule, they are implemented in hardware. Actually, the representative of this class - the PAUSE mechanism - when the device port receives more traffic than it can handle, it sends the PAUSE Frame to the opposite node with a request to lower the sending speed.
  

  This can happen when connecting different speeds of interfaces to each other - for example, FE in GE. Or when setting speed limits on switch ports. Even incidents happen , but I haven’t had to deal with such problems.
  
  Once, I came across Pause Frame in their unusual behavior. On that day, the counters received by PAUSE Frames grew rapidly on the interfaces, the monitoring system drowned in accidents, the rain did not stop on the 7th day. They began to analyze: the amount of traffic on these interfaces barely exceeded a couple of percent, no drops, no errors. Moreover, what is most surprising, at the opposite end, the device did not send these same PAUSE Frames - Pause Frame Output counters to zeros. Some kind of fanaticism, because there are not even intermediate devices.
  By means of deep debugging with the participation of the developers, it turned out that these were some kind of internal iron troubles - the switching chip has a small buffer and sends Pause Frames to the line card so that it reduces activity, but all this tricky way out inside the box and does not affect services .
  

  
  
  The Pause mechanism is a technology for full duplex liquors. There is Back Pressure for Half-Duplex . It is very strict and not only makes it slow down, but blocks the data transfer, because it actually tells the transmitting switch that there is a collision and that it is necessary to stop its futile attempts. But who cares now?
  
• Slow - those same Slow Protocols. They don’t have such big appetites for sending frequency and delay. They are implemented programmatically. OAM and LACP relate to this particular type.
  They use a special MAC address: - 0180-s200-0002, and EtherType 8809.

Further, a very free translation of this document, which is an addition to the standard 802.3.

Limitations
Firstly, the following restrictions are imposed on this type of protocol:

1) Transmit no more than 10 frames per second
2) The maximum number of protocols with EtherType 8809 is ten. Theoretically, there may be more, but they will already have a different type in the Ethernet header.
3) The frame size of the “slow” protocols is limited to 128 bytes. * Not to say that it is done fairly - OAMPDU, for example, can easily exceed this size.

The above limitations have a simple goal - to reduce the amount of service traffic on the network.

As for the protocols of a higher level, there are specially allocated multicast IP addresses (224.0.0.5 for OSPF, for example), and the "slow" protocols have a separate multicast MAC address: 01-80-C2-00-00-02 .

This MAC address belongs to the range allocated by ISO / IEC 15802-3 for protocols limited to one link. In fact, this means that frames transmitted to a given address cannot be redirected outside this particular link.



It is possible that there may be “slow” protocols that require unicast frame forwarding - this is not prohibited. That is, the address 01-80-C2-00-00-02 is not a requirement - this is a wish.
A “slow” protocol can use a different MAC address, but no protocol other than a “slow” one can use this one (01-80-C2-00-00-02).

As I noted above, the protocol type of the Slow Protocols (EtherType) group is 8809 . Next, subtypes are defined - subtypes for specific representatives of this glorious class:

Subtypes

Subtype	Destination
0	Unused forbidden subtype
1	Link Aggregation Control Protocol (LACP)
2	Link Aggregation — Marker Protocol
3	Operations, Administration, and Maintenance (OAM)
4-9	Reserved
10	Organization Specific Slow Protcol (OSSP)
11–255	Unused forbidden subtype

As you can see, 8 bits are allocated for the subtype. We'll talk about type 10 a little lower, but everything is clear with the rest:
1 - the usual LACP familiar to us;



2 - also part of the LAG mechanism for balancing the load, orderly receiving frames and optimizing the management of LAG links.
3 - Ethernet OAM protocols.



How to behave when receiving a Slow Protocols frame

1) Discard all frames in which prohibited subtypes of Slow protocols are indicated
2) Skip frames that carry known Slow protocols (with known subtypes) and transfer them to the appropriate services.
3) Skip frames that carry valid but unknown protocols and pass them to the MAC client.

OSSPDU

In fact, the two protocols that we know now that use this standard are LACP and OAM, but in general there is the opportunity to create your own “slow” protocol for your needs. This is the very point ten - OSSP - Organization Specific Slow Protocol .

This applies to appendix 57B, which describes recommendations for implementing specific protocols.

Like other protocols, there are names for their frames (LACPDU, OAMPDU, BPDU), OSSP has some generalized term for these purposes - OSSPDU.

The following are completely logical requirements for the OSSPDU frame structure and transmission rules for the network, but the standard is the standard that describes all the subtleties.

In general, I took it a little deeper.



That's the whole tale of these simple, but little described in RuNet protocols.

By the way, from ignorance of the intricacies of application, the work of protocols, some incidents are born. Here are some of them and I had to face . After which, in fact, became interested in this topic.

The pcap file for picking.