[c-nsp] Possible Stupid Questions Alert - Combining VLAN's

[Tim Franklin]

On Mon, June 25, 2007 5:23 pm, Skeeve Stevens wrote:

> As I said - Possible Stupid Question Alert ;-)
>
> What I want to do I think is valid, so please keep flames on low!
>
> I want to literally be able to change a VLAN's number in a path of
> switches.
>
> For example: in a peering point we have half a dozen ISP's sharing a
> central switch for some private peering.
>
> All connections are Trunks so the different ISP's can patch dot1q VLAN's
>  to each other in whatever way they like.
>
> The issue is with conflicting VLAN numbers in the switch chain (involving
>  3750G, 3550, 3560G, 3524XL) and the trunks to the ISP's themselves.
>
> So, when there is a conflict, I'd essentially like to 'renumber' the VLAN
>  and then pass it off up the chain so their isn't a conflict in the path.

Ignoring the technical piece for a minute, this seems to rely on three
things:

- All the ISPs "playing nice" and telling you / checking with you before
they use a new VLAN
- You doing the admin to maintain a record of who is using what and
generate re-mappings accordingly
- You configuring switches to match

Now, if all of those are true, why not instead ask the ISPs to just ask
for a new VLAN when they want one, at which point they get assigned a new
one that's global to the exchange point?  You update the database, and
update the switch config to permit this VLAN only on the "core"-facing
trunk ports, and the trunks connecting to the ISPs who want to peer.

Seems to me to have the exact same level of interaction with the ISPs,
record-keeping, and switch config, without having to come up with anything
hairy - and has the bonus that ISPs *can't* inject traffic on "wrong"
VLANs when they "forgot" to ask you, as their trunks are locked down.

You could probably even automate the whole thing through a web front end
and let the ISPs effectively self-provision their own interconnects.

Regards,
Tim.