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 <[email protected]>: > 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 <[email protected]> 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 [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
