Saku Ytti wrote:
If customer does not react, put it on quarantine VLAN. This can be automated too. Wrong MTU => open internal case, contact customers email, no customer response in N days, quarantine VLAN.
... and then the customer will leave the service down because it the primary peering lan works fine and they couldn't be bothered fixing jumbo lan connectivity because the neteng who wanted the 9000 byte mtu connectivity in the first place got distracted by a squirrel or left the company or was too busy doing other things.
work, but it's very difficult to actually know without trying what works and what does.
I've spent a good deal of time and effort trying to get a jumbo peering vlan to work and it didn't work for the reasons that I've mentioned, and others. For example, many types of hardware don't allow you to specify a different MTU for different .1q tags on the same physical interface. This means that if you want a connection to a jumbo MTU vlan and a standard mtu vlan, you needed two separate connections into the IXP. At that point, the ixp participant is unlikely to want to bother because there's no cost:value justification in getting the second connection. Don't get me wrong: jumbo MTU IXPs are a great idea in theory. In practice, they cause an inordinate amount of pain. Nick