05 Ccnp 642 813 Switch Trunking

So in our next section we're gonna talk about the VLAN trunking which again is used between multiple physical switches when we're trying to span the broadcast domains or span the VLANs between the devices and there's gonna be 2 different ways that we can do this based on the frame formatting But typically the links between the switches are gonna be trunks There are other couple design cases where you may wanna run trunking in the network One is that if you're going from the switch to the router and the router can run what's known as routing on a stick or router on a stick where it has multiple IP interfaces or multiple IP subnets then based on the VLAN number that the switch is sending it it can route between them based on that We'll take a look at some examples of that later and also from the switch to your end server like if you're running VMware for example you can have multiple virtual machines that are on different VLAN numbers and over the ethernet that you're using the physically physically connect into the switch network You can run this trunking encapsulation But the overall idea behind this is that when the ethernet frames are sent between the switches we need some additional encoding in order to carry the VLAN number And this is what our trunking encapsulation does where the normal ethernet header if we were to look at the actual layer 2 packet format it doesn't have a feel to to handle the VLAN number this is what the 2 protocols ISL for interswitch link or 802.1Q are gonna be used to accomplish Now the overall design goal of either these protocols is the same That we're just trying encode the VLAN number The main differences between them are that the first protocol interswitch link or ISL is a Cisco proprietary implementation Where specifically it uses 30 bytes of encapsulation and it doesn't modify the original frame So it adds a new header onto the front of it, it adds a new trailer onto the end of it Which it did frame check sequence for error checking So it's not changing what's going on inside the original frame The 802.1Q is an IEEE standard which basically means that any vendor can implement it there's recommendations on what the actual protocol format is supposed to look like and this is a 4-byte tag or a 4-byte header Since this is modifying the original frame when .1Q encapsulation happens the frame check sequence that's at the end needs to be updated in order to to calculate a new error check on the frame But in either case, it's basically gonna do the same thing There is a document on Cisco's website that is the interswitch link and 802.1Q frame formats If you would search for this document it shows you the specifics of what are the differences of them actually look like Here we have the the ISL header then the original data frame followed by the frame check sequence Most of the time these level of details really aren't that important because we're not doing low level layer 1 and layer 2 programming This step is gonna happen automatically behind the scene But if you do want to look at those details, you can see this document here Interswitch link and IEEE 802.1Q frame formats For the first of them, the ISL the key again is that the this one is Cisco proprietary uses 30 bytes of encapsulation where 26 go in the front and 4 go in the end Where the 4-byte trailer or basically the end of the frame this is used for a frame check sequence which you use for error checking to make sure the one I sent at across that the devices receiving it nothing changed from a layer 1 point of view The advantage of this was that ISL supported not only ethernet but trunking with Token ring and FDDI Today's networks, that doesn't really matter Cause we don't really have implementations of Token ring and FDDI in new implementations You may find some some very corner case scenarios where you have some legacy protocols like maybe still running on Token ring But the vast majority of cases today are just gonna be using ethernet For this reason, a lot of new versions of code in Cisco's IOS don't even support ISL 802.1Q by far, this is the one that's more popular to implement now because you can run it between any anybody's implementation You have a Cisco switch on one side and you have a a Netgear switch on the other side or some other vendor There's not gonna be any problems with encoding the packet cause its standard define Specifically this uses a 4-byte tag value which is a header but not a trailer Specifically this is added between the source and destination MAC address and what's known as the length and type or TYPE/LENGTH fields These values inside of the the ethernet frame tell the switch what is the next upper layer protocol? Like is at IPv4 or is at IPv6 Or specifically the encoding for IPv4 uses an ether type value of 0 by 800 Where other protocols like the address resolution protocol for IP uses a value of 0 by 806 Really this level of detail we're not really that concerned about it, just inside the header there is a way for the next protocol stack to figure out is for me or is it for someone else So when the router receives packets in its ethernet interface and sees that it's 0 by 800 it knows that it's supposed to go to the IP process or if it's going to 0 by 806 it knows that it needs to go to the ARP process from a software point of view But since we're changing the header, since we're adding this new 4-bytes between the the MAC address and the TYPE/LENGTH field it means that the router or the switch needs to rebuild rebuild the trailer or the frame check sequence 802.1Q also supports what's know as the native VLAN which is used for untag packets that go across the interface and essentially the the idea behind this is that if we had VLAN 10 on one side of the network and we have VLAN 10 On the other side when router 2 is trying to send packet to router 1 or to router 3 when the frame is received in here inside the ethernet header We're going to have the source MAC address We're gonna have the destination MAC address Then we're gonna have the the type and length fields When switch 2 moves this frame to the outgoing interface to the trunk link it's gonna add the tag value between these two fields, between the the MAC addresses and between the TYPE/LENGTH and this tag value basically is gonna tell the other switch what's the VLAN number that it's supposed to be in So this number This VLAN number is significant between the switches If VLAN 10 on this side if we want the CAM table to be basically be the same one that's over here we need to make sure that they agree on this number Now for the native VLAN encapsulation This basically means that there could be a VLAN number like VLAN 1 by default is the native VLAN This is use where a packet comes from VLAN 1 on this side goes across the trunk link but then does not get a .1Q tag The idea behind this is that if I received a frame on a .1Q trunk link and it doesn't have a tag I'm gonna assume that it's part of my native VLAN So really the only thing that you need to keep in mind for this value the native VLAN is that it has to match on both sides of the link Otherwise you can end up in strange designs where the host are supposed to be in the same VLAN and they up to not be or host are supposed to be in different VLANs and they end up on the same one Where basically traffic leads from one broadcast domain to the other one if the switches don't agree on the VLAN number between them You could see this on the command line if you were to look at the the show interface switch port What is the native VLAN number? And this is gonna be always 1 by default unless you change it for some reason So you can change it but most of the time, you just leave it that It's not gonna matter There's some corner case applications where maybe they need the VLAN number like if you're running one case would be like the firewall services module on the catalyst 6500 or some of the intrusion prevention systems for security Sometimes they want this number to be tagged and not untagged Because it's basically a problem at the application level but most of the time like between the switches the number's not gonna matter As long as they agree on it then they can either tag the frames on normal VLANs and leave them untag on the native VLAN and it's gonna work fine Again, the only problem in case you gonna run into is that if on one side I say that if on this side I say my native VLAN is 10 and on this side my native VLAN is 1 When these frames are encapsulated they get no tag When switch 1 receives them it thinks they're suppose to be part of VLAN 1 So the traffic ends up going to the wrong MAC address table or the wrong CAM table It's kind of use for like backwards compatibility for devices that didn't support the .1Q encapsulation One of the things that the Cisco switches were able to do with that originally is to tunnel spanning tree over it And it's not really needed in today's networks but if you had a Cisco switch that connected to some other switch like Bay Networks And then eventually it comes out on the Cisco switch on the other side One of the kind of legacy problems would be that if the Cisco switches supported the per VLAN spanning tree protocol the Bay network switch didn't support this because this is Cisco's specific implementation, Cisco proprietary So one thing that you could do is send this on tag across the switch on the middle and it comes out on the other side and it looks like these switches are directly connected In today's networks, you don't really need it though because we'll see there's replacement for this which is the raping spanning tree protocol and the multiple spanning tree protocol which are the new enchancements to Cisco's custom version You just need to make sure that all the switches agree on what the native VLAN is and then it'll work itself out There's also a feature for this that is known as Q in Q or sometimes as 802.1Q tunnels The idea behind this is that a service provider network that is running Metro ethernet can take traffic from one customer add an additional VLAN tag on it send across their own ethernet transport network and it comes out on the other side as a a single tag where the customer traffic is not changed as it goes through the network The idea behind this is that you could have a topology that looks like this where we have the the service provider cloud in the middle and they're attaching to the customer customer edge 1 and customer edge 2 as .1Q trunks then on the customer switches, if we have multiple VLANs let's say we have VLAN 10 here and VLAN 10 here But we also hace VLAN 20 and VLAN 20 The ideas that I wanna get this traffic to bridge over the service provider network But it's probably likely that the service provider has some other customer that's also using VLAN numbers 10 and 20 So what you can do is take the ethernet frame that comes from the customer edge switch which is the attaching to the service provider but it's it's under the customers maintenance You take the original data packet that has this VLAN 10 tag on it Or the original data packet that has tag 20 You put a new tag on the outside let's say 2000 This becomes what's known as the metro tag which is what the service provider uses this to get between the customer sites So in the service provider networks, we have multiple ethernet switches switch 1 and switch 2 that's somewhere along their paths they're running .1Q trunking then they're able to switch the traffic based on the new metro tag of 2000 But when the traffic comes out on the other side it comes out as the original one that went in So the VLAN number is maintained end to end between the customer sites So essentially there's an arbitrary length that you can continue to add tag values over and over and over which allows the traffic to transparently tunnel over the service provider network where from the customer's perspective it looks their switches are directly attached like if I went to customer edge 1 and said show CDP neighbors it would appear that that CE 2 is directly attached on that link So it's kind of like how MPLS VPN would work from a layer 2 point of view But you can do it with just ethernet and one of the limitations of ISL is that you cannot do this Overall, you'll see that .1Q trunking is a lot more popular than ISL is simply because you have interoperability between the vendors and keep in mind that this this type of encapsulation is only locally significant between the switches So if I had a case where I have connections from switch 1 to switch 2 switch 2 to switch 3 and then I have some end host, I'm trying to get traffic from A to B A is assigned to VLAN 10 and B is assigned to VLAN 10 But technically, I could configure the link between switch 1 and switch 2 as a .1Q trunk and then configure the trunk between switch 2 and switch 3 as ISL It's not really gonna make a difference because the only thing I'm doing is just adding that number as the frame is moving between the links So you don't necessarily have to choose one or the other, you can use both as long as this side and this side agreed that they're using .1Q and likewise that this side and this side agreed that they're using ISL So let's take a loot at an example of this now Where previously we have router 1 and router 3 that were connected over VLAN 10 and switch 1 is using layer 2 switching to get the traffic between them means they're in the same broadcast domain They're showing the same MAC addresst table when we went to switch 1 and we looked at the show MAC address table for VLAN 10 we saw that there were dynamic entries in here that were for router 1 and router 3's MAC addresses So we're gonna use the same logic but now we're gonna extend it between an additional switch So on switch 2, this has physical connections that go to router 2 and to router 4 The first thing I'm gonna do is set up router 2 and 4 to be added to this network So router 2 on its ethernet interface is gonna have the address 10.0.0.2/24 as is router 4, same subnet From the switch that is connecting them switch 2 in this case when we enable the interfaces we should see these two log messages saying that there's nothing wrong with the layer 1 status that's our link up message and there's nothing wrong with the layer 2 status, the line protocol is up If I were to look at the the show interfaces status we would see that basically basically everything on the switch is default parameters That all of the interfaces are assigned to VLAN 1 there's some link between the switches that have automatically negotiated this trunking We'll talk about this in a second but I can see that my port Fa0/2 and my port Fa0/4 at a minimum it shows that they're connected So there's nothing wrong with my layer 1 status like there's no cabling problems If I were to look at the show CDP neighbors I see that router 2 and router 4 are attached on my local interfaces, these are Fa0/2 and Fa0/4 Now at this point with no other configuration on the switch since these ports are defaulting to both be in VLAN 1 I should see that router 2 is able to send traffic to router 4 If we look at the show ARP router 2 and 4 are directly gonna know each others IP address to MAC address association If I were to send traffic to router 1 we would see that this traffic is not gonna get through because on this portion of the network here this is VLAN 1 on this portion of the network, it's VLAN 10 So between the switches, this is not the same MAC address table basically This means that when router 2 is sending a ARP request going to that all broadcast even if the frame floods over to switch 1 switch 1 is gonna get this it's not gonna send the packet out that port and it's not gonna send it up this one Because they're in different MAC address tables, we have VLAN 10 10 on this side, we have VLAN 1 on this side So the next thing I would need to do would be to change the assignment so that this is VLAN 10 on this side And remember there's gonna be 2 steps to this First thing I need to do is what? Is to create the VLAN So I say VLAN 10, that's gonna create it then at the interface level we assign it with what command? Switch port Switch port access VLAN is 10 Where the default option for this is 1 on all of the ports So I did this on Fa0/2 same thing on Fa0/4 Switch port access VLAN is 10 Now also to make this out a little bit easier to read what I'm gonna do is change the MAC addresses on the routers So we know what addresses we're looking at instead of looking at those long hack strings I could do this on the router's interface if I simply say MAC address and then I'll give router 1 let's see if I can do all 0s and a 1 There's a specific format that you need to conformed to, so that's valid So this will be router 1 Router 2 will just be all 0s and a 2 Router 3 will be all 0s and a 3 and router 4 is all 0s and a 4 Then on the switches on switch 1 and switch 2 I'm gonna delete the old entry that they had in the MAC address table And I could do this by saying clear MAC address table clear the dynamic entries from VLAN 10 Switch 2 is gonna do the same thing The end result of this is not gonna change any of the traffic forwarding The only thing it's gonna do is make it a little bit easier easier for us to read the table that all 0s and a 1 is router 1 If we show interface Fa0/0 on router 1 what is gonna tell us is that the original address was this, this is the burned in address But this is the one that I changed it to Normally you wouldn't really need to do this for any valid design case but you technically can if you wanted to If it went out of the VLAN the MAC address would change when it goes of the VLAN It would change the router's address So the key is that for these addresses, they're supposed to be unique but it really only matters that it's unique on a per VLAN basis Because the MAC address is what is considered a link local address It means that it's only used to communicate with someone who's on your directly attached segment or your local segment When I try to route traffic to a different router and then move it out to some other portions of the network the layer 2 header is gonna change any ways It's gonna change so that the destination address is my default gateway then when the gateway routes the traffic, they're gonna change the source MAC address to be theirs So as long as this value is unique inside of VLAN 10, that's all that we really care about You can change all them if you want to, you don't necessarily have to The only reason I'm doing this is that when we look at the result of the show MAC address table dynamic for VLAN 10 it's gonna make a little bit clear who's actually attached to which ports So from switch 1's perspective this goes to router 1 This goes to router 3 On switch 2 if we do the same thing and show MAC address table for VLAN it knows that on port Fa0/2 there's some host that has this address On port 4, there's some host that have this address If router 2 was to now try to reach the devices on the other switch So if I send a ping that goes to router 1's address when this frame is encapsulated over the trunk link The switch is not gonna change what is the source MAC address The only thing it's doing is gonna add between the source and the destination MAC and the TYPE/LENGTH value It's gonna add the VLAN number It's gonna add VLAN 10 When switch 1 receives this it says it came on a trunk link and it came from VLAN 10 It means that I should now take the interface number Fa0/13 and in the MAC address table, I'm gonna associate port 13 with the address 0000.0000.0002 and when the frame comes from router 4 I'm gonna learn that on port 13 as well that all 0s and then the 4 address So the key is that switch 1 is gonna know about every MAC address that's in VLAN 10 over here And switch 2 needs to know about every MAC address that's in VLAN 10 over here And this is one of the scalability limitations of the ethernet network If the broadcast domain is very large it means that each of the switches needs to maintain tons of MAC addresses in their tables Correct. For each VLAN, it's independent. So you keep separate copies of the table that I don't care if I have all 0s and then a 2 in VLAN 10 and 20 because they're separate virtual networks There are. We'll talk about those later There's some protocols that the devices uses multiple MAC addresses One of the applications for that would be the first hop redundancy protocols like HSRP or VRRP or GLBP has to do with the association of your default gateway to a MAC address We're gonna talk about that in more detail tomorrow The end result of this is what we should see is that router 2 should be able to reach router 1 And then it should be able to reach router 3 Now I may have forgot to did I actually assign the VLANs? Did assigned them. What this means is that the switches didn't automatically form the trunk link Physically in this case the switches are connected together with Fa0/13 Switch 1 in my rack is a 3560 as is switch 2 On the trunk link that is connecting them they're gonna be running a protocol that is known as the dynamic trunking protocol (DTP) They're gonna try to automatically figure out that this is a trunk link versus an access port And that's what the dynamic switch port does On these devices, if we were to look at the show interface Fa0/13 switch port it says that the mode of the interface is running in dynamic mode The operational mode or basically the result of the negotiation was that the interfaces in access mode It could also be the result of trunking It just depends did the other device also run dynamic mode? So did it run the negotiation of trunking and did someone actually initiate the trunking? So did the other switch asked me, do you wanna from a trunk link? Or did I ask them do you want to form a trunk link? For this particular version these ports are running in dynamic auto mode which means to listen for DTP but not to send DTP It means that if someone else is trying to start the trunk link, that's fine But I'm not gonna automatically start it This would be the difference on the interface between the switch port mode dynamic desirable versus dynamic auto And you'll see the different platforms have different through this This particular one is running in dynamic auto which means since both since neither of the sides are starting the negotiation they don't end up forming a trunk link But most of the time in the network you wouldn't really want this You know what are the physical connections between your switches I would say this is a trunk link and nothing else is So it kind of tries to ease the management to make the network more plugin play But it set the the sacrifice of security in the network because if an end host wants to run trunking the only thing they need to do is send the switch this DTP request And we'll talk about this when we get to layer 2 security Normally you would not leave the network in this state, the dynamic auto state If the port between them was in VLAN 10, yes. Because in that case we're treating it just as an access port which means it's just a native member of the link So you technically don't need trunking between the switches but only if you're using only one VLAN The key with trunking is that you can encode multiple numbers because I'm gonna assume that on my switch are probably have more than one VLAN number name used But if I were to say switch port access VLAN is 10 on this side And then on switch 2, do the same thing When I look at the show interface Fa0/13 switch port says now the access VLAN is 10, that's the assignment Once the spanning tree protocol converges and if we were to look at the show spanning tree for VLAN 10 what I wanna see for this is that it changes to forwarding state Right now it's in the learning state Which means it's trying to build the MAC address table Eventually, this is gonna change to forwarding and then I can send traffic And on router 3 So let's try this now, on router 1 Let's ping 10.0.0.2 and 10.0.0.4 We could see from the debug output router 1 is still debugging the ARP process the address resolution protocol So it's sending a request saying that this is my IP address, this is my MAC address The MAC address is the all 0s and 1 that I set I'm trying to figure out what is the MAC address of this IP Router 2 replies says this is my MAC address Router 1 should now put this into the ARP cache and the layer 2 switches should now all agree where the host located So if we show MAC address table look at the dynamic entries for VLAN 10 It says that the host 1 and 3 are connected on ports 1 and 3 respectively But host 2 and 4 both of them are located on 13 So you can have multiple ports that have multiple MAC addresses But you can only have one unique MAC address per CAM table So if someone else assigned router 1's MAC address here there's gonna be a problem So let's say I were to do this on router 2 if we went to, we should see we have connectivity to 1 3 and 4 If I were to go to the interface and say MAC address is all 0s and a 1 If I clear the ARP cache and send new requests the switches are gonna figure out that there's a problem That I now have the same MAC address on multiple ports and they may generate a log message here It's a MAC address flap notification Says the MAC address move from port 13 to 1 Normally this is an indication of one of two things Either two devices have the same address or there are some sort of loop in the layer 2 network where packet went out and then it came back around Usually, what is supposed to stop this, the loops in the network Spanning tree protocol is gonna stop that So if you were looking at your sys log messages this might be one that you would want to to do a notification on That if I start getting this message over and over and over it could mean that there's a loop in the spanning tree network and that can quickly take your layer 2 network down Also router 1 is generating generating an error message Says it filtered out an ARP request that came from our own address So it knows there's some sort of errors in the network But again normally you wouldn't have this because the MAC addresses should be automatically assigned as unique values to begin with So what we have now is basically just access ports that are spanning between the multiple physical switches Where these two ports are in access mode This is access, this is access SRDs And they're all assigned to the same VLAN number, VLAN 10 This would be the case if you take two unmanaged switches like if you have a linksys switch and you plug it into another one Even though you're spanning the traffic between multiple switches it's technically not a trunk link because unmanaged switches, they don't need to run trunking, they just have all of the ports in the same MAC address table But in most designs, this wouldn't be what we want Because it now eliminates the case that if I add a new VLAN on switch 1 let's say I have router 5 here that's in VLAN 20 and I have router 6 over here that's in VLAN 20 I now have no way to encode these frames as they go across that link I could put another physical interface between them and then assign this to VLAN 20 But as you could probably guess, it's not very scalable to do this So this is what the trunking encapsulation was design to solve that I want the VLANs to span between multiple physical devices So I need to add this number in the header as it sent between the two of them So let's change this time between the switches What would I normally wanna do is say on this port the ultimate goal is to get it to be a trunk port and to get it to be with the switches agree on what the encapsulation is that both sides run ISL or both sides run .1Q We could set the trunking encapsulation with the switch port trunk encapsulation command normally that's set to negotiate which means we're gonna use that dynamic protocol to try to figure it out If I were to say the encapsulation is manually ISL I would also have to say that the switch port mode is trunking This basically tells it to not worry about the negotiation of the link So in most designs, you would have both of these commands at the same time. Choose the encapsulation and choose that trunking is on So switch port trunk encapsulation is ISL switch port mode is trunk Once we do this if we look at the show interfaces trunk this is gonna show any of the interfaces locally that are running in trunking mode Some of them here I didn't configure like ports 16 to 21 These ones ran DTP the dynamic trunking protocol and they automatically negotiated ISL encapsulation The reason why in this case that this works is that on the other side, this connection here goes to switch 4 which is a 3550 The 3550 by default has the switch port mode dynamic desirable command on Which is fine as long as we know that there's a difference between them, and we know how to verify that So you don't need to memorize what are all the platforms and what are all the defaults as long as I know, how do I check to see what is the mode and are you running the negotiation and again we could see that by looking at the the show interface switch port So on the other switches if I were to go to switch 3 and the switch 4 On switch 3 if I show interfaces trunk It says that these 9 interfaces, numbers 13-21 These are running in desirable mode and if I were to show interface Fa0/13 trunk or excuse me, interface switch port It says the interfaces running in desirable mode which basically means to start the negotiation The other side has dynamic auto which means to listen for it but not to initiate or not to start the negotiation But as long as they agree that we're running the negotiation of trunking then the end result, the operational mode there ends up to be trunk It prefers ISL first. So it's gonna try to negotiate ISL if that doesn't work it'll try to negotiate .1Q If that doesn't work, it'll fall back to access mode So let's look at the end result of this now We should see that between these two port 13s On switch 2 if I were to say show interfaces trunk I should see that number 13 is trunking The status is trunking We could see the native VLAN is 1 by default So if we were running .1Q encapsulation it would mean if you took layer 2 packet analysis here, like you ran a sniffer and you looked at the actual frames going across the link the ones inside of VLAN 1 they would not have the .1Q tag Only any other VLAN besides 1 would get it But the end results is the same since they both agree that the native VLAN is 1 the MAC address tables for VLAN 1 end up to be the same Then for any other VLAN like 10 since we're encoding this on the link I know that 10 on this side is supposed to be 10 on the other side There's also a couple other key fields here So the interfaces running ISL encapsulation it's running in trunk mode This here is redundant This doesn't do anything now So normally you would just remove that No switch port access VLAN Same thing as gonna be on the other side If we look at the show interface trunk or more specifically the show interface Fa0/13 trunk couple other key things I would wanna know here One of them is which VLANs am I going to allow to be sent on that interface This would be if you wanna basically do a filter to say the certain VLAN shouldn't forward over this interface The next it says, which ones are allowed plus active This means which one did I actually create So in the VLAN database of switch 2 the only VLANs that are active are 1 which is there by default and 10 Lastly, which VLANs are in the spanning tree forwarding state and not pruned These are the ones that are actually being sent Where typically you would see that if there's multiple trunk links between the switches they would normally all agree on what are the allowed VLANs The number of active VLANs would be the same This actually controls are you sending traffic or not? And we'll see a little bit later more detail why you would need to know this portion of the output If we were to change this to .1Q it's only one command where we would say say what? The switch port trunk encapsulation is .1Q You'll see that for catalyst IOS platforms that do not support this command it means they only run .1Q If you say switch port trunk encapsulation and then put a question mark And it says unknown command it means it only supports .1Q A lot of the newer platforms are moving towards that way phasing out ISL cause there's really no advantage of running it Desirable and desirable will So the combinations would be if we add switch 1 and switch 2 connected You could have on and on You could have desirable and auto You could have desirable and desirable You could have on and desirable or you could have on and auto And these two would be kind of special cases, we'll look at these next Most commonly, you would have the first one Where you know it's a trunk link just statically set it to be a trunk link You don't really want the network to negotiate this We'll get to examples of that but if the configuration of the member interfaces which are the physical ports If it doesn't match the channel configuration the channel fails to setup Because you end up in a spanning tree loop where if let's say you have two physical links If this port spanning tree configuration doesn't match the other one I could have a port go out on this link and come back on the other one So the switch tries to prevent that, just says the the config has to be 100% equal otherwise, it won't allow the channel to work So when we change this here, switch port trunk encapsulation .1Q if we were now to look at the the show interface Fa0/13 trunk or just interface trunk, that would show all of them The difference is then gonna be what's the encapsulation In this case it's .1Q, not ISL The end result of it is gonna be the same though From the end host perspective router 1 doesn't care am I using an ISL trunk or am I using a .1Q trunk to reach router 2 Because the VLAN number is not encoded inside of my frames It's only encoded between the two switches This means one of two things here that one and two can't communicate with each other Either by changing that MAC address that I did before so that it it had the overlapping address either that still stuck in the MAC address table or there's something wrong with the trunk link If you have a problem with layer 2 comminucation, if the devices are supposed to be on the same VLAN and there's supposed to be on the same subnet if you were to look at the show ARP and it says the entry is incomplete It means there's some error in the ethernet network So router 1 should be ARPing for 2 but it's not getting a response back in From a troubleshooting point of view Probably the next thing I would wanna check is, is there anything wrong with the physical cable between them? Now previously we were sending traffic fine so we know that should be that should be an issue But if we were to show IP interface brief I would wanna check from router 1's point of view is the link up and is the protocol status up? This first one shows the layer 1 status Second one shows the layer 2 status I could then figure out who is my next top neighbor that's connected to this port By looking at show CDP neighbors It says I'm connected to switch q on switch 1 it's port Fa0/1 If I were to go to switch 1 and say show interface Fa0/1 switch port This should show me any of the layer 2 options that I could possibly need to know says the interface is running in access mode The access VLAN is 10 The next thing I would wanna know is for VLAN 10, I know it's running between these two But is VLAN 10 actually running between these 2? Because I should be getting the ARP request coming in here And I should be able to flood it in that direction So on switch 1, how could I check the VLAN 10 is actually running on that interface If we look at the show VLAN this is gonna show just your access port assignment So it shows port 1 and 3 are in access mode in the VLAN but it doesn't show me my trunk links Show interface trunk is gonna show me on that port is it trunking and is the VLAN actually running So all the way down towards the bottom, I need to make sure that 10 is in this category for spanning tree forwarding and the switches actually should be generating a a log message here One is in ISL, one is in .1Q Or I probably enter the command twice on the same switch but let's look at another thing here, let's say show interfaces status the switch should be detecting this and it should say that the interface is in error disable mode This version may not do that automatically But we could see the result of it is that I cannot encode the frames over the trunk because the frame format on one side doesn't match the frame in the other side So I need to make sure both of them are running the same encapsulation So on switch 1 here, I would need to go to Fa0/13 and say what? switch port trunk encapsulation is .1Q Now when router 1 sends the ARP eventually it should get the the response back in We'll see it still gonna take about 30 seconds here because spanning tree needs to go to the forwarding state first Now I got the reply So now eventually 1 and 2 should be able to talk which they can But these type of steps that I went through this is the type of stuff you need to know for the troubleshooting exam So when they show you an example of the network and it says you can't get from point A to point B you need to know what are all the possible variations of what could be going wrong in the middle and then how do I try to track that down It will automatically reconverge because what happened is that when I change the encapsulation it took the interface down it took the line protocol status down and then it brings it back up This is when spanning tree is gonna re-run So if we look at the final configuration results of of this As long as the switches agree on what the encapsulation is that the interfaces running in trunking mode and that this number is gonna match on the ports then the broadcast domain between these four devices, it should be the same should be end to end Which means now we can use IP at layer 3 to automatically do the resolution to the layer to MAC addresses with ARP But if ARP is broken, then anything above this is not gonna work, none of the routing protocols none of the applications We need to always verify that the layer 2 LAN works first for anything else on top of it Then here we have the The show interface trunk and the show interfaces switch port The bottom one is gonna show you all of the details The top one is kind of a summary of of the main stuff that's important For the .1Q configuration it's gonna be almost identical you just, you're changing this keyword But the end result of that is gonna be the same The host are in the same broadcast domain And they should be able to reach each other.