PSA; Cisco SDA and DNA default settings break broadcasts and BACnet discovery

If your vendor isn't listed discussion for that goes here. If we get a lot of discussion on it we will create a sub and move posts.
Post Reply
User avatar
Maxburn
Posts: 97
Joined: Wed Mar 04, 2020 12:51 am

PSA; Cisco SDA and DNA default settings break broadcasts and BACnet discovery

Post by Maxburn »

This was posted to an internal user group but could potentially impact many of us;
Josh Leonhart, Control Service Co. wrote:Here's what I've got that I shared with our group:

Affected Cisco switches: (so far…)
3850
3650
93xx
94xx

Based on testing, “Multicast support” has to be enabled in their setup for our ports/equipment, which is not on by default. This also requires something called “L2 flooding”. There are issues with this feature until the follow firmware revision:
Fabric controllers: 1.3 (Which runs 16.11.1c on border controller switches)

The above probably makes no sense. It doesn’t to me either. I’m providing the information hoping it will make sense to the networking teams you may encounter. But the important takeaway is if a customer is using the above mentioned Cisco Catalyst switches (the new “SD-access” setup), they’ll need to move to this firmware/code (16.11.1c) or later in order for our equipment to work, then enable multicast support.

Potential side effects you may see if this is NOT in place:
• Network points not passing between LGRs/G5s (OA, runfor, requests, ect) even with routers on the same network subnet
• LGR/G5 dropping offline and not coming after power cycle or download


Cisco updates aren’t a single linear progression like Windows or our module drivers. Customers choose a level of how close to the newest they’re willing to tolerate. Something like Stable / Release Candidate / Beta kinda thing, but serious fixes are merged into older stuff also. Therefor, it may be some time before this fix makes it into the mainstream stuff our customers may be seeing or more importantly implementing.
To me it seems like the "L2 flooding" being disabled by default is definitely a contributing factor.

https://community.cisco.com/t5/networki ... -p/3943916
Cisco SD-Access fabric provides many optimizations to improve unicast traffic flow, and to reduce the unnecessary flooding of data such as broadcasts. But, for some traffic and applications, it may be desirable to enable broadcast forwarding within the fabric. By default, this is disabled in the Cisco SD-Access architecture. If broadcast, Link local multicast and Arp flooding is required, it must be specifically enabled on a per-subnet basis using Layer 2 flooding feature.
This feature being off by default sounds like it will break a bunch of things. I know on one such network the IT guy commented camera discovery didn't work either.
Post Reply