0 Kudos

allowing rate limit/shaping on interface belonging to switch group

Submitted by -
Status: New Idea

Actually, this mostly works today. I can add a rate shape and limit on a physical interface that is part of switch0. I can see that the limit is working correctly. The problem is, that when you reboot, it determines that this is an invalid config and refuses to configure itself properly, mostly making the switch useless. There are three possible suggestions for how to fix, and an explanation of the use case below.

 

To fix:

*1) preferred: disable the logic that prevents the switch from failing to boot properly. Allow rates and limits on physical interfaces in a switch group. Everything seems to work fine except for the booting part

 

*2) only disable the configuration lines for the rate limit and warn about it. The rate limit won't be applied, but the switch will otherwise work normally (2nd choice, but sub-optimal; at least the switch is usable, the rate limit fails to apply)

 

*3) adjust configuration to disallow setting rate and shape commands on interfaces that are part of switch. If you must. I don't like this option and I'm not sure why you would want to. #1 seems to be the easiest and I don't understand why you wouldn't just enable it at boot. There must be some reason, but as far as I can see it works quite well.

 

Use case (why do I want this, and presumably others)

 

We have a campus wireless network using UBNT sector antennas and Nanobeam AC dish CPEs. All of the links are managed by us and allocated, for simplicity reasons, out of a single address block. This make management, addition, removal, etc. of new CPE devices quite easy. Just add or remove the IP.

 

At CPE sites, all CPEs have either a physical network (lan) on an edge-router-X (lite), a wireless lan using some local indoor or outdoor APs, or both. All local customer devices are dynamically allocated with DHCP from the edge-router-X and given an IP range of 192.168.3 for customer devices. This is then NAT'd up to the campus level where it traverses to the edge firewall and out to the Internet.

This uniformity of config makes deploying at a new site rather easy, also troubleshooting. All CPE devices are dynamic and allocated out of the same respective range, All Edge-router-X have a switch with all of the ports in it and a couple of vlans. There is the campus vlan and the local vlan and they are the same across devices. The only difference is the nanobeam IP per customer and some local variances in number of ports used for physical or wireless.

 

But, we want to be able to bandwidth limit per customer based upon what they pay, since they end up consuming real internet bandwidth. We want to do this on the uplink from the customer to the campus, which means on the port of the Edge-router-X where it connects to the nanobeam. Perfectly sensible, right? So, applying a rate limit on that physical port is just the right solution. We don't want to put rhe rate limit on the switch port because that affects customers going from wireless to LAN or from lan-local to lan-local port. That's not desirable. We want it on the physical port that is the uplink and all of the other switch ports should be unaffected. We could, theoretically redo the entire config and have a layer 3 routed setup at each CPE, but then we also need to allocate a per-client distinct network to route and be less uniform and cookie-cutter in deployments.

 

As I said, the rate limit does work, until you reboot. Then the switch becomes basically a multi-port brick with no devices able to get their IP, etc until you login to it locally and fix things.