[c-nsp] 802.1QinQ setup in local-loop provider network

[Martin T]

Keegan,
thanks for reply!

I don't know the platform. Actually the only thing I know is a service
description from local-loop provider and it's following:

<<<<<
We have no need to agree upon vlan-id:s, because our setup is a q-in-q
transparent solution with 9100B MTU.

You are able to use any vlan-id´s towards the NNI and the same vlans
are transported through our network to any UNI -connection you order
from us. It is a full-mesh topology. You are able to add and remove
any vlan you want. Just tag your interface towards us and use whatever
vlan-id´s.

For further connections the function is the same. Just add any vlan to
the NNI and you are able to use it anywhere in our network where we
have added your outer-vlan tag (Q-in-q)
>>>>>

According to this description, I thought, that maybe the local-loop
provider network looks something like this:
http://img26.imageshack.us/img26/4553/8021qinq.png

>You shouldn't have customer facing boxes
> without q-in-q enabled as they would be vulnerable to vlan hopping.

How is this possible if customer facing port is an access port?

>There's also a question of how to
> treat customer QOS/COS values, etc/
Aren't DSCP values checked only by L3 equipment?

According to the service description, this local-loop provider uses
802.1QinQ(not VPLS) and I would like to know, how can they provide
such service?


regards,
martin

2011/3/24 Keegan Holley <keegan.holley at sungard.com>:
> What platforms are being used?  With dot1Q and any such configuration the
> mac-address table size and vlan tag limits become scarce  resources.  Vlans
> (provider vlans) cannot be reused with all equipment and 4096 vlans will go
> fast if you have 20k customers for example and vlan-maps/cross connects can
> be strange.  Some providers use vpls or L2vpn to overcome some of these
> limits but that increases the price tag of the equipment.  There are other
> concerns as well such as security.  You shouldn't have customer facing boxes
> without q-in-q enabled as they would be vulnerable to vlan hopping.  You
> should also limit mac address consumption.  Someone could be nasty and
> connect a traffic generator or test set and fill up the mac address table
> just to cause problems in the network.  There's also a question of how to
> treat customer QOS/COS values, etc/
>
> On Wed, Mar 23, 2011 at 8:18 PM, Martin T <m4rtntns at gmail.com> wrote:
>>
>> I made a following simplified network picture:
>>
>> http://img26.imageshack.us/img26/4553/8021qinq.png
>>
>> It's simplified in sense that there might be actually hundreds of
>> other ISP's like ABC using the local-loop provider services and each
>> such ISP might have hundreds of customers like "customer X", "customer
>> Y" and "customer Z". In addition, the network of local-loop is of
>> course much larger.
>>
>> This local-loop provider provides a last-mile service in order to
>> connect ISP's with their clients. Each ISP configures dot1q trunk port
>> facing the local-loop provider and customers of ISP("customer X",
>> "customer Y" and "customer Z" in this case) will get an access port
>> from local-loop provider. ISP will just add a different VLAN for each
>> customer to the trunk port with local-loop.
>> The question is, how such local-loop provider network is made? Is this
>> possible at all? In my opinion, this
>> http://img26.imageshack.us/img26/4553/8021qinq.png should be one
>> possibility, but this solution has at least one disadvantage- there
>> might occur VLAN overlapping in the last switch of last-mile provider.
>> In addition, if local-loop provider switches check only the outer-tag,
>> then isn't all the traffic for each end-customer distributed across
>> entire outer-VID(VLAN 777 in the picture)?
>>
>> All the design descriptions/suggestions are most welcome!
>>
>> regarding,
>> martin
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>
>