I know you're all desperate to find out how we configure Q-in-Q between IOS and JunOS and here we have it. You know, when we did this the effort required to get the Juniper EX part done was worrying. The Juniper documentation was pretty good and the Cisco Q-in-Q part is very well documented of course. This techguide will hopefully help some of you out there desperate to join these two great platforms as one.
First I guess we should provide a little background to Q-in-Q services. The idea is pretty simple, Q-in-Q is a process whereby a normal 802.1q frame is attached to another 802.1q header, hence the name. You will most likely use this is you have a requirement to say connect two layer 3 networks together which are separated by a layer 2 network. The layer 3 networks at each end may be in the same subnet and each of these geographically disparate networks can act as one.
Here is our challenge:

The laptop at the top of the diagram is connected to a Cisco 6509E and is in VLAN 186 with layer 3 network 10.1.186.0/24. We have another laptop at the bottom of the diagram connected to a Juniper EX cluster again in VLAN 186 with network 10.1.186.0/24. We need to get both of these laptops to operate within the same network despite being separated by a number of switches and hops. That is to say when I ping from one side to the other I want one hop to the destination.
Lets begin.
First we're hopefully all up to speed on VLANs and what they mean. If you need to read up on VLANs then take at look at our other techguides for a reminder. Lets create VLAN 186 on the first 6500 connected to the laptop and then place the port connected to the laptop into that vlan:
6500_FRONT(config#) vlan 186
6500_FRONT(config-vlan)# name X_SITE_INTERNET
6500_FRONT(config-vlan)# exit
6500_FRONT(config)# int g0/0
6500_FRONT(config-if)# switchport mode access
6500_FRONT(config-if)# switchport access vlan 186
6500_FRONT(config-if)# no shutdown
6500_FRONT(config-if)# end
6500_FRONT#
So now lets take a look at the port connected between the FRONT and BACK 6500's. We need to configure this as an 802.1q port. Remember the Q-in-Q takes our 802.1q frames first.
So we take the VLAN 186 and only allow it on this port. Untagged traffic is also placed into VLAN 186 but this is necessary. We've forced the port to not use DTP (switchport nonegotiate) and we're manually configuring it as a trunk port. Forcing the port as a trunk is not required but is good practice.
Lets have a look at the 6500_BACK configuration for the port connected to the 6500_FRONT G4/11.
OK, looks like a lot of configuration here so lets go through the main lines. Now on a trunk port if you have a configuration for an access vlan (switchport access vlan) but configure 'switchport mode trunk' then the port os a trunk port and the acces vlan configuration is ignored. In our case we're configuring a dot1q tunnel port and therefore the access vlan IS IMPORTANT. So what are we saying here? Basically the 802.1q tagged traffic ingress into the port is left tagged (as if it were an access port with no tagging). The next line switchport mode dot1q-tunnel no performs the double tagging - we're going to be ramming tagged VLAN 186 traffic into VLAN 3043. The MTU is set to 9216 to accommodate for the double 802.1Q tag and should not be missed.
We're disabling CDP so that we can tunnel CDP. What?! Well to help to explain this here is an example. When you have two directly connected cisco devices and CDP is running and enabled on these ports then you can 'see' the other device by issuing a 'show cdp neighbors'. This process is true also for Q-in-Q neighbors but we must turn off CDP between the two endpoints for the tunnel or else it would stomp all over the tunnel start points (in our example CDP would be tunnelled from 6500_FRONT but since the other startpoint is a Juniper device which doesn't undertsand CDP this step is unnecessary).
The l2ptotocol-tunnel allows us to send spanning-tree BPDU's down the Q-in-Q tunnel and CDP...we don't need them in our example but maybe you are creating a spanning-tree loop in your deployment so I think these lines are useful...just in case.
So now we are going to configure a normal run of the mill ordinary 802.1Q trunk link between the 6500_BACK and 3560 switches.
6500_BACK# configure terminal
6500_BACK(config)# interface g4/12
6500_BACK(config-if) switchport trunk encapsulation dot1q
6500_BACK(config-if) switchport mode trunk
6500_BACK(config-if) switchport trunk allowed vlan 1559,2127,3043,3738
6500_BACK(config-if) mtu 9216
So here we're just creating a normal trunk as we said. We're going to be trunking the Q-in-Q vlan 3043 we already created. Don't forget the jumbo frame MTU requirement. The other VLANs allowed on the trunk are for other things.
Right, at the other end of the link between the 6500 and 3560 we're going to again configure a normal bog standard trunk.
3560(config)# system mtu jumbo
Then we need a reboot. Without this line the switch will not be able to support the minimum 1504 bytes required to transport the Q-in-Q frames. So when we're back we can move on - all should be fine so far...it's just trunking.
Here is the configuration for the port connected to the Juniper EX stack.
So we're still trunking 3043...and some others but ignore those.
Now onto the Juniper EX stack dot1q-tunnel configuration.
First enable the protocol frame support.
Now lets create the VLAN - this took some time to get right int he Juniper documentation.
Lets configure the port connected to the Cisco 3560. Again we need a dot1q trunk port and we'll restrict it to carrying only VLAN 3043.
So the last port configuration part if for the laptop port...
A quick 'show vlans XSITE_INTERNET_0 extensive'?
So there we go, IOS to JunOS using dot1q tunnelling. IT works, it's great tech, have fu.
No comments:
Post a Comment