I came across this great outline for the Routing and Switching Lab Exam.  I’ve printed out a copy and will use it for a guide to make sure I haven’t forgotten anything.   I also plan to add to it as I find things.

WRED can be IP Precedence or DSCP based (default is precedence).  First choose which one is appropriate

To enable WRED on an interface:

Router(config-if)# random-detect [dscp-based | prec-based]

Decide if it’s flow based:

Router(config-if)# random-detect flow

Next, make any changes to the minimum and maximum thresholds and the mark probability denominator:

Router(config-if)# random-detect dscp dscp-value min-threshold max-threshold [max-probability-denominator]

or

Router(config-if)# random-detect precedence {precedence | rsvp} min-threshold max-threshold max-probability-denominator

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Verify WRED with:

Router# show queueing interface

CAR is a way to police traffic coming into or out of an interface (it’s a single bucket, two-color policer).  It’s being replaced by the police command within the MQC but I guess it can still appear on the lab exam.  Here’s the deal:  Within an interface, you can configure a number of these ‘rate-limit’ commands which amount to the selecting of a set of traffic defined by an ACL, qos group, or dscp value.  It then sets the average rate, the burst rate and the excess burst rate for the traffic and performs an action on the traffic that conforms to that rate or exceeds that rate. Here’s the syntax:

Router(config-if)# rate-limit {input | output} {bps | access-group acl-index | [rate-limit] rate-limit-acl-index] | dscp dscp-value | qos-group qos-group-number} burst-normal burst-max conform-action conform-action exceed-action exceed-action

The actions can be one of the following:

•continue—Evaluate the next rate-limit command.
•drop—Drop the packet.
•set-dscp-continue—Set the differentiated services codepoint (DSCP) (0 to 63) and evaluate the next rate-limit command.
•set-dscp-transmit—Transmit the DSCP and transmit the packet.
•set-mpls-exp-imposition-continue—Set the Multiprotocol Label Switching (MPLS) experimental bits (0 to 7) during imposition and evaluate the next rate-limit command.
•set-mpls-exp-imposition-transmit—Set the MPLS experimental bits (0 to 7) during imposition and transmit the packet.
•set-prec-continue—Set the IP precedence (0 to 7) and evaluate the next rate-limit command.
•set-prec-transmit—Set the IP precedence (0 to 7) and transmit the packet.
•set-qos-continue—Set the quality of service (QoS) group ID (1 to 99) and evaluate the next rate-limit command.
•set-qos-transmit—Set the QoS group ID (1 to 99) and transmit the packet.
•transmit—Transmit the packet.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

You can verify CAR with the following command:

Router# show interfaces rate-limit

I ran into a problem where the MTU difference was giving OSPF problems.  One of the parameters that must match for an OSPF adjacency to form is the MTU.  As is documented here this can be an issue.  It looks like the default MTU for a Cisco 3550 is 1503 unless someone knows otherwise (I don’t have a 3550 handy).

You can make a router join a specific multicast group to verification purposes.  This is great for testing in the lab:

First, join an interface to the group:

Router(config-if)# ip igmp join-group group-address [source source-address]

Now if you ping the group address from another router, you should be able to verify correct configuration using the ’show ip mroute’ command.  Remember that if you’ve joined the group and specified a specific source, you’ll only get a response when you ping from that source.

To enable a router to support Source Specific Multicast (SSM), you need to do two things:

1) Enable IGMPv3

Router(config-if)# ip igmp version 3

2) Enable SSM

Router(config)# ip pim ssm {default | range access-list}

Use default to use the standard SSM range of 232.0.0.0/8 or use an ACL to allow a different range of multicast addresses

First, enable multicast routing:

Router(config)# ip multicast-routing

Next, you must make sure that there is multicast connectivity between all of the nodes within the multicast network.  This can get a little tricky for a couple of reasons:

1) Frame-relay must support the multicasting between spoke nodes.  Either inverse-arp is enabled with dynamic mapping or make sure you have the mapping statically configured with the broadcast flag

2) The sparse-dense problem.  For RP mapping to occur using autoRP, the two multicast group which are utilized must be in dense mode.  Remember that autoRP is used to dynamically discover RPs.  If the autoRP mapping agent sends out the mappings, it must flood them to the multicast network otherwise the RP will have to be known before anyone can join that group.  Obviously there’s some recursion there, so to avoid this, make sure one of the following is going on: dense mode or sparse-dense mode is enabled on all interfaces OR configure ‘ip pim autorp listener‘ in global config mode.

Router(config-if)# ip pim sparse-dense-mode

or

Router(config)# ip pim autorp listener

Configure the RP to send out announcements that it’s the RP (these are sent to group 224.0.1.239):

Router(config)# ip pim send-rp-announce {interface-type interface-number | ip-address} scope ttl-value [group-list access-list] [interval seconds] [bidir]

NOTE:  Make sure if you’re using the sparse-dense method, that the interface that is configured to source these announcements has the ip pim sparse-dense-mode configured.

Now, configure the mapping agent to send out the announcements:

Router(config)# ip pim send-rp-discovery [interface-type interface-number] scope ttl-value [interval seconds]

If needed, you can filter certain nodes from becoming the RP for a group.  This is done on the mapping agent with the following command:

Router(config)# ip pim rp-announce-filter rp-list access-list group-list access-list

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Verification of autoRP

Router(config)# show ip pim rp mapping

A guest VLAN on an 802.1x enabled port is used for devices which are not 802.1x compatible.  If the switch doesn’t receive any reponse to it’s EAP messages toward the client, the client is placed in the guest vlan.  This configured as follows:

Switch(config-if)# dot1x guest-vlan vlan-id

There’s a number of commands to enable 802.1X on a switch:

First turn on aaa:

Switch(config)# aaa new-model

Tell aaa how to authentication dot1x:

Switch(config)# aaa authentication dot1x {default} method1

Enable 802.1x on the switch:

Switch(config)# dot1x system-auth-control

You can add an optional authorization mechanism which authorizes network level service requests:

Switch(config)# aaa authorization network {default} group radius

Finally, within the interface upon which 802.1X is going to be configured, set the dot1x status of the port:

Switch(config-if)# dot1x port-control auto

NOTE:  This configuration set assumes that a radius server has been configured using the “radius-server” commands.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Verification of 802.1X status:

Switch# show dot1x

and

Switch# show dot1x interface interface-id

That’s a convoluted way of saying that you can selectively change the administrative distance of learned OSPF routes on a router.  Check it out:

R6 is learning OSPF routes from R5 (amongst other things).  Of course by default, OSPF’s “trust level” or administrative distance is 110.  So all learned OSPF routes are going to have an administrative distance of 110:

Gateway of last resort is not set

145.55.0.0/16 is variably subnetted, 6 subnets, 5 masks
O    145.55.136.5/32 [110/64] via 145.55.156.5, 00:00:05, Serial0/1
                     [110/64] via 145.55.136.5, 00:00:05, Serial0/0
O    145.55.136.3/32 [110/128] via 145.55.156.5, 00:00:05, Serial0/1
                     [110/128] via 145.55.136.5, 00:00:05, Serial0/0
C    145.55.136.0/29 is directly connected, Serial0/0
C    145.55.156.0/22 is directly connected, Serial0/1
O    145.55.25.0/24 [110/65] via 145.55.156.5, 00:00:05, Serial0/1
                    [110/65] via 145.55.136.5, 00:00:05
                    [110/65] via 145.55.136.5, 00:00:05, Serial0/0
C    145.55.64.0/19 is directly connected, FastEthernet0/0
O    192.168.5.0/24 [110/65] via 145.55.156.5, 00:00:05, Serial0/0
                    [110/65] via 145.55.136.5, 00:00:05, Serial0/0
C    192.168.6.0/24 is directly connected, Loopback1
O    192.168.2.0/24 [110/66] via 145.55.156.5, 00:00:05, Serial0/1
                    [110/66] via 145.55.136.5, 00:00:05
                    [110/66] via 145.55.136.5, 00:00:05, Serial0/0
O    192.168.3.0/24 [110/129] via 145.55.156.5, 00:00:05, Serial0/1
                    [110/129] via 145.55.136.5, 00:00:05, Serial0/0
R6#

To change the administrative distance of one route, let’s choose the 192.168.5.0/24 route, you can apply the distance router command (this command isn’t OSPF specific, it’s for all IP routing protocols):

distance {ip-address {wildcard-mask}} [ip-standard-list] [ip-extended-list]

So by applying the following commands, we can change the administrative distance to 50:

R6(config)#ip access-list standard AD_Change
R6(config-std-nacl)#permit 192.168.5.0 0.0.0.255
R6(config-std-nacl)#
R6(config-std-nacl)#router ospf 67
R6(config-router)#distance 50 5.5.5.5 0.0.0.0 AD_Change

5.5.5.5 is the router which is sourcing the routes that we’d like to change and 0.0.0.0 means that we want to only match 5.5.5.5.  Now check it out:

Gateway of last resort is not set
145.55.0.0/16 is variably subnetted, 6 subnets, 5 masks
O    145.55.136.5/32 [110/64] via 145.55.156.5, 00:01:04, Serial0/1
                     [110/64] via 145.55.136.5, 00:01:04, Serial0/0
O    145.55.136.3/32 [110/128] via 145.55.156.5, 00:01:04, Serial0/1
                     [110/128] via 145.55.136.5, 00:01:04, Serial0/0
C    145.55.136.0/29 is directly connected, Serial0/0
C    145.55.156.0/22 is directly connected, Serial0/1
O    145.55.25.0/24 [110/65] via 145.55.156.5, 00:01:04, Serial0/1
                    [110/65] via 145.55.136.5, 00:01:04
                    [110/65] via 145.55.136.5, 00:01:04, Serial0/0
C    145.55.64.0/19 is directly connected, FastEthernet0/0
O    192.168.5.0/24 [50/65] via 145.55.156.5, 00:01:04, Serial0/1
                    [50/65] via 145.55.136.5, 00:01:04, Serial0/0
C    192.168.6.0/24 is directly connected, Loopback1
O    192.168.2.0/24 [110/66] via 145.55.156.5, 00:01:05, Serial0/1
                    [110/66] via 145.55.136.5, 00:01:05
                    [110/66] via 145.55.136.5, 00:01:05, Serial0/0
O    192.168.3.0/24 [110/129] via 145.55.156.5, 00:01:05, Serial0/1
                    [110/129] via 145.55.136.5, 00:01:05, Serial0/0
R6#