topic Re: Wireless Anchor SDA MSRBs in Software-Defined Access (SD-Access)

Wireless Anchor SDA MSRBs

mike.rohman — Tue, 03 Feb 2026 22:51:28 GMT

Hi all,

We have a 100+ sites scattered across the country and are deploying Cisco SDA for them. There are currently two data centers with existing, non-SDA anchor WLCs for Guest Wifi. Thus, the Guest/BYOD service is centralized for the sites.

There are a few exceptions regarding these sites. They can't support the 9100 MTU on WAN circuits which is required for SDA MSRB. As of now, the deployment/design is enabling the SDA fabric at each of our sites. They range from fabric-in-a-box sites to large sites with primary/secondary WLCs. Each WLC at each site will have all of the SSIDs configured for the enterprise including anchor Guest access. To deal with the scale, we're planning to leverage Catalyst Center templates and profiles for automation of config changes , like cert renewal.

Should we examine the MSRB solution for anchor services vs. deploying all of the SSIDs at each fabric site? We think that the current solution is simple and scalable, but we'll have many more controllers. We're wary of the 9100 MTU size and potential problems with VXLAN over the Cisco SD WAN. Per Cisco's recommendation, we'll make all configuration changes via Catalyst Center so that it's network inventory will stay in sync. We don't plan to be making manual changes to fabric WLCs.

We have VNs and SGTs to separate the east/west traffic , by the way.

Thanks!

Re: Wireless Anchor SDA MSRBs

Sebastien CIELOCH — Fri, 27 Feb 2026 07:05:03 GMT

Hello @mike.rohman

I'm facing the same challenge, MSRB requires MTU 9100 because of the Don't Fragment with VXLAN as you said. Documentation is clear about that.

It means from my understanding that the EN in your branch must have /32 routes without fragmentation in the GRT towards the MSRB BN/CP hosting the anchored VN. Because of this limitation, I don't know if a lot of companies can use this feature... even if they want to.

Apparently you can solve the problem for TCP trafic, by enabling the TCP MSS fuctionnality on the anycast gateway. However it does't works for large UDP packet.
The Path MTU discovery function could also help if the client support it, but it won't solve the problem from my point of view, it's too random.
https://www.ciscolive.com/c/dam/r/ciscolive/global-event/docs/2024/pdf/BRKENS-2816.pdf

@jedolphi @Andrii Oliinyk any advice from your side to solve this MTU limitation / Guest use-case correctly ? Or an upcoming solution in CatC version 3 ? 🙂

Maybe configuring the EWC in branches for Fabric SSID with local Handoff (no MTU issue), and Guest SSID to a Unified/centralized Guest Anchor WLC (non-Fabric with P2P blocking mode enabled) to achieve a similar result ?
thanks

Re: Wireless Anchor SDA MSRBs

Andrii Oliinyk — Fri, 27 Feb 2026 09:21:10 GMT

Hej Sebastien
for the MSRB to work u need transit capable of 1564B roughly. in case of any doubts fallback to wireless anchor OTT with foreign WLCs probably also running fabric SSIDs (solution you assumed in the end of your message). Though, afair u'll be limited with max 100 foreign WLCs with this deployment.

Re: Wireless Anchor SDA MSRBs

Andrii Oliinyk — Fri, 27 Feb 2026 09:39:20 GMT

u dont need strictly ~9K MTU on SDA-transit, with whatever actual MTU on interconnects from BN to BN it just must be capable of VXLAN packet size - 1564B (hopefully u dont run in generic payload IPv6 Extension Headers making encapsulated packet greater than that :0)

Re: Wireless Anchor SDA MSRBs

Sebastien CIELOCH — Sat, 07 Mar 2026 08:59:27 GMT

Is the VXLAN fragmented paquet droped by the Campus BN once received? And do you know by chance a cmd to view these drops if they apprear ?

On my lab I didn't notice any application issue, but maybe I had some silent drops for "big" UDP greater than 1472B

Cheers

Re: Wireless Anchor SDA MSRBs

Andrii Oliinyk — Fri, 27 Feb 2026 10:59:13 GMT

"Is the VXLAN fragmented paquet droped by the Campus BN once received? And do you know by chance a cmd to view these drops if they apprear ?"
u'll likely will have egress SDA-transit interface configured with high MTU otherwise SDA-transit wont be consistent from BN perspective. BN will forward VXLAN packet there, but if peer interface is uncapable of VXLAN entire frame it will drop it.

UPD. on your side u can try "show platform hardware fed switch active fwd-asic drop" or its variant

Re: Wireless Anchor SDA MSRBs

jedolphi — Mon, 02 Mar 2026 13:51:32 GMT

Hello, no changes in SDA / CatC 3+ that will change this scenario. What is lowest transport MTU between fabric sites and MSRB? What very large UDP would be in a guest network? Why is PMTUD too random for guest traffic? If it's wireless guest, note that Cisco AP will by default adjust MSS down to 1250. Cheers

Re: Wireless Anchor SDA MSRBs

Sebastien CIELOCH — Mon, 02 Mar 2026 17:54:29 GMT

Hi @jedolphi

Mtu supported by our ISP is arround 1450 (I don't remember the exact number).

I don't except very large UDP MTU from guest to be honnest, but if a client sends some UDP packet with standard 1500 MTU, VXLAN will be fragmented => dropped. Tcp will be because TCP MSS adjusted to 1250.

Yes it's for a wireless guest (maybe wired as all the VN is anchored).

In the design guide I see this sentence which states "tcp mss only works for tcp applications" => I understand from this sentence that UDP will be silently dropped

If you have more info or docs to read please send 😄 maybe i'm not understanding correctly the cons.

Extract from the design :

There are scenarios where the underlay network does not support more than 1500-byte packets, for example, if the fabric sites are connected using a Cisco SD-Access transit over a WAN that does not support more than 1500-byte packets. In these scenarios, the Transmission Control Protocol Maximum Segment Size (TCP MSS) can be set to limit the packet size, considering the overhead from VXLAN header encapsulation. The recommended value is 1250. Catalyst Center supports TCP MSS automation. This method works only on TCP applications.

Re: Wireless Anchor SDA MSRBs

Andrii Oliinyk — Mon, 02 Mar 2026 19:04:58 GMT

Hi Sebastien
i'm not sure why u so care of inability by guest user to send 1500+ UDP payload (honestly i'd like to see a guest using something different from web-surfing :0). If it's still critical from your pov dont use SDA-transit for their traffic. but still it will be limited by DF-bit set on its way to destination &| potential obstacles preventing ICMP-DU-FN to be received back to source.
UPD: u may disclaim guests on UAP-page from using UDP w/ jumbo payload :0D

Re: Wireless Anchor SDA MSRBs

Sebastien CIELOCH — Mon, 02 Mar 2026 19:53:24 GMT

Haha I got your point 😂 not sure they'll understand the UAP

tbh we have "long term guest", almost like contractors, working for several weeks for us. 4G/5G is so bad we need to provide Wi-Fi internet access or they can't work.

If a guest user have a UDP based VPN like OpenVPN and complain about it, I won't have workaround. However, I didn't find any "non-working application" on my lab... I hope it scares me for no reasons 😂

Re: Wireless Anchor SDA MSRBs

jedolphi — Tue, 03 Mar 2026 09:35:09 GMT

Many modern mainstream applications that use UDP should adjust down size automatically because devs understand that 1500B MTU isn't always guaranteed. Best way to know certain is to test the specific applications.