Hi,

On Wed, 12.05.2010 at 01:09:55 +0000, Stuart Henderson <s...@spacehopper.org> 
wrote:
> First talk to your wan provider, they might either be able to allocate
> you a couple of vlans that they'll carry for you, or do QinQ (i.e. you
> feed the provider plain vlans, and they appear directly at the other
> side).

I would very much prefer to abstain from reshuffling vlans in the
remote data centre. If possible, I'll try to arrange for
non-overlapping vlan ids, which would solve the immediate problem, but
could allow for unauthorized use of vlans (eg. what if someone
reconfigures their vlan stuff, and suddenly their packets enter the
wrong vlan?). I need to prevent this scenario. Using QinQ directly
would be much better.

The carrier said that they will transport all packets up to 64k per
frame fully transparently, w/o any alteration. I need to re-hash the
frametype issue, though.

> In-tree, there is the option of 'ifconfig vlanXXX vlandev vlanYYY" which
> might get you somewhere. This uses the same ethertype on inner and
> outer vlans and doesn't interoperate with other vendors vlan stacking,
> but you might be able to do something with it (or maybe you'll just
> confuse your providers switches).

So I can't change the frame types on a per-vlan basis, eg. to match
their respective switches' expectations... hmmm.

> There's also a diff at 
> http://www.mail-archive.com/misc@openbsd.org/msg65694.html
> that switches ethertype so you can interoperate with other vendors QinQ (it
> will need updating for -current).

Thanks for pointing this out! I'll have a close look.

> But usually you just feed plain vlans to the wan provider and they handle
> translation or stacking..

?!?

> >                                    I also need to do traffic shaping on
> > a per-vlan basis.
> 
> This does seem to work but I'm under the impression that queueing
> "should" be done on the physical interface (vlandev).

I don't know how useful this really is. I need to limit and/or reserve
bandwidth of individual vlans on the (one) wan pipe.



Kind regards,
--Toni++

Reply via email to