You remember from your CCNA studies that when a port goes through the transition from blocking to forwarding, you're looking at a 50-second delay before that port can actually begin forwarding frames. Configuring a port with PortFast is one way to get around that, but again, you can only use it when a single host device is found off the port. What if the device connected to a port is another switch?
A switch can be connected to two other switches, giving that local switch a redundant path to the root bridge, and that's great - we always want a backup plan! However, STP will only allow one path to be available, but if the available path to the root switch goes down, there will be a 50-second delay due to the STP timers MaxAge and ForwardDelay before the currently blocked path will be available.
The delay is there to prevent switching loops, and we can't use PortFast to shorten the delay since these are switches, not host devices. What we can use is Uplinkfast.
The ports that SW3 could potentially use to reach the root switch are collectively referred to as an uplink group. The uplink group includes the ports in forwarding and blocking mode. If the forwarding port in the uplink group sees that the link has gone down, another port in the uplink group will be transitioned from blocking to forwarding immediately. Uplinkfast is pretty much PortFast for wiring closets. (Cisco recommends that Uplinkfast not be used on switches in the distribution and core layers.)
Some additional details regarding Uplinkfast:
The actual transition from blocking to forwarding mode takes about three seconds.
Uplinkfast cannot be configured on a root switch.
Uplinkfast is configured globally. You can't run Uplinkfast on some ports or on a per-VLAN basis - it's all or nothing.
The original root port will become the root port again when it detects that its link to the root switch has come back up. This does not take place immediately. The switch uses the following formula to determine how long to wait before transitioning back to the forwarding state:
( 2 x FwdDelay) + 5 seconds
Uplinkfast will take immediate action to ensure that the switch upon which it is configured cannot become the root switch. First, the switch priority will be set to 49,152, which means that if all other switches are still at their default priority, they'd all have to go down before this switch can possibly become the root switch. Additionally, the STP Port Cost will be increased by 3000, making it highly unlikely that this switch will be used to reach the root switch by any downstream switches.
And you just know there's got to be at least one option with this command, right? Let's run IOS Help and see.
SW2(config)#spanning-tree uplinkfast ?
max-update-rate Rate at which station address updates are sent
When there is a direct link failure, dummy multicast frames are sent to the MAC destination 0100.0ccd.cdcd. The max-update-rate value determines how many of these frames will be sent in a 100-millisecond time period.
Mastering the details of UplinkFast, BackboneFast, BPDU Guard, and Loop Guard are vital to your success on the CCNP exams, and one or more of these features are in use on almost every network in the world. Learn these features for success in both the exam room and the real world!
Showing posts with label port. Show all posts
Showing posts with label port. Show all posts
Thursday, December 25, 2008
Cisco CCNP / BCMSN Exam Tutorial: Dynamic VLANs and VMPS
Knowledge of Dynamic VLANs and VMPS is important in your efforts to pass the BCMSN exam and earn your CCNP, and it's also a great skill to have for your networking career.
As a CCNA and CCNP candidate, you know how and why to configure static VLANs. Static VLANs can be a powerful tool for reducing unnecessary broadcast and multicast traffic, but if hosts are moved from one switch port to another, you've got to make those changes manually on the switch. With Dynamic VLANs, the changes are made - how else? - dynamically.
The actual configuration of dynamic VLANs is out of the scope of the BCMSN exam, but as a CCNP candidate you need to know the basics of VMPS - a VLAN Membership Policy Server.
Using VMPS results in port VLAN membership changes being performed dynamically, because the port's VLAN membership is decided by the source MAC address of the device connected to that port. (Yet another reason that the first value a switch looks at on an incoming frame is the source MAC address.)
In my home lab network, I've got a host connected to switch port fast0/1 that resides in VLAN 12. What if we had to move Host 1's connection to the switch to port 0/6? With static VLANs, we'd have to connect to the switch, configure the port as an access port, and then place the port into VLAN 12. With VMPS, the only thing we'd have to do is reconnect the cable to port 0/6, and the VMPS would dynamically place that port into VLAN 12.
I urge you to do additional reading regarding VMPS. Use your favorite search engine for the term configuring vmps and you'll quickly find some great official Cisco documentation on this topic.
To review, the VLAN membership of a host is decided by one of two factors. With static VLANs, the host's VLAN membership is the VLAN to which its switch port has been assigned. With dynamic VLANs, it is dependent upon the host's MAC address.
As a CCNA and CCNP candidate, you know how and why to configure static VLANs. Static VLANs can be a powerful tool for reducing unnecessary broadcast and multicast traffic, but if hosts are moved from one switch port to another, you've got to make those changes manually on the switch. With Dynamic VLANs, the changes are made - how else? - dynamically.
The actual configuration of dynamic VLANs is out of the scope of the BCMSN exam, but as a CCNP candidate you need to know the basics of VMPS - a VLAN Membership Policy Server.
Using VMPS results in port VLAN membership changes being performed dynamically, because the port's VLAN membership is decided by the source MAC address of the device connected to that port. (Yet another reason that the first value a switch looks at on an incoming frame is the source MAC address.)
In my home lab network, I've got a host connected to switch port fast0/1 that resides in VLAN 12. What if we had to move Host 1's connection to the switch to port 0/6? With static VLANs, we'd have to connect to the switch, configure the port as an access port, and then place the port into VLAN 12. With VMPS, the only thing we'd have to do is reconnect the cable to port 0/6, and the VMPS would dynamically place that port into VLAN 12.
I urge you to do additional reading regarding VMPS. Use your favorite search engine for the term configuring vmps and you'll quickly find some great official Cisco documentation on this topic.
To review, the VLAN membership of a host is decided by one of two factors. With static VLANs, the host's VLAN membership is the VLAN to which its switch port has been assigned. With dynamic VLANs, it is dependent upon the host's MAC address.
Cisco CCNP / BCMSN Exam Tutorial: Dynamic Trunking Protocol (DTP)
When you're studying to pass the BCMSN exam on the way to earning your CCNP certification, you're going to add to your CCNA knowledgebase every step of the way. Nowhere is that more than configuring a trunk between two switches.
You know that IEEE 802.1Q ("dot1q") and ISL are your two choices of trunking protocols, and you know the main differences between the two. What you might not have known is that there's a third trunking protocol that's running between your Cisco switches, and while it's a transparent process to many, you had better know about it for your BCMSN and other CCNP exams!
The Cisco-proprietary Dynamic Trunking Protocol (DTP) actively attempts to negotiate a trunk link with the remote switch. This sounds great, but there is a cost in overhead - DTP frames are transmitted every 30 seconds. If you decide to configure a port as a non-negotiable trunk port, there's no need for the port to send DTP frames.
DTP can be turned off at the interface level with the switchport nonegotiate command, but as you see below, you cannot turn DTP off until the port is no longer in dynamic desirable trunking mode. (Dynamic desirable is the default mode for most Cisco switch ports.)
SW2(config)#int fast 0/8
SW2(config-if)#switchport nonegotiate
Command rejected: Conflict between 'nonegotiate' and 'dynamic' status.
SW2(config-if)#switchport mode ?
access Set trunking mode to ACCESS unconditionally
dynamic Set trunking mode to dynamically negotiate access or trunk mode
trunk Set trunking mode to TRUNK unconditionally
SW2(config-if)#switchport mode trunk
SW2(config-if)#switchport nonegotiate
When you're working with Cisco switches in a home lab or rack rental environment, run IOS Help regularly to see what options are available for the commands you're practicing with. Cisco switch ports have quite a few options, and the best way to find them is with one simple symbol - the question mark!
You know that IEEE 802.1Q ("dot1q") and ISL are your two choices of trunking protocols, and you know the main differences between the two. What you might not have known is that there's a third trunking protocol that's running between your Cisco switches, and while it's a transparent process to many, you had better know about it for your BCMSN and other CCNP exams!
The Cisco-proprietary Dynamic Trunking Protocol (DTP) actively attempts to negotiate a trunk link with the remote switch. This sounds great, but there is a cost in overhead - DTP frames are transmitted every 30 seconds. If you decide to configure a port as a non-negotiable trunk port, there's no need for the port to send DTP frames.
DTP can be turned off at the interface level with the switchport nonegotiate command, but as you see below, you cannot turn DTP off until the port is no longer in dynamic desirable trunking mode. (Dynamic desirable is the default mode for most Cisco switch ports.)
SW2(config)#int fast 0/8
SW2(config-if)#switchport nonegotiate
Command rejected: Conflict between 'nonegotiate' and 'dynamic' status.
SW2(config-if)#switchport mode ?
access Set trunking mode to ACCESS unconditionally
dynamic Set trunking mode to dynamically negotiate access or trunk mode
trunk Set trunking mode to TRUNK unconditionally
SW2(config-if)#switchport mode trunk
SW2(config-if)#switchport nonegotiate
When you're working with Cisco switches in a home lab or rack rental environment, run IOS Help regularly to see what options are available for the commands you're practicing with. Cisco switch ports have quite a few options, and the best way to find them is with one simple symbol - the question mark!
Cisco CCNP / BCMSN Exam Tutorial: Configuring PortFast And BPDU Guard
In your CCNA studies, you learned about PortFast and the trouble it can cause if configured on the wrong port! Suitable only for switch ports connected directly to a single host, PortFast allows a port running STP to go directly from blocking to forwarding mode.
A Cisco router will give you a warning when you configure PortFast:
SW1(config)#int fast 0/5
SW1(config-if)#spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a
single host. Connecting hubs, concentrators, switches, bridges, etc...
to this interface when portfast is enabled, can cause temporary
bridging loops. Use with CAUTION
%Portfast has been configured on FastEthernet0/5 but will only
have effect when the interface is in a non-trunking mode.
SW1(config-if)#
Not only will the switch warn you about the proper usage of PortFast, but you must put the port into access mode before PortFast will take effect.
Now, you'd think that would be enough of a warning, right? But there is a chance - just a chance - that someone is going to manage to connect a switch to a port running Portfast. That could lead to two major problems, the first being the formation of a switching loop. Remember, the reason we have listening and learning modes is to help prevent switching loops. The next problem is that there could be a new root bridge elected - and it could be a switch that isn't even in your network!
BPDU Guard protects against this disastrous possibility. If any BPDU comes in on a port that's running BPDU Guard, the port will be shut down and placed into error disabled state, shown on the switch as err-disabled. A port placed in err-disabled state must be reopened manually.
BPDU Guard is off on all ports by default, and is enabled as shown here:
SW1(config)#int fast 0/5
SW1(config-if)#spanning-tree bpduguard enable
It's a good idea to enable BPDU Guard on any port you're running PortFast on. There's no cost in overhead, and it does prevent the possibility of a switch sending BPDUs into a port configured with PortFast - not to mention the possibility of a switch not under your control becoming a root switch to your network!
A Cisco router will give you a warning when you configure PortFast:
SW1(config)#int fast 0/5
SW1(config-if)#spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a
single host. Connecting hubs, concentrators, switches, bridges, etc...
to this interface when portfast is enabled, can cause temporary
bridging loops. Use with CAUTION
%Portfast has been configured on FastEthernet0/5 but will only
have effect when the interface is in a non-trunking mode.
SW1(config-if)#
Not only will the switch warn you about the proper usage of PortFast, but you must put the port into access mode before PortFast will take effect.
Now, you'd think that would be enough of a warning, right? But there is a chance - just a chance - that someone is going to manage to connect a switch to a port running Portfast. That could lead to two major problems, the first being the formation of a switching loop. Remember, the reason we have listening and learning modes is to help prevent switching loops. The next problem is that there could be a new root bridge elected - and it could be a switch that isn't even in your network!
BPDU Guard protects against this disastrous possibility. If any BPDU comes in on a port that's running BPDU Guard, the port will be shut down and placed into error disabled state, shown on the switch as err-disabled. A port placed in err-disabled state must be reopened manually.
BPDU Guard is off on all ports by default, and is enabled as shown here:
SW1(config)#int fast 0/5
SW1(config-if)#spanning-tree bpduguard enable
It's a good idea to enable BPDU Guard on any port you're running PortFast on. There's no cost in overhead, and it does prevent the possibility of a switch sending BPDUs into a port configured with PortFast - not to mention the possibility of a switch not under your control becoming a root switch to your network!
Wednesday, December 24, 2008
Cisco CCNA Certification Exam Tutorial: Port-Based Authentication
To pass your CCNA exam and earn this coveted certification, you must understand the details of port-based authentication. This knowledge has a great deal of value in production networks as well, since this authentication scheme is regularly implemented. Let's take a look at this particular CCNA skill.
Consider a situation where you have a server that will be connected to your switch, and you want the port to shut down if a device with a different MAC address that that of the switch attempts to connect to that port. You could also have a situation where you have someone who has a connection to a switch port in his office, and he wants to make sure that only his laptop can use that port.
Both of these examples are real-world situations, and there are two solutions for each. First, we could create a static MAC entry for that particular switch port. I don't recommend this, mainly because both you and I have better things to do than manage static MAC entries. The better solution is to configure port-based authentication on the switch.
The Cisco switch uses MAC addresses to enforce port security. With port security, only devices with certain MAC addresses can connect to the port successfully. This is another reason source MACs are looked at before the destination MAC is examined. If the source MAC is non-secure and port-based authentication is in effect, the destination does not matter, as the frame will not be forwarded. In essence, the source MAC address serves as the password.
MAC addresses that are allowed to successfully communicate with the switch port are secure MAC addresses. The default number of secure MAC addresses is 1, but a maximum of 132 secure MACs can be configured.
When a non-secure MAC address attempts to communicate with the switch port, one of three actions will occur, depending on the port security mode. In Protect mode, frames with non-secure MAC addresses are dropped. There is no notification that a violation has occurred. The port will continue to switch frames for the secure MAC address.
In Restrict mode, the same action is taken, but a syslog message is logged via SNMP, which is a messaging protocol used by Cisco routers.
In Shutdown mode, the interface goes into error-disabled state, the port LED will go out, and a syslog message is logged. The port has to be manually reopened. Shutdown mode is the default port-security mode.
Port-based authentication is just one of the many switching skills you'll have to demonstrate to earn your CCNA certification. Make sure you know the basics shown here, including the action of each particular mode, and you're on your way to CCNA exam success!
Consider a situation where you have a server that will be connected to your switch, and you want the port to shut down if a device with a different MAC address that that of the switch attempts to connect to that port. You could also have a situation where you have someone who has a connection to a switch port in his office, and he wants to make sure that only his laptop can use that port.
Both of these examples are real-world situations, and there are two solutions for each. First, we could create a static MAC entry for that particular switch port. I don't recommend this, mainly because both you and I have better things to do than manage static MAC entries. The better solution is to configure port-based authentication on the switch.
The Cisco switch uses MAC addresses to enforce port security. With port security, only devices with certain MAC addresses can connect to the port successfully. This is another reason source MACs are looked at before the destination MAC is examined. If the source MAC is non-secure and port-based authentication is in effect, the destination does not matter, as the frame will not be forwarded. In essence, the source MAC address serves as the password.
MAC addresses that are allowed to successfully communicate with the switch port are secure MAC addresses. The default number of secure MAC addresses is 1, but a maximum of 132 secure MACs can be configured.
When a non-secure MAC address attempts to communicate with the switch port, one of three actions will occur, depending on the port security mode. In Protect mode, frames with non-secure MAC addresses are dropped. There is no notification that a violation has occurred. The port will continue to switch frames for the secure MAC address.
In Restrict mode, the same action is taken, but a syslog message is logged via SNMP, which is a messaging protocol used by Cisco routers.
In Shutdown mode, the interface goes into error-disabled state, the port LED will go out, and a syslog message is logged. The port has to be manually reopened. Shutdown mode is the default port-security mode.
Port-based authentication is just one of the many switching skills you'll have to demonstrate to earn your CCNA certification. Make sure you know the basics shown here, including the action of each particular mode, and you're on your way to CCNA exam success!
Cisco CCNA Certification: How And Why Switches Trunk
Your CCNA studies are going to include quite a bit of information about switches, and for good reason. if you don't understand basic switching theory, you can't configure and troubleshoot Cisco switches, either on the CCNA exam or in the real world. That goes double for trunking!
Trunking is simply enabling two or more switches to communicate and send frames to each other for transmission to remote hosts. There are two major trunking protocols that we need to know the details of for exam success and real-world success, but before we get to the protocols, let's discuss the cables we need.
Connecting two Cisco switches requires a crossover cable. As you know, there are eight wires inside an ethernet cable. In a crossover cable, four of the cables "cross over" from one pin to another. For many newer Cisco switches, all you need to do to create a trunk is connect the switches with a crossover cable. For instance, 2950 switches dynamically trunk once you connect them with the right cable. If you use the wrong cable, you'll be there a while!
There are two different trunking protocols in use on today's Cisco switches, ISL and IEEE 802.1Q, generally referred to as "dot1q". There are three main differences between the two. First, ISL is a Cisco-proprietary trunking protocol, where dot1q is the industry standard. (Those of you new to Cisco testing should get used to the phrases "Cisco-proprietary" and "industry standard".) If you're working in a multivendor environment, ISL may not be a good choice. And even though ISL is Cisco's own trunking protocol, some Cisco switches run only dot1q.
ISL also encapsulates the entire frame, increasing the network overhead. Dot1q only places a header on the frame, and in some circumstances, doesn't even do that. There is much less overhead with dot1q as compared to ISL. That leads to the third major difference, the way the protocols work with the native vlan.
The native vlan is simply the default vlan that switch ports are placed into if they are not expressly placed into another vlan. On Cisco switches, the native vlan is vlan 1. (This can be changed.) If dot1q is running, frames that are going to be sent across the trunk line don't even have a header placed on them; the remote switch will assume that any frame that has no header is destined for the native vlan.
The problem with ISL is that is doesn't understand what a native vlan is. Every single frame will be encapsulated, regardless of the vlan it's destined for.
Switching theory is a big part of your CCNA studies, and it can seem overwhelming at first. Just break your studies down into smaller, more manageable parts, and soon you'll see the magic letters "CCNA" behind your name!
Trunking is simply enabling two or more switches to communicate and send frames to each other for transmission to remote hosts. There are two major trunking protocols that we need to know the details of for exam success and real-world success, but before we get to the protocols, let's discuss the cables we need.
Connecting two Cisco switches requires a crossover cable. As you know, there are eight wires inside an ethernet cable. In a crossover cable, four of the cables "cross over" from one pin to another. For many newer Cisco switches, all you need to do to create a trunk is connect the switches with a crossover cable. For instance, 2950 switches dynamically trunk once you connect them with the right cable. If you use the wrong cable, you'll be there a while!
There are two different trunking protocols in use on today's Cisco switches, ISL and IEEE 802.1Q, generally referred to as "dot1q". There are three main differences between the two. First, ISL is a Cisco-proprietary trunking protocol, where dot1q is the industry standard. (Those of you new to Cisco testing should get used to the phrases "Cisco-proprietary" and "industry standard".) If you're working in a multivendor environment, ISL may not be a good choice. And even though ISL is Cisco's own trunking protocol, some Cisco switches run only dot1q.
ISL also encapsulates the entire frame, increasing the network overhead. Dot1q only places a header on the frame, and in some circumstances, doesn't even do that. There is much less overhead with dot1q as compared to ISL. That leads to the third major difference, the way the protocols work with the native vlan.
The native vlan is simply the default vlan that switch ports are placed into if they are not expressly placed into another vlan. On Cisco switches, the native vlan is vlan 1. (This can be changed.) If dot1q is running, frames that are going to be sent across the trunk line don't even have a header placed on them; the remote switch will assume that any frame that has no header is destined for the native vlan.
The problem with ISL is that is doesn't understand what a native vlan is. Every single frame will be encapsulated, regardless of the vlan it's destined for.
Switching theory is a big part of your CCNA studies, and it can seem overwhelming at first. Just break your studies down into smaller, more manageable parts, and soon you'll see the magic letters "CCNA" behind your name!
Subscribe to:
Posts (Atom)
