Layer 2 Technologies

1.1 Configure and verify switch administration

SDM Templates

The Switch Database Manager allows administrators to create templates that can set limits to the various elements of the TCAM. These templates allow the network administrator to control the TCAM table sizes and prevent any one table from exhausting the resource. There are a number of different template profiles that can be used to fine-tune the table memory for the function that the switch will be performing.

You can show the template that is being used for the TCAM by issuing the show sdm prefer privileged exec command. 

Managing MAC address table

What is the difference between the MAC address-table and the CAM table? For the most part, the terms are used interchangeably. The MAC address-table is located within the CAM table. The CAM table refers to the hardware memory of the switch.

 

Both the CAM table and the MAC address-table are inside the TCAM (Ternary Content Addressable Memory) which consists of five things:

  1. Layer 2 Learning Table: This sets the rules for how addresses are learned.
  2. ACL Table: When Layer 3 switching is enabled or Layer 2 switching with VLAN ACLs compiled ACLs are stored here.
  3. Layer 3 Routing Table: Layer 3 routes are stored here. This is empty if routing is not enabled.
  4. QoS Table: The rules and configuration for any QoS implementation are stored here.
  5. Layer 2 Forwarding table: This is where the MAC address-table resides.

 

The TCAM is a very fast memory chip that can perform at near wire-speed communication even with all the above logic applied to it. Although the TCAM is very fast, it has a finite amount of resource to share among the five tables above. In enterprise use cases this can become a problem if one of the five tables begins to grow to large and take away memory resource from the other tables and cause it to no longer function. In these scenarios use can use the SDM (Switch Database Manager) to create templates to prevent this from happening.

 

The default timeout for MAC addresses in the mac address-table is 300 seconds (5 minutes) this can be verified using the command show mac address-table aging-time. The aging-time can be modified globally or on a per VLAN basis.

The ageing time can be modified using the global command:

mac address-table aging-time .

To configure a particular VLAN to have a different aging-time you will need to append the desired VLAN to the command:

mac address-table aging-time .

Troubleshooting err-disable recovery

This error can create a situation where the port link light remains active and looks like it is functioning correctly but it is not. It can be caused by a number of things: port security violations, cabling issues, duplex mismatch, among many other possible causes.

You can see if a port is err-disabled via the show interface status and the show interface privileged exec commands.

The latter will give you much more information than the former, which will simply show you which port(s) are in a bad state.

If port-security is configured then checking the state will reveal if the err-disabled is due to a security violation: show port-security

1.2 Configure and verify Layer 2 protocols

CDP, LLDP

Cisco Discovery Protocol

Allows for the detection and discovery of neighbouring hardware. It is enabled by default on most Cisco switching platforms. It is a layer 2 protocol that does not require IP addressing to be configured to discover neighbours. CDP is a Cisco proprietary protocol. CDP is often turned off as it creates a vulnerability in the network. This is because CDP advertises a great deal of information about the network infrastructure in plain-text. As an example, one of the pieces of information that is broadcast out to the network is the IOS version that is running on the hardware, attackers are able to view this information and then use it to search for vulnerabilities that they can exploit to can access to the network.

CDP can be turned on or off globally or per interface. 

 

Link Layer Discovery Protocol

Is very similar to CDP but is an open standard version of it. The configuration of LLDP is also very similar. However, there are some things that LLDP addresses in comparison to CDP. LLDP is open, this means that network equipment from all sorts of different vendors can utilise it's feature. In addition to it being open, LLDP is also configurable. You can choose which information about the network is broadcast out on the link. For example, you can send only the hostname and platform that LLDP should send but not firmware versions and other critical information. On Cisco Systems products LLDP is not enabled by default. LLDP is turned on with a similar command to CDP, lldp run

To configure what information LLDP is sending out you use the global command lldp tlv-select. This will enable the information that will be sent from the hardware out to the network. If you explicitly turn on TLVs then that is the only information that will be sent. Similarly, if you explicitly turn off certain TLVs, everything but that information will be sent.

Mandatory TLVs

Port Description: 

System Name:

System Description:

System Capabilities:

Management Address: 

Optional TLVs

Port VLAN ID:

MAC/PHY configuration/status: 

LLDP can be turned on or off globally or per interface. Interfaces can also be set to transmit-only or receive-only. 

UDLD

Uni-Directional Link Detection is principally used for links between networking equipment. On a connection between a switch and an endpoint it will be obvious that there is something wrong with a link. Quite simply, the endpoint will not be functioning correctly. This is not necessarily true when it comes to links between network devices. For example, connections between switches may not always be fully active. If a switchport connected to another switch is in an STP blocking state there will be no traffic to speak of but the port could be receiving BPDUs to keep the port blocking. As this port is only required to receive network traffic for the time being it will not be obvious if there is an issue with the link until such time as that port is removed from blocking and traffic attempts to traverse it. UDLD is useful for situations such as this. UDLD is a service that ensures that there is a full link available on ports that it is enabled on. UDLD can be enabled on copper links with the udld port aggressive interface command and is enabled on fibre links with the udld enable interface command. There are two modes that UDLD can run in: normal mode and aggressive mode. Aggressive mode is the only option you have available to you on a copper link. In normal mode UDLD sends frames with a fake MAC address of 0100.0ccc.cccc, the far-end of the link sees the MAC address and responds to it. This operation works even on ports that are held-down or in a blocking state and proves full connectivity on the link. In normal mode, if no response is received from the far-end of the link then a warning status is generated but the port is not taken offline/shutdown. In aggressive mode, if no response is received after 8 consecutive attempts the ports is placed into err-disabled. UDLD timers can be modified globally with the command udld message time . This timer is the frequency that the messages are sent in seconds, by default this is set to 15 seconds.

 

UDLD is recommended to be configured on every fibre link as these are more prone to unidirectional traffic than copper cables. It should also be configured on trunk links and EtherChannel connections to ensure that these can be fully utilised. 

1.3 Configure and verify VLANs

Access Ports

These ports have access to only one VLAN and they are most commonly used to directly attach endpoints to the network infrastructure. Access ports are assigned a VLAN that logically segments it from other VLANs on a switch. A VLAN is a broadcast domain and for an endpoint to access network resource outside of it's assigned VLAN requires routing.

VLAN Database

The VLAN database is used to store VLAN data for a switch and by default is stored in non-volatile memory in the file vlan.dat. You can change the VLAN database file via the global command vtp file .

 

You can create VLANs in three different ways via the CLI:

  1. The VLAN command: using the global configuration command vlan . This is the preferred method as it allows you to also configure additional parameters such as the VLAN name. Changes to the VLAN Database are written until you exit config-vlan.
  2. From the interface: using the interface configuration command switchport access vlan . If the configured VLAN does not exist in the VLAN Database it will be enabled and you will be informed via a prompt on the CLI that this has been done.
  3. In the VLAN Database: this method is deprecated and the switch will - in all likelihood - alert you to that fact. To do this you need to first access the VLAN database with the privileged exec command vlan database. You can then add the required VLAN vlan .

 

As the VLAN Database is stored as a separate file and not part of the startup-config you must ensure that you delete the vlan.dat file when decommissioning equipment.

Normal, extended VLAN, voice VLAN

  • Normal VLANs are in the range 1-1005. This range of VLANs has been available since they were first introduced to networking. The last 4 VLANs in this range are not available for use as they are reserved to be default VLANs for some older technologies: VLAN1002 = FDDI, VLAN1003 = Token Ring TrCRF VLAN, VLAN1004 = FDDI NET VLAN, VLAN1005 = Token Ring TrBRF VLAN. Whilst these network technologies have largely gone away, the VLAN code within IOS was so integrated with them that they have remained for longer than their useful life. In newer Cisco platforms with completely new IOS they are no longer present.
  • Extended VLANs are in the range 1006-4094. Originally, Cisco switches used a VLAN range of 1-1024. The range of usable VLANs was 1-1001, with 1002-1005 being reserved for the FDDI and Token Ring default VLANs and 1006-1024 being reserved for system use only. As the VLAN identifier field is 12 bits in length it was possible to extend the range of available VLANs up to 4096 to allow for a greater number of usable VLANs. Within this range it is worth noting that are still some VLANs that you cannot use 0, 1 (default), 1002-1005 (reserved) and 4095. Additionally, there are some network devices which are still not able to use 1006-1024 (reserved for system use) so it is worth steering clear of those too where possible.
  • Voice VLANs are a special type of VLAN in a Cisco switch. It is highly likely that a VLAN that is being used for voice traffic will require QoS to be applied. To reduce the required port density in businesses which deploy Cisco IP telephony, Cisco IP phones are able to pass through a data connection from the phone to a users PC. This halves the amount of ports required on a switch but it does create some security concerns and if the PC data connection is consuming too much bandwidth it could have an adverse affect on the call quality for the IP phone. Voice VLANs get around this by, effectively, creating a trunk to the Cisco IP phone with the Data VLAN and the Voice VLAN. The Cisco phone then passes through the connection to the PC on the Data VLAN. This means that you can apply a QoS policy to the Voice VLAN and prioritize that traffic. You can apply this configuration with the following interface configuration commands: Voice VLAN switchport voice vlan , Data VLAN switchport access vlan .

1.4 Configure and verify trunking

DTP

Dynamic Trunking Protocol is a way of Cisco switches to automatically configure VLAN trunks between them. Whilst this could be a great convenience, it is more often regarded as quite a severe security risk. If all it takes to form a trunk connection to a switch is a DTP packet that opens up the possibility of exploitation. An attacker could give themselves access to all the VLANs on the port which could be all the VLANs on the switch.

Turning off DTP. The way to stop DTP from forming trunks dynamically is to configure a static switchport. You do this with either the switchport mode access or switchport mode trunk interface configuration command.

Note: you will need to first set the encapsulation type to dot1Q on the static trunk port before putting it into trunk mode with the interface configuration command switchport trunk encapsulation dot1q.

Statically setting the switchports does not suppress DTP entirely and it will still be active on the switchport. This won't be a problem unless you try and set a trunk between two switches that are in different VTP domains. DTP advertisements include the switch VTP domain and differing VTP domains on even a manually configured trunk will a domain mismatch error. To get around this you will have to suppress all DTP on the port. This can be achieved with the switchport nonegotiate interface configuration command.

Switchport ModeTrunkDynamic DesirableDynamic AutoAccess
TrunkYesYesYesNo
Dynamic DesirableYesYesYesNo
Dynamic AutoYesYesNoNo
AccessNoNoNoNo

VTPv1, VTPv2, VTPv3, VTP Pruning

VLAN Trunking Protocol is used to keep switch vlan databases in sync. When a new VLAN is configured on a switch that is operating in VTP Server mode, the new configuration will be sent to all other switches within the VTP Domain. This feature can reduce the time it takes to deploy another VLAN to the network and achieve greater consistency in VLAN configuration. However, misconfiguration or incorrect implementation of VTP can cause widespread issues. As an example, if you were to accidentally connect a switch to the network with the correct VTP domain name and password but a higher VTP revision number than what the network currently has (such as a switch that had been removed from the network for maintenance and returned with its VLAN information deleted) then the entire VTP Domain would adopt the VLAN configuration of the new switch which is likely to cause loss of VLAN information on all switches in the VTP Domain.

 

VTP Server: In this operating mode (default) a switch can make changes to the VLAN database and advertise that database.

 

VTP Client: In this operating mode a switch will listen to and pass along the advertisements from VTP Servers and update the VLAN database on the switch inline with the information that it receives, it cannot make changes to the VLAN database.

 

VTP Transparent: In this operating mode a switch will be a part of VTP in that it will pass VTP advertisements to other switches in the VTP domain. However, it will not update it's VLAN database with the information from the VTP Server, it is transparent to the VTP domain.

 

Configuration Revision when a change is made to the VLAN database the VTP Configuration Revision is increased. For a VTP domain, the switch that is operating in server mode that has the highest configuration revision number is expected to be the switch with the most reliable information. As in the example above, if a switch with a higher configuration revision is added to the VTP domain it will become the most reliable source and propogate it's VLAN database to the other switches in the domain, regardless of whether this information is correct or not. There is two ways to reset the configuration revision. The first is to put the switch into VTP Transparent mode and then back in to VTP Server mode. The other way is to delete the vlan.dat file and reboot the switch.

 

VTP Version 1 supports normal VLANs only (1-1005). Advertisements distribute the following global domain information:

  • VTP domain name.
  • VTP configuration revision number.
  • Update identity and update timestamp.
  • MD5 digest VLAN configuration, including maximum transmission unit (MTU) size for each VLAN.
  • Frame format.

VTP advertisements distribute this VLAN information for each configured VLAN:

  • VLAN IDs (ISL and IEEE 802.1Q)
  • VLAN name
  • VLAN type
  • VLAN state
  • Additional VLAN configuration information specific to the VLAN type 

 

VTP Version 2 supports the following additional features: 

  • Token Ring support—VTP version 2 supports Token Ring Bridge Relay Function (TrBRF) and Token Ring Concentrator Relay Function (TrCRF) VLANs
  • Unrecognized Type-Length-Value (TLV) support—A VTP server or client propagates configuration changes to its other trunks, even for TLVs it is not able to parse. The unrecognized TLV is saved in NVRAM when the switch is operating in VTP server mode.
  • Version-Dependent Transparent Mode—In VTP version 1, a VTP transparent switch inspects VTP messages for the domain name and version and forwards a message only if the version and domain name match. Because VTP version 2 supports only one domain, it forwards VTP messages in transparent mode without inspecting the version and domain name.
  • Consistency Checks—In VTP version 2, VLAN consistency checks (such as VLAN names and values) are performed only when you enter new information through the CLI or SNMP. Consistency checks are not performed when new information is obtained from a VTP message or when information is read from NVRAM. If the MD5 digest on a received VTP message is correct, its information is accepted. 

 

VTP Version 3 supports these features that are not supported in version 1 or version 2:

  • Enhanced authentication - You can configure the authentication as hidden or secret. When hidden, the secret key from the password string is saved in the VLAN database file, but it does not appear in plain text in the configuration. Instead, the key associated with the password is saved in hexadecimal format in the running configuration. You must reenter the password if you enter a takeover command in the domain. When you enter the secret keyword, you can directly configure the password secret key.
  • Support for extended range VLAN (VLANs 1006 to 4094) database propagation. VTP versions 1 and 2 propagate only VLANs 1 to 1005. If extended VLANs are configured, you cannot convert from VTP version 3 to version 1 or 2.
  • Private VLAN support.
  • Support for any database in a domain. In addition to propagating VTP information, version 3 can propagate Multiple Spanning Tree (MST) protocol database information. A separate instance of the VTP protocol runs for each application that uses VTP.
  • VTP primary server and VTP secondary servers. A VTP primary server updates the database information and sends updates that are honored by all devices in the system. A VTP secondary server can only back up the updated VTP configurations received from the primary server to its NVRAM. By default, all devices come up as secondary servers. You can enter the vtp primary privileged EXEC command to specify a primary server. Primary server status is only needed for database updates when the administrator issues a takeover message in the domain. You can have a working VTP domain without any primary servers. Primary server status is lost if the device reloads or domain parameters change, even when a password is configured on the switch.
  • The option to turn VTP on or off on a per-trunk (per-port) basis. You can enable or disable VTP per port by entering the [novtp interface configuration command. When you disable VTP on trunking ports, all VTP instances for that port are disabled. You cannot set VTP to off for the MST database and on for the VLAN database on the same port. When you globally set VTP mode to off, it applies to all the trunking ports in the system. However, you can specify on or off on a per-VTP instance basis. For example, you can configure the switch as a VTP server for the VLAN database but with VTP off for the MST database.

 

VTP Pruning increases available network bandwidth by restricting traffic from flowing down trunks where it is not required. When VTP pruning is not enabled in a network that is utilising VTP; all flooded traffic will be sent down all trunk links even if the destination switches do not have active VLANs for that traffic. This means that the traffic could be sent across the network only to be dropped at the far end. To enable VTP Pruning you need to issue the vtp pruning global configuration command on a switch operating in VTP Server mode and VTP will propagate the change to the other switches in the domain. You can also turn it on in the client with the same command, this will not propagate the configuration to other switches in the domain though . However, VTP pruning can only be successfully implemented in networks that have been designed with VTP Pruning in mind. Take the example below. In this network, if VTP Pruning were to be enabled Switch1 would not send any VLAN20 traffic to Switch3 via Switch2. Switch2 does not have active ports on VLAN20 so VTP has pruned VLAN20 from the trunk between Switch1 and Switch2. It is for this reason that most networks use manual VLAN pruning. It is a very rare network that is able to be planned and maintained in such a way that VTP pruning never leaves switches with orphaned VLANs.

{{ brizy_dc_image_alt uid='wp-34efc249e28e1d25d84084d70ee1e05c' }}

dot1Q

IEEE 802.1Q or dot1Q as it is named here it a networking standard that supports the implementation of VLANs on network equipment. Dot1Q adds a 32 bit field between the source MAC address and the EtherType/Size fields of an ethernet frame, it is commonly referred to as the VLAN tag. This tag allows the network equipment to differentiate traffic for VLANs.

 

As described in the DTP section, when you are manually configuring your trunks you will need to hard set the encapsulation mode to dot1Q using the interface configuration command switchport trunk encapsulation dot1q. 

Native VLAN

The native VLAN is the VLAN that untagged traffic will be placed into. Using native VLANs as part of your network implementation is not secure and best practice involves setting the native VLAN of ports to something that is not used. Lots of networks have VLAN 999 set aside for this purpose.

switchport trunk native vlan interface configuration command to set/amend the native VLAN for an interface.

show interface trunk to view the native vlan for trunk ports.

To maintain the tagging on the native vlan and drop untagged traffic, use the vlan dot1q tag native global configuration command. When this command is configured on the switch it will tag the traffic received on the native VLAN and admit only tagged frames, dropping any untagged traffic (which includes untagged traffic in the native VLAN). If the switch is configured in such a way, control traffic will still be accepted as untagged on the native VLAN of a trunked port. 

Manual Pruning

By default, a trunk is allowed to carry all VLANs that are available on the switch, whilst this is good for reachability it is not ideal from a security standpoint. Best practice with regards to security would be to only permit a trunk to carry the VLANs that are required for the switch/trunk to complete it's role within the network. This can be achieved by pruning manually pruning the VLANs that are allowed on a trunk. Pruning is configured from the interface configuration using the switchport trunk allowed vlan add. You can also remove VLANs from the trunk using switchport trunk allowed vlan remove.

1.5 Configure and verify EtherChannels

LACP, PAgP, manual

When there are multiple links in a network that have been for the purposes of resilience/redundancy they are normally disabled by STP to prevent loops in the network. Whilst the redundancy will remain, there is one link's worth of bandwidth that is there and not being used. Bonding the ports using one of the methods that follows will allow a network administrator to make use of additional bandwidth if both links are good while still providing an amount of resilience/redundancy for a link failure.

 

If you attempt to configure an EtherChannel across links that are not capable of the same speeds then the slowest links in the EtherChannel configuration will be suppressed until such time as they can no longer be regarded as the slowest links in the set. For example, if you were to bond two gigabit ethernet ports and two fast ethernet ports into the same EtherChannel, the configuration would be accepted. However, the two fast ethernet ports would be held down and the two gigabit ports would be utilised. If the two gigabit ports suffered a loss of connection then, an only then, would the fast ethernet ports come online as active members of the EtherChannel.

LACP - Link Aggregation Control Protocol (IEEE 802.1ax)

LACP is an open standard that was ratified by the IEEE in 2000, it does everything that PAgP does but is vendor agnostic. PAgP is most likely to be used between two Cisco Switches, there are very few vendors that support the use of PAgP. To turn on LACP, use the following configuration:

  1. Switch(config)# interface range GigabitEthernet 1/1 - 4
  2. Switch(config-if-range)# channel-protocol
  3. Switch(config-if-range)# channel-group 1 mode 
  4. Switch(config-if-range)# end
  5. Switch# show run interface port-channel 1
  6. Switch# show etherchannel summary 

When the channel-group mode is set to active the port-channel will accept and respond to PAgP requests to form an EtherChannel bundle otherwise the ports will remains as access ports.

When the channel-group mode is set to passive the port-channel is actively trying to create an EtherChannel bundle and will be trying to initiate the creation of the EtherChannel. 

channel-group modeactivepassive
activeYesYes
passiveYesNo

PAgP - Port Aggregation Protocol

PAgP is the Port Aggregation Protocol and it is a proprietary protocol that was acquired by Cisco Systems in 1994. Configuring PAgP is very similar to LACP just with slightly different options:

  1. Switch(config)# interface range GigabitEthernet 1/1 - 4
  2. Switch(config-if-range)# channel-protocol
  3. Switch(config-if-range)# channel-group 1 mode 
  4. Switch(config-if-range)# end
  5. Switch# show run interface port-channel 1
  6. Switch# show etherchannel summary

When the channel-group mode is set to auto the port-channel will accept and respond to PAgP requests to form an EtherChannel bundle otherwise the ports will remains as access ports.

When the channel-group mode is set to desirable the port-channel is actively trying to create an EtherChannel bundle and will be trying to initiate the creation of the EtherChannel. 

channel-group modedesirableauto
desirableYesYes
autoYesNo

Manual EtherChannel

You can configure an EtherChannel even with just a single port. This can be good if you are planning to add more ports to the EtherChannel at a later date. Configuring EtherChannel on a switch requires the switchports to be shutdown temporarily. So, in the aforementioned scenario where you will be adding extra ports at a later date it makes sense to start the EtherChannel configuration early on, this way you will not incur any downtime when you want to add the additional links to the EtherChannel as the port-channel will already be established. When you create a manual EtherChannel you are bonding interfaces together logically. These bonded interfaces create a virtual interface called a 'port-channel'. A port-channel will appear as a single link to STP and therefore will not cause STP to recognise the multiple links as a loop in the network. The steps to create a manual EtherChannel are as follows:

 

  1. Switch(config)# interface range GigabitEthernet 1/1 - 4 
  2. Switch(config-if-range)# channel-protocol
  3. Switch(config-if-range)# channel-group 1 mode on
  4. Switch(config-if-range)# end
  5. Switch# show run interface port-channel 1
  6. Switch# show etherchannel summary 

 

The command channel-group 1 mode on creates the virtual interface port-channel 1 from a group of interfaces, once this has been created all configuration for the port-channel will happen on this new interface.

The channel-group is only locally significant to the switch as it determines what the port-channel interface number will be. If you were to configure an EtherChannel that has channel-group 1 (port-channel 1) on one side and channel-group 4 (port-channel 4) on the other side it will function correctly as these do not have to match. 

Layer 2, Layer 3

For the most part EtherChannel is used for Layer 2 Trunk connections. It is possible to use EtherChannel on Layer 3 links. On a multi-layer switch you can assign switchports to be routed ports (no switchport interface configuration command). You can do EtherChannel on these ports, it will create a bonded link between two similarly capable multi-layer switches:

 

  1. Switch(config)# interface range GigabitEthernet 1/1 - 4
  2. Switch(config-if-range)# channel-protocol
  3. Switch(config-if-range)# channel-group 1 mode
  4. Switch(config-if-range)# exit
  5. Switch(config)# interface port-channel 1
  6. Switch(config-if)# ip address X.X.X.X X.X.X.X
  7. Switch# show run interface port-channel 1
  8. Switch# show etherchannel summary 

 

Speaking plainly, you can apply most configurations to a port-channel that you can apply to a switchport (or routed port). If you are implementing EtherChannels then you will need to perform this configuration on the port-channel once it is active.

Load Balancing

When you are utilising an EtherChannel implementation the connections that have been bundled into a channel-group to create the port-channel need to be able to load balance network traffic between the available links. Otherwise there is not a lot of point in using EtherChannel. To see what kind of EtherChannel load balancing is being used by the switch you can issue the privileged exec command show etherchannel load-balance. To change the load balancing mode you need to use the global configuration command port-channel load-balance . It is worth noting that as this command is issed in global configuration mode, you cannot mix load balancing types on the switch, you can set one type only and that is used for all EtherChannels. There are a number of different modes that can be used and these can vary between different switch models as the ability to load-balance the data successfully can be hardware limited.

 

Source-based

When connections are load-balanced by source MAC or source IP address or source port it means that connections from that particular address will always be sent down a particular link. Whilst this does mean that the traffic source is limited to whatever the speed of a single link in the EtherChannel is (and therefore not able to take advantage of the extra speed provided by EtherChannel bundles), it also means that the traffic source if, effectively, policed to not take more than the bandwidth available from a single link in the bundle.

 

Destination-based

When destination-based load balancing is applied to the EtherChannels on a switch it stops the single-link limitation on a network device that is applicable in source-based load balancing. An endpoint/network element could use more than a single-link for its connections and utilise multiple links in the bundle.

 

Source-Destination-based

This kind of load balancing employs both elements of the previous two, it will load balance connections based on both the source and destination. With this kind of load balancing method you could even have connections on separate links in the bundle that are going to and from the same host but simply with a different destination port on the far-end.

EtherChannel misconfiguration guard

There is no misconfiguration guard for manually created EtherChannel links. If you are using a dynamic EtherChannel protocol such as LACP or PAgP there is a feature called EtherChannel misconfiguration guard. It checks if the switch is configured for LACP or PAgP and if the connection does not work as it should the ports will not be allowed to fall back to being access ports. Instead EtherChannel Misconfiguration Guard will put the ports into an err-disabled mode.

This feature is configured via a spanning-tree global configuration command spanning-tree etherchannel guard misconfig. After this is enabled, any port-channels which do not come up properly will then be err-disabled.

1.6 Configure and verify spanning tree

Spanning-tree or 802.1d is a protocol that is used by switches to prevent layer 2 loops on the network. They do this by sending and receiving BPDUs (Bridge Protocol Data Units) out of their ports to gather information about the network. With this information a root bridge is elected. First, the bridge priority is interrogated, the lower the priority the better (the default value is 32768). If all switches have the same priority then the next stage of election will use the MAC address of the switch, again, the lower the better. However, this also means that older slower networking hardware will be preferred over newer and faster switches as the newer switches will have higher MAC addresses. The rationale behind using the lowest MAC address as the most reliable source is that if you are installing new switches on the network you might not want them to automatically become the root bridge of the network. You can view which MAC address is associated the switches spanning tree process by issuing the show spanning-tree command in privileged exec mode.

Port roles

Root Port this port is the best one to use to reach the root bridge.

Designated Port this port is the best path to the root bridge for a link.

Non-designated Port all other ports (placed in a blocking state).

 

Port States

Disabled a port that is shutdown and not taking part in the spanning-tree process

Blocking a port that is in the blocking state

Listening a port that is not forwarding traffic and not learning MAC addresses

Learning a port that is not forwarding traffic and is learning MAC addresses

Forwarding a port that is sending and receiving traffic

The spanning-tree process 

 

Elect a root bridge

BPDUs are broadcast to the network segment to perform the root bridge election. The root bridge is determined by the data contained within the BPDUs (the bridge priority and the MAC address). The switch with the lowest bridge priority for a segment will become the root. Where all bridge priorities are equal, the root port is elected to be the switch with the lowest MAC address value as expressed in Hexadecimal.

 

Place root interfaces into a forwarding state 

Once the root bridge is elected, it places all of it's switchports into a forwarding state. It is the root of the network to which all paths must lead so it cannot be the source of any loops.

 

Non-root switches/bridges determine which port will become their root port.

The non-root switches calculate which switchport is the best path to take to the root bridge. The calculation is determined using the port cost, with a lower port cost being preferable. In the event of a tie-break where two (or more) paths to the root bridge have the same cost via different switches, the bridge priority is compared. If the bridge priority is equal then the port priority is compared. If port priorities are also a tie then the decision is made based on which port has the lowest port number.

 

Remaining links choose a designated port

The selection of the designated port follows the same process of the selection of the root port. Cost>Bridge Priority>Port Priority>Port Number. A designated port is a port with the lowest STP cost to the root bridge for a given LAN segment.

 

All other ports are placed into a blocking state 

PVST+, RPVST+, MST

PVST+

Per VLAN Spanning Tree plus is a Cisco proprietary implementation that runs a spanning-tree process for each VLAN on the switch. The original IEEE 802.1d standard does not take multiple VLANs into account. Implementing STP in this way probably will not be optimal for all of the VLANs on a switch, by running a spanning-tree process per VLAN it allows the network to run STP in the most efficient way for each VLAN. It was put forward to IEEE for standardisation but it was not approved at the time because other network vendors did not have the processor power to run a number of STP instances on the same switch. In the years since, other network companies have been making hardware fully capable of running PVST+.

 

PVST+ is enabled by default on Cisco switches. For every VLAN that is created on a Cisco switch, a corresponding STP process is created.

 

With PVST+ the bridge priority is slightly different to the standard implementation of STP. The default bridge priority is still 32768 but with PVST+ the VLAN ID (referenced as sys-id-ext) is added to the default (or configured) bridge priority to generate the actual bridge priority for the segment. The downside of the way that PVST+ works is that manually configured bridge priority values are only able to be configured in increments of 4096 from 0-61440, this leaves 15 values (if we exclude 0). The standard STP implementation allows for all values of bridge priority to be configured.

RPVST+ (and RSPT 802.1w)

Rapid Per VLAN Spanning Tree Plus (and Rapid Spanning Tree) are versions of the spanning tree protocol that were created to provide a faster convergence of STP enabled network segments. There is not a lot of difference between STP and RSTP or PVST+ and RPVST+, the main difference is the speed of the state changes and the port states. The state changes are different because the listening and learning states of STP are combined into the Learning state. With RSTP/RPVST+ there are only three port states:

 

  1. Discarding: where the port is receiving BPDUs but not taking any action on the information that it is receiving
  2. Learning: this is the combination of the listening and learning state from CST (Common Spanning Tree), the port is listening for MAC addresses and any that it does see are added to the MAC table.
  3. Forwarding: where the port is sending and receiving traffic.

 

In addition to collapsing the port states to speed up the state transitions RSTP/RPVST+ also introduces the notion of alternate ports. Alternate ports are different from non-designated ports, they are ports that are discarding but they are the next best path to the root bridge, they are an alternate path to the root. As there is a next best path to the root bridge installed in the spanning tree process, the switch does not have to go through the learning state if there is a failure on the root port.

The Cisco recommendation for enabling RSTP/RPVST+ is to turn it on for the whole network segment. RSTP/RPVST+ is not enabled by default. To enable RSTP/RPVST+ you need to issue the global configuration command:

switch(config)# spanning-tree mode rapid-pvst

because PVST+ is enabled on Cisco switches by default there is no option to enable just RSTP , each STP process will be running RSTP.

MST

Multiple Spanning Tree MST is an IEEE standard (802.1s) and not a Cisco proprietary feature. It is the implementation of PVST+ that is used by other network vendors. However, MST does not perform STP on a Per-VLAN basis like PVST+ does. Instead, the IEEE version created Multiple Spanning Tree (MST) which is able to utilise 16 separate instances per switch. With the instances configurable on MST you are able to configure a number of VLANs to one MST instance. Compared to PVST+, MST requires some planning to implement it efficiently. To enable MST on a Cisco switch you will first need to change the spanning-tree mode as PVST+ is enabled by default on Cisco switches:

switch(config)#spanning-tree mode mst

switch(config)#spanning-tree mst configuration

switch(config-mst)#name <instance name>

switch(config-mst)#revision <revision number>

switch(config-mst)#instance <instance id> vlan <VLAN IDs>

switch(config-mst)#exit

switch(config)# 

 

An MST instance requires a name to work. Revision numbers are used in much the same way that VTP revision numbers are, the higher the revision number the better the information is assumed to be. Much like VLANs, MST configurations are not applied until you exit the MST configuration interface. The way that MST works is very similar to the Cisco implementation where the bridge priority is added to the VLAN number to make the new bridge priority but in the case of MST it is the instance number that is added to the bridge priority.

Switch priority, port priority, path cost, STP timers

Switch priority

The switch priority is a range of values between 0 and 65535, by default it is set to 32768 (the midpoint). The switch/bridge priority is adjusted so that network administrators can modify which switch(es) in the network should become the root bridge. The lower the switch/bridge priority the better. The lowest switch/bridge priority in a network segment will become the root bridge. If all switch/bridge priorities are the same within a segment then spanning-tree will determine what switch becomes the root by using tie breakers. The first tie-breaker after switch/bridge priority is MAC address, the lower the better.

Port priority 

Once a root bridge has been elected, the non-root bridges must undergo a process to shutdown the loops in the network by closing extraneous paths to the root bridge. The switches do this by closing ports that they are receiving BPDUs on until there is only one port/path that the BPDUs are able to come in on. It is during this process that the port priority is used. The port priority is made up of a priority number and a cost (the cost is calculated using the bandwidth of the port). If th

Path cost

The cost of a path is calculated from the bandwidth capabilities of the port, where cost is concerned a lower value is better

 

BandwidthShort Path Cost Method CostLong Path Cost Method Cost
10 Mbps1002,000,000
100 Mbps19200,000
1,000 Mpbs / 1 Gbps420,000
10,000 Mbps / 10 Gbps22,000
100,000 Mbps / 100 GbpsN/A200
1 TbpsN/A20
 

STP Timers

The STP timers are inherited from the root bridge, if the timers on the root bridge have been modified then all the switches for the spanning-tree instance will use those timers for the process as they are contained within the BPDUs that are sent out by the root bridge. The timers can be adjusted with the following global configuration command:

switch(config)#spanning-tree vlan <vlan ID> <forward-time| hello-time|max-age>

 

Default TimersDescription
Hello2 secondsThe amount of time between Hello messages that are generated by the root bridge, used as a keepalive so that the other switches know that the root bridge is still operational
MaxAge20 secondsIf there are no BPDUs received after the MaxAge timer has expired the switch becomes aware that something is wrong
Forward Delay15 secondsThis is the timer for both the Listening and Learning states. The default is for 15 seconds, which means that the Listening state will take 15 seconds and the Learning state will take 15 seconds meaning that the port will not be forwarding for 30 seconds.
  

Portfast, BPDUguard, BPDUfilter

Portfast

Portfast is a manual STP configuration where you specify that the port that you are configuring is not connected to a switch and will not introduce a switching loop on the network. In effect, the STP is being told to trust that no switching loops will be caused by this port. As the port has been configured to be an access port that will have an endpoint attached and not a switch, the port will not have to go through the STP listening/learning states. This means that the port will come up straight away, which can resolve a lot of issues for endpoints that are missing IP addresses due to the network not being available quick enough. However, if any BPDUs are received on the port STP will know that something has gone awry and the port should be included in the STP process.

To configure portfast on an interface you need to issue the following interface configuration command:

switch(config-if)#spanning-tree portfast

To set portfast to be the default on the switch you can issue the global configuration command:

switch(config)#spanning-tree portfast default 

BPDUguard

BPDUguard is a security mechanism that works in conjunction with portfast. When a BPDU is received on a portfast enabled port, BPDUguard will put that port into an err-disabled status

To enable BPDUguard by default on all portfast ports, issue the global configuration command: 

switch(config)#spanning-tree portfast bpduguard default

To enable BPDUguard on an interface issue the global configuration commands: 

switch(config-if)#spanning-tree portfast

switch(config-if)#spanning-tree bpduguard enable 

BPDUfilter

BPDUfilter is a less aggressive version of BPDUguard, instead of putting the affected port into an err-disabled state it discards the BPDU packets. It is not really useful in the same way as BPDUguard for security but it can be used to manipulate how STP is running on the network by filtering out BPDUs from certain switches.

To enable BPDUguard by default on all portfast ports, issue the global configuration command:

switch(config)#spanning-tree portfast bpdufilter default

To enable BPDUguard on an interface issue the global configuration commands:

switch(config-if)#spanning-tree portfast

switch(config-if)#spanning-tree bpdufilter enable 

Loopguard and Rootguard

Loopguard

Loopguard, rather unsurprisingly, helps to guard from loops occurring. Nowadays it is mostly replaced by the functionality that is provided by UDLD. Loopguard was created by Cisco before UDLD was created to provide a similar functionality. If a port stops receiving BPDUs that was once receiving BPDUs it will mark the port as inconsistent and blocks the traffic on the link.

To enable loopguard globally, use the global configuration command:

switch(config)#spanning-tree loopguard default 

To enable loopguard on an interface, use the interface configuration command:

switch(config-if)#spanning-tree guard loop

Rootguard

Rootguard is a way to prevent other switches connecting to the network from becoming the root. It allows a network administrator to control which switch is the root bridge and can also be implemented as a security measure against rogue switches being connected to the segment and making themselves the root bridge. Root bridge is also useful in mixed-vendor networks where bridge priority defaults differ. 

To enable rootguard on an interface, use the interface configuration command

switch(config-if)#spanning-tree guard root 

1.7 Configure and verify other LAN switching technologies

SPAN, RSPAN

A consideration when using SPAN/RSPAN. You should not send traffic from a source that has a higher amount of bandwidth than the destination. For example, if the monitor session source is a 10Gbps interface and the monitor session destination interface is a 1Gbps interface, there is a high likelihood that the destination interface will be sent more traffic than it can cope with. If the bandwidth of the destination port becomes saturated it will fail to an err-disabled status.

 

When you have finished the monitor session you should remove them to avoid wasting bandwidth unnecessarily. 

SPAN

Switch Port Analyser is the Cisco implementation of port mirroring. It allows a network administrator to send traffic from specific ports to an alternate destination so that network traffic can be analysed. SPAN is configured using monitor sessions, you have to add a source interface and a destination interface for the monitor session. The source interface tells the switch the network traffic that you want to capture and the destination session tells the switch where you want that traffic to be sent. By default, monitor session destination ports do not participate in network activity, if you want a monitor session destination port to still be active then you can configure this by adding the option ingress to the end of the monitor session destination configuration command. An example configuration of SPAN:

switch(config)#monitor session 1 source interface g0/1

switch(config)#monitor session 1 destination interface g0/24

In the above example, all the network traffic that is present on g0/1 will be sent via the backplane to interface g0/24. If a network administrator were to connect a computer/server that has network analyser software on it (such as Wireshark) they will be able to troubleshoot any network issues occurring on g0/1 without disturbing the switch or endpoint.

RSPAN

Remote Switch Port Analyser, this is very cool. RSPAN is used when you want to send SPAN traffic across a number of switches which allows you to analyse endpoints when your network analyser is not or cannot be connected to the same switch as the problematic port/device. RSPAN makes use of a special VLAN that is dedicated to transmitting RSPAN traffic. The first step to enabling RSPAN is to create the RSPAN VLAN, this should be a VLAN that is not used by anything else on the network it should be used only for carrying RSPAN traffic. For obvious reasons, this VLAN will need to be available and configured for RSPAN on each switch that will carry the traffic to the destination.

switch(config)#vlan <VLAN ID>

switch(config-vlan)#remote-span

switch(config-vlan)#name RSPAN <-- NOT REQUIRED, BUT RECOMMENDED

The remote-span VLAN will not be pruned if your network is running VTP pruning, as it is automatically removed from VTP pruning. Once the RSPAN VLAN is enabled in the correct switches that are required to be enabled between the source and the destination you can configure the monitor session:

Monitor Session Source Switch

switch(config)#monitor session 1 source interface g0/1

switch(config)#monitor session 1 destination remote vlan <VLAN ID>

Monitor Session Destination Switch

switch(config)#monitor session 1 source remote vlan <VLAN ID>

switch(config)#monitor session 1 destination interface g0/24

 

1.8 Describe chassis virtualization and aggregation technologies

Stackwise

StackWise is only available on a limited range of Cisco switches, it is not present on the lower end switches and it is not required on the chassis based switches. The mid-range switches are where Cisco StackWise is available (3750 and 3850 series), and it is useful for networks that need more powerful switching infrastructure than the lower end devices can provide but where a chassis based system is not feasible. StackWise allows these mid-range switches to be amalgamated into one logical switch. So, a network can start with one or two switches connected together and as the port requirement increases more switches can be added to the stack. On the back of a StackWise capable switch there are two interfaces labelled "STACK 1" and "STACK 2", these interfaces are connections to the switch backplane and allow a connection to the backplane of another switch. The latest switches are able to connect to the backplane via stackwise with a 480Gbps connection. When a StackWise Cluster is created by two or more switches being connected together with a StackWise cable, one of the switches becomes the master. The master switch handles all the logic for the stack and processes all the configuration commands. If the master fails one of the other switches takes over as master. The configuration of the master switch is replicated to all the other switches in the StackWise Cluster so they are able to take over from the failed master.

When you connect the cables you will need the same amount of cables as you have switches, plus one to complete the loop (N+1). Connections should always be from "STACK 1" on one switch to "STACK 2" on the next switch. In this manner, the cabling provides redundancy for one switch in the cluster to fail completely and the rest of the StackWise Cluster to still be operational.

{{ brizy_dc_image_alt uid='wp-63c33b35cdc4c56d7573b9d82baf4fbd' }}

Once the cables are connected, assuming all other requirements are met, the Cluster will come straight up. Similar to VTP and PVST+ it is just there and working by default. Again, similarly to VTP, it is not the best idea to just leave the switches to manage which should be the StackWise Cluster master as you will want to have some control of what is going on in the network. To configure a master switch manually you will have to do the following:

switch#show inventory 

This will output information relating to the priority of the switch as pertains to the StackWise Cluster.

switch#show switch 

This will output which switches are in the StackWise Cluster along with their priorities and other information. The switch number with the asterisk by it indicates which switch the command prompt is being provided by. 

switch(config)#switch <switch number> priority <1-15> <-- With switch priority, higher is better

This command sets the switch priority for the given switch

switch#show switch stack-ring speed

This command will show you the speed that the StackWise backplane is operating at. 

Virtual Switching System

The virtual switching system allows you to configure a pair of physical switches as a single logical switch, with one switch being the active switch and the other being a standby. The active switch handles the load and the standby is ready to take over should the need arise. Switches that are configured to be a VSS pair are connected with a Virtual Switch Link (VSL). VSL connections require 10GbE connections as a minimum so the VSS Chassis supervisor engines must be capable of supporting these connection speeds. The Active switch and the Standby switch both perform packet forwarding for ingress data traffic on their local hosted interfaces. All control traffic for the standby switch is sent to the active switch for processing. The VSL is, in actuality, an EtherChannel connection between the two switches that form the VSS. The VSL gives control traffic higher priority than data traffic so that control messages are never discarded.

Multichassis EtherChannel (MEC)

A multi-chassis EtherChannel is a port-channel that is connected to both of the chassis that comprise a VSS. The access switches that connect in to a VSS should have one interface of the port-channel connecting to the active switch chassis and the other connecting to the standby chassis.

The data traffic is load balanced across the VSL links by the configured EtherChannel load-balancing algorithm.

Redundancy and High Availability 

As already mentioned, in a VSS, each switch is performing packet forwarding for ingress data traffic on their local hosted interfaces but the supervisor engine operates only on the active switch. Supervisor engine redundancy is achieved using Stateful SwitchOver (SSO) and Non-Stop Forwarding (NSF). The two switches exchange configuration and state information across the VSL and the VSS is running in a hot-standby mode. The standby is monitoring the VSS active switch using the VSL. If the standby switch detects a failure, it initiates a switch-over to take on the active role. Alternatively, if the standby detects a loss of connection from the VSL, the standby will assume that the active switch has filed completely and initiate a switch-over. If/When a failed switch recovers it will take on the standby role. If, after a failure, both switches are active the dual-active detection feature initiates a recovery.

Infrastructure Security

2.1 Configure and verify switch security features

DHCP Snooping

DHCP snooping is a way of protecting against DHCP Spoofing. With DHCP spoofing a rogue DHCP server connects to the network to hand out IP addresses to clients. Rogue DHCP servers can also send out DHCP options that allow attacks to take place by manipulating options such as the default gateway, time servers, WINS servers, etc. Probably the most common ways that rogue DHCP servers are attached to the network is when someone brings in a home router/wireless access point to give WiFi access. By default. these home devices run DHCP so that people can connect to their home network with little to no knowledge of networking. Consequently, if someone attaches one of these devices to a corporate network they could be introducing a rogue DHCP server, which will cause a litany of issues at least for the VLAN that the device is attached to as this directly-attached device is likely to respond to DHCP requests quicker than the corporate DHCP server which could be a few networks away.

DHCP snooping works by limiting where DHCP offer packets can be sent from. On the switch you configure trusted ports where DHCP offers should be coming from and the rest of the ports will be configured for DHCP Snooping. Ports that have DHCP Snooping configured will not be able to transmit DHCP Offers to the network.

Enabling IP DHCP Snooping

switch(config)#ip dhcp snooping

switch(config)#no ip dhcp snooping information option*

To configure DHCP snooping for a VLAN.

switch(config)#ip dhcp snooping vlan <VLAN ID>

Configuring a trusted port

switch(config-if)#ip dhcp snooping trust

Configuring a trusted port allows this port to transmit DHCP offer packets to the network. The device connecting to this port, in this scenario, should be your DHCP server. If your DHCP server is not directly connected to the switch then you will have to configure the link that carries the traffic to the DHCP server as a trusted port, in most cases this would be your trunk port to the distribution or core switches. 

Setting a request limit on untrusted ports

switch(config-if)#ip dhcp snooping limit rate <1-2048/sec>

Even though dhcp snooping is enabled and prevent rogue DHCP servers from existing on the network there are still other DHCP attacks that can occur. For example, if someone where to connect a computer running Kali linux they would be able to commence a DoS attack whereby they can request hundreds of addresses to exhaust the DHCP pool of the DHCP server. To mitigate this risk you can configure the switchports to rate-limit the amount of DHCP discover messages that a port sends.

 

*no ip dhcp snooping information option. This is optional, if clients do not get addresses from your DHCP server then enable it. 

IP Source Guard

IP Source Guard prevents IP Spoofing attacks. The switch does this by matching the IP address and the MAC address, if those match an entry in the Source Guard table for the switchport then the traffic is permitted. If the IP and MAC do not match the entry that is in the Source Guard table for the switchport then the packet(s) are dropped.

Limitations of IP Source Guard

1) You can only have maximum of 10 IP addresses per Source Guard port. This can be a problem on access switches that connect to user laptops and devices that move often, the switchports will quickly run out of room in the Source Guard table in this kind of scenario.

2) IP DHCP Snooping has to be turned on to enable IP Source Guard.

Configuring IP Source Guard

switch(config-if)#ip verify source 

switch(config-if)#ip verify source port-security

switch#show ip verify source

The first two commands will enable IP Source Guard on a switchport and the last command will show the configuration that is current for IP Source Guard. This configuration will allow IPs that have been dynamically learned via DHCP to be added to the IP Source Guard table for the switchport. In networks where DHCP is not enabled or in instances where you want to manually configure the Source Guard you are also able to put in static mappings of IP and MAC addresses into the IP Source Guard table.

Manually configuring bindings

The command to manually configure is quite a long one so first I will show the command with the 'variable' names and then an example:

switch(config)#ip source binding <MAC address> vlan <VLAN ID> <IP address> interface <interface ID>

switch(config)#ip source binding 0056.4444.3210 vlan 10 172.16.128.12 interface GigabitEthernet 0/18

To then prove that the IP Source Guard table reflects the binding that you have configure you can issue the following show commands from privileged exec:

switch#show ip verify source

switch#show ip verify binding 

Dynamic ARP Inspection

Dynamic ARP Inspection provides protection from ARP Spoofing. ARP Spoofing happens when a third party uses gratuitious ARP to alter the ARP caches of systems to update them with the third party's MAC address. This means that a communication from Host A that was intended for Host B could be sent to Host C as Host C had update the ARP Caches so that the network devices send all traffic that is destined for Host A's IP address to the MAC address of Host C. Host C would intercept all this traffic and then forward it on as it is aware of the true ARP values for the communication. This is how a man-in-the-middle attack occurs. Host C has put itself in the middle of the communication occurring between Host A and Host B by manipulating the ARP caches of the network devices on the segment.

DAI depends on the entries in the DHCP snooping binding database to verify IP-to-MAC address bindings in incoming ARP requests and ARP responses. Make sure to enable DHCP snooping to permit ARP packets that have dynamically assigned IP addresses. When DHCP Snooping is not enabled or when the network is a non-DHCP environment ARP ACLs will be required to permit or deny packets.

Enabling Dynamic ARP Inspection 

switch(config)#ip arp instpection vlan

switch#show ip arp inspection vlan  

Dynamic ARP Inspection on Trunk links 

For trunk links you will need to configure trusted ports in a similar to way the was required with DHCP Snooping interfaces.

Statically configuring via ARP ACLs

switch(config)#arp access-list

switch(config-arp-nacl)#permit ip host mac host

switch(config-arp-nacl)#exit

switch(config)#ip arp inspection filter vlan

switch(config)#ip arp inspection validate

switch(config-if)#ip arp inspection trust

The above commands will create an arp access-list then create the access-list ACEs to be permitted. It then creates an inspection filter for the VLAN and you can configure what you are validating against destination or source MAC address or IP address. Then you enable arp inspection at the interface/switchport level by adding ip arp inspection trust.

Port Security

Port security is a way of - shockingly - securing the ports on a Cisco switch. Port security focuses predominantly on controlling the MAC addresses that are attempting to connecting to the switch. There are a few different ways of configuring the port security on a Cisco switch. As the main point of port security is to control the MAC addresses, they are the main thing that has to be configured. You can have the MAC addresses learned dynamically or you can assign them statically. In most cases, you are not going to be assigning MAC addresses statically, as a method of network administration it is not really maintainable. For the most part, networks are in a constant state of flux, with people and devices coming and going regularly.

To enable switchport security you have issue the oft overlooked interface configuration command:

switch(config-if)#switchport port-security

It is often overlooked because you can configure a lot of the options of switchport security without actually enabling it. The above command actually tells the switch that the port needs to be secured, adding the configuration commands that you will see below on their own will not enable the security features offered.

Limiting the amount of MAC addresses connecting to a port 

switch(config-if)#switchport port-security maximum <1-n*>

This command will configure the maximum amount of devices that can register MAC addresses against the port. Setting a reasonable maximum amount of MACs that can be registered against this port will prevent things like dumb switches being attached to the network. For example, if a user were to bring an unmanaged/home switch in to allow them to connect more devices. In this case, limiting the amount of MAC addresses will help prevent unauthorised devices being connected to the network.

Statically assigning MACs or dynamically learning

When you have set maximum number of MACs that the port can have assigned to it you are able to configure how those MACs are able to connect you have three options:

1) Do nothing, the MACs will be learned dynamically as they are normally, these MAC addresses will be aged out of the MAC address table in accordance with the configured mac address-table aging-timer (default: 300 seconds).

2) Configure the MAC addresses that are learned on the interface to be sticky. With this method the MACs that are learned on the interface are then made into static entries up to the maximum that is permissible on the switch. If the maximum is reached and another device attempts to connect to the switch then the port will follow it's port-security violation protocol.

switch(config-if)#switchport port-security mac-address sticky 

3) Configure the MAC addresses statically, With this method you are manually entering the MAC address(es) that you are expecting to request connectivity from the switch and any other address(es) will cause the switch to carry out it's port-security violation protocol.

switch(config-if)#switchport port-security abcd.0123.4567 

Configuring the violation protocol

If the switchport is exceeds it's configured maximum number of MAC addresses or a disallowed MAC address attempts to connect to the switchport it will perform the configured violation protocol

1) protect. Protect violation will stop any frames entering the switch but it will not alert that an error or violation has occurred.

switch(config-if)#switchport port-security violation protect 

2) restrict. Restrict violation does the same thing as protect in that it will stop frames entering the switch. However, in addition to stopping the network traffic, it will also send out SNMP traps and log messages to inform the network administrators that a port-security violation has occurred.

switch(config-if)#switchport port-security violation restrict 

3) shutdown. Shutdown is exactly what you think it is going to be. In the event of a port-security violation the interface will be shutdown and placed into an err-disabled mode. As we learned earlier, when a port goes into err-disabled it requires a manual intervention to be brought back online. When a port-security violation shutdown has happened you will need to first fix the reason that the violation occurred and then issue a shut/no shut on the tinerface for it to come back up.

switch(config-if)#switchport port-security violation shutdown

Automating err-disabled recovery

There is a way that you can automatically attempt to recover from a shutdown violation. You can configure this with a port-security aging time. When this is configured on an interface the switch will automatically attempt to recover the port from the err-disabled state after the amount of time specified. If the reason for the port-security violation is still present then the port will not be able to be recovered. You have to first enable this option at a global configuration level:

switch(config)#errdisable recovery cause psecure-violation

Once it is enabled you have to set the aging time on the interface(s).

switch(config-if)#switchport port-security aging time <1-1440>

 

n* = N because the maximum number of MACs that can be associated with a switch is dependent on the hardware capabilities of the switch. 

VLAN ACLs

Why use VLAN ACLs (VACLs) and not regular ACLs? VACLs are useful for when you want to restrict traffic between devices on the same network segment/VLAN. Regular ACLs will not work in this instance because the traffic would never get to the router to be processed through the ACL. VACLs are applied only on ingress traffic and are strictly for security packet filtering and redirecting traffic to specific physical interfaces.

Port ACLs 

Port ACLs are exactly what they sound like, they are an ACL that you apply to a single port. You can use these to easily stop traffic from a particular MAC getting to the host attached to the port. Their configuration is very similar to regular ACLs but with some of the keywords differing:

switch(config)#mac access-list extended <ACL number|ACL name>

switch(config-ext-macl)#deny host <MAC address> any

switch(config-if)#mac access-group <ACL number|ACL name> in

VLAN ACLs

These are also known as wire-speed ACLs as they operate at the ASIC level. VACLs use access-maps to contain an ordered list of one or more map entries. the map entries associate IP or MAC ACLs to an action. When the switch applies a VACL to a packet it performs the action that is configured in the first access map entry which contains an ACL that permits the packet. An access-map entry can perform one of three actions:

  1. Forward: send the traffic to the destination.
  2. Redirect: redirect the traffic to the specified interface(s).
  3. Drop: drop the traffic. dropped packets can also be logged as with standard ACLs.

Configuring VACLs happens in three stages:

Create the access-list(s).

Confusingly ACEs in the lists will always be permits as we are not dropping the packets at this stage. The ACEs are used to classify the traffic, the action that should be taken against traffic that matches the ACE is defined in the access-map.

switch(config)#access-list <ACL name|ACL number> permit ip host <IP address> host <IP address>

or, if you are using mac access-list(s)

switch(config)#mac access-list <ACL name|ACL number> permit host <MAC address> host <MAC address

Associate the access-list with the access-map and define action to take

When you have classified the traffic with the ACL you need to map the ACL to the action that needs to be applied to it with the access-map. 

switch(config)#vlan access-map <access-map name> <sequence number>

switch(config-access-map)#match <ip|mac> address <ACL number|ACL name>

switch(config-access-map)#action <drop|forward> 

Apply the filter to the VLAN 

As with standard ACLs you will have to apply the VACL to the interface that you want them to work on, remember you can only apply VACLs as ingress.

switch(config)#vlan filter <access-map name> vlan-list <VLAN ID(s)>

 

Show commands

switch#show vlan access-map

switch#show filter access-map <access-map name

 

Do not forget the golden rule of ACLs, at the bottom of every one there is an implicit deny!! 

Private VLAN

Private VLANs partition the Layer 2 broadcast domain of a VLAN into subdomains, which allows you to isolate the ports on a switch from each other. A subsomain consists of a primary VLAN and one or more secondary VLANs. All VLANs within a primary VLAN domain share the same primary VLAN. The secondary VLAN ID separates one subdomain from another.

Primary and Secondary VLANs

Primary VLAN: Each private VLAN domain has only one primary VLAN. Each port that is in a private VLAN domain is a member of the primary VLAN. The primary VLAN is the entire private VLAN domain:

  1. Promiscuous Ports: A promiscuous port belongs to the primary VLAN, it can communicate with all interfaces, including the community and isolated host ports which belong to the secondary VLANs that are associated with it. You can have several promiscuous ports attached to a primary VLAN. You can associate a secondary VLAN to more than one one promiscuous port as long as the promiscuous ports and secondary VLANs are within the same primary VLAN.

Secondary VLAN: The secondary VLANs may be either isolated VLANs or community VLANs:

  1. Isolated VLAN: A host on an isolated VLAN can only communicate with the associated promiscuous port in it's primary VLAN. Hosts on isolated VLANs can only talk to the primary VLAN. Ports within an isolated VLAN cannot communicate directly with each other at the Layer 2 level. 
  2. Community VLAN: Hosts in community VLANs can communicate among themselves and with the associated promiscuous port in the primary VLAN but they cannot communicate with ports in other community VLANs. Ports within a community VLAN can communicate with each other but cannot communicate with ports in another community VLAN or with isolated VLANs at the layer 2 level. 

Limitations

It only works on Cisco 3560 (or newer) switches (some 3550 switches will have the commands available in the ios but they will not work). 

The switch has to be configured to be operating in VTP transparent mode which means that each of the VLANs on the switch will have to be managed manually, you do not want theses changes propogating out to the rest of the network which is the rationale behind this requirement.

Configuring Private VLANs

The first step is to configure the switch to be operating in VTP transparent mode:

switch(config)#vtp mode transparent

Next you have to set up the secondary VLAN:

switch(config)#vlan

switch(config-vlan)#private-vlan

switch(config-vlan)#exit 

After the secondary VLAN is configured you will need to create the primary VLAN or configure an existing vlan to be the primary VLAN and then associate it with the secondary VLAN:

switch(config)#vlan

switch(config-vlan)#private-vlan primary

switch(config-vlan)#private-vlan association add

switch(config-vlan)#exit

Next, you can configure which ports your secondary VLAN will be associated with:

switch(config-if)#switchport mode private-vlan host

switch(config-if)#switchport private-vlan host-association

Once this is set up you can configure your promiscuous port and associate the secondary VLAN(s) with it:

switch(config-if)#switchport mode private-vlan promiscuous

switch(config-if)#switchport private-vlan mapping

Storm Control

A traffic storm happens when packets flood the LAN causing excessive traffic and adversely affects the network's performance. By implementing storm control the switch prevents ports from being disrupted by a broadcast/multicast/unicast storm on the physical interfaces. Traffic storm control monitors the incoming traffic levels over a 1 seconds traffic storm control interval and compares it with the traffic storm control level that is configured. The traffic storm control level is a percentage of the total available bandwidth of the port. Each physical port has a single storm control level that is used for all types of traffic broadcast/multicast/unicast so if there is an increase in both broadcast and multicast that when combined push the port passed the level that is configured for the port then the traffic storm control mediation actions will take place. By default, the action that traffic storm control takes is to drop the traffic until the storm control interval ends. There are also two configurable optional actions:

  1. Shutdown: If a traffic storm occurs then traffic storm control will move the port to an err-disabled state. The ports can be re-enabled automatically with the err-disable detection and recovery feature of it can be re-activated using the shutdown and no shutdown interface commands.
  2. Trap: When a traffic storm occurs, traffic storm control will generate an SNMP trap.

Configuring Traffic Storm Control

switch(config-if)#storm-control <broadcast|multicast|unicast> level <rising threshold (bandwidth %|bps|pps)> <falling threshold (bandwidth %|bps|pps)>

broadcast example: switch(config-if)#storm control broadcast level 50 25

If broadcast traffic rises to be equal or greater than 50% of the switchport's bandwidth enable traffic storm control remediation, once broadcast traffic return to be equal to or less then 25% of the switchport bandwidth traffic storm control remediation actions will be removed.

multicast example: switch(config-if)#storm control multicast level bps 500k 250k

If multicast traffic on a port rises to be equal to or greater than 500 Kbps enable traffic storm control remediation, once multicast traffic returns to be equal to or less than 250 Kbps traffic storm control remediation actions will be removed.

unicast example: switch(config-if)#storm control unicast level pps 100 25

If unicast traffic on a port rises to be equal to or greater than 100 pps (packets per second) enable traffic storm control remediation, once multicast traffic returns to be equal to or less than 25 pps traffic storm control remediation actions will be removed. 

Configuring Traffic Storm Control optional actions

switch(config-if)storm-control action  

 

storm-control unicast and storm-control multicast are only configurable on GigabitEthernet or faster switchport interfaces.

traffic storm control will not block BPDU and CDP traffic 

2.2 Describe device security using Cisco IOS AAA with TACACS+ and RADIUS

These notes are focused on switch based implementations of TACACS+ and RADIUS for more in-depth notes on these topics go to the 
ROUTE 300-101
notes.

AAA with TACACS+ and RADIUS

IEEE 802.1x port-based authentication is configured on a device to prevent unauthorised devices, known as supplicants, from gaining access to the network. To be able to configure port-based authentication on Cisco Switches there needs to be a RADIUS server that is capable of supporting 802.1x and EAPOL (Extensible Authentication Protocol Over LAN). Once 802.1x is configured for a switchport that switchport is logically treated by 802.1x as two ports:

  1. controlled: the controlled port is not able to transmit data until the supplicant device has been authenticated by the RADIUS server.
  2. uncontrolled: the uncontrolled port is allowed to transmit data without being authenticated by the RADIUS server. However, the only traffic that will be sent or received on this logical port is EAPOL, STP and CDP. So, the only traffic on this part of the switchport is authentication, spanning-tree and Cisco Discovery Protocol traffic

These two logical parts of the switchport are created automatically once the port is configured for dot1x and a device is connected to the port.

Configuring dot1x authentication

switch(config)#aaa new-model

switch(config)#aaa authentication dot1x default group radius

switch(config)#dot1x system-auth-control

switch(config)#radius-server host <IP address> auth-port <authentication port> acct-port <accounting port> key <radius server key

switch(config-if)#switchport mode access 

switch(config-if)#authentication port-control <auto|force-authorized|force-unauthorized>

switch(config-if)#dot1x pae supplicant 

Local privilege authorization fallback

No notes for this one yet. I will be creating them as I go through my course(s) and have something to put in here.

Infrastructure Services

Layer 3 Switching

Why route on switches?

Routers are primarily designed and implemented as devices for connecting to the WAN/Internet, if you were to have a network that was completely operating on Layer 2 except for the routers which were doing all the routing for the entire internal network as well as that for external traffic then they would quickly become exhausted of resource and unable to perform their job. When multi-layer switches are used in a network they are able to perform the internal routing for traffic that is going between subnets on that network, leaving the router(s) more able to do their job of routing the traffic that is destined to external networks or across the WAN. Switches have huge backplane buses that are capable of moving many Gbps of traffic and are able to move lots of data through the network without taxing the switch, when coupled with the port density available to switches it begins to make sense to perform as much routing as possible on multi-layer switches.

When you are routing on a switch there are a few different ways of assigning an IP address to a port:

Physical Port/Routed Port: to create a physical port on the switch you need to stop the interface from being a switchport by issuing the no switchport interface configuration command. A routed port will have an IP address assigned directly to it.

switch(config-if)#no switchport

switch(config-if)#ip address <IP address> <subnet mask>

Switch Virtual Interface: SVIs are created when you assign an IP address to a VLAN interface. SVIs are generally the preferred method of adding layer 3 addressing to a switch as it is simple to set up and user-friendly to use. When you have an SVI assigned to a VLAN, any switchport that is attached to that VLAN is able to access the layer 3 address via the SVI. This avoids many issues such as problems occuring from switchport failures; because many ports can be assigned to the VLAN, if one port fails then the others will still be able to communicate with the SVI. Routed ports do not function in this way, if a routed port fails it is no longer contactable.

BVI - a new type of interface

Well, it is new to me at least. There have been a few occasions that I have been in need of the functionality that Bridge group Virtual Interfaces (BVI) can provide but I had no idea that they existed. I don't recall it ever being covered in the study that I have done previously and I have never come across them whilst working. So, where would you use BVI? To quote the Cisco document "...say that you want to bridge two interfaces on the router and want them to be in the same Layer 2 broadcast domain. In this scenario, BVI/BDI would act as the routed interface for those two bridged physical interfaces. All the packets coming in or going out of these bridged interfaces will ahve to pass through the BVI/BDI". To clarify, BVI/BDI could be used if you wanted to connect two computers directly to a router and you wanted to have both of those computers in the same subnet. Normally you would not be able to get this working as the console will return an error saying that the addresses overlap. So, the workaround is to create a BVI and assign that an IP address from your required subnet and then assign the two interfaces that you want to connect the computers on to the bridge-group that is created by the BVI. The configuration is similar to that of a port-channel in it's appearance.

switch(config)#bridge irb

switch(config)#bridge <1-255> protocol ieee

switch(config)#bridge <1-255> route ip

switch(config)#interface GigabitEthernet 0/1 

switch(config-if)#bridge-group <1-255>

switch(config)#interface GigabitEthernet 0/2

switch(config-if)#bridge-group <1-255>

switch(config)#interface BVI <1-255>

switch(config-if)#ip address <IP address> <subnet mask>

In the above configuration we are first setting up the bridge. IRB is an initialisation of Integrated Routing and Bridging. The next command sets the protocol with other options being DEC and IBM which I assume are - for the most part -outdated as well as vlan-bridge which I have not yet found any information for (after a cursory look). After that you configure the type of routing that you need the bridge to perform, the only relevant one being IP for most use-cases. After that it is a simple matter of assigning the required ports to the port-bridge and addressing the BVI as per your requirements.

BDI is a similar/sister concept to BVI, the major differences being that it is for the IOS-XE platform and the commands are also quite different.

 

As a side note, this BVI seems extremely similar in form and function to the concept of Bridges on routerOS/MikroTik systems. 

3.1 Configure and verify first-hop redundancy protocols

HSRP

Hot Standby Routing Protocol is a Cisco proprietary solution for network redundancy in IP networks. It ensures that user traffic immediately and transparently recovers from first hop failures. HSRP allows a set of routers to work together and present the illusion of a single virtual router to hosts on the network. The set of routers is known as a HSRP group or a standby group. In normal operation, a single switch/router is elected to be responsible for forwarding packets that hosts send to the virtual router, this switch/router is known as the Active router. Another switch/router from the group is elected to be the standby, in the event that the active router fails the standby will assume the packet forwarding duties. If the standby router becomes the active router a new standby is elected (where possible). After the HSRP election has taken place the only HSRP traffic on the network will be between the current Active and Standby routers where they will contact each other to ensure that the other is still available. On a LAN there may be multiple HSRP/standby groups, each standby group emulates a virtual router. Individual routers may participate in multiple groups and for each group the router maintains separate states and timers. Each standby group has a single well-known MAC address as well as an IP address.

HSRP well-known MAC addresses

The virtual MACs that HSRP uses are well-known, that is, they are always the same for every system and are dependent on what the HSRP/standby group number is.

In HSRP version 1, the format for the MAC is 0000.0c0.7.ac** where the last two hexadecimal digits refer to the group number 0-255 which in hexadecimal is 00-FF.

In HSRP version 2 the amount of available HSRP/standby groups was increased to 4096, the construct of the well-known MAC is similar to version one except the variable portion is larger to accommodate the larger group number range. The format for the version 2 MAC is 0000.0C9F.F*** where the last three hexadeciaml digits refer to the group number 0-4095 which in hexadecimal is 000-FFF.

Configuring HSRP

switch(config-if)#standby <standby/HSRP group number> ip <IP address>

This command on it's own will enable HSRP with the default values and if there is at least one other router configured similarly they will perform an HSRP election and HSRP will be running for the network in question. Configuring the other options will allow different possibilities with HSRP

switch(config-if)#standby <standby/HSRP group number> priority <1-254>

The priority command will allow you to choose which router should - in the normal course of network operations - be the active router. The range of configurable priority values is 1-255 and the default value for HSRP is 100. With HSRP priority, higher is better.

HSRP States

HSRP StateDefinition
InitialThe state at the beginning, it is entered once there has been a configuration change which enables HSRP
LearnThe router has determined the virtual IP address and has not yet seen an authenticated hello message from the active router. The router is waiting to hear from the active router.
ListenThe router knows the virtual IP address but the router is not the active or standby router, it listens for hello messages from those routers.
SpeakThe router sends periodic hello messages and actively participates in the election of the active/standby routers. It listens for hello messages from those routers.
StandbyThe router is a candidate to become the next active router. It sends periodic hellos. There is, at most, one router in the group that is in the standby state.
ActiveThe router currently forwards packets that are sent to the group virtual MAC address, The router sends periodic hellos. There is, at most, one router in the group that is in the active state.

HSRP Preemption

The HSRP preeemption feature - when enabled - ensures that the highest priority router immediately becomes the active router for the group. The priority is determined first by the configured HSRP priority of the router. If all the HSRP priorities are equal then the tie-breaker is the router that has the highest IP address of the group. When a higher priority router preempts a lower priority one it sends a coup message. When a lower priority router that is the active router for a group receives a coup message or a hello message from a higher priority router it changes to the speak state and sends a resign message.

switch(config-if)#standby <standby/HSRP group number> preempt 

Preempt delay is a configurable option that will delay the preemption of a lower priority router giving the higher priority router time to populate it's routing table before becoming the active router. The delay timer starts once the preemption is first attempted.

HSRP and IP SLAs

For the most part, IP SLAs is covered in the 
CCNP ROUTE 300-101
notes, go there for more information on IP SLAs. HSRP tracking allows you to track routes in the table and if a route changes or disappears will influence which HSRP node becomes active in that scenario. Tracking can be done via checking whether a non-HSRP interface fails or if a route is lost.

To track an interface:

switch(config)#track <track ID> interface <interface ID> line-protocol

switch(config-if)#standby <standby/HSRP group number> track <track ID> decrement <value>

To track a route:

switch(config)#track <track ID> ip route <route network> <route netmask> reachability

switch(config-if)#standby <standby/HSRP group number> track <track ID> decrement <value>

The decrement value is the amount that the HSRP priority should be changed by.

HSRP Multicast Hello addresses

HSRP version 1: 224.0.0.2 - UDP port 1985

HSRP version 2: 224.0.0.102 - UDP port 2029

Lab ideas

Configure HSRP between three L3 switches.

Setup HSRP with priorities failover (and recover) switches to see HSRP working.

Next, add preempt and failover and recover switches to see HSRP with preempt working.

Use SLA and interface tracking to make changes to priorities

VRRP

Virtual Router Redundancy Protocol is the standards based version of the Cisco proprietary HSRP. It is very similar to HSRP in it's usage and configuration. When configuring VRRP you would just need to replace the word standby from the HSRP configuration commands and insert the word vrrp and away you go. However, you are able to assign a Virtual IP that is actually assigned to a real address on a gateway, for the sanity of the network administrators it is best to use a virtual IP in the same way that HSRP does. Additionally, the roles are not active/standby. Instead, they are master/backup, the master does not 'see' the backup(s) and does not know that they are there. The backup routers do communicate with each other and the master but the master does not do the same with the backups. The main reason for this is that the backup servers might be ready to share the IP that the master is using (remember VRRP can be configured to use an IP address that is actually configured on the master router).

On VRRP, preemption is enabled by default.

On the master: 

switch(config-if)#vrrp <group number> ip <IP address>

On the backup(s):

switch(config)#track <track ID> interface <interface ID> line-protocol

switch(config-if)#vrrp <group number> ip <IP address>

switch(config-if)#vrrp <group number> priority <priority value>

switch(config-if)#vrrp <group number> track <track ID> decrement <value

VRRP Multicast Hello addresses

VRRP: 2240.0.18 - IP protocol 112 

GLBP

Gateway Load Balancing Protocol takes the redundancy concepts of HSRP/VRRP and adds the ability for more than one router to be active as a gateway at any one time. It not only provides redundancy from switch/router failures, but also provides Load Balancing of traffic between multiple active gateways by using a single virtual IP address and multiple virtual MAC addresses. Each gateway is configured with the same virtual IP and all routers in the group participate in forwarding packets. GLBP members communicate with each other through hello messages sent every 3 seconds to the multicast address 224.0.0.102 via UDP port 3222.

This is a high-end feature with a lot of switches not supporting it. It is more commonly found on routers and chassis based switches with router processor modules

Active Virtual Gateway

With GLBP the members of a GLBP group elect one gateway to the Active Virtual Gateway (AVG) for the group, the other group members provide backup for the AVG in the event that the AVG fails/is unavailable. The AVG assigns a virtual MAC address to each member of the group and the gateways map that to the virtual IP address of the group. When a gateway has a virtual MAC address mapped to the virtual IP address and is forwarding the traffic for them it has become an Active Virtual Forwarder (AVF). The AVG is responsible for answering ARP requests of the virtual IP address and it performs load sharing by repluing to the ARP requests with different virtual MAC addresses of the group. an AVG will also be and AVF as it will also be forwarding traffic on behalf of the GLBP group whilst performing the additional duties of being the AVG. If an AVF were to become unreachable on the network then the clients that are utilising that virtual MAC address as their gateway destination will not stop working, another router from the group will assume the responsibility of forwarding packets for the downed virtual MAC address.

Virtual MAC Address Assignment

A GLBP group allows a maximum of four virtual MAC addresses per group. The AVG assigns the virtual MACs after the other members of the group send a request that follows the election of the AVG. An AVF that is assigned a virtual MAC address by the AVG is a primary virtual forwarder for that MAC address. During the course of normal operation the AVFs are learning the MAC addresses of the other AVFs in the group via hello messages. An AVF is a secondary virtual forwarder for the virtual MAC addresses it has learned from the other members of the GLBP group. 

Virtual Gateway Redundancy

GLBP operates it's gateway redundancy in much the same way as HSRP and VRRP do. One gateway is elected to be the AVG and another is elected to be the standby, the remaining gateways are placed into a listen state. If an AVG fails, the standby will assume responsibility for the virtual IP address and a new standby is elected from the gateways that are in the listen state.

Virtual Forwarded Redundancy

If an AVF fails, one of the secondary virtual forwarders in the listen state assumes responsibility for the virtual MAC address. The AVF that takes over for the failed one is also a primary virtual forwarder for a different MAC address. GLBP then beings the process of migrating hosts away from the old forwarder.

Gateway Priority

Setting the gateway priority provides a way of manually configuring which of the gateways should become the AVG and then what the order of ascendancy is for the remaining gateways if the AVG should fail. If the priorities are configured as default then the gateway with the highest IP address for the subnet wins the tie-breaker. The range of values for GLBP priority are 1-255 where higher is better, the same as HSRP/VRRP.

Gateway Weighting and Tracking

GLBP uses a weighting scheme to determine the forwarding capacity of each router in the GLBP group. The weight assigned to a router in the GLBP determines the proportion of hosts in the LAN that it will forward packets for. You can set thresholds to disable forwarding when the weight falls below a certain value and when it rises above another forwarding can be automatically re-enabled. Additionally, you can configure GLBP to automatically adjust the weighting by tracking the status of an interface on the router. If a tracked interface goes down, the GLBP group weighting is reduced by a specified value.

Load Balancing Methods 

MethodDefinition
host-dependentSpecifies a load balancing method based on the MAC address of a host where the same forwarder is always used for a particular host while the number of GLBP group members remains unchanged.
round-robinSpecifies a load balancing method where each virtual forwarder in turn is included in address resolution replies for the virtual IP address. This method is the default.
weightedSpecifies a load balancing method that is dependent on the weighting value advertised by the gateway.

Benefits

GLBP can share the load between multiple routers.

Multiple virtual routers. GLBP supports up to 1024 virtual routers or GLBP groups on each physical interface of a router with up to 4 virtual forwarders per group.

Preemption is enabled by default and allows you to preempt and AVG with a higher priority backup virtual gateway.

Simple text authentication is available to authenticate the GLBP group. 

Configuring GLBP

switch(config-if)#glbp <glbp group> ip <virtual IP address>

It really is as simple as that to configure the default implementation of GLBP.

switch(config-if)#glbp <glbp group> load-balancing <host-dependent|round-robin|weighted>

switch(config-if)#glbp <glbp group> weighting <weight max value> lower <lower threshold> upper <upper threshold>

GLBP Multicast Hello address

224.0.0.102 via UDP port 3222 

Configure and verify spanning tree

Bridge Priority

  • lower is better
  • Cisco default is 32768 
  • Values are 0- 65535

MAC address

  • switch#show spanning-tree will show the MACs being used for the spanning-tree process
  • Root ID shows the MAC address and priority of the Root Bridge.
  • Bridge ID shows the MAC address and priority of the current switch

the next thing

  • bullet 1
  • bullet 2
  • bullet 3 
BandwidthShort Path Cost Method CostLong Path Cost Method Cost
10 Mbps1002,000,000
100 Mbps19200,000
1,000 Mpbs / 1 Gbps420,000
10,000 Mbps / 10 Gbps22,000
100,000 Mbps / 100 GbpsN/A200
1 TbpsN/A20

If you need a new website or your website needs updating go to https://10kinds.tech.

10 Kinds Technology
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram