My question is : does the actual RSP720-3C-10GE also support the Q-in-Q feature ?
We have a client that might want to shift away from the 7200/NPE-G2 and start using the 7600 series router and asked me if it does support the feature without use of the ES+ line cards.
Cisco is not very helpfull if you do not have a service contract.
I have a expired CCNA cert …and only CCIE like you get access to all the Cisco tools and TAC.
But you are right if i research by software , then choose the RSP720 / major release / release / feature set i find Q-in-Q and also with 802.1ad .
The weird thing is that I can still not find it when i search by Feature/Technology … i do find the feature 802.1ad … the only IOS releases i get are XE IOS then i see the ASR903 ASR-920
With the other last releases (15.4S and 15.5S) i only find the ME3600/3800 machines.
Frame Comes From R1 to SW1, the max size could be 1522 bytes(1460data+20TCP+20IP+14ETH+4FCS+4VLAN_TAG) and when leave from switch size will be 1526 bytes (adding another 4 byte tag) but you mentioned the size 1500 and 1504. Little bit confused on it. Thanks,
The Ethernet MTU is 1500 bytes which means that the payload of the Ethernet frame can be 1500 bytes. In reality, the entire frame is 1460 (data) + 20 (IP) + 20 (TCP) + 14 (Ethernet header) = 1514 bytes.
By setting the MTU to 1504, we can send a payload of 1500 bytes including a 4 byte 802.1Q tag.
Is it usually recommended that the customer tag its own packets? Doesnt seem to be a requirement in your demonstration but I can see how things can go wrong very quickly. Native VLAN might be used for something else within the SP cloud. Although they can force all the frames to be tagged with the vlan dot1q tag native command.
The customer does not necessarily have to tag his own packets. It is not a requirement. The packets will pass through the q-in-q tunnel in whatever format the customer sends them in: either tagged or untagged depending on his needs.
I’ve implemented a q-in-q production network and I tend to agree with you that it is a much cleaner implementation if no untagged traffic was allowed on (the outer layer of) a q-in-q tunnel. (The inner layer or the customer traffic can send whatever they want). The dot1q tag native command is very useful in keeping the implementation clean.
I’m not sure I understand your question completely. Can you describe the situation in more detail? If I understand correctly, when your customer equipment access port goes down and then comes back up, CDP is disabled? Can you give me a little more information?
QinQ tunneling is mainly used by telcos to allow for the trunking of multiple customer VLANs over one telco VLAN. It is rare to actually use QinQ tunneling just within a customer’s network.
I can give you an example of the use of QinQ within a customer environment based on my experience. I am administrator of a Municipal Fibre Optic (MAN) network which is owned by the municipality that I partner with. There are over 80 km of fibre optic cabling that terminates at 24 different nodes with Cisco equipment in each. The fibre optic network serves many of the municipality’s buildings but also provides network connectivity for the city’s hospitals, schools and other public services. Each service that is connected is provided with one VLAN.
The municipality itself is a special case, because we have 18 VLANs that serve the internal networks of the municipality itself. So, I created VLAN 35 on the Fibre Optic network (propagated to all switches via VTP) as a QinQ VLAN and pass all of the municipality’s internal VLANs over that VLAN. So because the MAN belongs to the municipality, strictly speaking, I created a QinQ VLAN within the customer’s network.
In order to warrant the use of QinQ on a customer’s network, it must be a very large network with special VLAN requirements. You will not come across such a network very often.
one question, as we have MTU size is 1500, means link can have max frame of 1500 byte(including payload and header), now with QinQ we are adding
2 valns(means 8 Bytes)this means we need to change MTU size to 1508. pls explain
When implementing QinQ, it is always a good idea to increase the size of the MTU of the “outer” network, that is the network providing the carrier VLAN. The MTU size of 1500 accommodates the first VLAN tag of 4 bytes. In other words it is included in the 1500. So, strictly speaking, the MTU of the outer VLAN must be at least 1504 bytes to accommodate the extra tag.
In practice, it is always best to go higher to be sure you can accommodate all necessary traffic.
…and only CCIE like you get access to all the Cisco tools and TAC.