|
0:00:12
|
In our next section here we're going to talk about 802.1q tunneling
|
|
0:00:18
|
along with Layer 2 protocol tunneling and then some advanced designs of running dot1q tunneling and Layer 2 protocol tunneling over EtherChannel.
|
|
0:00:28
|
Now dot1q tunneling is designed to provide a Layer 2 VPN service over an Ethernet network which is typically deployed in a metro Ethernet type environment.
|
|
0:00:40
|
Now dot1q tunneling is essentially a very lightweight version of MPLS Layer 2 VPNs which are also described as the any transport over MPLS, the atom feature,
|
|
0:00:52
|
and the virtual private LAN services or VPLS feature. Now the Layer 2 VPNs, those are not going to be within the scope of routing and switching.
|
|
0:01:00
|
So when we get to MPLS we won't cover atom or VPLS but it's the same type of logic of what we're doing here with the dot1q tunneling.
|
|
0:01:10
|
Now the idea is that the customer switch or customer router that is connecting to the provider switch is going to run on 802.1q trunk link.
|
|
0:01:21
|
So it's a Layer 2 trunk that is running between the customer and the provider. From the customer side they are sending multiple VLANs with different dot1q encapsulations
|
|
0:01:31
|
up to the provider. When the provider receives these frames inbound, it is adding an additional dot1q tag that is known as the metro tag or the QinQ tag
|
|
0:01:44
|
in order to transport the frames over the provider network.
|
|
0:01:49
|
So within the service provider network each customer is going to be assigned the same VLAN.
|
|
0:01:56
|
So customer A will have VLAN A, customer B will have customer B, within the service provider network.
|
|
0:02:02
|
Now this also means that in the core of the service provider network, they will not need to know any of the VLAN information about the end customers.
|
|
0:02:12
|
So this would allow customer A to use VLANs 1, 2, and 3 and customer B likewise to use VLANs 1, 2, and 3 while keeping them in separate broadcast domains.
|
|
0:02:23
|
So there's no way for the traffic to leak between the two customers based on the fact that the provider is keeping them in separate CAM tables based on the metro tag
|
|
0:02:32
|
or essentially just the VLAN that is assigned to that particular interface.
|
|
0:02:38
|
Now the configuration of the feature is very straightforward. On the provider edge switch, which is on the provider network facing down to the customer,
|
|
0:02:47
|
we set the switchport mode to be dot1q tunnel. This tells the switch that for whatever frames it receives inbound it will add the additional encapsulation
|
|
0:03:00
|
of whatever the access VLAN has assigned to the link. So if the access VLAN is 10, this is what the metro tag, or the QinQ tag, will be for any frames that are received.
|
|
0:03:15
|
So configuration of this is just going to be on the provider edge switches that are connecting to the customers.
|
|
0:03:21
|
There's not really a lot of verification that we need to do for this. There is the show dot1q tunnel command that is going to tell us
|
|
0:03:27
|
that the link is running in tunneling mode and what the metro tag is. Beyond that we just need to make sure that inside the provider network everyone knows how to switch that particular VLAN.
|
|
0:03:40
|
So if the metro tag is 10, we need to make sure that 10 exists in the VLAN database of the service provider network.
|
|
0:03:49
|
Now this feature cannot be dynamically negotiated through DTP so we need to manually set the mode to be dot1q tunnel.
|
|
0:03:57
|
Again, this is on the provider edge switches on the links that are facing towards the customers.
|
|
0:04:05
|
So if we look at our topology the logic behind this, let's say that we have on switch three, we have one link that is going to router three
|
|
0:04:17
|
and on switch four we have a link that is going to router four. So behind router three there is a flat Layer 2 network. Behind router four, likewise there's a flat Layer 2 network.
|
|
0:04:33
|
So this consists of multiple VLANs - 10, 20, 30, 40, etc. The key is that these VLAN numbers are the same on both sides of the customer network
|
|
0:04:46
|
so they are trying to span traffic from VLAN 20 on router 3 side to the VLAN 20 on router 4 side.
|
|
0:04:55
|
Same with whatever other numbers they have - 10, 30, 40, etc.
|
|
0:05:00
|
This means that when the provider edge, which in this case would be switch three and switch four, these are the PE switches,
|
|
0:05:08
|
any frame that is received in here whether it is for VLAN 10 or it's for VLAN 20 or whatever, and then we have the payload inside there,
|
|
0:05:19
|
all of these frames are going to be encapsulated with the new metro tag. So let's say in this case the metro tag is 100.
|
|
0:05:28
|
Okay, this is the VLAN that will be assigned on the interface that connects to these routers.
|
|
0:05:36
|
So there's no special configuration for that. We just say switchport access VLAN 100.
|
|
0:05:40
|
Once the interfaces are configured as tunnels by saying switchport mode dot1q tunnel
|
|
0:05:46
|
any traffic that is received from three or four is transparently sent up the trunk links using VLAN 100 as it's transport.
|
|
0:05:58
|
So this means that the switches in the middle, switch one and switch two which are considered provider switches, they do not need to know about VLANs 10, 20, 30, and 40.
|
|
0:06:10
|
The only thing they care about is the ability to transit VLAN 100 which is the customers VLAN that is the metro tag.
|
|
0:06:20
|
So to do this on router 3 and 4, I'm going to configure a couple different sub interfaces where we want to be able to ping from 3 to 4 on multiple different VLANs.
|
|
0:06:32
|
We'll say just 2 VLANs. We'll say 10 and 20. Then on switch 3 and 4, they will configure the links to the routers as tunnel ports
|
|
0:06:43
|
and agree on what the access VLAN number is so we'll say VLAN 100 again that's going to be the metro tag or the QinQ tag.
|
|
0:06:51
|
So first let's start on the routers on 3 and 4 and we're back to a blank configuration so we don't have anything on the interfaces here
|
|
0:07:03
|
and this is going to be on router 3 this is FastEthernet 0 slash 1. So we'll say on FastEthernet 0 slash 1 dot 10
|
|
0:07:14
|
we're encapsulating dot1q 10, IP address is 10 0 0 3. We also have sub interface dot 20 that is VLAN 20. Okay, we'll say this is 20 0 0 3 and then we'll add a third one. Let's say VLAN 30.
|
|
0:07:39
|
So the key point about this feature is that it doesn't matter how many VLANs the customer is using, all of them are going to be transparently sent
|
|
0:07:47
|
across the service provider network using that additional VLAN tag.
|
|
0:07:54
|
So on router four we're essentially going to have the same exact configuration here. We just need unique IP addresses.
|
|
0:08:04
|
So let's just take what router four's configuration is and we'll change it around a little bit.
|
|
0:08:15
|
So this will be we'll say dot four.
|
|
0:08:32
|
If we look at the result, let's say show IP interface brief, we see that the physical link is up, the fast Ethernet zero slash one,
|
|
0:08:42
|
and we have the three different sub interfaces - 10, 20, and 30.
|
|
0:08:46
|
So ideally once this configuration is complete I should be able to ping 10 0 0 3, 20 0 0 3,and 30 0 0 3.
|
|
0:08:52
|
So at this stage we don't have any of the switches configured so they're not going to be receiving or they will not be able to transport this traffic to the destination.
|
|
0:09:06
|
So next step we have in the transit network let's make sure that the switches are trunking with each other.
|
|
0:09:14
|
So on switch one let's say show interface trunk. Okay, we have the trunks that are going to
|
|
0:09:25
|
switch one and...or not, that is switch one. The trunks are going to switch two and three.
|
|
0:09:32
|
And to simplify this I'm going to remove the other VLAN so let's say no VLAN 2-1000. The only VLAN we need is 100. That's going to be our metro tag.
|
|
0:09:44
|
On switch two let's say the same thing. Show interface trunk. Okay, we have just VLAN 100 now.
|
|
0:09:54
|
Switch 3 and switch 4, these are the provider edge switches. So on switch 3's port FastEthernet 3, this is where we will say that the switchport mode is dot1q tunnel
|
|
0:10:10
|
and the switchport access VLAN is 100. Now notice it gives us a log message there, a warning. We'll come back in a second and talk about what that particular warning message means.
|
|
0:10:25
|
So otherwise the configuration here are pretty straightforward, just those two commands. Notice also by default it disables CDP on the interface.
|
|
0:10:35
|
This is to make sure that the customer and the provider are not leaking any information between each other.
|
|
0:10:46
|
So on switch four that's the link that connects to...oops, wrong one. That should be FastEthernet four.
|
|
0:11:00
|
And likewise switch four is complaining about that; that the...it says system MTU of 1500 might be insufficient.
|
|
0:11:08
|
So at this point if VLAN 100 is forwarding across the trunk links, if we look at show spanning tree VLAN 100,
|
|
0:11:19
|
Any traffic that is received in from router four should then be transparently sent over to router three.
|
|
0:11:27
|
So if we ping router three on the VLAN ten, the VLAN twenty, and thirty we can see that we can reach those devices.
|
|
0:11:47
|
Now if we were to go into the provider network, let's say on switch one, and create interface VLAN 10 with address 10 0 0 7,
|
|
0:12:02
|
and we'll also create VLAN 10, then do the same thing on switch 2, let's say interface VLAN 10 is 10 0 0 8.
|
|
0:12:20
|
We should see that switch 1 and 2 will be able to reach each other.
|
|
0:12:30
|
So once VLAN 10 actually starts to forward, let's show spanning tree VLAN 10, okay now the protocol is up so if we ping 10 0 0 7
|
|
0:12:45
|
we could see switch one and switch two, they have reachability to each other on this segment. But if we tried to send traffic down to the customer
|
|
0:12:53
|
technically these are two different broadcast domains. Even though it's sharing the same number, VLAN 10,
|
|
0:13:00
|
From the providers network traffic that is received in from router 3 that has a payload that says number 10, that's not the same as the switch virtual interface 10 that is on switch 1 and switch 2.
|
|
0:13:17
|
So the customers traffic is segmented from the providers traffic based on the fact that the metro tag is added to every frame that is received inbound.
|
|
0:13:29
|
When the frames go outbound from switch 3 to router 3 the metro tag is removed.
|
|
0:13:35
|
So then router 3 sees the actual final VLAN number, VLAN 10 or VLAN 20, that was set by router 4 who was originating the traffic.
|
|
0:13:50
|
Okay, any questions up to this point on the dot1q tunnel?
|
|
0:13:58
|
So again our configuration's pretty straightforward here. Just on the PE device which is switch 3 and switch 4, we're setting what the metro tag is
|
|
0:14:09
|
and we're turning the tunnel on. As long as everyone in our switch network knows about VLAN 100, that's pretty much all that we need to do.
|
|
0:14:22
|
Now there are some additional design issues we need to take into account if we're doing this tunneling.
|
|
0:14:28
|
First and foremost that the whole entire transit network would need to be Layer 2 only.
|
|
0:14:35
|
So between each of the customer sites as we attach the provider and then the provider attaches to it's other devices that would have to be Layer 2 Ethernet only.
|
|
0:14:46
|
So the main design issue here is that it's not scalable. If the service provider network is very large, they're not going to want to run a flat Layer 2 network everywhere
|
|
0:14:56
|
in order to transport the traffic for the customer. This is the main advantage of running MPLS, Layer 2 VPNs, over the dot1q tunnel VPN
|
|
0:15:10
|
because with MPLS the provider cloud can run just IP.
|
|
0:15:15
|
So with MPLS they can offer both Layer 2 and Layer 3 service while essentially tunneling the traffic inside IP in the core.
|
|
0:15:23
|
In our case here we're just tunneling Ethernet inside of Ethernet.
|
|
0:15:32
|
Okay, there's a question - what is the config of the router to the switchport?
|
|
0:15:37
|
Let's go back to that. So we see the provider edge config here. Router 3 and 4's config, they have sub interfaces that are running the VLANs.
|
|
0:15:47
|
So normally this device would be a switch that is running a Layer 2 trunk up to the provider.
|
|
0:15:54
|
But I'm simulating it in this case by using the router with multiple trunked sub interfaces.
|
|
0:16:03
|
There's a question - how does the provider know...how do the providers switches know which particular interfaces they should route?
|
|
0:16:09
|
So if we look at...let's look at router three and say show ARP.
|
|
0:16:20
|
And let's include...or actually there's only two addresses. Okay, we can see that the sub interfaces of router 3, the 10, the 20, and the 30,
|
|
0:16:29
|
these are all sharing the same MAC address. Okay? It's this 3AC1 address. Then router 4 is the 9A5D.
|
|
0:16:41
|
If we look at the provider edge which is switch 3 and switch 4, if we show MAC address table dynamic for VLAN 100,
|
|
0:16:55
|
and if we look back to these, these were 3AC1 and 9A5D
|
|
0:17:08
|
9A5D, we could see that the provider edge switch knows about the MAC addresses of the customer.
|
|
0:17:17
|
So this is another scalability issue that in the core of the service provider network, when we look at the CAM table,
|
|
0:17:28
|
show MAC address table for VLAN 100, they're going to know...uh, MAC address table dynamic for VLAN 100,
|
|
0:17:40
|
the service provider core switches basically need to know about every single MAC address of all of the end customers.
|
|
0:17:49
|
So figure if one of the customers has 10,000 end hosts and we're running Layer 2 only, it means that the service provider core would have 10,000 MAC addresses just for that one customer.
|
|
0:18:00
|
So this is another reason why it's not scalable. We're using just normal spanning tree logic and the normal CAM table in order to switch the traffic between the ports.
|
|
0:18:12
|
Okay, there's another question - can we use ISL in the provider trunks? Technically you can as long as it...because it will maintain the inner header which is the dot1q
|
|
0:18:27
|
original traffic from the customer. So if we look at let's say the link between switch one and switch two here
|
|
0:18:35
|
if we change this to ISL it should be fine. So on switch one let's say show interface trunk. This is port 13. On 13 let's say switchport trunk encapsulation is ISL.
|
|
0:18:55
|
Then the same thing on switch 2, switchport trunk encapsulation is ISL.
|
|
0:19:06
|
If we show interface trunk we see that we're now running ISL on port 13. Switch 2 should still have reachability to switch 1. Once spanning tree re-converges again here...
|
|
0:19:41
|
So we see switch 1 and switch 2 have reachability. This means that the ISL trunk is working. Now if router 4 is able to reach router 3, which it can,
|
|
0:19:52
|
we can see actually the dot1q tunnel is being tunneled over ISL.
|
|
0:19:59
|
So it's kind of a weird logic but it technically still works because ISL takes whatever is received on the link and it is encapsulating it with that VLAN 100 on the outside.
|
|
0:20:10
|
As long as the link between the customer and the provider, so in this case this would be...let me clean up this diagram a little bit.
|
|
0:20:23
|
So the link from switch 3 to router 3 and from switch 4 to router 4, these two have to be dot1q.
|
|
0:20:36
|
As long as in the service provider cloud we have some sort of Layer 2 trunk transport then it doesn't actually matter how it happens as long as there's Layer 2 reachability end to end.
|
|
0:20:54
|
Okay, there's another question - is there a technical difference between tagging and stacking when talking about tunnels?
|
|
0:21:00
|
Technically they mean the same thing it's just that when the packets come in from the customer there's going to be the outer Ethernet header that has their VLAN number so in this case it's VLAN 10.
|
|
0:21:17
|
Switch 3 is taking this frame and then adding a new header onto it, VLAN 100. This header is how big?
|
|
0:21:34
|
It's going to be an additional four bytes. We could technically take this result and then put it inside another tunnel and you can keep going basically indefinitely
|
|
0:21:45
|
the only issue is that the MTU starts to get smaller and smaller and smaller that you can use for the end customers transport.
|
|
0:21:53
|
So that's the next design problem that we have that not only is it not scalable because we need end to end Layer 2 trunking
|
|
0:22:00
|
and the service provider network learns every MAC address about the customer, the issue is that for every additional tag that you add
|
|
0:22:09
|
we're reducing the effective MTU of the payload. The real reason why this is an issue is that Ethernet as a protocol does not support fragmentation.
|
|
0:22:21
|
Where if this was IP, like an MPLS tunnel, then it's not an issue because the MPLS network is going to support fragmentation
|
|
0:22:30
|
because MPLS is essentially just an IP packet in the core.
|
|
0:22:35
|
Now in our example we did not see this problem yet because I'm doing just normal pings between router 4 and router 3.
|
|
0:22:46
|
So on router 4 we can see that we can ping router 3 no problem. If I try to send a large packet though this is where we can see the issue.
|
|
0:22:59
|
So now router 4 is trying to generate an ICMP ping where the entire IP packet, so the IP header followed by the ICMP payload, that entire packet is 1500 bytes,
|
|
0:23:15
|
since we're adding an additional 4 bytes of encapsulation on to the Ethernet header, now the total effective MTU is 1504.
|
|
0:23:25
|
So this would then mean that the end customer can only send packets as big as 1496. If we go above that to 1497, this is going to get dropped because now the size of this packet is actual 1501.
|
|
0:23:41
|
Now this is only going to be an issue if the service provider network does not support transporting packets larger than 1500 bytes.
|
|
0:23:52
|
Normally this isn't really an issue to begin with because these would be like gigabyte Ethernet links which support the giant frames
|
|
0:24:01
|
and I want to say it goes up to about 8,000 bytes or higher that it supports. But with regular FastEthernet the specification says you cannot go above 1500 bytes.
|
|
0:24:13
|
So in our case since we're using regular FastEthernet between the switches, somebody said 9142, that's the maximum for gig e but for regular fast e it's 1,500.
|
|
0:24:25
|
So when the packet comes in here at 1,500 we're adding the additional 4 bytes of encapsulation. This now means it's 1504 so now we're not able to transport it over switch 1.
|
|
0:24:41
|
There is a quick work around for this. It's just to tell the switch to allow that. So on switch one if we say that the system MTU
|
|
0:24:53
|
is at least 1504 then this is going to account for the larger frames. Now we can see for the jumbo frames which is for either gig e or 10 gig e
|
|
0:25:09
|
this one is going to support up to 9,000 so really it depends on the individual hardware platform how large of a frame that it's going to support.
|
|
0:25:18
|
But again the problem in the first place is that Ethernet doesn't support fragmentation. If this was an IP transit network the router could generate 2 IP packets out of the original larger frame and then we wouldn't have an issue.
|
|
0:25:32
|
So when you're doing dot1q tunneling and you can see that's what the switches we're talking about when they generated that log message.
|
|
0:25:39
|
It says you should at least set your MTU to 1504 because we're going to assume that the end hosts are probably going to try to use 1500.
|
|
0:25:49
|
If the end host did not use 1500 then you wouldn't have this problem in the first place and we could see that like on router four.
|
|
0:25:56
|
As long as I keep my payload size under 1497 then it's fine but as soon as I go one byte over that those packets are going to be dropped.
|
|
0:26:09
|
So typically when you do the dot1q tunnel configuration you would also want to go to the switches and then change the system MTU.
|
|
0:26:19
|
The problem then you can see it says this isn't actually going to take effect until you reload the device. So if we show system MTU
|
|
0:26:33
|
right now the MTU is 1500. When we reload then it's going to go to 1504.
|
|
0:26:42
|
So on all four of the switches we would need to change this.
|
|
0:26:51
|
The third issue with this tunneling is that by default the provider edge switch as it receives frames from the customer it is going to drop the control plane.
|
|
0:27:03
|
Control plane packets like CDP, VLAN trunking, spanning tree protocol; the reason why is that these are encoded with special source and destination MAC addresses
|
|
0:27:14
|
and by default those cannot be inserted into the CAM table. So when we look at the MAC address table of switch one in the transit path and we show
|
|
0:27:29
|
show MAC address table dynamic for VLAN 100, these MAC addresses again these are of the end customers. These are of routers three and four.
|
|
0:27:41
|
When three and four are sending frames like CDP and VTP or spanning tree those are using special destination MAC addresses that are reserved for those protocols.
|
|
0:27:52
|
So it's not valid to insert them as a normal MAC address in the CAM table. The result of this is that when switch 3 receives these packets on FastEthernet 3,
|
|
0:28:07
|
interface FastEthernet 3, these are just going to be dropped. This is why we can see that the switch disables CDP by default
|
|
0:28:16
|
because we cannot receive CDP packets from them. We could send them CDP packets but really we don't want to do that.
|
|
0:28:28
|
So Cisco came up with a solution for this by using the Layer 2 protocol tunneling feature which is essentially a special encoding of the control plane protocols like spanning tree to a new specific MAC address.
|
|
0:28:43
|
So not all vendors are going to support this. This is a Cisco proprietary extension to the QinQ standard.
|
|
0:28:51
|
Typically this is used with a dot1q tunnel but technically it doesn't have to. You could do Layer 2 protocol tunneling without configuring a dot1q tunnel.
|
|
0:29:01
|
This would be with some sort of design where let's say that we don't have anything to do with tunnels but we want switch three to show up as a CDP neighbor with switch two.
|
|
0:29:18
|
On switch one we could say create a protocol tunnel, a Layer 2 protocol tunnel, between those interfaces for CDP. Then as the update, the CDP update, goes from switch three out,
|
|
0:29:29
|
switch one would take that inbound and then just transparently forward it out that interface.
|
|
0:29:37
|
So really without dot1q tunneling there's not a reason why you would want to do it but technically you can.
|
|
0:29:51
|
There's a question here - what's the benefit of doing that? I'm not really 100% sure. So they're unrelated features. You can use them separately but normally there would be no reason to.
|
|
0:30:02
|
So within the scope of the lab exam it's kind of like a stupid router trick that you can do. You could configure switch two and switch three to run VTP with each other directly
|
|
0:30:12
|
or to run spanning tree or CDP. We'll take a look at a case here where we can use it to tunnel an EtherChannel between the neighbors
|
|
0:30:21
|
and we can also tunnel the EtherChannel negotiation which is the PAGP or the LACP.
|
|
0:30:28
|
But now let's say in this particular design we already have that in addition to the actual end user traffic which is coming from router 3 and router 4 that we want them to be CDP neighbors
|
|
0:30:46
|
and we also want them to run spanning tree together. So we'll configure a bridge group on the different sub interfaces.
|
|
0:30:56
|
So the configuration of this is pretty straightforward. Again, it's going to be on the PE to CE link on the PE switch.
|
|
0:31:05
|
So on switch three it's going to be on the interface that faces down to the customer which is router three.
|
|
0:31:12
|
Syntax wise this is the L2 protocol dash tunnel command. We could say CDP, VTP, or STP, and then also for the point to point tunneling we can do the EtherChannel negotiation
|
|
0:31:26
|
or unidirectional link detection which is like a Layer 2 keep alive. Okay, the point to point tunnel we'll come back to in a minute but let's look at the one using CDP and spanning tree.
|
|
0:31:41
|
So right now on router three if we look at the show CDP neighbors we don't see anything located on FastEthernet zero slash one.
|
|
0:31:53
|
So FA zero slash one again, this is the link that we're using for the tunnel.
|
|
0:32:01
|
On switch three, which is the PE switch, we'll go to this link and say L2 protocol tunnel CDP and STP. Same thing on switch four's end.
|
|
0:32:21
|
So on FastEthernet four CDP and spanning tree. Now on router three I'm going to create three different bridge groups. We'll say bridge 10 protocol IEEE, bridge 20 and 30.
|
|
0:32:41
|
So we're essentially running three different instances of spanning tree. These are going to run on sub interfaces ten, twenty, and thirty.
|
|
0:33:05
|
Okay, this log message basically says that the router needs to generate a random MAC address for it's bridge ID.
|
|
0:33:11
|
This configuration, we'll come back to this later in the week and talk about transparent bridging on the routers but basically these two commands are first off just turning spanning tree on
|
|
0:33:23
|
which is the bridge command. Then we're saying that this interface, this particular sub interface, is part of that spanning tree domain. So this is like assigning the VLAN.
|
|
0:33:36
|
The bridge group is essentially the VLAN number.
|
|
0:33:43
|
Okay, then on router four I'm going to do the same thing. So let's say show run include bridge or interface.
|
|
0:34:07
|
So this config here, it's going to be identical on router four.
|
|
0:34:17
|
If we look at the result of this and say show CDP neighbors we could see now router four shows up as a CDP neighbor on our local FastEthernet zero slash one.
|
|
0:34:31
|
It says on the other end of the link they are also FastEthernet zero slash one. But in reality, this is the link here, this FastEthernet zero slash one, this is what we connect to switch three.
|
|
0:34:43
|
Their link, that's what they're connecting to switch four with. It's that we have that transparent tunnel between the two that is putting the CDP inside of it.
|
|
0:34:54
|
Okay, if we were to also look at the show spanning tree ten, where ten is the bridge group number or basically the VLAN, router three says that it is the root of the spanning tree.
|
|
0:35:11
|
This is it's priority value. This is it's MAC address. If router four now agrees that this address is the root, it then means that spanning tree is properly being tunneled over the dot1q tunnel.
|
|
0:35:29
|
So on router four let's look at the same thing. Show spanning tree ten. It says the current root for instance ten has a priority of 32768, address 0 0 11 21 A 4 etc.
|
|
0:35:46
|
So if this is router three's address, which it is, then it means that the spanning tree is being properly tunneled. If we look now in the core of the network, let's say on switch one,
|
|
0:36:05
|
and look at the MAC addresses...actually it doesn't show up in the CAM table here. Let's see. What did we have before?
|
|
0:36:26
|
Let's clear this out. Let's say clear MAC address table dynamic VLAN 100.
|
|
0:36:40
|
So it's not going to show the specific MAC address but if we take a look at the documentation under the configuration guide for the switches
|
|
0:36:49
|
this would be under configuring IEEE 802.1q and Layer 2 protocol tunneling. If you look at the configuring or understanding Layer 2 protocol tunneling...
|
|
0:37:20
|
I thought it said here what the addresses were.
|
|
0:37:28
|
When protocol tunneling is enabled end switches on inbound side of the service provider network encapsulate Layer 2 protocol packets with a special MAC address and send them across the service provider network.
|
|
0:37:39
|
So there is some special format that they use for this. From our perspective it doesn't even really matter what it is. Just the fact that the PE switches, which in this case are
|
|
0:37:51
|
switch 3 and switch 4, as these frames are coming in they know the difference between CDP and STP. So they're using some sort of basically like a Layer 2 nat
|
|
0:38:02
|
that is changing the destination addresses of these protocols so that they can be tunneled all the way across. So actually the tunnel is between these two interfaces then.
|
|
0:38:25
|
There's a question - the example I showed earlier where switch 3 and switch 2 are shown as CDP neighbors with just configuring switch 1 with a Layer 2 tunnel and not dot1q
|
|
0:38:40
|
would this cause problems like Layer 2 spanning tree problems? Yes, it potentially could. So the question is in this example before I showed on switch one,
|
|
0:38:51
|
you could technically configure a tunnel between these two ports, a Layer 2 tunnel, that tunnels spanning tree
|
|
0:39:00
|
but you could now end up in a case where maybe the BPDU goes out and then loops back around which in that case it's not valid to do that.
|
|
0:39:10
|
In order to fix this the switches automatically have a Layer 2 tunneling guard that on the PE router, or the PE switch I should say, if we look at the error disable recovery, or the error disable detection cause
|
|
0:39:32
|
is the L2 PT guard, Layer 2 protocol tunneling guard. So how it does this specifically I'm not 100% sure. It's probably looking for the tunneled MAC address
|
|
0:39:46
|
to go out one interface and then be received back in another and then it would know that there's a loop in the Layer 2 tunnel.
|
|
0:39:54
|
But this is on by default. If you mis-configure this so that you cause a loop the switch is going to put the tunnel ports into error disabled mode
|
|
0:40:02
|
so that it's not going to actually bring down the rest of the network.
|
|
0:40:10
|
So generally you would only want to use the Layer 2 protocol tunneling with a dot1q tunnel because then you're basically configuring two different logical networks.
|
|
0:40:19
|
So the network between router three and router four, it's completely unrelated to the service provider network in the core.
|
|
0:40:30
|
Now there is one other potential issue that you could run into with this tunnel and it has to do with the native VLAN on the PE to CE link.
|
|
0:40:48
|
If for some reason a packet that the customer sends in has a VLAN tag that matches what the native VLAN of switch three is then the tag is going to get stripped as it is sent out towards switch one.
|
|
0:41:09
|
The end result of this is basically that the customers traffic leaks into the service provider network and you can see they show an example of this in the configuration guide if we just search for native VLAN.
|
|
0:41:31
|
It says that if traffic coming from a customer network is not tagged, which is the native VLAN, these packets are bridged or routed as normal. All packets enter...not what we want.
|
|
0:41:53
|
Okay, so here's the problem they're showing. It says that from the customer switch it says the native VLAN is 40. If for some reason the native VLAN that they are using matches the metro tag
|
|
0:42:15
|
It says that the tag is not going to be added as the packets go out there.
|
|
0:42:22
|
So essentially traffic that switch A is sending if it is in VLAN 40, it leaks out to the wrong destination. So it says this is the incorrect path due to traffic misconfiguration. So...
|
|
0:42:43
|
Tag not entered for VLAN 40. So then it goes...the traffic ends up going this direction instead of towards the top.
|
|
0:42:50
|
The way that you can prevent this though is just by tagging the native VLAN as well. So on all of the switches in the service provider network
|
|
0:43:03
|
you ideally should also add the VLAN dot1q tag native. So this was actually added as kind of a hack to the dot1q tunnel process
|
|
0:43:20
|
to make sure that you don't accidentally leak the traffic from the customer to the provider network.
|
|
0:43:27
|
So you don't technically have to do it to get the basic configuration working. Within the scope of the exam it would really depend on what the question is talking about.
|
|
0:43:37
|
But if they say something like prevent leaking of traffic from the customer to the provider, that's what this is talking about - that you need to tag the native VLAN
|
|
0:43:45
|
otherwise if coincidentally the numbers match up then the traffic doesn't get properly tagged again with the metro tag and the traffic ends up inside of the service provider network.
|
|
0:44:02
|
Okay, any other questions up to this point with the dot1q tunnel?
|
|
0:44:14
|
There's one additional application that you could use this for, the dot1q tunnel; is on the PE to CE links to allow the customers to aggregate multiple links together
|
|
0:44:27
|
transparently over the service provider network. So in this type of design it would look like the case where switch 1 and switch 2, they're not going to be considered the service provider network.
|
|
0:44:46
|
Okay, let's say that between these two switches we have 10 gig e. Then between switch 1 and switch 3 we have two FastEthernet interfaces - FA zero one, FA zero two.
|
|
0:45:07
|
Same between switch 2 and switch 4. So FA zero one, FA zero 2. Switch 1 and switch 2, these are the PE switches.
|
|
0:45:22
|
Switch 3 and 4, these are the customer edge. The goal here is to tunnel the EtherChannel between switch 1 and switch 2
|
|
0:45:35
|
so that switch 3's port here thinks it's connected to this port. Actually it would be down here. So switch 3 thinks this port is connected to this one
|
|
0:45:50
|
and it thinks that the second port is connected to this one. So it would allow the customer to aggregate multiple links together if the last mile access doesn't have enough bandwidth.
|
|
0:46:05
|
So let's say for some reason they can only offer them FastEthernet ports but they need more bandwidth than that, you could just give them multiple physical links and then bind them together as an EtherChannel.
|
|
0:46:18
|
So the EtherChannel configuration is nothing special. On switch 3 and switch 4 it's just a normal channeling config. The difference is how the tunnel is configured on the PE switches.
|
|
0:46:31
|
In this type of design we would essentially need two metro tags - one for each link that is making up the channel.
|
|
0:46:41
|
So we would say that we have VLAN 100 here and we have VLAN 200.
|
|
0:46:53
|
The reason that we would need two separate VLANs is that we need to prevent the case where a packet leaves switch 3,
|
|
0:47:04
|
is routed back to itself, is received at switch 2, and then forwarded out both of these links. If we were to use the same VLAN number on switch 1 and switch 2 for all of the ports
|
|
0:47:20
|
we would see that for every packet switch 3 sends out, one loops back to itself and then two are received on the other side.
|
|
0:47:30
|
So the key behind this design is that EtherChannel always has to be point to point. It's always a point to point connection between two devices.
|
|
0:47:39
|
Okay, there's some exceptions nowadays with like the 6500 and the VSS but the vast majority of cases if you're binding multiple links together it has to be point to point.
|
|
0:47:52
|
Okay, it has to be between just two devices so if the packet leaves switch 3 and is not received exactly on one interface of switch 4 then you basically have cause a Layer 2 loop.
|
|
0:48:06
|
The switches may be able to figure this out automatically if they're running channel negotiation; so if they're running LACP or PAGP.
|
|
0:48:14
|
But if they're blindly creating the channel without negotiation then you would cause a Layer 2 loop.
|
|
0:48:23
|
So for this configuration we're going to have two separate VLANs and the port assignments specifically it's going to be these FastEthernet ones. Let's see this would be...let's start this over.
|
|
0:48:45
|
On switch three to switch one
|
|
0:48:56
|
we'll just use the same interfaces we did before for the regular Layer 2 EtherChannel.
|
|
0:49:09
|
So on switch 1 this is 16 and 17. On switch 3 this is 13 and 14. Then on the other side we have 19 and 20 and 16 and 17.
|
|
0:49:22
|
So first let's configure switch 3 and switch 4. There's really not going to be anything special about this set up. So on switch 3 this is 13 and 14.
|
|
0:49:34
|
So first let's say default interface range FastEthernet 13 to 14.
|
|
0:49:43
|
Okay, I'll shut down both of the ports and once we have all of our tunneling set up that's going to be the very last step that we'll bring the member interfaces up.
|
|
0:49:54
|
Let's say channel group 34 mode active. So we're running LACP.
|
|
0:50:04
|
Then on switch 4 these are ports 16 and 17 so we'll say default interface range FastEthernet 16 to 17.
|
|
0:50:24
|
Then we'll shut these down.
|
|
0:50:28
|
We'll create the channel group, channel group 34 mode passive. So this means that switch 3 is going to be the one initiating the channel because it's running in LACP active mode.
|
|
0:50:42
|
Switch four is going to be listening for the negotiation from the other side. It's running in passive mode.
|
|
0:50:51
|
Okay, now when the transit path, this is switch 1 and switch 2, I need to separate VLANs that are going to be used for the metro tags. So let's say that this is VLAN
|
|
0:51:04
|
101 and 102. Okay, two separate values. I need to revert interfaces 16 and 17 to default. Default interface range.
|
|
0:51:29
|
And the same thing on switch 2 so this is going to be 19 and 20. Default interface range FastEthernet 19 to 20.
|
|
0:51:42
|
If we do show VLAN I want to make sure that I know about VLANs 101 and 102 first. Okay, which I do. Since there's already a trunk link between switch 1 and switch 2...
|
|
0:51:56
|
So this is our trunk. This is what's going to be carrying the tunnel. On switch 1 port 16 and port 19 on switch 2, these are going to be in 101.
|
|
0:52:18
|
Then 20 and 17, these are going to be in 102. So we're ensuring that the traffic is not going to leak between the two different interfaces.
|
|
0:52:30
|
On switch 2 we'll say interface FastEthernet 19 switchport access VLAN 101. The switchport mode is dot1q tunnel.
|
|
0:52:45
|
On FastEthernet 20, it's also a tunnel but it's in a different VLAN. For both of these interfaces we're running Layer 2 protocol tunneling
|
|
0:53:00
|
and we are going to tunnel LACP because that's what they're trying to negotiate the EtherChannel with.
|
|
0:53:10
|
Then switch 1 is going to do the same thing. We'll say on interface 16 switchport mode dot1q tunnel switchport access VLAN 101 and Layer 2 protocol tunnel.
|
|
0:53:23
|
This is a point to point tunnel and we're tunneling LACP. FastEthernet 17 essentially says the same thing but it's just in a different VLAN. It is a tunnel and we're tunning LACP.
|
|
0:53:44
|
Okay, now on the switches we can bring this up. What we should see ideally is that now switch 3 and switch 4 can negotiate the EtherChannel with LACP while it is actually being tunneled
|
|
0:54:02
|
over the dot1q trunks inside the rest of the network. So in a real design typically there would be more switches between these two and this again would have to be the Layer 2 trunking end to end.
|
|
0:54:28
|
So 13 and 14 are up. 14 is down. Okay. Now it's coming up. Now the port channel is up. So if we look at the show EtherChannel summary
|
|
0:54:42
|
it says the links are in the channel. If we look at the other side too, show EtherChannel summary,
|
|
0:54:55
|
it says both of those are in the channel. How could I test this now to see if the EtherChannel is actually being tunneled?
|
|
0:55:11
|
What if I were to tunnel spanning tree on switch one and switch two?
|
|
0:55:20
|
So in addition to the LACP let's say that on 16 we have L2 protocol tunnel STP and on 17. Then the same thing on switch 2 which is 19 and 20.
|
|
0:55:47
|
If this is working we should be able to look at the show interface trunk and figure out what VLANs are supposed to be forwarding over the channel.
|
|
0:55:57
|
So right now if we show interface port channel 34 switchport it says that this has been negotiated as a static access port. Okay, I want this to run as a trunk so I'm going to change this from
|
|
0:56:14
|
dynamic desirable. I'm going to change it from dynamic to be a static trunk link. Okay, even though this side is desirable and probably the other side is as well
|
|
0:56:29
|
the trunk was not able to negotiate because the DTP frames are not being tunneled over the dot1q tunnel. So I would just need to statically set this as a trunk link. So let's say that we have
|
|
0:56:51
|
on port channel 34 switchport trunk encapsulation dot1q switchport mode trunk.
|
|
0:57:04
|
Mode trunk. Okay, the same thing on switch three.
|
|
0:57:12
|
Switchport trunk encap dot1q. Switchport mode trunk.
|
|
0:57:19
|
Okay we can see since there's an order of operations problem here I really should have disabled the links before I made this change.
|
|
0:57:28
|
Now it says that there's...they cannot be bundled together. So I'd have to go to the interface range, try to shut these down, and then bring them back up.
|
|
0:57:55
|
So really in this type of configuration,
|
|
0:58:01
|
you would want to figure out what's the entire configuration that you want upfront, do all the configuration, then as the very, very last step activate the interfaces.
|
|
0:58:12
|
So now I'm going to have some problem. I might not even be able to get this to work without...oh, no, that's missing a...it's missing these two statements that's why.
|
|
0:58:34
|
13 to 14
|
|
0:58:40
|
and I should have put this on the channel also. So I should have taken my own advice and done all of them at the same time; which is these two commands. So I need this on the member interfaces and the channel.
|
|
0:58:59
|
Then we'll say for the member interfaces now we can bring them up.
|
|
0:59:07
|
Because again when we look at the final result of this EtherChannel, let's say on switch four, when I look at the running config of 16, 17, and the port channel,
|
|
0:59:20
|
essentially everything needs to be identical with the exception of the channel group command. This is not going to be on the port channel itself.
|
|
0:59:30
|
But we could see the member interfaces and the channel agree that it's dot1q and they agree on the mode, that the mode is statically trunk.
|
|
0:59:40
|
In the case of switch three there was a short period of time when they did not agree on that. That's why the error message was generated. So let's say show EtherChannel summary.
|
|
1:00:00
|
It says now the ports are down.
|
|
1:00:15
|
So let's see. Is there a mismatch here? Let's look at 13, 14, and the port channel which... the config is the same but now we have that order of operations of problem.
|
|
1:00:32
|
So this may actually not work for me now unless I remove everything and apply it in the correct order or alternatively I could just save the config and reload.
|
|
1:00:42
|
So then the switch will initialize the commands in the particular order that it wants.
|
|
1:00:47
|
Now within the scope of the lab exam, don't exclude rebooting your devices as part of the troubleshooting process.
|
|
1:00:55
|
Some of these features since you're adding so many commands and removing them over and over and over, sometimes the processes internally will get hung
|
|
1:01:04
|
and the only way it's going to work is either if you rip out all the config and put it back in in the right order or just save the config and reload.
|
|
1:01:13
|
So if you hit a wall in your troubleshooting and you think you've exhausted every option that you think is feasible,
|
|
1:01:19
|
save your config and reload. Go get a cup of coffee or something and check it back in a couple of minutes and see if it affects it.
|
|
1:01:27
|
So I'm not going to go any further with this now because I don't want to spend an hour troubleshooting the problem when we can just reload
|
|
1:01:33
|
but the key for this example is that this design technically is supported. It's less of a common implementation to see
|
|
1:01:44
|
because most of the providers that you would want to buy this service from, they're going to use MPLS for the transport. They're not going to use Layer 2 switching.
|
|
1:01:53
|
So in summary, everything we've seen up to this point with Ethernet, the big key with these core topics is that you always have to build the network in a structured fashion.
|
|
1:02:04
|
So it doesn't make sense to configure port security or quality of service before you've configured your VLANs, your trunking, and gotten basic connectivity.
|
|
1:02:15
|
The reason why is that if we're configuring let's say some security feature and then later down the road we cannot get reachability between some devices
|
|
1:02:24
|
how do we know that the problem was in security as opposed to just an underlying VLAN mismatch or a trunk is mis-configured.
|
|
1:02:32
|
So you always want to build the minimum possible config in Layer 2. Verify that that's working before you move on to any other more advanced options.
|
|
1:02:44
|
So in our next section we'll start to get into those peripheral topics for switching like modifying the spanning tree, different types of features like the
|
|
1:02:56
|
port security, port protection, private VLANs and that type of stuff in security. But everything we've covered up to this point you pretty much need to know this 100% off the top of your head
|
|
1:03:08
|
before you get into the lab exam. Okay, you can't waste time with configuring VLANs, VTP, trunking, EtherChannel. That's the stuff that needs to be up and working as soon as possible
|
|
1:03:21
|
so that you could spend more time on the real difficult topics; so maybe large scale BGP or QoS or MPLS multicast, that type of stuff.
|
