BSCI Preparation

OSPF network types:

OSPF defaults to point-to-point mode on the point-to-point subinterface and to nonbroadcast mode on the multipoint subinterface.

LSA Type 3: Summary LSA
The ABR sends type 3 summary LSAs. A type 3 LSA advertises any networks owned by an area to the rest of the areas in the OSPF autonomous system.

LSA Type 4: Summary LSA
A type 4 summary LSA is used only when an ASBR exists within an area. A type 4 LSA identifies the ASBR and provides a route to it. The link-state ID is set to the ASBR’s router ID. When an ABR receives a type 1 LSA from an ASBR, it sends out a type 4 summary LSA to advertise the presence of the ASBR to other areas.

Summary LSAs do not, by default, contain summarized routes. Therefore, by default, all subnets in an area will be advertised.

LSA Type 5: External LSA
Type 5 external LSAs describe routes to networks outside the OSPF autonomous system. Type 5 LSAs are originated by the ASBR and are flooded to the entire autonomous system.

Route summarization on ABR:

area area-id range address mask [advertise | not-advertise] [cost cost]

Route summarization on ASBR:

summary-address ip-address mask [not-advertise] [tag tag]

Areas
To configure stub area - use area area-id stub router configuration command.
To configure totally stub area - use no-summary parameter to the area area-id stub command at the ABR only!
To configure NSSA area, area area-id nssa [no-redistribution] [default-informationoriginate] [metric metric-value] [metric-type type-value] [no-summary] command is used.
Configuring OSPF Virtual Links

area area-id virtual-link router-id

area-id parameter is a number of an area where router-id resides.
OSPF authentication:
interface Serial0/0/1
ip address 192.168.1.101 255.255.255.224
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 secretpass


EIGRP

Hello timer on fast links - 5 seconds, on slow link (
Hold timer X3 hello timer, by default. Doesn't reflect the change of hello timer.

To pass default route ip default-network network-number must be used

When you configure the ip default-network command and specify a subnet, a static route (the ip route command) is generated in the router’s configuration; This can be confusing when you want to remove the default network; the configuration must be removed with the no ip route command, not with the no ip default-network command.

Summarization (same as RIP)

ip summary-address eigrp as-number address mask [admin-distance] interface configuration command.

Authentication
ip authentication mode eigrp 100 md5
ip authentication key-chain eigrp 100 R1chain

Quote:
1. A remote router extends the query about a network only if it has an exact match in the routing table.
2. Stub routers are not queried. Instead, hub routers connected to the stub router answer the query on behalf of the stub router.

Stub routers.
To configure a router as an EIGRP stub, use the eigrp stub [receive-only | connected | static |summary] router configuration command. A router configured as a stub with this command shares information about connected and summary routes with all neighbor routers by default.
The connected keyword permits the EIGRP stub routing feature to send connected routes. If a network command does not include the connected routes, it might be necessary to redistribute connected routes with the redistribute connected command under the EIGRP process.
The static keyword permits the EIGRP stub routing feature to send static routes. Redistributing static routes with the redistribute static command is still necessary.

IS IS
Level 1 intra-area routing is based on system IDs;
The area address is used to route between areas; the system ID is not considered.
The system ID is used to route within an area; the area address is not considered.

Routers on a LAN establish adjacencies with all other routers on the LAN.

Criteria for DIS selection are, first, highest priority and second, highest SNPA (recall that on LANs the SNPA is the MAC address). Cisco router interfaces have a default L1 and L2 priority of 64.


LSPs on broadcast media (LANs) are sent as multicast, and LSPs on point-to-point links are sent
as unicast.

Routers calculate ES reachability with a partial route calculation (PRC), based on the L1 and L2 SPF trees.

Example:

R2(config)#router isis

R2(config-router)#net 49.0001.0000.0000.0002.00

R2(config-router)#is-type {level-1 | level-1-2 | level-2-only}

R2(config)#interface FastEthernet0/0

R2(config-if)#ip router isis

R2(config-if)#isis circuit-type level-1

R2(config)#interface serial 0/0/1

R2(config-if)#ip router isis

R2(config-if)#isis circuit-type level-2-only

R2(config-if)#isis metric 35 level-2

R2(config-router)#summary-address address mask [level-1 | level-2 | level-1-2] [tag tag-number] [metric metric-value] router configuration command.

The summary-address command works on all IS-IS routers (L1 and L2), but it will only summarize the external IS-IS L1 routes (routes that were redistributed into IS-IS L1).

Manipulating routing updates

Routes must be in the routing table for them to be redistributed.
The default-metric router configuration command establishes the seed metric for all redistributed routes. Cisco routers also allow the seed metric to be specified as part of the redistribute command, either with the metric option or by using a route map.

When redistributing routing information, set the seed metric to a value larger than the largest metric within the receiving autonomous system, to help prevent suboptimal routing and routing loops.

The redistribute Command for RIP (EIGRP is the same)
Use the redistribute protocol [process-id] [match route-type] [metric metric-value] [route-map map-tag] router configuration command to redistribute routes into RIP.
When redistributing into RIP, the default metric is infinity except when redistributing a static route (including a default static route defined using the ip route 0.0.0.0 0.0.0.0 command) or connected route. In that case, the default metric is 1.
When redistributing a static or connected route into EIGRP, the default metric is equal to the metric of the associated static or connected interface.
The redistribute Command for OSPF
Use the redistribute protocol [process-id] [metric metric-value] [metric-type type-value] [route-map map-tag] [subnets] [tag tag-value] router configuration command to redistribute routes into OSPF.
When redistributing into OSPF, the default metric is 20, the default metric type is 2, and subnets are not redistributed by default.

The redistribute Command for IS-IS
Use the redistribute protocol [process-id] [level level-value] [metric metric-value] [metric-type type-value] [route-map map-tag] router configuration command to redistribute routes into IS-IS.
By default, routes are introduced into IS-IS as Level 2, with a metric of 0.

Default Routes and Routing Protocols
The ip default-network command is used to distribute default route information to other routers. For RIP, this command provides no functionality for the router on which it is configured.

For example, EIGRP does not redistribute the 0.0.0.0 0.0.0.0 default route by default. However, if the network 0.0.0.0 command is added to the EIGRP configuration, it redistributes a default route as a result of the ip route 0.0.0.0 0.0.0.0 interface command (but not as a result of the ip route 0.0.0.0 0.0.0.0 address or ip default-network commands).


Distribute Lists
(config-router)#distribute-list 7 out Serial0/0/0
!
access-list 7 permit 172.16.0.0 0.0.255.255
Route Maps
1. Only one condition listed on the same match statement must match for the entire statement to be considered a match.
2. However, all match statements within a route map statement must match for the route map to be considered matched.

BGP
BGP specifies that a BGP router can advertise to its peers in neighboring autonomous systems only those routes that it uses. This rule reflects the hop-by-hop routing paradigm generally used throughout the current Internet.
BGP does not let one AS send traffic to a neighboring AS, intending that the traffic take a different route from that taken by traffic originating in the neighboring AS.

To avoid routing loops within an AS, BGP specifies that routes learned through IBGP are never propagated to other IBGP peers.
By fully meshing all IBGP neighbors, when a change is received from an external AS, the BGP router for the local AS is responsible for informing all other IBGP neighbors of the change. IBGP neighbors that receive this update do not send it to any other IBGP neighbor, because they assume that the sending IBGP neighbor is fully meshed with all other IBGP speakers and has sent each IBGP neighbor the update.

The BGP synchronization rule states that a BGP router should not use, or advertise to an external
neighbor, a route learned by IBGP, unless that route is local or is learned from the IGP.

BGP sends BGP/TCP keepalives by default every 60 seconds.
The default hold time is 180 seconds.

BGP defines the following message types:
■ Open
■ Keepalive
■ Update
■ Notification

The attributes defined by BGP include the following:
■ Well-known mandatory attributes:
— AS-path
— Next hop
— Origin
■ Well-known discretionary attributes:
— Local preference
— Atomic aggregate
■ Optional transitive attributes:
— Aggregator
— Community
■ Optional nontransitive attribute:
— Multiexit-discriminator (MED)
In addition, Cisco has defined a weight attribute for BGP. The weight is configured locally on a router and is not propagated to any other BGP routers.

BGP Path Selection
0. Synchronized
1. Weight
2. Local Preference
3. Self Originated
4. AS-Path
5. Origin
6. MED
7. External (eBGP>iBGP)
8. IGP Cost
9. eBGP peering (oldest)
10. RID

EBGP Next Hop
For EBGP, the next hop is the IP address of the neighbor that sent the update.
IBGP Next Hop
For IBGP, the protocol states that the next hop advertised by EBGP should be carried into IBGP. It is very important, therefore, that Router C knows how to reach the subnet, advertised via IBGP as next-hop, either via an IGP or a static route; otherwise, it will drop packets because it will not be able to get to the next-hop address for that network. The IBGP neighboring router performs a recursive lookup to find out how to reach the BGP next-hop address by using its IGP entries in the routing table.

The MED indicates to external neighbors the preferred path into an AS. This is a dynamic way for an AS to try to influence another AS as to which way it should choose to reach a certain route if there are multiple entry points into the AS.
Unlike local preference, the MED is exchanged between autonomous systems. The MED is sent to EBGP peers; those routers propagate the MED within their AS, and the routers within the AS use the MED, but do not pass it on to the next AS.

Paths that the router originates have a weight of 32768 by default, and other paths have a weight of 0 by default.

Network command
The BGP network command determines which networks this router advertises. The list of network commands must include all networks in your AS that you want to advertise, not just those locally connected to your router. Note that the prefix must exactly match (address and mask) an entry in the IP routing table.
 If you configure network 192.168.0.0 mask 255.255.0.0 to advertise a CIDR block, BGP looks for 192.168.0.0/16 in the routing table. It might find 192.168.1.0/24 or 192.168.1.1/32; however, if it never finds 192.168.0.0/16, BGP does not announce the 192.168.0.0/16 network to any neighbors. In this case, you can configure the static route ip route 192.168.0.0 255.255.0.0 null0 toward the null interface so that BGP can find an exact match in the routing table.

Example:

router bgp 65000

neighbor 10.1.1.2 remote-as 64520

neighbor 192.168.2.2 remote-as 65000

neighbor 192.168.2.2 update-source loopback 0

neighbor 192.168.2.2 next-hop-self

network 172.16.10.0 mask 255.255.255.0

network 192.168.1.0

network 192.168.3.0

Example2. Influencing traffic entrance to AS:

neighbor 192.168.28.1 route-map med_65004 out
!
route-map med_65004 permit 10
match ip address 66
set metric 100
route-map med_65004 permit 100
set metric 200

Example3 Influencing outbound traffic:

neighbor 192.168.28.1 remote-as 65002
neighbor 192.168.28.1 route-map local_pref in
!
route-map local_pref permit 10
match ip address 65
set local-preference 400
!
route-map local_pref permit 20
!
access-list 65 permit 172.30.0.0 0.0.255.255

Configuring Weight
neighbor {ip-address | peer-group-name} weight weight router configuration command.
Local Preference
Router(config-router)# bgp default local-preference value
MED
Router(config-router)# default-metric value



Multicast

Link-local addresses (224.0.0.0/24);
Source-specific multicast (232.0.0.0/8);
GLOP (233.0.0.0/8);
Administratively scoped addresses (239.0.0.0/8) - private;
Globally scoped addresses (224.0.1.0–231.255.255.255 and 234.0.0.0–238.255.255.255)

IGMP
ip igmp snooping
ip igmp version {1 | 2 | 3}

ip multicast-routing global configuration command

ip pim sparse-dense-mode interface configuration command

ip pim send-rp-announce interface type scope ttl group-list access-list global configuration command on a router that you want to be an RP.
ip igmp join-group group-address interface configuration command. With this command, the router joins the specified group; the router accepts multicast packets in addition to forwarding them.
ip igmp static-group group-address interface configuration command. With this command, the router itself is a statically connected member of the group. The router does not accept the group’s packets itself, but only forwards them.

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

BSCI topics

Implement EIGRP operations

• Explain the functions and operations of EIGRP (e.g., DUAL).
  
• Configure EIGRP routing. (e.g., Stub Routing, authentication, etc.)
  
• Verify or troubleshoot EIGRP routing configurations.
  

Implement multiarea OSPF operations

• Explain the functions and operations of multiarea OSPF.
  
• Configure multiarea OSPF routing. (e.g., Stub, NSSA, authentication, etc.)
  
• Verify or troubleshoot multiarea OSPF routing configurations.
  

Describe integrated IS-IS

• Describe the features and benefits of integrated IS-IS.
  
• Configure and verify integrated IS-IS.
  

Implement Cisco IOS routing features

• Describe, configure or verify route redistribution between IP routing IGPs. (e.g., route-maps, default routes, etc.)
  
• Describe, configure or verify route filtering (i.e., distribute-lists and passive interfaces).
  
• Describe and configure DHCP services (e.g., Server, Client, IP helper address, etc.).
  

Implement BGP for enterprise ISP connectivity

• Describe the functions and operations of BGP.
  
• Configure or verify BGP operation in a non-transit AS (e.g., authentication).
  
• Configure BGP path selection. (i.e., Local Preference, AS Path, Weight or MED attributes).
  

Implement multicast forwarding

• Describe IP Multicast (e.g., Layer-3 to Layer-2 mapping, IGMP, etc.).
  
• Describe, configure, or verify IP multicast routing (i.e., PIM Sparse-Dense Mode).
  

 Implement IPv6

• Describe IPv6 addressing operations.
  
• Describe IPv6 interoperation with IPv4.
  
• Describe, configure or verify OSPF routing with IPv6 addressing.