We are working with a customer that is moving from MPLS to SD-WAN solution for all 20 or so of their locations. We have a POC active currently with the SD-WAN handoff on a layer3 interface vlan assigned to a trunk port on a Catalyst 3850 switch. We are able to manipulate the traffic through static routes to get the traffic we need back to their data center over the Verizon SD-WAN solution. Our issue is with some additional guest networks that were created on the Cisco 4431 ASR router at each site (was also previously being used as their ISP and MPLS router). They used zone-based IOS firewalls to split out the ISP connection, along with separate DHCP pools created for each on the router. Those were then trunked to the core 3850 switch and then devices assigned to the respective guest vlan on that switch port. The customer wants to get rid of the router and maintain the same type of setup. I know we can create the additional interface vlans on the switch, create the local dhcp pools, but the zone based firewall capability of the router, I am not sure this is even possible to do on this switch? I am inclined to advise them to keep the routers in place, as the current solution has worked flawlessly for years. But I don't want to tell them that unless I am sure its not possible to do on the switch.
The ISR defines interfaces by zones, the zones being:
zone security INSIDE
zone security OUTSIDE
zone security GUEST
zone security AIRMEDIA
zone security TIMECLOCK
zone security VERT
zone security SIGNAGE
Each of these today have a corresponding sub interface on the router, gig0/0/0.224, gig0/0/0.272, for each of the zones. Is this possible to replicate on a catalyst series switch, possibly with the new IOS-XE 17.X versions? Right now I have Verizon handing off to me on a trunk port with vlan 110 for the private SD-WAN networking, and vlan 2010 for general internet, we created a /29 network for each on the switch so we can route the traffic and put in static routes to those corresponding next hop addresses, and that is working just as we expected. But the need for all these separate "guest" networks is a bit of curve ball. If anyone has any ideas here, it would be most appreciated.
