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

[Martin T]

Keegan,

Which MAC address limitations do you mean? Limitations for CAM table?
Or did you mean maximum number of VLAN's configured to the switch?
To sum up, you think that from some point this QinQ setup in
local-loop provider network will go over to VPLS?


regards,
Martin

2011/3/25 Keegan Holley <keegan.holley at sungard.com>:
>
>
>
> On Thu, Mar 24, 2011 at 4:12 AM, Martin T <m4rtntns at gmail.com> wrote:
>>
>> 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.
>
> Ok that explains alot.  Also, they may have said tag-type 9100 with giant
> frames enabled, but that shouldn't matter.  They shouldn't care about your
> VLAN tags since they are just adding their own on top of it.  They probably
> impose mac address limitations though.
>>
>> 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.
>
> Did you order an NNI from them or are they just calling the port facing them
> NNI?  EIther way they are saying that your topology and vlans are fully
> encapsulated inside of theirs so it shouldn't matter what they do.
>>
>> 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)
>> >>>>>
>
> translation: we can send your traffic wherever you can afford to pay us to
> send it.  I think I recognize this carrier.
>
>>
>> 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
>
> I thought you were trying to design a local loop network.  Each provider
> network is different.  Some have multiple switches, some have a single edge
> switch and plug directly into a vpls/mpls router, some don't even really
> hand you ethernet, but sonet with the media conversion done at the edge MUX.
>  The q-in-q stuff on your diagram is probably there in most cases, but the
> actually topology is probably radically different.
>>
>> >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?
>
> I thought you were designing a metro network.  In general providers
> shouldn't have a switch facing the customer that isn't doing q-in-q unless
> it's managed cpe.
>>
>> >There's also a question of how to
>> > treat customer QOS/COS values, etc/
>> Aren't DSCP values checked only by L3 equipment?
>
>
> No, most metro-E vendors can inspect L3 headers in L2 traffic and create
> policies based on them.  Even non-metro gear such as the 3560 can do this.
>  Also, COS values are in the vlan tags so they do not require L3 capable
> hardware.
>>
>> 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?
>
> Most use vpls or l2vpn at some point.  However you can build a functioning
> metro topology using q-in-q.  There are some pretty important limitations
> though.
>>
>> 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/
>> >>
>> >
>> >
>>
>
>