|
0:00:12
|
In our next section here we're going to talk about both Layer 2 and Layer 3 EtherChannel
|
|
0:00:18
|
and specifically some of the problems that we could run into with this configuration when we're not doing the config in the correct order.
|
|
0:00:26
|
Now as we know, EtherChannel is used to aggregate the bandwidth of multiple physical links
|
|
0:00:31
|
along the same type of logic as PPP Multilink is used for multiple T1s or multiple T3s in order to aggregate the bandwidth together.
|
|
0:00:42
|
Now the configuration is going to be made up of two different portions. The port channel interface that is the logical link that represents the member interfaces
|
|
0:00:53
|
where the member interfaces are the physical interfaces that are actually switching the traffic.
|
|
0:00:59
|
Now the channel itself can be any type of link. There's no requirement of it being a Layer 2 trunk.
|
|
0:01:06
|
It could be technically be a Layer 2 access port, it could be a Layer 2 tunnel if we're doing dot1q tunneling, or it could be a Layer 3 routed interface.
|
|
0:01:16
|
Now for a Layer 2 access port the typical case this would be is if you are doing NIC teaming or channeling down to a server
|
|
0:01:27
|
where the server is still assigned to one logical VLAN.
|
|
0:01:31
|
So any time you hear the word NIC teaming that's typically referring to EtherChannel because EtherChannel is just the trademark word that Cisco came up with for the feature.
|
|
0:01:45
|
Now when we're configuring the channel there's two different negotiation protocols that we can use to get the channel to form automatically.
|
|
0:01:54
|
These are PAGP or port aggregation protocol and LACP or link aggregation control protocol.
|
|
0:02:02
|
The difference between them is that PAGP is Cisco proprietary where LACP is an open standard.
|
|
0:02:09
|
And I want to say that LACP is defined in 802.3AD. The third option we have is to use no negotiation.
|
|
0:02:18
|
So in similar cases where we disabled DTP negotiation the advantage of not running LACP or not running PAGP
|
|
0:02:27
|
would be to reduce the Layer 2 convergence time when a channel goes up or down.
|
|
0:02:33
|
The disadvantage of not using negotiation would be that we cannot prevent against mis-configurations that could potentially result in a Layer 2 loop in the network.
|
|
0:02:45
|
Now as you're doing this configuration, if you do make a mistake and you do cause a Layer 2 loop,
|
|
0:02:51
|
typically what you'll see is that the switch's CPU utilization goes up to near 100%.
|
|
0:02:57
|
So the vast majority of the time if the Layer 2 switch's utilization is very, very high it is due to a Layer 2 loop.
|
|
0:03:06
|
There's very few cases just from traffic forwarding that the Layer 2 switch should have CPU utilization.
|
|
0:03:13
|
Because normally the Layer 2 switching is done in hardware so you don't need to talk to the general purpose CPU.
|
|
0:03:20
|
The same thing would be true of the higher level platforms like a 6500.
|
|
0:03:24
|
It's very, very rare that you would see the CPU on the supervisor go up to 100%.
|
|
0:03:29
|
Usually that's a good indication of some sort of Layer 2 loop that's occurring.
|
|
0:03:36
|
Now just like in DTP where we had the desirable and auto modes,
|
|
0:03:42
|
PAGP and LACP have equivalent modes that we can configure it to either just listen for the negotiation or to start the negotiation.
|
|
0:03:54
|
For PAGP this is going to be desirable to initiate and auto to listen where LACP uses active to initiate and passive to listen.
|
|
0:04:06
|
So we need to make sure that if we're running PAGP on one side that we're running a compatible PAGP mode on the other side.
|
|
0:04:14
|
So if we look at the five different variations either we can have both sides of the channel on,
|
|
0:04:20
|
both of them desirable which means that they're both listening for and initiating negotiation,
|
|
0:04:26
|
one as desirable and one as auto - so one is initiating and one is listening, and then likewise for LACP - active active or active passive.
|
|
0:04:35
|
What will not work is auto auto, passive passive, or any variation of on and desirable auto active or passive.
|
|
0:04:45
|
So if we're not using negotiation we need to not use it on both sides. If we are using negotiation we need to make sure at least one of the sides in initiating the communication.
|
|
0:04:58
|
Once the channel is formed the switch still needs to figure out which of the member interfaces are the actual frames going to forward out.
|
|
0:05:07
|
So the general idea of EtherChannel when we're looking from this at a Layer 2 point of view
|
|
0:05:12
|
is that the EtherChannel process tricks the spanning tree process into thinking that the logical port channel is one interface.
|
|
0:05:21
|
Because as we know with spanning tree, the overall goal of STP is to prevent duplicate links in the network so that we don't have a Layer 2 loop.
|
|
0:05:31
|
With EtherChannel we're basically violating this rule by forwarding on multiple interfaces at the same time in the same direction.
|
|
0:05:39
|
So we need at some physical level a way to actually figure out which interface are we going to use.
|
|
0:05:46
|
So the EtherChannel, depending on the particular version and platform you're running
|
|
0:05:50
|
there will be a couple different variations where we can load balance based on the source MAC address or the destination MAC address,
|
|
0:05:56
|
source IP or destination IP, or some various combinations of both.
|
|
0:06:01
|
So we could do like source and destination MAC, source and destination IP, just try to get some combination where we get some sort of
|
|
0:06:10
|
equal split or at least close to equal split between the physical links.
|
|
0:06:15
|
Now in a real design, if you're implementing EtherChannel and you see that one of the member interfaces is much higher utilized than the other ones
|
|
0:06:26
|
it generally means you just need to change your load balancing method.
|
|
0:06:30
|
Now the case that this would occur in would be that if all of the traffic flows end up to fall under the same load balancing manner.
|
|
0:06:40
|
So let's say for example that we have a file server
|
|
0:06:46
|
that is connecting to a Layer 2 switch to switch one
|
|
0:06:51
|
and then switch one has a couple different interfaces that are channeled together as they go out towards switch two.
|
|
0:06:58
|
So then somewhere in the rest of the IP cloud we have devices that are sending requests to these servers and then the return traffic going the same way.
|
|
0:07:10
|
Now if the vast majority of the traffic flows are the second flow; so from the file server down to the clients, not from the clients to the server,
|
|
0:07:21
|
and we are doing the default load balancing method of source MAC addresses, when switch one is receiving these frames in
|
|
0:07:30
|
they're all going to be coming from the same MAC address that's assigned to the NIC card of the server.
|
|
0:07:36
|
So if the server's MAC address is A, switch one will say for any frames coming from A maybe I'll use the first link in the channel.
|
|
0:07:45
|
So all traffic from A is going to go out this direction.
|
|
0:07:50
|
The result of this could be that the first link has very high utilization while the other links have zero or relatively low utilization comparatively
|
|
0:08:00
|
so this means that switch one would need to change it's load balancing mechanism.
|
|
0:08:06
|
This is independent on either end of the channel so switch one does not need to agree with switch two as to what load balancing method they're using.
|
|
0:08:17
|
So switch one could use destination MAC addresses while switch two is using source IP addresses.
|
|
0:08:24
|
For the Layer 3 categorization whether we're doing source or destination IP, you do not need to do Layer 3 routing in order to do that method.
|
|
0:08:35
|
So if the EtherChannel is a Layer 2 trunk you can still do load balancing based on the source and destination MAC addresses
|
|
0:08:42
|
based on the fact that the switch is Layer 3 aware to begin with.
|
|
0:08:47
|
Now within the scope of the lab exam there really would be no need to change the load balancing mechanism unless the question specifically tells you to.
|
|
0:08:57
|
So if it says that there's some problem with the utilization and you're trying to fix it or it simply says change how it's load balancing
|
|
0:09:04
|
then you could do that with the port channel load balance command in global config.
|
|
0:09:10
|
But for our case here we really don't need to look at the options to this. If you look under the command reference
|
|
0:09:16
|
for the port channel command you can see what the specific usage of the load balancing command is.
|
|
0:09:22
|
So let's look at our Layer 2 topology and we're going to add some additional links here between the switches to bundle them together as EtherChannels.
|
|
0:09:32
|
So first we'll start with switch one and switch three. So I'm going to add an additional link here
|
|
0:09:43
|
where on switch three this is going to be port number 14. On switch one this is going to be port number 17.
|
|
0:09:53
|
So this means from switch one's perspective interfaces 16 and 17 are going to be the members of the channel
|
|
0:10:03
|
where as from switch three's perspective these are going to be 13 and 14.
|
|
0:10:10
|
Also some of the higher level platforms have restrictions as to what particular links can be channeled together.
|
|
0:10:18
|
So you'll see that there may be restrictions on channeling between line cards but it really depends on the version.
|
|
0:10:27
|
Most of the newest platforms and the newest versions don't have those restrictions
|
|
0:10:31
|
but if you're implementing this in production you do need to check the release notes
|
|
0:10:35
|
to see if your platform supports channeling maybe 1 gig ecard on 1 line card versus...along with another gig eport on a second line card.
|
|
0:10:46
|
Okay there's a question for this example would you configure switch one with destination based load balancing
|
|
0:10:54
|
and on switch two source based load balancing since the server is behind switch one and the clients are behind switch two? So let's look back at that
|
|
0:11:03
|
example here. So the key for the load balancing is that the vast majority of the traffic flows
|
|
0:11:09
|
are coming from the file server with the MAC address A going down to clients that are located anywhere else in the network.
|
|
0:11:17
|
So one solution for this would be like you said to configure switch one to destination based MAC address load balancing
|
|
0:11:26
|
and then switch two could do source based load balancing.
|
|
0:11:30
|
It really depends on what the individual traffic flows look like because it may be that this first flow
|
|
0:11:37
|
which is the request from the client to the server is very low bandwidth to begin with where the vast majority of the transfer is in the opposite direction.
|
|
0:11:47
|
So on switch two it may not even matter what the load balancing mechanism is.
|
|
0:11:51
|
It really depends on your individual traffic pattern in the network.
|
|
0:11:55
|
So let's look at the command line on switch one and switch three.
|
|
0:12:00
|
Again on switch three we're using ports 13 and 14; on switch one we're using ports 16 and 17.
|
|
0:12:08
|
So what I probably want to check first is are these interfaces actually enabled and are these the correct numbers that are connecting the switches.
|
|
0:12:19
|
So one way I can do this is just to go to both of these links so on switch one this is interface FastEthernet 16 and 17
|
|
0:12:30
|
and what I'm going to do first is set their configuration to be the default.
|
|
0:12:38
|
The reason I'm doing this is that the member interfaces in an EtherChannel must have identical configs.
|
|
0:12:48
|
So all of the options that are on the physical port have to match between the member interfaces otherwise they cannot be members of the same channel.
|
|
0:12:58
|
So on switch one now if I say do show run interface FastEthernet 16 and 17, these are all the default configs.
|
|
0:13:09
|
Then on switch three, I'll say default interface range FastEthernet 13 to 14.
|
|
0:13:20
|
So now if I show run interface
|
|
0:13:25
|
F zero 13 and F zero 14, now these are the default configs. Okay, we can see on this side on switch three the default mode is dynamic desirable.
|
|
0:13:35
|
On the other side the default mode was dynamic auto.
|
|
0:13:40
|
So before proceeding here what I may want to check is to make sure these are actually the link numbers that are correct.
|
|
0:13:48
|
So what's one way I can see are switch one and three actually connected over these interfaces?
|
|
0:13:55
|
One way would be to look at the CPD neighbors.
|
|
0:14:00
|
So on switch three it says on my ports 13 and 14, these go to the remote interfaces 16 and 17 on switch one.
|
|
0:14:10
|
So within the scope of the lab exam it doesn't hurt to add this additional verification in
|
|
0:14:15
|
to make sure that whatever interface or whatever information is in the diagram or whatever information is in the question actually matches up with your physical topology.
|
|
0:14:25
|
So we don't want to run into the case where we just configure the wrong interface number then we have to spend half an hour or more troubleshooting the problem
|
|
0:14:33
|
when it was basically a Layer 1 issue that we were not using the correct physical links.
|
|
0:14:40
|
The next thing I want to do is to configure an interface range for all of the members and disable the ports, basically just shut them down.
|
|
0:14:51
|
The reason why I want to do this is that if the EtherChannel fails to negotiate or has a different configuration on one side versus the other
|
|
0:15:01
|
then I'm leaving myself open for the possibility of a Layer 2 loop.
|
|
0:15:07
|
So by disabling the links I'm ensuring that once I actually bring them up after all the configuration is done
|
|
0:15:15
|
that the switch should initialize the configuration in the correct order that it want.s
|
|
0:15:22
|
So I'll do this on switch three. I'll say interface range FastEthernet 13 to 14 and I'll shut these down.
|
|
0:15:30
|
Shutting them down on one side should also affect the line protocol on the other side so I don't necessarily need to do it on both of them.
|
|
0:15:40
|
On switch one this will be interface range FastEthernet 16 to 17.
|
|
0:15:46
|
So next step is to configure the channel with the channel group command.
|
|
0:15:51
|
The number here is locally significant. It could be whatever value we want. Let's just say this is channel number one.
|
|
0:15:59
|
Then we have the channel mode. This is going to determine what type of negotiation protocol if any are we using.
|
|
0:16:07
|
So in this case let's use PAGP. If we use PAGP these are going to be either the auto or desirable modes
|
|
0:16:15
|
where we need at least on end to be desirable and the other end could be either auto or desirable.
|
|
0:16:22
|
As long as one of them is initiating the negotiation that's what we care about. So say here on switch one this mode is desirable.
|
|
0:16:31
|
On switch three we'll say channel group one mode auto
|
|
0:16:40
|
and for clarity I am matching the channel group numbers. They technically don't need to be the same
|
|
0:16:46
|
but it makes the configuration a little bit easier to read if we're using the same numbers on both sides.
|
|
0:16:53
|
Once this is done we can bring up the member interfaces
|
|
0:16:58
|
and we should see that the line protocol of the member links plus the logical port channel interface comes up.
|
|
0:17:12
|
So now we want to see did switch three actually negotiate the channel with switch one.
|
|
0:17:18
|
A couple of different ways to do this - first would be to check what's the status of the EtherChannel. If we show EtherChannel summary
|
|
0:17:26
|
this is going to tell us what are the channels,
|
|
0:17:29
|
what mode are they running in, so are they switchports or routed interfaces,
|
|
0:17:35
|
what is the negotiation protocol, so here the port channel number.
|
|
0:17:40
|
Capital S means it's a switchport. Capital U means it's in use.
|
|
0:17:46
|
So here Layer 2 switchport; capital U is in use. Okay, this is what we want to see from this field.
|
|
0:17:53
|
The protocol is PAGP which is what we would expect. It says the ports are 13 and 14
|
|
0:17:58
|
and these are capital P which is bundled in the port channel. This is what we would want to see here.
|
|
0:18:04
|
If we see down or suspended then it means or I; so
|
|
0:18:12
|
DI or lowercase S; basically anything besides P, it means there's something wrong with the channel config.
|
|
0:18:20
|
Usually this is due to the fact that the member interfaces have different options configured onto them.
|
|
0:18:26
|
So if one of them has a QoS policy and the other one doesn't that's not going to be supported. The member interfaces need to have the identical configs.
|
|
0:18:35
|
The way that I'm ensuring that that happens is by using the interface range any time I want to make a change.
|
|
0:18:45
|
So this is ensuring that I'm using the same command on both member interfaces at the same time.
|
|
0:18:55
|
Okay, the next verification, since this is a Layer 2 channel, would be to look at the spanning tree status. If this port channel is a trunk link
|
|
0:19:06
|
which it should be by default because switch three is running in dynamic desirable mode of DTP.
|
|
0:19:12
|
Switch one is running in dynamic auto. This should form a trunk. So if I look at show interface trunk
|
|
0:19:19
|
port channel one is listed there. It has negotiated ISL encapsulation. If we look at the show spanning tree
|
|
0:19:28
|
for let's say just for VLAN one, ideally we should see the port channel interface listed not the physical member interfaces.
|
|
0:19:41
|
If it shows us the member interfaces here it means that they were not bundled together in the channel.
|
|
0:19:48
|
So this verification for a Layer 2 channel is going to be the final step to make sure that the EtherChannel process
|
|
0:19:55
|
is essentially tricking the spanning tree process into thinking that this is one logical link.
|
|
0:20:01
|
So from spanning trees point of view we're not violating any requirements because we're forwarding on only one interface.
|
|
0:20:08
|
But from an actual physical point of view, we are doing load balancing based on the two different interfaces.
|
|
0:20:15
|
So now let's see are we actually sending traffic over the different interfaces between the channel.
|
|
0:20:22
|
Okay, one way I could quickly test this would be to create different switch virtual interfaces on switch one and switch three.
|
|
0:20:34
|
When we looked at the show interface trunk it says we have VLANs 10, 13, and 15.
|
|
0:20:42
|
If on switch one we show interface trunk we have 10, 13, and 15 as well.
|
|
0:20:49
|
So what I'm going to do here on switch one, let's create interface VLAN 10. Let's say the address is 10 0 0 we'll say 7 for switch one.
|
|
0:21:02
|
Then I'll also create VLAN twenty and we'll say address is 20 0 0 7 slash 24.
|
|
0:21:13
|
And I now also need to create the VLAN so VLAN twenty in global config.
|
|
0:21:19
|
Switch three is going to do the same thing. We'll have interface VLAN ten, address is 10 0 0 9 for switch three.
|
|
0:21:34
|
Then interface VLAN twenty with the address 20 0 0 9.
|
|
0:21:44
|
Now once spanning tree starts to forward what I want to look at is what MAC addresses are associated in the CAM table
|
|
0:21:53
|
for the member interfaces of the channel. So from switch three let's ping 10 0 0 7
|
|
0:22:02
|
and 20 0 0 7. This is both of the remote channels. Okay, at least up to this point it's telling me I have basic Layer 2 connectivity between the switches.
|
|
0:22:14
|
If we now look at the show ARP, this is going to show me the addresses for those MAC addresses. Notice that it's the same address...
|
|
0:22:25
|
Actually no, it's not the same addresses. One of them is C1, one of them is C2. So let's say here show MAC address table
|
|
0:22:38
|
for the...or the dynamic table for the address 9BC1. If we look at the
|
|
0:22:50
|
second address, we could see that it's associated out the port channel.
|
|
0:22:57
|
So from the CAM table itself we can't actually tell where the traffic is forwarding
|
|
0:23:04
|
so we would really have to look at the link utilization to figure out where the traffic is going.
|
|
0:23:12
|
So from a Layer 1 point of view, traffic is not actually forwarding out the port channel because that's just a logical grouping of the physical interfaces.
|
|
0:23:22
|
The only issue is here we can't actually verify where the frame is going without doing some sort of Layer 1 packet analysis.
|
|
0:23:32
|
So we could do an additional physical connection between switch one and switch three that goes to a sniffer and just transparently pass the traffic through
|
|
0:23:40
|
and then see where the packets are going. Okay, another thing we could do would be to look at the physical link counters
|
|
0:23:47
|
and see which of them are going up. So if I say show interface FA zero 16.
|
|
0:23:58
|
No, that's not 16. Which one is it? Let's say show EtherChannel summary. This is 13 and 14 so show interface FastEthernet 13.
|
|
0:24:10
|
And I want to know how many packets are input or output so let's say show interface include
|
|
0:24:19
|
packets input or packets output and it will clear the counters.
|
|
0:24:36
|
So I want to see this on 13 and 14. Now we can see there are a minimal amount of packets going out and in. This is the Layer 2 control frames.
|
|
0:24:47
|
But if I were to ping 10 0 0 7 let's say with a repeat count of 10,000 packets
|
|
0:24:55
|
one of these interfaces is going to have higher counters than the other one.
|
|
0:24:59
|
So if I now look at the difference between 13 and 14
|
|
0:25:06
|
for that particular destination interface 13 was used. If we look at
|
|
0:25:14
|
let's ping now 20 0 0 7 and we'll say with a timeout of zero. This will just send the packets as fast as possible.
|
|
0:25:35
|
We can see that physical link FastEthernet 13 is still being used for both of them.
|
|
0:25:41
|
So if I did want to load balance more equally then I could say on switch three that the port channel
|
|
0:25:50
|
load balancing method let's say destination MAC address.
|
|
0:25:58
|
Okay, this particular platform, this is a 3550 so it doesn't support the same options as switch one does. If we say port channel load balance
|
|
0:26:11
|
we'll say source destination IP XOR, this definitely should give us a difference between one link versus the other.
|
|
0:26:22
|
So if we look...let's look at the output on switch one. Let's say show interface FastEthernet 16 include packets
|
|
0:26:34
|
input or output and 17. We'll clear the counters then I'll ping 10 0 0 9.
|
|
0:26:55
|
Let's send 10,000 packets with a timeout of zero.
|
|
0:27:08
|
Then if we look at the counters for 16 and 17, okay, we can see port 16 was used there. So now if we try the
|
|
0:27:17
|
the other address ideally assuming that the binary math ends up being different
|
|
0:27:23
|
we ideally should be using the other link which is number 17.
|
|
0:27:37
|
Which we're not in this case. So we'd have to look at it with more diverse addresses.
|
|
0:27:44
|
What would probably be a better verification for this would be to use the switches as transit
|
|
0:27:50
|
and not actually use the locally generated traffic because the
|
|
0:27:55
|
the routers and the switches, they treat the local traffic differently than they do the transit traffic.
|
|
0:28:00
|
So probably what I could do would be like to go to switch three and take one of the routers that's connected here, let's say like router three,
|
|
0:28:07
|
and then on switch one router one, I could do pings between one and three
|
|
0:28:13
|
then look at in the physical transit path between switch one and switch three which links are we using.
|
|
0:28:22
|
So there's really no recommendation as to what method you would use.
|
|
0:28:25
|
It just depends on your individual traffic flows.
|
|
0:28:29
|
What the diversity of the source MAC address is, destination MACs and source and destination IP addresses are.
|
|
0:28:36
|
Okay, there's a question - couldn't you use the show EtherChannel detail
|
|
0:28:42
|
and look under the primary aggregater statistics to see the load and number of bytes? Let's see if that will actually show us the counters.
|
|
0:28:50
|
If we show EtherChannel detail
|
|
0:29:15
|
Let's see, does it show us the utilization here?
|
|
0:29:34
|
I don't think it does give us a counter.
|
|
0:29:38
|
Well there's a load value. I'm not 100% sure if this changes. We'd have to look at it in real time. Normally what you would do in
|
|
0:29:46
|
a real design is just gather some sort of statistics from the Layer 2 switch about the utilization of the links
|
|
0:29:53
|
like by doing SNMP polling or SNMP trapping and then you would be able to figure out which link is utilized more than another one.
|
|
0:30:01
|
Okay, you could also do this with netflow. I'm not 100% sure if netflow is supported on these particular switches though for the Layer 2 links.
|
|
0:30:11
|
So probably you would be better off just using SNMP to poll what the counters are of the links
|
|
0:30:17
|
and then your network management station would be able to figure out on an average what does that result in like a packet per second value or a byte per second value.
|
|
0:30:27
|
So again, within the scope of the lab exam, it's not really that important
|
|
0:30:31
|
but it is a well known design issue for EtherChannel in real networks
|
|
0:30:36
|
that you do need to take into account what the traffic flow is because that's what the load balancing method is going to affect what the distribution of the traffic is.
|
|
0:30:50
|
Okay, there's a question - when you change the load balancing is there a loss of connectivity for a moment or can this be run in production?
|
|
0:30:57
|
There probably is going to be some sort of convergence time
|
|
0:31:02
|
whether it's negligible or not it really depends on how much high availability falls into your particular network design.
|
|
0:31:10
|
Because figure the old address does need to get flushed out of the CAM table and then reinserted on the correct link
|
|
0:31:18
|
so there's going to be some switch over time; most likely minimal though.
|
|
0:31:29
|
Okay, so let's look at our final configuration here for the interfaces 16 and 17.
|
|
0:31:38
|
The only thing we have right now is just the channel mode and the channel number.
|
|
0:31:45
|
Then if we show run interface port channel one we see the channel itself doesn't have any configuration on it.
|
|
0:31:52
|
Now from this point on if I want to make changes to the channel
|
|
0:31:57
|
the best way to do this is to make the changes on the member interfaces and the port channel all at the same time.
|
|
0:32:06
|
In most catalyst versions if you make a change on the port channel logical interface
|
|
0:32:12
|
the commands should be replicated down to the member interfaces
|
|
0:32:17
|
but I have seen some cases in production where there's a failure of this whether it's due to a bug or just some problem with that version
|
|
0:32:24
|
and the member interfaces don't match up with what the channel's config is.
|
|
0:32:29
|
So for example, let's say we want to go to port channel
|
|
0:32:36
|
port channel one and we'll say that the switchport trunk encapsulation is dot1q
|
|
0:32:45
|
when we look at the running config for the physical links
|
|
0:32:51
|
we can see that this command was replicated down to them so now it's on the physical links plus it's on the port channel
|
|
0:32:59
|
but this isn't going to work 100% of the time. Vast majority of cases it should be fine
|
|
0:33:05
|
but to be 100% sure about it what we would do instead is say interface range
|
|
0:33:11
|
FastEthernet 16 to 17 which is the member interfaces plus the port channel at the same time.
|
|
0:33:19
|
So now no matter what commands I'm adding, it's being applied to all three interfaces at the same time.
|
|
0:33:26
|
Okay, the only difference is that on the port channel itself we wouldn't be able to issue like the speed command or the duplex.
|
|
0:33:33
|
Okay, duplex full. It doesn't really make sense that the logical interface would get that type of config
|
|
0:33:39
|
so some of the attributes will be based on the physical links, the member interfaces and not the port channel itself.
|
|
0:33:47
|
So now if we show run interface port channel one; okay, it says the speed is 100 there but it doesn't really make sense.
|
|
0:33:54
|
Whether that's actually going to do anything or not, we'd have to look at the result of the traffic flow.
|
|
0:34:07
|
Okay, so now let's take a look at a case between switch one and switch two
|
|
0:34:15
|
where we're using LACP as opposed to PAGP. Then we'll look at a case where the negotiation fails of the channel
|
|
0:34:24
|
because there are some options on the member interfaces that don't agree.
|
|
0:34:30
|
So we'll say this second interface here, this is going to be FastEthernet 14.
|
|
0:34:37
|
So 13 and 14 on both sides are being channeled together. We'll use LACP in this case. On the previous one we used PAGP.
|
|
0:34:45
|
Where again the difference is in the mode. For PAGP this would be auto and desirable; LACP is going to be active and passive.
|
|
0:34:57
|
So on switch one first thing I'm going to do is default the interface range
|
|
0:35:06
|
for the member links. So that's setting them to be identical configs. Then I will shut the ports down.
|
|
0:35:25
|
Then the same thing on switch two.
|
|
0:35:32
|
We'll say default interface range FastEthernet 13 to 14.
|
|
0:35:40
|
Then on 13 and 14 we'll shut the ports down.
|
|
0:35:48
|
Okay, next let's configure the channel group. So we'll say channel group, give it a new number. Let's say number two.
|
|
0:35:55
|
The mode is; in this case we'll use LACP so we'll say active on this side. On switch one we'll say passive.
|
|
0:36:13
|
Channel group two mode passive and at this point the member interfaces are shut down. So once we bring them back up
|
|
0:36:23
|
then we should see the line protocol of the physical links come up followed by the line protocol of the port channel two interface.
|
|
0:36:31
|
So probably what this means we did not see the line protocol come up so they're probably shut down on switch two as well.
|
|
0:36:39
|
No shut.
|
|
0:36:47
|
So the links are up on switch two. Line protocol is up, now we see the line protocol of the channel come up.
|
|
0:36:54
|
Okay, next thing, if we look at the show EtherChannel summary
|
|
0:37:00
|
we see that this is a Layer 2 channel that is currently in use.
|
|
0:37:05
|
LACP is the negotiation protocol. These member interfaces are currently in the port channel which is what we want to see.
|
|
0:37:13
|
If we look at the show spanning tree for any VLAN, let's say VLAN one,
|
|
0:37:19
|
we see this is forwarding over the port channel. It's not including the member interfaces.
|
|
0:37:27
|
So again this would be one of our final verifications to see if the
|
|
0:37:32
|
the Layer 2 spanning tree process actually is detecting the logical port channel as opposed to the physical links.
|
|
0:37:42
|
Okay, now let's look at a case where there is a problem in the negotiation. So we'll go to the range of the physical links again and shut these down.
|
|
0:37:54
|
Now on one of them, let's say FastEthernet 13...
|
|
0:38:08
|
What can we do here. Let's say
|
|
0:38:13
|
spanning tree VLAN one cost is one.
|
|
0:38:20
|
Okay, so we're changing one option so basically any option on one of the member interfaces versus the other ones.
|
|
0:38:26
|
So now when we go back to the range and bring the links up
|
|
0:38:32
|
we should see that the member interfaces are not compatible to be channeled because they don't have identical configs.
|
|
0:38:42
|
This would be the advantage of using the negotiation protocols like LACP or PAGP
|
|
0:38:49
|
because they can detect these type of mis-configurations and then remove the individual members from the channel.
|
|
0:38:57
|
So if we show EtherChannel summary
|
|
0:39:02
|
okay, it still says these are up. So that particular option, that's not going to affect it. Let's say
|
|
0:39:17
|
Let's see if a QoS policy is going to do that. So let's say policy map ABC class class dash default
|
|
0:39:29
|
and I want to do policing. Let's say police to 1 Megabyte per second. Conform normal verse, let's say anything here. 8,000.
|
|
0:39:45
|
So conform will be transmit; exceed will be dropped by default. Okay, so now on the member interface we'll say service policy input is ABC
|
|
0:40:00
|
the on the interface range we'll bring this back up. So you can see not every single option that you change would cause the channel to fail.
|
|
0:40:22
|
So this one is not either. Let's look at the show EtherChannel summary.
|
|
0:40:34
|
It's still aggregating them both together. Let's try access list. Access list one deny any. FastEthernet 13 IP access group one in.
|
|
0:41:11
|
So you'll see different version and different platforms have different requirements for this.
|
|
0:41:16
|
If you look in the release notes for the particular version and then look at the EtherChannel documentation, it will talk about what
|
|
0:41:24
|
what are some of the options that need to be the same and if it mismatches it's going to cause it to fail. One we could definitely do would be that if the...
|
|
0:41:37
|
let's say one of them is going to be an access port. One of them is going to be a trunk port.
|
|
0:41:44
|
So on the
|
|
0:41:47
|
the range of interfaces, I'll shut this down. FastEthernet 13 we'll say switchport mode access. FastEthernet 14
|
|
0:41:59
|
switchport mode is trunk. Switchport trunk encapsulation is ISL; switchport mode is trunk. Okay, now we should see
|
|
0:42:09
|
when I bring the range back up it's going to tell us these cannot channel together.
|
|
0:42:21
|
Okay, so this message, the log should tell you what is the particular reason why they're not being accepted.
|
|
0:42:32
|
It says 14 is not compatible with 13 and will be suspended because the DTP mode of 14 is on but of 13 it is off.
|
|
0:42:40
|
So if we look at the output of the show EtherChannel summary now, this is the output that you do not want to see.
|
|
0:42:49
|
So if you see that one of the ports, one or more of the ports are suspended
|
|
0:42:55
|
or if it said that 13 was independent, if you saw an uppercase I here,
|
|
0:43:01
|
this would mean that the channel is not properly working. The problem with this though is that if on the other side of the link
|
|
0:43:10
|
we are not running either LACP or PAGP, then we would cause a Layer 2 loop.
|
|
0:43:18
|
So if we look at the topology, let's assume that between switch one and switch two we're not doing automatic negotiation.
|
|
0:43:26
|
Okay, so we're running neither LACP or PAGP. From switch one's perspective,
|
|
0:43:32
|
the first interface, FastEthernet 13, this was admitted to the port channel.
|
|
0:43:39
|
From switch two's perspective, both of these interfaces are admitted.
|
|
0:43:44
|
This now means that switch two and switch one's spanning tree topologies do not agree with each other.
|
|
0:43:52
|
Switch one is going to be sending separate BPDUs out port 14 versus 13
|
|
0:43:58
|
where switch two is sending a single BPDU that is going to the logical port channel.
|
|
0:44:05
|
But if the mode of the channel is on on both sides the switches won't be able to detect this.
|
|
0:44:14
|
Now there's actually a feature that is...it should be on by default for these platforms
|
|
0:44:21
|
that if we look at the error disable...error disable detection cause
|
|
0:44:37
|
Not listed here. Let's say error detection recovery cause.
|
|
0:44:43
|
Oh, did it show it in the first one. Now it didn't. Okay, the channel misconfig.
|
|
0:44:49
|
So there is a default feature that the switch has on called the EtherChannel guard misconfig
|
|
0:44:55
|
that it tries to prevent the case where one side of the channels configuration does not match the other one
|
|
0:45:01
|
because the switch knows if that occurs there's most likely going to be a Layer 2 loop.
|
|
0:45:06
|
So if you see this message come up that says the links are...the member interfaces are going into the error disabled state
|
|
0:45:14
|
then it means that whatever config you have on one side is not compatible with the other one.
|
|
0:45:20
|
But again as long as you use the correct order of operations which is to make sure that the member interfaces match identically
|
|
0:45:29
|
to shut them down, do all the channel configs on both sides, and then as your very last step bring the interface out of the shutdown state,
|
|
0:45:37
|
you should never run into this problem. The issue is that if you get into this problem in the exam and we see now that
|
|
0:45:49
|
let's see...where was our error message? This one here.
|
|
0:45:54
|
So once the member interfaces do not agree with each other and they're not channeled, it's going to take some extra time for us to revert the configuration back
|
|
0:46:04
|
and get it to be where it is some working config. Also if the EtherChannel guard kicks in and it disables the interface
|
|
0:46:14
|
we would need to look at the show interface status...nah, that's statistics. S A T U, um, S T A T U S for status.
|
|
0:46:28
|
We would want to look here for either suspended or error disable.
|
|
0:46:39
|
So if a member of the channel says either suspended or error disable it means that you mismatched the configuration somehow that caused it not to be a valid setup.
|
|
0:46:50
|
So really again the key behind this is just to make sure that you do the config in the correct order. Now for Layer 3 EtherChannels
|
|
0:46:57
|
this likewise is susceptible to the order of operations problem
|
|
0:47:02
|
because it depends the order of where you enter, or when you enter I should say, when you enter the channel group command versus the no switchport command.
|
|
0:47:13
|
So we saw with the native Layer 3 routed interface when we say no switchport it means we're turning the Layer 2 process off
|
|
0:47:20
|
and we're running it as a regular routed link so we're going to assign the IP address to it.
|
|
0:47:25
|
With a Layer 3 channel it's the same type of logic.
|
|
0:47:29
|
Let's say we do this between switch two and switch four.
|
|
0:47:35
|
Where instead of running spanning tree over the interfaces we're going to use our Layer 3 routing in order to
|
|
0:47:48
|
do the network re-convergence. So this would be on switch two interfaces 19 and 20. And on switch four 16 and 17.
|
|
0:48:01
|
So we're going to bundle these together as a Layer 3 channel. On switch two let's say the address is 24 0 0 2. On switch four it will be 24 0 0 4.
|
|
0:48:14
|
So our first step, just like the previous Layer 2 channel, would be to remove any of the previous options.
|
|
0:48:21
|
So on switch two we'll say default interface range FastEthernet 19 through 20.
|
|
0:48:32
|
Once that is done I'm going to shut down the links. On switch four this will be FastEthernet 16 to 17.
|
|
0:48:45
|
They're already shut down on switch two so I don't necessarily need to do the same thing on switch four.
|
|
0:48:52
|
Next we're going to go to the interface range and configure the channel group. So let's say channel group 3 mode on. So in this case we will not use negotiation.
|
|
0:49:09
|
I also want this to be a Layer 3 interface. So these interfaces are not switchports.
|
|
0:49:18
|
On switch two we'll do the same thing. We'll say channel group 3 mode on and no switchport. Okay now let's bring the links up.
|
|
0:49:46
|
It says 19 is up. Let's make sure they're not shut down on this side as well.
|
|
0:49:55
|
17 is up which means 20 is up on the other side. Okay, so both of the member interfaces are not up but we didn't get a log message saying that port channel three was up.
|
|
0:50:07
|
So let's look at now the show EtherChannel summary.
|
|
0:50:15
|
It says we have channel number three but the status is capital D which is down.
|
|
0:50:30
|
So the channel is down and we can see that there's no members. Okay, this dash here in the protocol, that means we're not running PAGP or LACP.
|
|
0:50:44
|
So now we need to figure out why did the member interfaces not join the channel.
|
|
0:50:49
|
Let's look at the resulting configuration. This was supposed to be on FastEthernet 16 and 17.
|
|
0:50:59
|
No, it is 19 and 20. 19 and 20.
|
|
0:51:08
|
And then our port channel is number two.
|
|
0:51:15
|
So we can see the member interfaces they do have the no switchport command but they don't have the channel group command.
|
|
0:51:22
|
And if we scroll back up a little bit we'll see I did actually enter the channel group command along with
|
|
0:51:31
|
the no switchport. So I didn't miss the command. Both of them were in there but the running config only shows the second one, it doesn't show the first one.
|
|
0:51:42
|
The reason why is that once I issued the channel group command it is creating the logical interface, the port channel,
|
|
0:51:51
|
and by default the mode of this interface, whether it's access, trunk, tunnel, or routed is going to be inherited from the member interfaces.
|
|
0:52:05
|
So if we think about the order that I entered the commands, the first thing I did was channel group...actually, no it's not channel group two, it's channel group three here.
|
|
0:52:14
|
Show run interface port channel three. Okay, but same difference. There's no config on it. So I said channel group three mode on. That's generating this interface.
|
|
0:52:24
|
At the time the member interfaces were Layer 2 switchports which means that the port channel interface was generated as a Layer 2 switchport.
|
|
0:52:35
|
Once I said no switchport at the physical link there then removed from the channel because there is a misconfiguration between the two of them.
|
|
0:52:46
|
The member interfaces are trying to be Layer 3 while the port channel interface is trying to be Layer 2.
|
|
0:52:56
|
If I try to manually fix this by putting them back into the channel; so let's say interface range 19 and 20, channel group three mode on,
|
|
0:53:09
|
it's going to tell me I cannot do this because either the port is Layer 2 and the channel is Layer 3 or the other way around which is our case.
|
|
0:53:19
|
So the, in this case, the port is Layer 3 and the channel is Layer 2. This is not compatible.
|
|
0:53:35
|
So really what I should have done is first changed the member interfaces to Layer 3
|
|
0:53:42
|
then inserted them into the channel group which generates the port channel interface as a Layer 3 link.
|
|
0:53:50
|
Now I can work around this but it's just an additional headache that I should have realized I would have the problem in the first place.
|
|
0:53:58
|
So what I could do now would be to go to the port channel, manually change this to be not a switchport, then go back to the physical links and put them into the channel.
|
|
0:54:11
|
Okay, and I'll essentially need to do the same thing on the other side on switch four. I'll need to say that port channel three is not a switchport
|
|
0:54:21
|
and that the member interfaces are now in the channel.
|
|
0:54:33
|
Once this is done we can go to the port channel interface and then put the IP configuration on there.
|
|
0:54:49
|
24 0 0 2 slash 24.
|
|
0:54:55
|
If I now ping 24 0 0 4
|
|
0:55:00
|
we can see that the routing is working; or at least the basic Layer 2 connectivity is working. If we look in the routing table
|
|
0:55:08
|
assuming routing is on so let's say IP routing then show IP route, we should see that the port channel is listed as a normal routed interface.
|
|
0:55:22
|
If we look at the show EtherChannel summary we see that now the channel is routed so capital R.
|
|
0:55:32
|
Capital U so it's Layer 3 and it is in use and the member interfaces are 19 and 20.
|
|
0:55:43
|
Capital P means that they are bundled in the port channel which is what we want. So again the key for the Layer 3 channel
|
|
0:55:51
|
is that we need to issue the no switchport command on the member interface first.
|
|
0:55:56
|
So this will change the physical links to Layer 3.
|
|
0:55:59
|
Then once we issue the channel group command it automatically generates the port channel interface as a Layer 3 interface.
|
|
0:56:08
|
Otherwise we have that order of operations problem like I showed where we had to change the port channel manually to Layer 3
|
|
0:56:16
|
and then reinsert the member interfaces into the channel.
|
|
0:56:22
|
Beyond this we can treat the port channel interface just like any other normal routed port.
|
|
0:56:27
|
So the IP address, access lists, whatever Layer 3 configuration, the routing protocol config, all of that stuff would go on the port channel interface.
|
|
0:56:37
|
And again our main verifications, first would be how EtherChannel summary. We want to make sure that the channel is up
|
|
0:56:44
|
and that the member interfaces are in the port channel.
|
|
0:56:48
|
The for Layer 2 show spanning tree is going to be a good verification that it's working end to end
|
|
0:56:52
|
and then for Layer 3 that it did get inserted into the routing table with just show IP route.
|
