it did not work for my 3502. instead after changing the files, i can no longer hit escape to abort start up. thanks ... View more

Crossover for FastE or GigE or simply just use serial cables. ... View more

Hi Peter, I apologize for the late reply as I am busy these days.  It does make sense that a switching loop will be formed if someone decided to plug in an ethernet cable with both ends connecting to the switch. Just that I guess employees have a minimal sense of intelligence and they are not that bored. I guess its an unlikely but possible of cause of a problem. So if this is the case, how is the switch going to react to it? Will the port violation shuts down or err-disable the interface? I also understood the concept behind vlan 1 now that you had explained it this way. Exactly in my set up, vlan 1 is now left intact and the native is vlan 99. I dont know, im just trying to iron things out as a curious beginner would. I thought that vtp would cause my network to stop operating if an additional switch is added and because the revision is different, it wipes off all existing vlans. Thanks, Kin ... View more

Hi Peter, Thank You for your responses till this far, I really learned alot from you. I really enjoyed that you shared your experience of the server that has multiple ports connected to the switch, as all of the port are configured with bpdu filters, it will pose an issue because ports that are on a switch, destined to a host end-device, excluding server should be configured as access and bpdu parameters and portfast should be configured. Whereas if its a server, it should be in a trunking mode, in a separate promiscuous vlan, therefore bpdu parameters should never be configured in that scenario. For instance, if the server uses VMware vCenter with couple of vSwitches configured, it would means that the server does expect to receive bpdu frames on those interfaces. My scenario is that all the hosts connected to the access layer switches are desktop end user computers. No IP phones as well. The scenario examples you made are really spot on and I could say that it could be a recipe for MAN. Probably have a network for research facilities within a city would most benefit from it. I understood what you mean for root guard and I will not apply it, it certainly will cause issues when failure takes place on another interface or link. If VTP is always set to vlan1, wont it be unable to traverse if vlan1 is administratively shutdown because another vlan is chosen as the native vlan? Is it a better practice to use vlan1 as the native vlan as I think it might be vulnerable to hackers if they inject packets into vlan1 (with a vlan tag of vlan1), causing it to flood as part of a dos attack? Is there anyway to change how the vtp would use another vlan instead? Thanks, Kin ... View more

Hi Peter, Wow, Thank you for your explanation and I really appreciate that you provided me such in depth analysis of how the root guard function operates in STP. Before I continue to the interesting STP part, the bpdufilter that I intended to use should prevent any bpdu packets from leaving the access layer switches and ended up in host devices' medium. This is absolutely unnecessary to the host machines as they do not need bpdu information, but on the other hand, it creates additional overhead load on the link, hence the decrease in bandwidth. If someone pops a switch into my access ports, the interface will turn into err-disabled mode so thats not a problem. Pardon my little confusion over there where I said " root guard do defend the current root switch from turning into a non root switch, this is by preventing any root port from turning into root port. "  As I meant designated port to root port, well I guess you probably figured what I was trying to say anyway. I understood the main function of root guard now as it should not be applied in my internal network. I guess I was kind of paranoid as I anticipated an IF situation when the network is managed by a group of administrators, probably some juniors as well and in the interest in isolating the issue shall any of the administrator changes the switch priority, lesser than the root switch's priority, I was hoping some mechanism is able to prevent it. Having said that only the particular vlan is affected. I am also puzzled when you mentioned " Note that a root switch can also have blocked ports in the Backup role if there are two ports on the root switch connected together. " Are you referring to a stp or pvst? My topology is running pvrst and the rapid protocol implements the discarding role, therefore, there is no blocking of ports. Then again, I understands that pvrst is an improved version of pvst in which backup and alternate roles are used. I think I need to read up more on that. When you first showed the diagram, instantaneously I figured that root guard should be applied on the east interface of the middle switch, its a brilliant idea for networking between isp and client. However, I think that isp uses frame relay, ppp to connect with their client whereas through a switch, I am not sure if it is possible. The above topology is just demonstrating vlan 11 presented using visio. Say for example, some junior administrator changed the priority of DLS3 during a shift that I am not around, if root guard is applied on interfaces marked red, that would isolate the issue to only DLS3 and the other vlans with their respective switches should continue to operate per normal. Something to think about, if the vlan is a native vlan, untagged vtp packets will not be able to arrive at the desired switch and the entire network will be in trouble. Best Regards, Kin ... View more

Hi Peter, Thanks for taking the time to reply. I do know there are two options of bpdufilter, I want to thank you for enriching the second option as i was not entirely clear with that. While making this topology, I planned to use the first option and apply it on the physical interfaces. Problem here is that, The 2950 switch in packet tracer do not allow me to configure that. See the photo i attached. On second note regarding the root switch, I gotta admit I got mistaken with the terminology used of root switch and root port. okay okay, we can come to an agreement that a switch with all interfaces designated represents that it is the root switch of the particular vlan. What you are saying is that root guard prevents the interfaces from turning into root ports. If one of the interface decides to turn into a root port because it does not have root guard applied on, the current switch is no longer root switch of that vlan. The root switch selection will be contested elsewhere in which a better stp root is being advertised. In other words, root guard do defend the current root switch from turning into a non root switch, this is by preventing any root port from turning into root port. You got me thinking that whether it is applicable to my topology. I could say possibly. As each DLS is a root switch of 3 vlans, I do want to protect its designated interfaces from becoming root. The issue I am facing here is that if I configure root guard on the etherchannels, it defends all the ports from becoming root, that indeed is a problem. Because, it applies to ALL vlans spanning on the etherchannel. That would indeed be harmful to my network like you said because, for instance, DLS1's horizontal etherchannel is root port to vlan 41, because vlan 41 on DLS4 is the root switch. By applying root guard to that vertical etherchannel, as it is the alternating port, it will throw that root inconsistent error and puts the port into blocking mode. Best Regards, Kin ... View more