search

kytos-ng / of_lldp

Kytos LLDP Openflow Network Application (NApp)
https://kytos-ng.github.io/api/of_lldp.html
MIT License
0 stars 3 forks source link

LLDP with invalid Mac address may be dropped by underlaying transport #86

Closed italovalcy closed 1 year ago

italovalcy commented 1 year ago

Hi,

The Napp kytos-ng/of_lldp generates LLDP packets with an invalid source MAC address, as shown in this ofp_sniffer capture:

Packet #396 - 2023-06-27 19:01:00.437820 x.x.x.x:6653 -> x.x.x.x(0000000000400004):43702 Size: 136 Bytes
OpenFlow Version: 1.3(4) Type: OFPT_PACKET_OUT(13) Length: 82  XID: 2156411907
PacketOut: buffer_id: 0xffffffff in_port: OFPP_CONTROLLER(0xFFFFFFFD) actions_len: 16
 Actions:
   Output Port 3 Max_Len 65535 Pad 000000
Ethernet: Destination MAC: 01:80:c2:00:00:0e Source MAC: 00:00:00:00:00:00 Protocol: VLAN(0x8100)
VLAN: PCP: 0 CFI: 0 VID: 3799 Protocol: LLDP(0x88cc)
LLDP: Chassis Type(1) Length: 9 SubType: 7 ID: 00:00:00:00:00:40:00:04
LLDP: Port Type(2) Length: 5 SubType: 7 ID: 3
LLDP: TTL(3) Length: 2 Seconds: 120
LLDP: END(0) Length: 0

However, such an invalid frame may be discarded by the underlying transport. In other words, if an adjacent link is provided by a carrier ethernet link, the third-party equipment may end up discarding the frames sent with an ethernet source mac invalid (tested and confirmed with Juniper and Dell).

In fact, Kytos is already doing a nice job getting the interface.address: https://github.com/kytos-ng/of_lldp/blob/master/main.py#L87

However, in scenarios where that value is invalid, we also use an invalid value on our side.

I suggest adding a sanitization check on the above code that can use the switch mac address if the interface MAC address is invalid (i.e, a fallback mechanism). In case the switch mac address is also invalid or unavailable, we can use a random MAC address or truncated DPID.

viniarck commented 1 year ago

@italovalcy, right, let's provide this sanity and use a new src addr when it's invalid.

1 - Can we consider an invalid interface.addresss if it's either "00:00:00:00:00:00" (default pyof.foundation.basic_types.HWAddress) or if it has the last bit of the 1st octet set the multicast bit?

2 - Once it's considered invalid, I believe trying to derive it from DPID should make it slightly safer and more controllable, especially since most OF switches allow the dpid to be configurable too, right? We could derive the src address from the last 40 bits + interpolate the last 8 bits with port number % 256 formatted as two hex digits, and then always ensure that it's a unicast locally administered address (as we've done for coloring NApp). Let me know if you'd be OK with this or if you'd prefer other approach.

Note: I was also thinking of using the first 40 bits of the last 6 bytes of a DPID, but not all switches typically embed their switch/platform MAC in last 6 bytes like OvS typically does by default, so the last 40 bits + interpolated port + ensuring unicast locally administered seems safer to me.

italovalcy commented 1 year ago

Hi Vinicius, excellent work you have done so far on this task! Thanks a lot for your help on this and for the suggestions!

For 1, I was trying to check how Juniper validates the validity of a MAC address, but I wont able to find a trusted reference about this. Thus, I believe we are good to go with this validation.

2 - Yes, I believe it is okay to proceed with this approach. Even a random value would be okay, but the proposal you made sounds good to me. I went ahead and tested with our current DPIDs and possible port numbers and all packets were delivered using the source MAC address constructed with the proposal you sent.

Let's go for it!