Dependence between ARP max age time and MAC-address aging on Cisco switches

Let's begin with an example of typical switched network with multilayer distribution switches.

Assume that all the links between switches are trunk links, that both DL1 and DL2 are participating in HSRP groups where DL1 active for VLAN1 and VLAN3 and DL2 for VLAN2. STP is configured proportionally to block the rightmost links at access layer switches for even VLAN's and the leftmost links for odd VLAN's.

Now let's pretend that host C1 pings host C2.
Let's follow the path of the packet on its way to C2:
1. Since C1 resides in the different VLAN than host C2, then it should send the packets to its default gateway (DL1's VLAN1 interace). By means of ARP request C1 discovers MAC address of VLAN1 interface and sends the first ICMP packet.
2. DL1 routes the packet. VLAN2 is a directly connected network, so DL1 discovers with ARP MAC address of C2 and sends the packet to it (Packet traverse the link between DL1 and DL2 and then to AL2 since the leftmost link is blocked by STP for VLAN2 on AL2).

Important note: to this moment internal switch on DL1 have the following MAC-addresses: C1 in VLAN1 and C2 in VLAN2.

ICMP-reply from C2 follows the same path except that its default gateway will be DL2's VLAN2 interface. This means that in this network the routing between VLAN's is asymmetric.

What happens if the pings are coming for example for 10 minutes?
DL1 ages MAC-address entry for C2 in VLAN2 since it sees no new frames from it (remember, that reverse packets are first routed at DL2 and then sent from its VLAN1 interface?) and begins to flood the frames for C2 out of all its ports in VLAN2. Mirrored result is seen on DL2 for reverse packets.
The problem relies to the fact that router holds the arp entries for 14,400 seconds or 4 hours, but the switch ages CAM table in 5 minutes.

For this not to happen the timers on ARP and CAM table should be in SYNC!
The easiest way is to increase MAC aging time to 14,400 seconds.
For Catalyst 6500 it can be done with the following command:
mac-address-table aging-time seconds [vlan vlan_id]

Happy switching!

Direction on the access-lists on the VLAN interfaces

An access-list applied outbound to a vlan interface filters traffic going TO machines on that vlan.

An access-list applied inbound to a vlan filters traffic coming FROM machines on that vlan.

Using ACL's in a switch

vlan access-map map-name [sequence]

 math {ip | mac} {acl-name | acl - number}

 action {drop | forward | redirect type mod/num}

 exit

vlan filter map-name vlan-list vlan-list

Troubleshooting:

show vlan filter

show vlan access-map

Private Vlan's

First, we need to define secondary vlan's. We have to do it first, because they will be mapped to the primary vlan in a latter step.

vlan 201

 private-vlan community

vlan 202

 private-vlan isolated

Next, we need to identify primary vlan's and they association with secondary vlans

vlan 2

 private-vlan primary

 private-vlan association  201, 202

Now we need to identify switch ports. First, let's configure the ports connected to the user devices.

int fa0/1

 switchport mode private-vlan host

 switchport private-vlan host-association 2 201

int range fa0/2 - 3 

 switchport mode private-vlan host

 switchport private-vlan host-association 2 202

Now we need to identify any promiscuous ports on the switch. Routers will be connected to those ports.

int fa0/24

 switchport mode private-vlan promiscuous

 switchport private-vlan mapping 2 201, 202

Securing Switch Access

If an interface is undergoing the restrict or protect condition, we might need to clear the learned MAC addresses so that a specific host can use the switch port. We can clear a MAC address or the complete port cache with the following command:

Switch# clear port-security dynamic [address mac-addr | interface type mod/num]

Checking port states:

show port-security interface

show interfaces status err-disabled

show port-security

=================================================

Steps to enable dot1x authentication:

Switch(config)# aaa new-model

Switch(config)# radius-server host {hostname | ip-address} [key string]

Switch(config)# aaa authentication dot1x default group radius

Switch(config)# dot1x system-auth-control

Switch(config)# interface type mod/num
Switch(config-if)# dot1x port-control {force-authorized | forceunauthorized | auto}

Here, the 802.1x state is one of the following:
force-authorized—The port is forced to always authorize any connected client. No authentication is necessary. This is the default state for all switch ports when 802.1x is enabled.
force-unauthorized—The port is forced to never authorize any connected client. As a result, the port cannot move to the authorized state to pass traffic to a connected client.
auto—The port uses an 802.1x exchange to move from the unauthorized to the authorized state, if successful. This requires an 802.1x-capable application on the client PC.

If the switch should expect to find multiple hosts present on the switch port, use the following interface configuration command:

Switch(config-if)# dot1x host-mode multi-host

Verifying dot1x operations:

show dot1x all

=================================================

DHCP Snooping
When DHCP snooping is enabled, switch ports are categorized as trusted or untrusted. Legitimate DHCP servers can be found on trusted ports, whereas all other hosts sit behind untrusted ports. A switch intercepts all DHCP requests coming from untrusted ports before flooding them throughout the VLAN. Any DHCP replies coming from an untrusted port are discarded because they must have come from a rogue DHCP server. In addition, the offending switch port automatically is shut down in the Errdisable state. DHCP snooping also keeps track of the completed DHCP bindings as clients receive legitimate replies. This database contains the client MAC address, IP address offered, lease time, and so on.

Configuration:

Switch(config)# ip dhcp snooping

Switch(config)# ip dhcp snooping vlan vlan-id [vlan-id]

By default, all switch ports are assumed to be untrusted so that DHCP replies are not expected or permitted. Only trusted ports are allowed to send DHCP replies.

Switch(config)# interface type mod/num 

Switch(config-if)# ip dhcp snooping trust 

For untrusted ports, an unlimited rate of DHCP requests is accepted. If we want to rate-limit DHCP traffic on an untrusted port, use the following interface configuration command: 

Switch(config)# interface type mod/num  

Switch(config-if)# ip dhcp snooping limit rate rate

DHCP option-82 feature is enabled by default. We can enable or disable option-82 globally with the following configuration command:
Switch(config)# [no] ip dhcp snooping information option

Verifying:
Switch# show ip dhcp snooping [binding]
We can use the binding keyword to display all the known DHCP bindings that have been overheard.

Example:

Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan 104
Switch(config)# interface range fastethernet 0/35 – 36
Switch(config-if)# ip dhcp snooping limit rate 3
Switch(config-if)# interface gigabitethernet 0/1
Switch(config-if)# ip dhcp snooping trust

IP Source Guard
IP Source Guard works by making use of the DHCP snooping database and static IP source binding entries. If DHCP snooping is configured and enabled, the switch learns the MAC and IP addresses of hosts that use DHCP. Packets arriving on a switch port can be tested for one of the following conditions:
■ The source IP address must be identical to the IP address learned by DHCP snooping or a static entry. A dynamic port ACL is used to filter traffic. The switch automatically creates this ACL, adds the learned source IP address to the ACL, and applies the ACL to the interface where the address is learned.
■ The source MAC address must be identical to the MAC address learned on the switch port and by DHCP snooping. Port security is used to filter traffic.
If the address is something other than the one learned or statically configured, the switch drops the packet.

For the hosts that do not use DHCP, you can configure a static IP source binding with the following configuration command:
Switch(config)# ip source binding mac-address vlan vlan-id ip-address interface type mod/num
Here, the host’s MAC address is bound to a specific VLAN and IP address, and is expected to be found on a specific switch interface. 

Next, enable IP source guard on one or more switch interfaces with the following configuration commands:

Switch(config)# interface type mod/num

Switch(config-if)# ip verify source [port-security]

Verify the IP source guard status:
Switch# show ip verify source [interface type mod/num]

Dynamic ARP Inspection
When an ARP reply is received on an untrusted port, the switch checks the MAC and IP addresses reported in the reply packet against known and trusted values. A switch can gather trusted ARP information from statically configured entries or from dynamic entries in the DHCP snooping database.
If an ARP reply contains invalid information or values that conflict with entries in the trusted database, it is dropped and a log message is generated. This action prevents invalid or spoofed ARP entries from being sent and added to other machines’ ARP caches.
We can configure DAI by first enabling it on one or more client VLANs with the following configuration command:
Switch(config)# ip arp inspection vlan vlan-range 
By default, all switch ports associated with the VLAN range are considered to be untrusted. We should identify trusted ports as those that connect to other switches.
Switch(config)# interface type mod/num
Switch(config-if)# ip arp inspection trust

If we have hosts with statically configured IP address information, there will be no DHCP message exchange that can be inspected. Instead, we can configure an ARP access list that defines static MAC-IP address bindings that are permitted:
Switch(config)# arp access-list acl-name
Switch(config-acl)# permit ip host sender-ip mac host sender-mac [log]
[Repeat the previous command as needed]
Switch(config-acl)# exit
Now the ARP access list must be applied to DAI with the following configuration command:
Switch(config)# ip arp inspection filter arp-acl-name vlan vlan-range [static]

Finally, we can specify further validations on the contents of ARP reply packets. By default, only the MAC and IP addresses contained within the ARP reply are validated. This doesn’t take the actual MAC addresses contained in the Ethernet header of the ARP reply. To validate that an ARP reply packet is really coming from the address listed inside it, you can enable DAI validation with the following configuration command:
Switch(config)# ip arp inspection validate {[src-mac] [dst-mac] [ip]}

Verification:

show ip arp inspection 

 

SWITCH memo

EtherChannel
PAgP has 2 modes: auto (passive) and desirable (active).
LACP has modes active and passive
In active/desirable switch actively trying to form etherchannel and in auto/passive mode switch waits for the other side to negotiate.

If PAgP configured for a silent auto mode, the link will eventually come up (after bundling it to a port-channel) even without device configured for an etherchannel on the other end of the link. However, the link won't join Port-channel. It will be up, but not as a part of a channel. If the link was configured with silent desirable mode, it will form a channel without hearing any PAgP packet from the opposite side. It allows to form a channel with not a PAgP capable devices like servers etc.
If non-silent command was configured in Switch(config-if)# channel-group number mode {on | {{auto | desirable} [non-silent]}} then it will be required for each port to receive PAgP packets before adding them to a channel. If PAgP isn’t heard on an active port, the port remains in the up state, but PAgP reports to the Spanning Tree Protocol (STP) that the port is down.

If show commands, then show ETHERCHANNEL

If interface command, then int PORT-CHANNEL

If configuration commands, then CHANNEL-XXXX

Spanning Tree Protocol

Catalyst switches offer the PortFast feature, which shortens the Listening and Learning states to a negligible amount of time. When a workstation link comes up, the switch immediately moves the PortFast port into the Forwarding state. Spanning-tree loop detection is still in operation, however, and the port moves into the Blocking state if a loop is ever detected on the port. We can configure PortFast as a global default, affecting all switch ports with a single command. All ports that are configured for access mode (nontrunking) will have PortFast automatically enabled.

The UplinkFast feature on Catalyst switches enables leaf-node switches or switches at the ends of the spanning-tree branches to have a functioning root port while keeping one or more redundant or potential root ports in Blocking mode. When the primary root port uplink fails, another blocked uplink immediately can be brought up for use. UplinkFast works by keeping track of possible paths to the root bridge. Therefore, the command is not allowed on the root bridge switch. The goal is to keep UplinkFast limited to leaf-node switches that are farthest from the root. First, the switch’s bridge priority is raised to 49,152, making it unlikely that the switch will be elected to root bridge status. The port cost of all local switch ports is incremented by 3000, making the ports undesirable as paths to the root for any downstream switches.
When an uplink on a switch goes down, UplinkFast makes it easy for the local switch to update its bridging table of MAC addresses to point to the new uplink. However, UplinkFast also provides a mechanism for the local switch to notify other upstream switches that stations downstream (or within the access layer) can be reached over the newly activated uplink. The switch accomplishes this by sending dummy multicast frames to destination 0100.0ccd.cdcd on behalf of the stations contained in its Content-Addressable Memory (CAM) table. The MAC addresses are used as the source addresses in the dummy frames, as if the stations actually had sent them. The idea is to quickly send the multicast frames over the new uplink, giving upstream hosts a chance to receive the frames and learn of the new path to those source addresses.


BackboneFast works by having a switch actively determine whether alternative paths exist to the root bridge, in case the switch detects an indirect link failure. A switch detects an indirect link failure when it receives inferior BPDUs from its designated bridge on either its root port or a blocked port.
Normally, a switch must wait for the Max Age timer to expire before responding to the inferior BPDUs. However, BackboneFast begins to determine whether other alternative paths to the root bridge exist according to the following port types that received the inferior BPDU:
■ If the inferior BPDU arrives on a port in the Blocking state, the switch considers the root port and all other blocked ports to be alternative paths to the root bridge.
■ If the inferior BPDU arrives on the root port itself, the switch considers all blocked ports to be alternative paths to the root bridge.
■ If the inferior BPDU arrives on the root port and no ports are blocked, however, the switch assumes that it has lost connectivity with the root bridge. In this case, the switch assumes that it has become the root bridge, and BackboneFast allows it to do so before the Max Age timer expires.
If the local switch has blocked ports, BackboneFast begins to use the Root Link Query (RLQ) protocol to see whether upstream switches have stable connections to the root bridge. First, RLQRequests are sent out. If a switch receives an RLQRequest and either is the root bridge or has lost connection to the root, it sends an RLQ Reply. Otherwise, the RLQ Request is propagated on to other switches until an RLQ Reply can be generated. On the local switch, if an RLQ Reply is received on its current root port, the path to the root bridge is intact and stable. If it is received on a nonroot port, an alternative root path must be chosen. The Max Age timer immediately is expired so that a new root port can be found. BackboneFast is simple to configure and operates by short-circuiting the Max Age timer when needed. Although this function shortens the time a switch waits to detect a root path failure, ports still must go through full-length Forward Delay timer intervals during the Listening and Learning states.

When used, BackboneFast should be enabled on all switches in the network because BackboneFast requires the use of the RLQ Request and Reply mechanism to inform switches of Root Path stability.

Root Guard
The Root Guard feature was developed as a means to control where candidate root bridges can be connected and found on a network. Basically, a switch learns the current root bridge’s bridge ID. If another switch advertises a superior BPDU, or one with a better bridge ID, on a port where Root Guard is enabled, the local switch will not allow the new switch to become the root. As long as the superior BPDUs are being received on the port, the port will be kept in the root-inconsistent STP state.When the superior BPDUs no longer are received, the port is cycled through the normal STP states to return to normal use.

BPDU Guard should be used along with PortFast feature, to prevent inadvertent connection of bridging devices to an access port. However, BPDU Guard won't prevent loops, if non-STP capable device is connected to a port. BPDU Guard feature puts port to a err-disable state, if BPDU is received on a port.

Why is it so terrifying to get a bridge or switch on a Portfast enabled port? It is because port will transition from a blocking to a forwarding state without any delay (forward delay, max age etc), so a bridging loop might occur. That's why Portfast enabled ports should be "guarded" by a BPDU Guard feature (Guard enables on a port as soon as Portfast is enabled). When the BPDUs no longer are received, the port still remains in the errdisable state.

UDLD and LoopGuard. Suppose, the switch port is in Blocking state and it receives BPDU's from a designated port on a segment. If, BPDU's stop arrive, then switch assumes, that there is no STP device on that segment (like PC is connected), so it can safely move it to Forwarding state and make it designated on this segment. However, suppose, that something filtering BPDU's on their way to the switch, but there is still a device actively sending them on the opposite side of the link. This means, that switch should NOT transit port from a blocking to a forwarding state, however it will happen if LoopGuard feature isn't enabled on this port.
When enabled, LoopGuard keeps track of the BPDU activity on nondesignated ports. This feature will move port to a loop-inconsistent state if BPDU's go missing (effectively preventing loops to occur). After BPDU's are received on a port again, Loop Guard allows to port to move through the normal STP states and become active.
UDLD works like pings on fiber-optic links where link can become partly damaged and become unidirectional. So on the one side switch could stop to receive BPDU's, however it can send data across the link. A unidirectional link poses a potential danger to STP topologies because BPDUs will not be received on one end of the link. If that end of the link normally would be in the Blocking state, it will not be that way for long. A switch interprets the absence of BPDUs to mean that the port can be moved safely through the STP states so that traffic can be forwarded. However, if that is done on a unidirectional link, a bridging loop forms and the switch never realizes the mistake.
The objective behind UDLD is to detect a unidirectional link condition before STP has time to move a blocked port into the Forwarding state. To do this, the target time must be less than the Max Age timer plus two intervals of the Forward Delay timer, or 50 seconds. UDLD can detect a unidirectional link after about three times the UDLD message interval (45 seconds total, using the default). If none of those messages is echoed back, the port is placed in the Errdisable state so that it cannot be used (in case of aggressive mode, otherwise syslog message is generated).

HSRP/VRRP/GLBP
HSRP. Only the standby (the one with the second-highest priority) router monitors the hello messages from the active router.
HSRP mac address 0000.0c07.acxx, where xx represents the HSRP group number as a two-digit hex value. HSRP sends its hello messages to the multicast destination 224.0.0.2 (“all routers”) using UDP port 1985. Priority and group numbers:

• 0 to 255

VRRP MAC address is of the form 0000.5e00.01xx, where xx is a two-digit hex VRRP group number. VRRP sends its adverts to the multicast destination address 224.0.0.18 (VRRP), using IP protocol 112. Priority and group numbers:

•  group numbers range from 0 to 255;  priorities range from 1 to 254.

AVG sends periodic hello messages to each of the other GLBP peers. In addition, it expects to receive hello messages from each of them.
GLBP MAC addresses always have the form 0007.b4xx.xxyy. The 16-bit value denoted by xx.xx represents six zero bits followed by a 10-bit GLBP group number. The 8-bit yy value is the virtual forwarder number. Priority and group numbers

• group numbers range from 0 to 1023. Priority can be 1 to 255
• The maximum weight can range from 1 to 254 (default 100).

SWITCH Commands

Here I am going to post configurations commands related to the certain exam topics.

■ Vlan trunking configuration

Switch(config)# interface type mod/port

Switch(config-if)# switchport

Switch(config-if)# switchport trunk encapsulation {isl | dot1q | negotiate}

Switch(config-if)# switchport trunk native vlan vlan-id

Switch(config-if)# switchport trunk allowed vlan {vlan-list | all | {add | except | remove} vlan-list}

Switch(config-if)# switchport mode {trunk | dynamic {desirable | auto}}

If you decide to configure both ends of a trunk link as a fixed trunk (switchport mode trunk), you can disable DTP completely so that these frames are not exchanged. To do this, add the switchport nonegotiate command to the interface configuration.

■VTP should be in a first section, but i guess, that it's easy enough to configure it.

vtp mode server

vtp password SECRET

vtp version 1/2

vtp domain DOMAIN

Troubleshooting:

show vtp status

show vtp password

 
■EtherChannel
Load-balance distribution:

port-channel load-balance  METHOD

The following methods exist:

 PAgP configuration:
Switch(config)# interface type mod/num 
Switch(config-if)# channel-protocol pagp
Switch(config-if)# channel-group number mode {on | {{auto | desirable} [non-silent]}}
By default, PAgP operates in silent submode. The silent submode listens for any PAgP packets from the far end, looking to negotiate a channel. If none is received, silent submode assumes that a channel should be built anyway, so no more PAgP packets are expected from the far end.
Even if the two interfaces are using PAgP auto silence mode, the link will still eventually come up, although not as a channel.

LACP configuration:

Switch(config)# lacp system-priority priority
Switch(config)# interface type mod/num
Switch(config-if)# channel-protocol lacp
Switch(config-if)# channel-group number mode {on | passive | active}
Switch(config-if)# lacp port-priority priority

First, the switch should have its LACP system priority defined (1 to 65,535; default 32,768). If desired, one switch should be assigned a lower system priority than the other so that it can make decisions about the EtherChannel’s makeup. We can configure more interfaces in the channel group number than are allowed to be active in the channel. This prepares extra standby interfaces to replace failed active ones. The lacp port-priority command allows us to configure a lower port priority (1 to 65,535; default 32,768) for any interfaces that must be active, and a higher priority for interfaces that might be held in the standby state. Otherwise, we can use the default scenario, in which all ports default to 32,768 and the lower port numbers (in interface number order) are used to select the active ports.
Troubleshooting:

show etherchannel port-channel
show etherchannel summary
show etherchannel load-balance

■Spanning Tree Protocol
We can configure PortFast as a global default, affecting all switch ports with a single command. All ports that are configured for access mode (nontrunking) will have PortFast automatically enabled.

Switch(config)# spanning-tree portfast default

Switch(config)# spanning-tree uplinkfast [max-update-rate pkts-per-second]

Switch(config)# spanning-tree backbonefast

Switch(config-if)# spanning-tree guard root
Switch(config)# spanning-tree portfast bpduguard default
Switch(config-if)# [no] spanning-tree bpduguard enable
Switch(config)# spanning-tree loopguard default
Switch(config-if)# [no] spanning-tree guard loop
Switch(config)# udld {enable | aggressive | message time seconds}

Switch(config-if)# udld {enable | aggressive | disable}
Switch(config)# spanning-tree portfast bpdufilter default
Switch(config-if)# spanning-tree bpdufilter {enable | disable}
The default keyword indicates that BPDU filtering will be enabled automatically on all ports that have PortFast enabled. If PortFast is disabled on a port, then BPDU filtering will not be enabled there.

Troubleshooting

Switch# show spanning-tree

Switch# show spanning-tree detail

Switch# show spanning-tree [vlan vlan-id] summary

Switch# show spanning-tree [vlan vlan-id] root

Switch# show spanning-tree [vlan vlan-id] bridge

Switch# show spanning-tree interface type port

Switch# show spanning-tree uplinkfast/backbonefast

We can display switch ports that Root Guard (and not only Root Guard) has put into the root-inconsistent state with the following command: 

Switch# show spanning-tree inconsistentports
Switch# show udld [type mod/num]
Switch# udld reset - reenable ports that UDLD aggressive mode has errdisabled.

Very useful commands not only for spanning tree:

Router#show int status

Router#show int status err-disabled

MST - ?

■HSRP

Switch(config-if)# standby group priority priority
Switch(config-if)# standby group timers [msec] hello [msec] holdtime
Switch(config-if)# standby group preempt [delay [minimum seconds] [reload seconds]]
Switch(config-if)# standby group authentication string   - plain text auth
Switch(config-if)# standby group authentication md5 key-string [0 | 7] string
Switch(config-if)# standby group track type mod/num [decrementvalue]
Switch(config-if)# standby group ip ip-address [secondary]

Troubleshooting

Router# show standby [brief] [vlan vlan-id | type mod/num] 

■VRRP

Troubleshooting

Switch# show vrrp [brief]

■GLBP

Switch(config-if)# glbp group priority level

Switch(config-if)# glbp group preempt [delay minimum seconds]

Hello messages are sent at hellotime intervals, with a default of 3 seconds. If hellos are not received from a peer within a holdtime, defaulting to 10 seconds, that peer is presumed to have failed.

Switch(config-if)# glbp group timers [msec] hellotime [msec] holdtime

The redirect timer is used to determine when the AVG will stop using the old virtual MAC address in ARP replies. The AVF corresponding to the old address continues to act as a gateway for any clients that try to use it.
When the timeout timer expires, the old MAC address and the virtual forwarder using it are flushed from all the GLBP peers. The AVG assumes that the previously failed AVF will not return to service, so the resources assigned to it must be reclaimed.

Switch(config-if)# glbp group timers redirect redirect timeout

GLBP also can use a weighting function to determine which router becomes the AVF for a virtual MAC address in a group. Each router begins with a maximum weight value (1 to 254). As specific interfaces go down, the weight is decreased by a configured amount. GLBP uses thresholds to determine when a router can and cannot be the AVF. If the weight falls below the lower threshold, the router must give up its AVF role. When the weight rises above the upper threshold, the router can resume its AVF role. By default, a router receives a maximum weight of 100. If you want to make a dynamic weighting adjustment, GLBP must know which interfaces to track and how to adjust the weight.

Switch(config)# track object-number interface type mod/num {line-protocol | ip routing}

The maximum weight can range from 1 to 254 (default 100).

Switch(config-if)# glbp group weighting maximum [lower lower] [upper upper]

Switch(config-if)# glbp group weighting track object-number [decrement value]

Switch(config-if)# glbp group load-balancing [round-robin | weighted | hostdependent]

Switch(config-if)# glbp group ip [ip-address [secondary]]

Troubleshooting

show glbp [brief]

■Using ACL's in a switch

vlan access-map map-name [sequence]

 math {ip | mac} {acl-name | acl - number}

 action {drop | forward | redirect type mod/num}

 exit

vlan filter map-name vlan-list vlan-list

Troubleshooting:

show vlan filter

show vlan access-map