|
0:00:11
|
So now let's talk about some of the Layer 3 routing features of the switches.
|
|
0:00:17
|
So we saw all the variations of the Layer 2 switchports. Actually we didn't talk about dot1q tunneling yet. We will talk about that today though.
|
|
0:00:26
|
So for the Layer 3 routing, there's basically two different variations that these switches support.
|
|
0:00:33
|
They support the VLAN interfaces which are called the switch virtual interfaces are the SVIs
|
|
0:00:40
|
and they support native Layer 3 routing interfaces which is essentially the same as a FastEthernet or a gigabyte Ethernet port on the router.
|
|
0:00:49
|
Now the SVI interface is routing on behalf of multiple bridged interfaces.
|
|
0:00:57
|
So the bridge interfaces are going to be the ones that are in the VLAN, so switchport access VLAN ten for example.
|
|
0:01:03
|
Then we would have interface VLAN ten with an IP address on there that is going to route on behalf of those devices.
|
|
0:01:12
|
So in most typical designs you would have the default gateway for the host point to the switches SVI
|
|
0:01:18
|
then the switch would route the packets up to the rest of the Layer 3 domain.
|
|
0:01:24
|
Now one key point that's noted on the slides here, you need to make sure that the VLAN exists in the database first
|
|
0:01:31
|
before you create the SVI because there is no sort of error checking that the switch does to make sure it's actually there.
|
|
0:01:40
|
So for example if we were to go to switch one and say interface VLAN ten,
|
|
0:01:47
|
IP address 10 0 0 1 slash 24
|
|
0:01:55
|
then if we looked at the show
|
|
0:01:59
|
IP interface brief
|
|
0:02:02
|
we see we have VLAN ten there assigned 10 0 0 1 but the line protocol of the interface is down.
|
|
0:02:10
|
This is because there's no spanning tree instance that's forwarding for VLAN ten.
|
|
0:02:18
|
If we were to look at the show spanning tree for VLAN ten
|
|
0:02:26
|
it says an instance does not exist for two possible reasons - either we disabled spanning tree for VLAN ten
|
|
0:02:35
|
which we know in this case we didn't, or VLAN ten simply is not in the database. So if we show VLAN
|
|
0:02:43
|
show VLAN brief, we can see VLAN ten is not there.
|
|
0:02:49
|
Now once we go to assign the VLAN, if I say on FastEthernet one I have switchport access VLAN ten,
|
|
0:02:56
|
since this switch is in VTP server mode by default, it is going to create the access VLAN when we assign it to the interface.
|
|
0:03:06
|
So now if we look at the show spanning tree for VLAN ten
|
|
0:03:12
|
once any of these interfaces go into the forwarding mode for spanning tree
|
|
0:03:17
|
we should see that the line protocol of the VLAN interface is going to come up.
|
|
0:03:28
|
So the actual time that this takes is going to be based on the forwarding delay
|
|
0:03:32
|
which we'll talk about a little bit later this afternoon when we get into advanced spanning tree.
|
|
0:03:38
|
So now the link is up. If we look at the show IP interface brief, VLAN ten is up up.
|
|
0:03:45
|
If we look at the show IP route, at this point routing has not been enabled on this switch.
|
|
0:03:56
|
So anytime we see that the ICMP redirect cache is empty, this output here, where it says the default gateway is not set,
|
|
0:04:04
|
this means that the switch has no IP routing in global config.
|
|
0:04:11
|
Sometimes this can get a little bit confusing because when routing is off
|
|
0:04:17
|
the switch will try to ARP for a default gateway automatically.
|
|
0:04:23
|
So let's look at an example of this. Let's go to router one who is attached to switch one.
|
|
0:04:35
|
So right now we have switch one that goes to router one.
|
|
0:04:41
|
On switch one this is FA zero slash one and this is VLAN ten.
|
|
0:04:48
|
On the VLAN ten interface of switch one, we have the address 10 0 0 1 slash 24.
|
|
0:04:56
|
On router one let's say 10 0 0 anything, 254 slash 24.
|
|
0:05:06
|
So on router one let's go to interface FastEthernet zero zero, IP address is going to be 10 0 0 254 slash 24
|
|
0:05:18
|
and I should now be able to ping the switch virtual interface.
|
|
0:05:26
|
Which I can. So you can see the configuration is really straightforward here. As long as you had the VLAN created
|
|
0:05:33
|
then you could go to the interface VLAN and put your Layer 3 options on but now if we go to router one and let's say we create a loop back
|
|
0:05:42
|
interface loop back zero with address 1 1 1 1 slash 32.
|
|
0:05:52
|
From switch one, if we look at the routing table we don't have any destinations listed in there.
|
|
0:05:59
|
If we ping 1 1 1 1, we actually get reachability to this because of why?
|
|
0:06:12
|
Why would the switch be able to reach something that's not on it's local subnet
|
|
0:06:18
|
if we don't have routing on and we don't have a default gateway set?
|
|
0:06:23
|
The reason is that when a default gateway is not set, the switch is just going to try to ARP for everything.
|
|
0:06:30
|
So if we look at the show ARP, it sent an ARP request out for the destination 1 1 1 1.
|
|
0:06:40
|
This MAC address here that the response came in from, this is the same one that's assigned to router one's interface.
|
|
0:06:48
|
So based on the fact that router one is running proxy ARP
|
|
0:06:52
|
which means that if it has a route for the destination that is being ARP'd for, it will reply with it's own MAC address.
|
|
0:07:02
|
So it can be kind of a confusing output in some designs where if you're trying to configure the switch for routing,
|
|
0:07:10
|
so let's say we have RIP configured or OSPF, EIGRP, whatever, but we forgot to issue the IP routing command globally
|
|
0:07:18
|
some of the reachability will work but not all of it. It depends on the underlying routing design.
|
|
0:07:25
|
Also, if we were to go to global config, let's say router RIP. Some of these versions will tell you that IP routing is not enabled.
|
|
0:07:35
|
Let's see if we run router OSPF, that says the same thing. Router BGP1.
|
|
0:07:41
|
So this particular version does have the check in the parser. I have seen other versions of Catalyst IOS that it does not tell you this
|
|
0:07:49
|
so it would accept all of the routing commands but then they don't actually have any affect.
|
|
0:07:56
|
So we may be able to see this. Let's turn routing on. Run RIP.
|
|
0:08:07
|
So if we do show run section router rip or let's say begin router rip.
|
|
0:08:16
|
So we see the switch does have the rip configuration in it's running config. Now if I turn routing off
|
|
0:08:28
|
the rip configuration is going to be gone. So in certain versions it's not going to give you this error message.
|
|
0:08:37
|
It's simply not going to take the routing config and we can see now it deleted everything that was in there.
|
|
0:08:45
|
So the only thing you need to do is just look at the show IP route output.
|
|
0:08:49
|
If it looks like the normal routing table output on the routers then it means that the routing process is on.
|
|
0:08:56
|
Our next variation here would be the native Layer 3 routed interface
|
|
0:09:01
|
which we enable by turning the switchport process off on the interface.
|
|
0:09:06
|
So if we say no switchport then we can assign an IP address directly to the interface.
|
|
0:09:12
|
The end result of this is going to be the same as the properties of a normal Ethernet interface on a router.
|
|
0:09:18
|
So we could put access lists on there. We could put whatever other options that are related to a regular IP interface.
|
|
0:09:27
|
So if we look at the topology here, let's now say that on switch three,
|
|
0:09:33
|
or excuse me, switch one here, we have another interface that is going to router three.
|
|
0:09:40
|
On switch one this is FA zero slash three. On router three this is FA zero slash zero.
|
|
0:09:52
|
So on switch one let's go to interface FA zero slash three and we'll say no switchport.
|
|
0:09:59
|
Once the switchport process is off then I could put an IP address on the link so let's say IP address
|
|
0:10:06
|
30 0 0 1 slash 24. On router three, I'll put this in the same subnet. Let's say 30 0 0 3 slash 24.
|
|
0:10:22
|
Now I should be able to reach the switch from a Layer 3 point of view. So on switch one if we look at the routing table, do show IP route,
|
|
0:10:33
|
we can see FastEthernet zero slash three shows up just like any other interface on the router.
|
|
0:10:42
|
So really nothing too complex about these configurations as long as you remember to turn the IP routing process on.
|
|
0:10:49
|
Okay, there's a question - can you talk about the SVI auto state exclude?
|
|
0:10:56
|
Okay, let's look at the command reference then. Okay, so 3560 command reference, this would be under
|
|
0:11:05
|
RMON through VTP, through show, actually, no, next one - shut down through VTP.
|
|
0:11:17
|
Switchport autostate exclude. Now any time you're looking at the command reference here, and why did it not jump to that?
|
|
0:11:31
|
Let's search for it here. Switchport auto state.
|
|
0:11:37
|
Usually the first section of the command reference is not really going to tell you much about what the command does.
|
|
0:11:43
|
So it says use the switchport auto state command to exclude an interface from the VLAN
|
|
0:11:48
|
interface switch virtual interface line up or down calculation.
|
|
0:11:52
|
So this really on it's own, this doesn't tell us much. What we want to see instead
|
|
0:11:56
|
is if we scroll down a little bit further, what are the particular usage guidelines.
|
|
0:12:01
|
So we could see it says this was introduced in version 12 to 46; so it's a fairly recent feature.
|
|
0:12:09
|
It says enter this command on the Layer 2 access or trunk port that belongs to an SVI.
|
|
0:12:15
|
A VLAN interface is up if ports are forwarding traffic in the associated VLAN when all ports on the VLAN are down are blocking the SVI is down.
|
|
0:12:22
|
For the SVI to be up, at least one port in the VLAN must be up and forwarding.
|
|
0:12:26
|
You can use the switchport auto state exclude command to exclude a port from the SVI interface link up or down calculation.
|
|
0:12:34
|
So basically what this means is let's look at the diagram here.
|
|
0:12:41
|
Right now on switch one we have two different trunk links.
|
|
0:12:49
|
We have the trunk link that's going over to switch two. We have the trunk link that's going over to switch three.
|
|
0:12:55
|
If I create VLAN ten in the VLAN database, this is going to create a spanning tree instance
|
|
0:13:03
|
which means that VLAN ten should start forwarding over ports 13 and 16.
|
|
0:13:09
|
We can verify this is true on switch one if we look at the show interface trunk.
|
|
0:13:17
|
So it says that VLAN ten is allowed. VLAN ten is actually forwarding over these links.
|
|
0:13:23
|
If we look at the show spanning tree for VLAN ten,
|
|
0:13:28
|
VLAN ten is actually forwarding on three interfaces - the access port that goes down to router one,
|
|
0:13:33
|
the the two trunk ports that go over to switch two and three respectively.
|
|
0:13:38
|
Now when we look at the show IP interface brief, and let's include just that VLAN,
|
|
0:13:44
|
the state of the link here whether the line protocol is up or down
|
|
0:13:49
|
depends on whether spanning tree has a forwarding instance for the VLAN.
|
|
0:13:56
|
So what this command says that I could go to interface FA zero one
|
|
0:14:03
|
and say switchport auto state exclude.
|
|
0:14:09
|
Now if I were to go to interfaces FastEthernet 13 and 16 and shut these down
|
|
0:14:19
|
when we look at the show spanning tree for VLAN ten, we do still have an instance that is forwarding
|
|
0:14:28
|
it's on FastEthernet zero slash one, but when we look at the show IP interface brief the VLAN is now down.
|
|
0:14:37
|
The reason why is that this link says it shouldn't be included
|
|
0:14:43
|
for the calculation whether the line protocol for the VLAN interface should be up or down.
|
|
0:14:50
|
So I'm not really sure design wise why you would want to use this
|
|
0:14:53
|
but by default as long as there is any forwarding instance for spanning tree
|
|
0:14:59
|
then the VLAN interface should be up. So we should see if we go to the port here
|
|
0:15:05
|
on FastEthernet one and say no switchport auto state exclude
|
|
0:15:13
|
now the VLAN line protocol comes up.
|
|
0:15:17
|
Okay, there's another question here - is there an advantage to using an SVI versus a routed port?
|
|
0:15:24
|
Really it just depends on what the network design looks like. So typically
|
|
0:15:30
|
what you would have here is let's say we have switch one
|
|
0:15:35
|
and switch two that are switches connected to the access layer.
|
|
0:15:41
|
Switch one has a couple different hosts - A, B, and C - that are all in VLAN ten.
|
|
0:15:50
|
Since these are all layer two switchports we need to configure the SVI with is interface VLAN ten
|
|
0:16:00
|
with an IP address that's in that subnet that they're going to use basically for their default gateway.
|
|
0:16:06
|
So A, B, and C, they're going to route their own traffic that is not destined for their own subnet,
|
|
0:16:13
|
so non-local traffic. It's going to go up to the VLAN ten interface
|
|
0:16:17
|
then switch one is going to have to route it out some other Layer 3 interface.
|
|
0:16:23
|
So if the upstream device is switch two, we could configure this as a native routed interface
|
|
0:16:31
|
in which case it's up to the routing table to figure out where other particular destination is located.
|
|
0:16:37
|
We technically also could configure this as a trunk link
|
|
0:16:44
|
and configure different switch virtual interfaces. Let's say we have interface VLAN 20,
|
|
0:16:50
|
interface VLAN 20 on both sides. So these two switch virtual interfaces, they can participate in the routing process.
|
|
0:16:59
|
So if we were to enable OSPF or EIGRP or RIP, we can form adjacencies and we can exchange updates
|
|
0:17:08
|
It really just depends on what the physical topology looks like.
|
|
0:17:11
|
So if there's only one physical link for switch one to get out to the rest of the network
|
|
0:17:17
|
then it's probably easier just to use a native Layer 3 routed interface
|
|
0:17:22
|
as opposed to the Layer 2 trunk plus the VLAN interface.
|
|
0:17:30
|
The reason why that you would want to use the routed interface over the trunk
|
|
0:17:35
|
is that for the routed interface you do not have any spanning tree convergence issues.
|
|
0:17:40
|
For the trunk link, if there's a change in the topology you have to wait for spanning tree to converge
|
|
0:17:46
|
then still wait for your Layer 3 protocols to converge on top of that.
|
|
0:17:50
|
So it's usually more of an issue with high availability.
|
|
0:17:54
|
There's a really good design document that is called
|
|
0:18:00
|
I want to say it is the routed access layer
|
|
0:18:09
|
this one here - high availability campus network design.
|
|
0:18:14
|
Routed access layers using EIGRP or OSPF. So this document talks about the case where
|
|
0:18:21
|
on the access layer, which is going to be one of these, that these inter switch links
|
|
0:18:28
|
are Layer 3 as opposed to Layer 2
|
|
0:18:33
|
where in previous designs of switching networks you would have this configured as a Layer 2 trunk
|
|
0:18:42
|
and then at the core of the network, like let's say these are 6500s here, the 6500 would have the switch virtual interface
|
|
0:18:50
|
that is the default gateway for all of the hosts. But with the newer design these links run as Layer 3
|
|
0:19:00
|
where the advantage is that you do not extend your spanning tree domain from the access up to the distribution or from distribution up to the core.
|
|
0:19:10
|
Because figure you're already using your Layer 3 routing protocols for your convergence
|
|
0:19:15
|
so there's no reason to add additional Layer 2 convergence on top of that.
|
|
0:19:22
|
So the issue is whether you can redesign the network in order to do that because it's a major change to switch from the
|
|
0:19:29
|
Layer 2 trunks between access and distribution and then the Layer 3 routed interfaces.
|
|
0:19:35
|
But definitely take a look at this document, it's very good
|
|
0:19:41
|
design document. There's also one that's just called high availability campus network design overall.
|
|
0:19:55
|
Campus network for high availability design guide. Okay, this is a really
|
|
0:20:01
|
good document that talks about these types of Layer 2 issues.
|
|
0:20:04
|
Okay, all of these are located if you go to Cisco's website under the design zone.
|
|
0:20:11
|
So the design zone, this is what used to be called the solution reference network design guides or the SRNDs.
|
|
0:20:20
|
So from design zone, if we go to
|
|
0:20:28
|
let's say view all design guides
|
|
0:20:35
|
then this would be
|
|
0:20:38
|
the enterprise branch architecture design overview I believe.
|
|
0:20:44
|
They keep changing the names of what these are but there's a lot of good documents in here especially the enterprise QoS SRND.
|
|
0:20:55
|
This is a really good resource for Layer 2 QoS on the catalyst switches.
|
|
0:21:01
|
Okay, it basically breaks down the different QoS designs into the different roles in the network.
|
|
0:21:07
|
So your campus QoS would be what's going on at your access layer and how you're doing your classification and marking.
|
|
0:21:18
|
So if we look down further into the document it shows you on a per platform basis.
|
|
0:21:25
|
So for the 2970, 3560, 3750, these are using a similar QoS engine
|
|
0:21:31
|
which is different from the 2950 or the 3550. They syntax is a little bit different but if you look at their examples here for these ones
|
|
0:21:43
|
up to here, there's a lot of good information about how they QoS works on the 3560
|
|
0:21:49
|
both for the classification and marking and the ingress and egress queueing.
|
|
0:21:55
|
So if we look at the auto QoS model
|
|
0:22:06
|
we would see and there's actually a lot of stuff that it changes. We'll come back and talk about this in more detail when we get to QoS
|
|
0:22:13
|
but this is a good reference you can use in your preparation.
|
|
0:22:17
|
This type of document you're not going to have access to it in the actual exam though.
|
|
0:22:32
|
Okay, any other questions up to this point on the
|
|
0:22:39
|
the Layer 3 routing? So this stuff up to this point should be fairly straightforward.
|
|
0:22:44
|
The other variation of this would be to run the routing on a dedicated router
|
|
0:22:50
|
and use the switch just to trunk the traffic up to that router.
|
|
0:22:55
|
This is the design that's also called a router on a stick so it's basically a legacy version of what the switch virtual interface's do.
|
|
0:23:05
|
So in this design there's a Layer 2 switch that is separating the broadcast domains. The traffic is trunked up to the router.
|
|
0:23:12
|
The router makes the routing decision and then sends the traffic back down the same trunk link but with a different VLAN encapsulation.
|
|
0:23:23
|
So if we look at this type of design we would have some sort of Layer 3 device, let's say router one, that has a trunk link either
|
|
0:23:32
|
dot1q or ISL that goes down to the switch. On the switch we have different Layer 2 segments so we'll say A and B.
|
|
0:23:43
|
These are in VLAN ten. Then C and D, these are in VLAN 20.
|
|
0:23:56
|
So without Layer 3 routing we know that A and B can talk to each other and C and D can talk to each other
|
|
0:24:02
|
assuming they're in the same subnet and they're in the same broadcast domain, the same VLAN on the switches.
|
|
0:24:09
|
If we want to route the traffic between the devices then we're going to need some device to rebuild the Layer 2 encapsulation.
|
|
0:24:18
|
Because when we're doing normal Layer 2 bridging that is considered transparent bridging
|
|
0:24:24
|
because the Layer 2 switch doesn't actually modify anything in the frame.
|
|
0:24:28
|
It's just looking at the destination MAC address and then forwarding it out to the associated port.
|
|
0:24:33
|
But for Layer 3 routing we are rebuilding the Layer 2 encapsulation on a hop by hop basis.
|
|
0:24:39
|
So in this case router one basically has two different sub-interfaces. We'll say FA zero slash zero dot ten. FA zero slash zero dot twenty.
|
|
0:24:50
|
Interface dot ten is going to have an IP address that is in the same subnet as A and B.
|
|
0:24:59
|
Then likewise sub interface dot twenty is going to have an IP address that's in the subnet of VLAN twenty.
|
|
0:25:07
|
So the traffic flow from A to B would be from A to the switch, the switch up to router one,
|
|
0:25:15
|
router one routes the traffic between it's own sub-interfaces and then sends it back down.
|
|
0:25:24
|
So as you can imagine the disadvantage of this type of solution is that the packets are traversing the same physical link multiple times
|
|
0:25:32
|
as they go from the Layer 2 switch up to the router.
|
|
0:25:38
|
Now the configuration for this is pretty straightforward.
|
|
0:25:41
|
Really the only caveat that you need to be aware of is that if you are using
|
|
0:25:47
|
a different native VLAN other than VLAN one, you need to tell the router what the particular value is.
|
|
0:25:56
|
There's actually two ways we can do this. We can do it by assigning that subnet on the main interface
|
|
0:26:03
|
or assigning this on the sub-interface.
|
|
0:26:08
|
So let's look at an example of this.
|
|
0:26:16
|
Let's say that we have router one that's going to do our routing. This is going to have a trunk link that goes to switch one.
|
|
0:26:24
|
On switch one this is FA zero slash one. On router one this is FA zero slash zero.
|
|
0:26:31
|
Then we have two other devices, router three and router five, that are going to be in separate subnets.
|
|
0:26:39
|
We'll say that router three is going to be in VLAN 13. Router five is going to be in VLAN 15.
|
|
0:26:51
|
We'll say the two subnets here will be 13 0 0 0 slash 24 and 15 0 0 0 slash 24.
|
|
0:27:00
|
So this essentially means router one is going to have two different sub interfaces.
|
|
0:27:04
|
One that has an address in the VLAN 13 subnet; one that has an address in the VLAN 15 subnet.
|
|
0:27:15
|
There's a question here - do the sub interface numbers have to match the VLAN number? No they do not.
|
|
0:27:21
|
So the actual number of the interface we use on router one here is going to be arbitrary.
|
|
0:27:27
|
Usually you would match it with the VLAN number though just for clarity.
|
|
0:27:32
|
So if I see FA zero slash zero dot 1 2 3, I'm going to assume that's talking about VLAN 123.
|
|
0:27:39
|
But technically you don't have to match them you can set it up however you want.
|
|
0:27:46
|
So on router one I'm going to remove the previous config so on the main interface no IP address.
|
|
0:27:57
|
I'm going to create two different sub interfaces F 0 0 dot 10.
|
|
0:28:03
|
I'm running either dot1q or ISL; doesn't really matter as long as the switch agrees with it.
|
|
0:28:09
|
So in this case let's run dot1q. The VLAN number is ten.
|
|
0:28:16
|
Or actually no, I said the VLAN number would be 13 so let's get rid of that interface. Let's say F 0 0 dot 13,
|
|
0:28:29
|
encapsulation dot1q 13, IP address 13 0 0 1 slash 24.
|
|
0:28:38
|
You'll see that if you create the sub interface and then assign the IP address
|
|
0:28:44
|
before you assign the VLAN it's not going to allow you to do that. So it says if you are running trunking for this you need to tell me what the VLAN number is.
|
|
0:28:53
|
So the router doesn't actually have separate interfaces per se in the routing process
|
|
0:29:01
|
It's just categorizing the traffic based on the tag value of the packets that are being received in.
|
|
0:29:07
|
So we'll see later when we get to QoS, one of the implications of this is that the router has one single output queue
|
|
0:29:16
|
that corresponds to all of the sub interfaces for Ethernet.
|
|
0:29:21
|
So whereas with technologies like frame relay or ATM we can do per virtual circuit queueing.
|
|
0:29:27
|
The router doesn't support that for Ethernet. It's going to be one single output queue for the overall main interface
|
|
0:29:34
|
of the Ethernet link which in this case would be F 0 0 or just FA 0 slash 0. Okay, so let's look at our configuration here.
|
|
0:29:52
|
So pretty straightforward. We have no IP configuration on the main interface. Instead we have it on the separate sub interfaces.
|
|
0:30:01
|
So sub interface dot 13 is talking about VLAN 13. Sub interface dot 15 is talking about VLAN 15.
|
|
0:30:09
|
Again, the actual numbers of the links are arbitrary but it makes it a little bit easier to read the config
|
|
0:30:16
|
based on the fact that I matched 13 to VLAN 13.
|
|
0:30:24
|
Next on the other routers that are essentially going to be the end hosts
|
|
0:30:30
|
on router three we'll say the address is 13 0 0 3
|
|
0:30:40
|
and on router five we have 15 0 0 5.
|
|
0:30:50
|
Now since we're dealing with two different subnets, to move the traffic between them we're assuming that we have some sort of
|
|
0:30:58
|
routing solution in order to tell the router where the packets are supposed to go.
|
|
0:31:03
|
So we could run an IGP like EIGRP or OSPF. In this case I'm just going to set a basic static route
|
|
0:31:11
|
that says I'll send all of my packets to router one.
|
|
0:31:17
|
So if I don't already have a longer match in the routing table I'm going to use router one as the default gateway.
|
|
0:31:24
|
The router three is going to say the same thing. If I don't already have the route, just forward the packets to router one.
|
|
0:31:33
|
So next we have the Layer 2 switch that's in the middle, switch one. The VLAN numbers are VLANs 13 and 15.
|
|
0:31:41
|
So we need to make sure to create these in the database first. On router three's port the access VLAN is 13.
|
|
0:31:52
|
Okay, it says that's a Layer 3 interface so I need to change it back to Layer 2.
|
|
0:31:58
|
Then on FastEthernet five this is access VLAN 15.
|
|
0:32:06
|
So nothing real special here. We're just assigning what the VLAN number is.
|
|
0:32:11
|
On the link that goes to the router which in this case is router one,
|
|
0:32:17
|
we don't need an access VLAN because this is going to be a trunk.
|
|
0:32:22
|
So switchport trunk encapsulation is dot1q and the switchport mode is trunk.
|
|
0:32:29
|
Now I do need to enter both of these commands here because why?
|
|
0:32:37
|
Why do I need to tell the switch manually what the encapsulation is and that the mode is trunk?
|
|
0:32:46
|
The default interface mode is going to be what here?
|
|
0:32:50
|
Switchport mode dynamic auto.
|
|
0:32:54
|
For this particular configuration the routers don't support DTP.
|
|
0:33:01
|
So this means we need to manually tell the switch that this is a trunk. We're not going to rely on dynamic trunking protocol in order to do it.
|
|
0:33:09
|
Now also the router does not support VTP, VLAN trunking protocol.
|
|
0:33:13
|
So what we talked about yesterday, if we are doing pruning
|
|
0:33:17
|
we would manually need to edit the allowed list on the switch that goes to the router for the trunk.
|
|
0:33:25
|
So in this case I would say switchport trunk allowed VLAN 13 comma 15.
|
|
0:33:32
|
So I would want only those particular VLANs to forward to router one because I know that it's not trying to encapsulate any of the other ones.
|
|
0:33:42
|
So technically that's not really a requirement here. It's just to make the traffic flow a little bit more efficient.
|
|
0:33:52
|
Okay, so now let's see on router three am I able to reach router one.
|
|
0:34:03
|
So this is telling me that the VLAN is properly assigned on the switch
|
|
0:34:07
|
and that the trunk link between switch one and router one is working.
|
|
0:34:12
|
On router five I should be able to ping 15 0 0 1
|
|
0:34:19
|
which I can. Now Let's see if we can route between the segments. So on router five let's ping 13 0 0 3.
|
|
0:34:27
|
We can reach it. If we look at the trace for this; so if I trace 13 0 0 3,
|
|
0:34:35
|
we see that the packets first go to router one. Router one is changing the Layer 2 header
|
|
0:34:39
|
so it's routing it between the sub interfaces and then sending the packets back down.
|
|
0:34:46
|
So at this point really no complicated configuration here. We just have the
|
|
0:34:50
|
on the switch we have the access VLAN assignments
|
|
0:34:55
|
we have the trunk configuration going over to router one and then router one has the two different sub interfaces.
|
|
0:35:05
|
Now as I mentioned the caveat with this configuration is that if we were to change the native VLAN
|
|
0:35:10
|
we do need to make sure that the router knows what VLAN the untagged frames are supposed to be in.
|
|
0:35:19
|
So if I were to say on switch one that the switchport trunk native VLAN is 13
|
|
0:35:29
|
router one is now going to receive frames that are supposed to be in VLAN 13 but they don't have a dot1q tag.
|
|
0:35:40
|
So essentially router one says these land on the main interface which have no IP address so we cannot do anything with them.
|
|
0:35:49
|
The final result is that router five is not going to have reachability to router three.
|
|
0:35:55
|
Now I may need to actually reset the trunk. Let me shut that down.
|
|
0:36:07
|
Shut down the trunk and then
|
|
0:36:13
|
bring it back up.
|
|
0:36:19
|
Notice that when I shut this trunk link down it also said that the line protocol status for VLAN 10 went down.
|
|
0:36:30
|
Why would the switch be running VLAN 10 on that interface?
|
|
0:36:43
|
If we look at the show interface trunk
|
|
0:36:50
|
on FastEthernet zero slash one all VLANs are allowed.
|
|
0:36:57
|
So VLAN ten traffic, VLAN one traffic, that's all going to be forwarded to router one.
|
|
0:37:01
|
When router one receives those frame it's not going to do anything with them because it's not actually encapsulating those VLANs
|
|
0:37:09
|
but it's going to be an inefficient configuration so that's what I was mentioning with the allowed list.
|
|
0:37:14
|
I really should edit this interface so that VLANs allowed on the trunk, this really should only be 13 and 15.
|
|
0:37:29
|
So it should not affect our connectivity but it's going to be an inefficiency.
|
|
0:37:35
|
Okay, so now router five we see...actually it does have reachability to three. Let's look at the
|
|
0:37:45
|
the show ARP. We should see
|
|
0:37:51
|
that we are using router 1 to get to router 3. Let's trace 15 0 0 or not 15...13 0 0 3.
|
|
0:38:03
|
It says this goes to one and then back down to three.
|
|
0:38:12
|
Router one says
|
|
0:38:16
|
VLAN 13 is on this particular sub interface and the switch said that the native VLAN is 13.
|
|
0:38:31
|
Oh, actually I know why. I told the switch to tag the native VLAN.
|
|
0:38:37
|
So in this case that's actually another solution. I forgot to list that there then.
|
|
0:38:43
|
So if the switch is tagging the native VLAN then the router is going to receive it with the number.
|
|
0:38:49
|
Okay but normally the switch doesn't do this. The native VLAN is untagged. So in this case,
|
|
0:38:58
|
router 5's frame gets up to router 1. It doesn't have a VLAN 13 tag inside of it. Router 1 doesn't know what to do with it.
|
|
0:39:09
|
So actually there's three options for this solution then. So we could...
|
|
0:39:17
|
So it says this...we could do this on the main interface, we could do the sub interface with the native keyword, or we could tell the switch to tag the native VLAN.
|
|
0:39:28
|
So that's kind of a round about solution for it. The normal implementation would be to go to router one
|
|
0:39:36
|
and just tell it that VLAN 13 is native. So on this sub interface here
|
|
0:39:44
|
we would say VLAN 13 is the native VLAN. So when I receive any frames in that link that do not have a tag value
|
|
0:39:53
|
I'm going to assume that they belong to VLAN 13. So now we should see that the traffic flow works which it does.
|
|
0:40:02
|
Okay, the other option here which is
|
|
0:40:07
|
uh, still works but I'm not really sure why you would do it this way. If I got rid of the sub interface 13
|
|
0:40:15
|
and moved this subnet to the main interface
|
|
0:40:22
|
if the frames are untagged the router assumes that they should land on the main interface.
|
|
0:40:29
|
So now router five should be able to reach three.
|
|
0:40:34
|
Which it can but if we look at router one's config
|
|
0:40:41
|
it's basically half normal configuration, half router on a stick
|
|
0:40:46
|
where the main interface is for the native VLAN
|
|
0:40:55
|
and then sub interface 15, this is for anything that actually has a tag of 15.
|
|
0:41:10
|
Okay, any questions on either of these three configurations? Remember that the overall gaol
|
|
0:41:17
|
is that the native VLAN has to match between the two devices. So if you don't change the native VLAN you don't need to worry about it.
|
|
0:41:25
|
If you do change it either tell the router that that is the native VLAN
|
|
0:41:31
|
configure that subnet on the main interface
|
|
0:41:35
|
or you could tell the switch to run the native VLAN as tagged.
|
|
0:41:40
|
Now the only problem with doing that last solution which is running the native VLAN as tagged
|
|
0:41:47
|
is that essentially every switch in the network would have to agree on that.
|
|
0:41:58
|
So if we had a case where switch one said VLAN dot1q tag native
|
|
0:42:06
|
then we have other switches in the network
|
|
0:42:12
|
switch one is tagging
|
|
0:42:15
|
the native VLAN no matter what trunk links the packets go out so they're going out FastEthernet 0 1 to router 1
|
|
0:42:22
|
they're going out FastEthernet 13 and 16.
|
|
0:42:26
|
If the native VLAN is one which it is by default
|
|
0:42:31
|
this means that hosts in VLAN one on switch one
|
|
0:42:36
|
would not be able to reach hosts in VLAN one on switch three.
|
|
0:42:45
|
Why would this be the case here that if switch one is tagging the native VLAN but the other switches are not
|
|
0:42:55
|
we would lose interswitch communication for that particular VLAN number?
|
|
0:43:05
|
So the reason why is that switch tree is expecting the native VLAN to come in untagged.
|
|
0:43:17
|
So if you were to use this last solution, VLAN dot1q tag native, you basically need to do it on every switch in the network
|
|
0:43:23
|
to make sure that everyone agrees on what the value is.
|
|
0:43:34
|
Okay, there's a question - is the native keyword just allowed on one sub interface?
|
|
0:43:39
|
Yes, it's only allowed once because there can only be one native VLAN on the trunk.
|
|
0:43:47
|
There's another question - did you say earlier that ISL adds a new header and trailer
|
|
0:43:52
|
and dot1q doesn't add a tag but modifies the existing Layer 2 header?
|
|
0:43:58
|
Yes, that is correct. Where we could see this, there should be a reference here somewhere on Cisco's website,
|
|
0:44:09
|
the dot1q frame format versus the ISL frame format.
|
|
0:44:22
|
It says the ISL frame consists of three primary fields, the encapsulation frame which is the original frame,
|
|
0:44:29
|
which is encapsulated by the ISL header and a frame check sequence at the end. So the key being here
|
|
0:44:36
|
that this frame in middle, this is the original one that is unmodified.
|
|
0:44:42
|
Then the ISL header has this type of stuff - the destination address, the source address, the
|
|
0:44:50
|
the VLAN number, actually no. This one is the
|
|
0:44:58
|
that would be the encapsulation frame. This one is the header which has the VLAN number. If we look at the...
|
|
0:45:07
|
So you could see the individual field descriptions, it says ISL is going to a particular multicast destination.
|
|
0:45:16
|
But if we look at the dot1q format
|
|
0:45:21
|
we take the original frame and then after the source address we're adding the tag
|
|
0:45:27
|
which is the VLAN number followed by a new frame check sequence.
|
|
0:45:34
|
So since we're modifying the frame we need to change the original check
|
|
0:45:40
|
and we could see what's specifically in the field. So the VID, that's the VLAN number that's inside the dot1q header.
|
|
0:45:50
|
So this level of detail for the lab exam it doesn't really matter. You don't need to know things down to the frame format level
|
|
0:45:57
|
but technically if you're taking the most, the strictest interpretation, ISL encapsulates the frame where dot1q tags the frame
|
|
0:46:07
|
because ISL adds a complete new header and trailer where dot1q is just modifying here with the tag value.
|
