Solution.

CCIE Routing & Switching Lab Workbook Volume I Solutions Guide Lab 1

Copyright © 2005 Internetwork Expert www.InternetworkExpert.com1 - 1

1. Catalyst 3550 Task 1.1 SW1: vtp domain CISCO vtp mode server vtp password CISCO vlan 2,6,33,45,46,58,82 ! interface FastEthernet0/1 no switchport ip address 183.1.17.7 255.255.255.0 ! interface FastEthernet0/2 switchport access vlan 2 ! interface FastEthernet0/3 switchport access vlan 33 ! interface FastEthernet0/4 switchport access vlan 45 ! interface FastEthernet0/5 switchport access vlan 58 ! interface FastEthernet0/6 switchport access vlan 46 ! interface FastEthernet0/10 switchport access vlan 2 ! interface FastEthernet0/11 switchport access vlan 2 ! interface FastEthernet0/14 no switchport ip address 183.1.78.7 255.255.255.0 ! interface FastEthernet0/15 switchport access vlan 58 ! interface FastEthernet0/24 switchport access vlan 33

Quick Note VTP mode command is optional as the default VTP mode is server.



SW2: vtp domain CISCO vtp mode server vtp password CISCO ! interface FastEthernet0/4 switchport access vlan 46 ! interface FastEthernet0/5 switchport access vlan 45 ! interface FastEthernet0/6 switchport access vlan 6 ! interface FastEthernet0/14 no switchport ip address 183.1.78.8 255.255.255.0 ! interface FastEthernet0/15 no switchport ip address 183.1.58.8 255.255.255.0 ! interface FastEthernet0/24 switchport access vlan 82 ! interface Vlan82 ip address 192.10.1.8 255.255.255.0 Task 1.1 Breakdown The first step in configuring VLAN Trunking Protocol (VTP) is to define the VTP domain name. This is accomplished by issuing the vtp domain [name] command in either the vlan database or global configuration mode. By default, the VTP domain is NULL. Configuring the VTP domain name on either SW1 or SW2 will result in the opposite switch inheriting the VTP domain name. Therefore it is only necessary to configure the VTP domain name on one switch. Also note that the VTP mode on both switches will default to server. The next step is to define the VTP password. This is accomplished by issuing the vtp password [password] command on both switches. Finally, the VLANs must be defined. Since both SW1 and SW2 are VTP servers, this step may be performed on either switch. To define a VLAN, issue the VLAN [vlan] command in either the VLAN database or global configuration mode. In order to verify the above configuration, issue the show vtp status command. To check whether VTP is properly configured, ensure that the domain names are identical, the MD5 hash value of the VTP passwords are the same, and the configuration revision number matches.

Quick Note VTP mode command is optional as the default VTP mode is server.



In addition to access ports and trunk ports, some interfaces in the VLAN assignment table are listed as ‘routed’ and ‘VLAN’ interfaces. The Catalyst 3550 series switch is a layer 3 switch and defines three different interface types: switchports, routed ports, and switched-virtual interfaces (SVIs). ‘Switchports’ include layer 2 access, trunk, and tunnel ports. The default mode for all interfaces on the 3550 is to be a dynamic desirable layer 2 switchport. ‘Routed’ ports are native layer 3 interfaces, and can be directly configured with IP. To configure a routed interface, issue the no switchport command on the interface. Lastly, a ‘switched virtual interface’ (SVI) is a logical layer 3 interface that represents a domain of switchports. SVIs are used to configure inter-VLAN routing. To configure an SVI, simply issue the interface vlan [vlan] command in global configuration mode.

Further Reading

Understanding and Configuring VLAN Trunk Protocol (VTP) Configuring Inter-VLAN Routing on the Catalyst 3550 Series Switch

http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080094c52.shtml

http://www.cisco.com/en/US/tech/tk389/tk815/technologies_configuration_example09186a008015f17a.shtml



Task 1.2 SW1: interface FastEthernet0/13 switchport trunk encapsulation dot1q switchport trunk native vlan 46 switchport mode trunk SW2: interface FastEthernet0/13 switchport trunk encapsulation dot1q switchport trunk native vlan 46 switchport mode trunk Task 1.2 Breakdown By default all interfaces on the Catalyst 3550 series switch default to dynamic desirable mode. This will result in the interconnected ports negotiating an Inter Switch Link (ISL) trunk through Dynamic Trunking Protocol (DTP). ISL is a Cisco® proprietary trunking protocol, and tags all traffic sent over the trunk link with an ISL header. As an alternative to running ISL encapsulation over a trunk link, 802.1q offers a standards based trunking encapsulation. Unlike an ISL trunk, 802.1q tags all traffic sent over the trunk link with a dot1q header with the exception of the ‘native’ VLAN. Any frames received over a dot1q trunk that do not have a VLAN header are assumed to belong to the native VLAN.

To configure 802.1q encapsulation on a trunk link issue the switchport trunk encapsulation dot1q command on the interface.

By default the native vlan for a dot1q trunk is VLAN 1. To change this, issue the switchport trunk native vlan [vlan] command. Note that both ends of the trunk link must agree on the native VLAN. Since ports of the 3550 are dynamic ports, a failed negotiation in trunking will result in the port reverting to access mode. ‘Access’ mode implies that the interface will be connected to an end node, and belongs to one VLAN. To ensure that the interface always maintains trunking status, remove the port from ‘dynamic’ mode by issuing the switchport mode trunk interface command.

Note

A switchport cannot run in static trunking mode while the trunking encapsulation is set to auto-negotiate. Therefore be sure to issue the switchport trunk encapsulation command before issuing the switchport mode trunk command.



Further Reading

Configuring VLANs: Configuring VLAN Trunks

Task 1.3 SW1: interface FastEthernet0/10 spanning-tree portfast ! interface FastEthernet0/11 spanning-tree portfast Task 1.3 Breakdown Spanning-tree ‘forwarding delay’ refers to the time it takes a port to transition through the listening and learning phases of spanning-tree protocol (STP). These phases are used to determine what type of traffic is being received on an interface, and to avoid a loop in the spanning-tree topology if one is detected. Since end stations by definition are stub connections to the switch block, a spanning-tree loop cannot occur on these ports under normal circumstances. In addition to being unnecessary, running spanning-tree on ports that connect to end stations may result in undesirable effects. These effects may include hosts not being able to negotiate addresses through DHCP, log on to a network domain, etc. In order to minimize these effects spanning-tree portfast should be configured on interfaces which connect to end nodes.

Portfast reduces the delay associated with STP by skipping the listening and learning phases, and transitioning a port directly to forwarding state. To configure portfast issue the spanning-tree portfast command on the interface. Note that portfast should not be configured on interfaces that connect to routers, switches, or hubs, as this may result in a loop in the spanning-tree domain.

Further Reading

Using PortFast and Other Commands to Fix Workstation Startup Connectivity Delays

http://www.cisco.com/en/US/products/hw/switches/ps646/products_configuration_guide_chapter09186a008014f375.html

http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00800b1500.shtml

http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00800b1500.shtml



Task 1.4 SW1: interface FastEthernet0/10 spanning-tree bpduguard enable ! interface FastEthernet0/11 spanning-tree bpduguard enable Task 1.4 Breakdown As stated in the previous section portfast should not be configured on interfaces that connect to routers, switches, or hubs, as this may result in a loop in the spanning-tree domain. When portfast is enabled the listening and learning phases of STP are skipped. Since these are the phases used to determine if there is a loop in the topology, a loop can not be immediately detected if portfast is enabled. In order to prevent this case, the 3550 supports a feature known as ‘BPDU guard’.

A bridge protocol data unit (BPDU) is the packet used to advertise spanning-tree protocol information. If a BPDU is received on an interface it implies that there is a device running STP connected to that interface. If an BPDU is received on an interface which is configured with BPDU guard, the interface will be put into err-disabled state. BPDU guard can therefore be used in combination with portfast to prevent a loop if a switch or bridge is connected to a port running portfast. To enable BPDU guard, use the interface command spanning-tree bpduguard enable.

Further Reading

Spanning Tree Portfast BPDU Guard Enhancement

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a008009482f.shtml



2. Frame Relay Task 2.1 R1: interface Serial0/0 ip address 183.1.123.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 183.1.123.2 102 broadcast frame-relay map ip 183.1.123.3 102 no frame-relay inverse-arp R2: interface Serial0/0 ip address 183.1.123.2 255.255.255.0 encapsulation frame-relay frame-relay map ip 183.1.123.1 201 broadcast frame-relay map ip 183.1.123.3 203 broadcast no frame-relay inverse-arp R3: interface Serial1/0 ip address 183.1.123.3 255.255.255.0 encapsulation frame-relay frame-relay map ip 183.1.123.1 302 frame-relay map ip 183.1.123.2 302 broadcast no frame-relay inverse-arp

Quick Note Broadcast keyword not included to eliminate redundant broadcast replication.



Task 2.2 R3: interface Serial1/1 ip address 183.1.0.3 255.255.255.0 encapsulation frame-relay frame-relay map ip 183.1.0.4 315 frame-relay map ip 183.1.0.5 315 broadcast no frame-relay inverse-arp R4: interface Serial0/0 ip address 183.1.0.4 255.255.255.0 encapsulation frame-relay frame-relay map ip 183.1.0.3 405 frame-relay map ip 183.1.0.5 405 broadcast no frame-relay inverse-arp R5: interface Serial0/0 ip address 183.1.0.5 255.255.255.0 encapsulation frame-relay frame-relay map ip 183.1.0.3 513 broadcast frame-relay map ip 183.1.0.4 504 broadcast no frame-relay inverse-arp



Task 2.1 – 2.2 Breakdown Frame-Relay is a non-broadcast multi-access (NBMA) media. Unlike a true broadcast media such as Ethernet or Token-Ring, an NBMA media does not support an automatic mechanism for address resolution (ARP), nor does it natively support the transmission of broadcast or multicast packets. The first step in configuring Frame-Relay is to enable Frame-Relay encapsulation on the interface. This is accomplished by issuing the encapsulation frame-relay interface command. The next step is to determine whether layer 3 to layer 2 address resolution will be obtained through Frame-Relay Inverse-ARP or through a static layer 3 to layer 2 mapping statement.

Note

Layer 3 to layer 2 protocol resolution is not necessary when using point-to-point interfaces, since the only destination for any traffic sent out a point-to-point interface is the device residing on the other end of the link. This applies to Frame-Relay point-to-point interfaces, ATM point-to-point interfaces, and dialer interfaces in ISDN.

By default multipoint interfaces running Frame-Relay encapsulation will send Frame-Relay Inverse-ARP requests out all DLCIs configured on the interface for all supported protocols running on that interface. Frame-Relay Inverse-ARP requests may be disabled on a per protocol/DLCI pair basis by issuing the interface command no frame-relay inverse-arp [protocol] [dlci], or may be disabled for all protocols on all DLCIs on the interface by issuing the interface command no frame-relay inverse-arp. Frame-Relay Inverse-ARP requests may also be disabled on a per protocol/DLCI pair basis by creating a static protocol mapping for that protocol/DLCI pair.

Pitfall

Replies to Frame Relay Inverse-ARP requests cannot be disabled with the no frame-relay inverse-arp command. Ensure to check your layer 3 to layer 2 resolution via the show frame-relay map command to verify that there are no accidental dynamic mappings between endpoints.



In the case of Frame-Relay, a static layer 3 to layer 2 protocol mapping is defined through the frame-relay map [protocol] [protocol_address] [dlci] [broadcast] interface command. Since layer 3 to layer 2 protocol resolution is not required on point-to-point interfaces, the above command only applies to multipoint interfaces. Also since native broadcast and multicast transmission is not supported on an NBMA media, the broadcast keyword instructs the router to send both broadcast and multicast traffic out the DLCI as a replicated unicast.

Note

A ‘multipoint’ interface by definition is an interface that may connect to multiple end points of a network. Both physical interfaces and multipoint subinterfaces in Frame-Relay are by definition ‘multipoint’.

A ‘replicated unicast’ means that unlike a true broadcast or multicast transmission where only one packet is encapsulated on the interface, the packet must be replicated for each layer 2 circuit which it is destined for. For partially-meshed NBMA configurations, one or more endpoints of the network do not have direct layer 2 connectivity to all other endpoints of the network. Partial-mesh is sometimes also referred to as ‘hub-and-spoke’, in which case a single endpoint (hub) of the network has a direct layer 2 connection to all other endpoints (spokes), while all other endpoints of the networks (spokes) only have direct layer 2 connectivity to the hub. When using multipoint NBMA interfaces in a partially-meshed configuration it may be necessary to configure multiple layer 3 mappings that resolve to the same layer 2 address. This can be seen in the above configuration example where R1 has multiple frame-relay map statements that point to the same DLCI.

In the above configuration R1 only has the broadcast keyword applied to the mapping statement to R2. When a router is routing IP, an IP broadcast will never be forwarded from one interface to another by default. An IP broadcast can be forwarded between interfaces if the router is transparently bridging, but will not be forwarded out the same interface it was received on. Therefore, assuming that the hub of the network is routing IP, spoke devices on the NBMA network can neither send nor receive broadcast or multicast packets between each other. Furthermore while adding additional broadcast statements which point to the same layer 2 address is not only unnecessary, it will also cause the router to send redundant broadcast and/or multicast streams out the circuit. This may result in degraded performance on slower speed WAN links, or at the very least waste bandwidth. To avoid this behavior ensure that there is never more than one broadcast statement mapped to a single protocol on a single DLCI in a spoke in a hub and spoke environment.



Task 2.3 R6: interface Serial0/0/0 encapsulation frame-relay ip address 54.1.1.6 255.255.255.0 frame-relay map ip 54.1.1.254 101 broadcast

3. Interior Gateway Routing Task 3.1 R3: router ospf 1 router-id 150.1.3.3 network 150.1.3.3 0.0.0.0 area 0 network 183.1.0.3 0.0.0.0 area 0 ! interface Serial1/1 ip ospf network broadcast ip ospf priority 0 R4: router ospf 1 router-id 150.1.4.4 network 150.1.4.4 0.0.0.0 area 0 network 183.1.0.4 0.0.0.0 area 0 ! interface Serial0/0 ip ospf network broadcast ip ospf priority 0 R5: router ospf 1 router-id 150.1.5.5 network 150.1.5.5 0.0.0.0 area 0 network 183.1.0.5 0.0.0.0 area 0 ! interface Serial0/0 ip ospf network broadcast Task 3.1 Breakdown The first step in enabling OSPF is to define the OSPF process. This is accomplished with the global configuration command router ospf [process_id]. The OSPF process ID is a locally significant number. Next, specify the OSPF router-id by issuing the command router-id [router_id] under the OSPF process. Although this step is not necessary, it will prevent certain problems that will be evident later.



Pitfall

Router-IDs used for OSPF, BGP, and even EIGRP must be unique. Router-IDs like 1.1.1.1, 2.2.2.2, and 3.3.3.3 may be unique in a home lab environment, but in the actual CCIE lab they may not be unique. This could be due to the fact that shared backbone routers may also connect to other candidates’ racks, and in this situation you could possibly end up using the same router-ID as another candidate. To help guard against this possibility it is recommended choose an existing loopback address to ‘hard code’ as your router-ID. Using a router-ID selection method of X.X.Y.Y where X is your rack number and Y is the device number (1=R1, 2=R2, etc) would also suffice.

The next step in configuring OSPF is to enable OSPF on an interface. This is accomplished by issuing the network [address] [wildcard] area [area_number] command under the OSPF process. The ‘address’ field specifies the IP address of an interface or a range of IP addresses, while the ‘wildcard’ field specifies which bits of the address field are checked. In the above case OSPF is configured over Frame-Relay. By default the OSPF process assumes that multipoint Frame-Relay interfaces do not support the transmission of multicast packets, and therefore do not support the transmission of OSPF hello packets. In order to compensate, OSPF defines various ‘network types’. These network types are: Broadcast Non-Broadcast Point-to-Point Point-to-Multipoint Point-to-Multipoint Non-Broadcast Loopback The default OSPF network type on multipoint Frame-Relay interfaces is non-broadcast. In order to establish adjacency on an OSPF non-broadcast network segment OSPF hello packets must be sent as unicast packets. This is accomplished by issuing the neighbor statement under the OSPF process.



Of the above network types only the broadcast and non-broadcast network types support a designated router (DR) and a backup designated router (BDR) election. The task in question states that although R5 must be elected DR, the neighbor statement should not be configured. This requirement implies that the chosen OSPF network type for the Frame-Relay network should therefore be broadcast. To change the OSPF network type, issue the ip ospf network [network_type] interface level command. The OSPF DR for a segment is determined through an election process. This process first looks for the router with the highest OSPF priority. If there is a tie in the OSPF priority the router with the highest router-ID wins. The OSPF priority value has a range of 0-255, where 255 is most likely to be elected, and 0 indicates that the router will never be elected. Therefore to ensure that R5 is always elected the DR for the aforementioned segment, R3 and R4 should be configured with an ip ospf priority of 0.

Pitfall

Although it is true that the device with the highest OSPF priority value will be elected as the DR, the OSPF election does not support preemption. This means that once a device is elected the DR no other device may assume this status unless the DR goes down. Therefore there may be devices in the network with a higher priority than the current DR or BDR. This also implies that the only way to ensure that a device is elected as the DR is to remove all other devices from the election process by setting their priority to 0.

Task 3.2 R4: interface Ethernet0/0 ip ospf network non-broadcast ! router ospf 1 network 183.1.45.4 0.0.0.0 area 45 neighbor 183.1.45.5 R5: interface Ethernet0/1 ip ospf network non-broadcast ! router ospf 1 network 183.1.45.5 0.0.0.0 area 45



Task 3.2 Breakdown The default OSPF network type for Ethernet interfaces is broadcast, which sends OSPF hello packets as multicast. By changing the network type to non-broadcast, hello packets will be sent as unicast. Therefore assuming that the underlying layer 2 transport device is a switch and not a hub, which it is in this case, other devices in VLAN 45 will not receive the OSPF packets sent between R4 and R5. Task 3.3 R4: router ospf 1 network 183.1.46.4 0.0.0.0 area 46 R6: router ospf 1 router-id 150.1.6.6 network 150.1.6.6 0.0.0.0 area 46 network 183.1.46.6 0.0.0.0 area 46 redistribute connected route-map CONNECTED2OSPF ! ip prefix-list VLAN_6 permit 183.1.6.0/24 ! route-map CONNECTED2OSPF permit 10 match ip address prefix-list VLAN_6 Task 3.3 Breakdown The two ways to originate prefixes into OSPF are through the network statement under the routing process, and through redistribution. In the above example redistribution is used to advertise a connected interface into the OSPF process. By filtering the redistribution through the route-map CONNECTED2OSPF which calls the prefix-list VLAN_6, only the connected interface with the subnet 183.1.6.0/24 is redistributed. Task 3.4 R4: interface Ethernet0/0 ip ospf cost 10000 ! router ospf 1 area 45 virtual-link 150.1.5.5 R5: interface Ethernet0/1 ip ospf cost 10000 ! router ospf 1 area 45 virtual-link 150.1.4.4



Task 3.4 Breakdown The above task states that R4 should route out the Frame Relay link to R5 unless it is down, in which case it should use the Ethernet link. Since OSPF cost is derived from interface bandwidth, the 10Mbps Ethernet link will be preferred over the 1.544Mbps Serial link by default. Therefore to prefer the Frame Relay link the cost of the Ethernet segment has been increased. Note that this can also be accomplished by manipulating the bandwidth value of the interface. The next step required to solve this task is to configure a virtual-link. The virtual-link between R4 and R5 is needed due to the fact that the Loopback0 interface of R4 is advertised into OSPF area 0. When the Frame Relay link to R5 goes down area 0 becomes partitioned. Therefore the virtual-link must be configured over the transit area 45 to reconnect the area 0 adjacency between R4 and R5.

Pitfall

When creating a virtual-link the IP addressed referenced is the OSPF router-ID of the remote ABR. To ensure that this ID does not change, and hence cause virtual-link configurations to become non-functional, it is recommended to issue the router-id command when the OSPF process is initialized.

Task 3.5 R3: interface Serial1/1 ip ospf hello-interval 1 R4: interface Serial0/0 ip ospf hello-interval 1 R5: interface Serial0/0 ip ospf hello-interval 1 Task 3.5 Breakdown OSPF convergence is based on the amount of time it takes the router to detect the failure of a neighbor relationship, and the amount of CPU time required to perform SPF. By lowering the OSPF hello interval to one second the OSPF dead interval is automatically adjusted to four seconds. This implies that R4 will know about a failure of the Frame Relay circuit to R5 within four seconds. Assuming that the router can run SPF within two seconds the network will reconverge within six seconds as per the requirement.



Task 3.6 R1: router eigrp 100 eigrp router-id 150.1.1.1 network 150.1.1.1 0.0.0.0 network 183.1.17.1 0.0.0.0 network 183.1.123.1 0.0.0.0 no auto-summary R2: router eigrp 100 eigrp router-id 150.1.2.2 network 150.1.2.2 0.0.0.0 network 183.1.2.2 0.0.0.0 network 183.1.123.2 0.0.0.0 no auto-summary ! interface Serial0/0 no ip split-horizon eigrp 100 R3: router eigrp 100 eigrp router-id 150.1.3.3 network 183.1.123.3 0.0.0.0 no auto-summary R5: router eigrp 100 eigrp router-id 150.1.5.5 network 183.1.58.5 0.0.0.0 no auto-summary SW1: ip routing ! router eigrp 100 eigrp router-id 150.1.7.7 network 150.1.7.7 0.0.0.0 network 183.1.17.7 0.0.0.0 network 183.1.78.7 0.0.0.0 no auto-summary SW2: ip routing ! router eigrp 100 eigrp router-id 150.1.8.8 network 150.1.8.8 0.0.0.0 network 183.1.58.8 0.0.0.0 network 183.1.78.8 0.0.0.0 no auto-summary

Recommended Command

Quick Note Unlike RIP and IGRP split-horizon is never automatically disabled for EIGRP.



Task 3.6 Breakdown The first step in enabling EIGRP is to start the EIGRP process and define the EIGRP AS number. This is accomplished by issuing the router eigrp [as_number] global configuration command.

Note

IP routing is disabled by default on the Catalyst 3550 series switches. To enable the IP routing process, issue the ip routing global configuration command.

Once the EIGRP process has been defined, a good general practice is to disable auto summarization by issuing the no auto-summary command under the routing process. This will ensure that networks are not automatically summarized to the classfull boundary when passing between major network boundaries. Specifically in the above case, auto-summary must be disabled since discontiguous networks exist throughout the routing domain. Next, to enable EIGRP on an interface issue the network command under the EIGRP process. Like OSPF the network command syntax for EIGRP includes both an address and a wildcard as of IOS 12.0(4)T. These two fields in combination specify which interfaces, based on their IP address, or range of interfaces, based on the range of their IP addresses, will run EIGRP. In the above example the wildcard mask is 0.0.0.0. This implies that only the interface with that specific IP address will be running EIGRP. Lastly, the no ip split-horizon eigrp [as_number] command is configured on R2. By default split-horizon is enabled for EIGRP on all interfaces. Since from R2’s perspective both R1 and R3 are reachable out the same interface, split-horizon must be disabled to ensure that R1 learns about R3’s routes and vice versa.



Task 3.7 R3: router eigrp 100 redistribute connected metric 10000 100 255 1 1500 route-map CONNECTED2EIGRP ! route-map CONNECTED2EIGRP permit 10 match interface Ethernet0/0 Task 3.7 Breakdown As seen in the show ip route output routes with the D EX prefix denote external EIGRP routes. External routes are those which have been injected from a different routing domain through redistribution. In the above case the network in question is a connected interface. Therefore, the interface is injected in as an external route by issuing the redistribute connected routing process sub-command. In addition to this, a route-map has been created which matches the interface in question. Therefore, other networks are not unnecessarily injected into the EIGRP domain as external routes. Task 3.8 R6: key chain EIGRP key 1 key-string CISCO ! interface Serial0/0 ip authentication mode eigrp 10 md5 ip authentication key-chain eigrp 10 EIGRP ! router eigrp 10 eigrp router-id 150.1.6.6 network 54.1.1.6 0.0.0.0 no auto-summary

Quick Note Be careful to not put a ‘space’ at the end of the password in the key-string.



Task 3.8 Breakdown For added network security EIGRP supports MD5 authentication of adjacency relationships through the usage of a key chain. To enable EIGRP authentication first define the key chain in global configuration. Next specify the key number and the associated key-string (password). Finally enable MD5 authentication on the interface with the ip authentication mode eigrp [as_number] md5 command, and apply the key chain with the ip authentication key-chain eigrp [as_number] [key-chain] command.

Note

The key numbers within the key-chain must match between EIGRP neighbors for authentication to be successful.

Task 3.9 SW2: key chain RIP key 1 key-string CISCO ! interface Vlan82 ip rip authentication mode md5 ip rip authentication key-chain RIP ! router rip version 2 network 192.10.1.0 no auto-summary Task 3.9 Breakdown Like EIGRP, RIP uses a key-chain configuration for authentication. Unlike EIGRP however, RIP supports both clear-text and MD5 authentication. In either case, RIP authentication is only supported for RIPv2. Therefore, the above task implies that RIPv2 should be enabled.

Note

The key numbers within the key-chain do not need to match between RIP neighbors for authentication to be successful.

Recommended Command



Task 3.10 R3: router eigrp 100 redistribute ospf 1 metric 10000 100 255 1 1500 ! router ospf 1 redistribute eigrp 100 subnets R5: router eigrp 100 redistribute ospf 1 metric 10000 100 255 1 1500 ! router ospf 1 redistribute eigrp 100 subnets distance 89 0.0.0.0 255.255.255.255 1 ! access-list 1 permit host 150.1.1.0 R6: router eigrp 10 redistribute ospf 1 metric 10000 100 255 1 1500 ! router ospf 1 redistribute eigrp 10 subnets ! route-map CONNECTED2OSPF permit 20 match interface serial0/0/0 SW2: router eigrp 100 redistribute rip metric 10000 100 255 1 1500 ! router rip redistribute eigrp 100 metric 1 Task 3.10 Breakdown The above redistribution section presents two problems based on the current configuration. One of these problems is located on R6, and involves the redistribution of EIGRP into OSPF. In a previous OSPF section on R6 VLAN 6 was advertised into OSPF through redistribution. When this redistribution was configured a route-map was used to limit redistribution to only the VLAN 6 interface. However when EIGRP is then redistributed into OSPF on R6, connected interfaces running EIGRP will not be redistributed into OSPF. This is due to the fact that the route-map CONNECTED2OSPF ends in an implicit deny. Therefore either the route-map could be removed from the configuration, or it could be modified to allow the connected Serial interface to be redistributed into OSPF.



The next issue is per the requirement of R5 to route through R3 to get to R1’s Loopback interface. R1 advertises its Loopback interface into EIGRP with the network statement. This means that R5 will have this route installed as an EIGRP internal route via SW2 with an administrative distance of 90. Additionally R3 is redistributing this route from EIGRP into OSPF. Therefore R5 will also have this route in the OSPF database as an external route learned from R3, which has an administrative distance of 110. Based on this default behavior R5 will choose the internal EIGRP route due to the lower administrative distance. Therefore to get R5 to route through R3 we can either filter out the advertisement from SW2 to R5, which is not allowed per the requirement, or change the administrative distance. In the above solution the administrative distance is changed with the statement distance 89 0.0.0.0 255.255.255.255 1, where 89 is the administrative distance (one lower than EIGRP’s 90), 0.0.0.0 255.255.255.255 is the neighbor the route is learned from (any neighbor), and 1 is a standard access-list matching the prefix 150.1.1.0. This means that the distance of the OSPF prefix 150.1.1.0 will be changed to 89, and will therefore be preferred over the EIGRP route.



4. Exterior Gateway Routing Task 4.1 R1: router bgp 200 bgp router-id 150.1.1.1 no synchronization neighbor 183.1.17.7 remote-as 200 neighbor 183.1.17.7 route-reflector-client neighbor 183.1.123.2 remote-as 200 R2: router bgp 200 bgp router-id 150.1.2.2 no synchronization neighbor 183.1.123.1 remote-as 200 neighbor 183.1.123.3 remote-as 100 R3: router bgp 100 bgp router-id 150.1.3.3 no synchronization neighbor 183.1.0.5 remote-as 100 neighbor 183.1.123.2 remote-as 200 neighbor 204.12.1.254 remote-as 54 R4: router bgp 100 bgp router-id 150.1.4.4 no synchronization neighbor 150.1.5.5 remote-as 100 neighbor 150.1.5.5 update-source Loopback0 R5: router bgp 100 bgp router-id 150.1.5.5 no synchronization neighbor 150.1.4.4 remote-as 100 neighbor 150.1.4.4 update-source Loopback0 neighbor 150.1.4.4 route-reflector-client neighbor 150.1.6.6 remote-as 100 neighbor 150.1.6.6 update-source Loopback0 neighbor 150.1.6.6 route-reflector-client neighbor 183.1.0.3 remote-as 100 neighbor 183.1.0.3 route-reflector-client neighbor 183.1.58.8 remote-as 200 R6: router bgp 100 bgp router-id 150.1.6.6 no synchronization neighbor 54.1.1.254 remote-as 54 neighbor 150.1.5.5 remote-as 100 neighbor 150.1.5.5 update-source Loopback0



SW1: router bgp 200 bgp router-id 150.1.7.7 no synchronization neighbor 183.1.17.1 remote-as 200 neighbor 183.1.17.1 route-reflector-client neighbor 183.1.78.8 remote-as 200 SW2: router bgp 200 bgp router-id 150.1.8.8 no synchronization neighbor 183.1.58.5 remote-as 100 neighbor 183.1.78.7 remote-as 200 neighbor 192.10.1.254 remote-as 254 neighbor 192.10.1.254 password CISCO Task 4.1 Breakdown Like other routing protocols the first step in enabling BGP is to issue the router bgp [as_number] command in global configuration mode. Note that only one BGP process may run on the router at any given time. Unlike most IGPs, BGP does not supply its own transport protocol. Instead, BGP uses TCP to provide reliable transport. This implies that to establish a BGP peering relationship, end-to-end IP reachability must already be established. To form a BGP peering relationship, use the BGP subcommand neighbor [address] remote-as [remote_as_number]. One fundamental rule about BGP peering relationships is that all iBGP peering sessions must be fully meshed by default.

Note

Since all devices in the transit path throughout the network are running BGP, synchronization has been disabled. As of 12.2(8)T, BGP synchronization is disabled by default. Implications of BGP synchronization will be covered in depth in later scenarios.

Since BGP does not use a discernible metric value as IGPs do, the main loop prevention mechanism built into iBGP is that fact that routes learned from an iBGP neighbor cannot be advertised onto another iBGP neighbor. Therefore, this stipulation implies that all iBGP speaking devices must establish direct peering relationships with all other iBGP devices within your autonomous system.



Note

There are two exceptions to this rule, route-reflection and confederation. Route-reflection allows the establishment of one or more points of distribution for iBGP learned prefixes, which can significantly reduce the amount of internal BGP peering sessions required. In a confederation the AS may be broken down into smaller sub-autonomous systems. Inter sub-AS communication in confederation is treated as an EBGP peering session. Since the aforementioned rule does not apply to EBGP peerings, confederation implies that fully meshed iBGP must only be maintained within the sub-autonomous system. Route-reflection may be used within a sub-AS in confederation to further reduce the amount of peering sessions.

Based on the provided table used to illustrate the BGP peerings in the above task, it is evident that fully meshed iBGP peering relationships do not exist in either AS 100 or AS 200. Therefore this implies that route-reflection must be configured. To understand which specific devices should act as route-reflectors throughout the network, it is important to understand how a route-reflect behaves when a prefix is learned from a BGP neighbor. Three different roles are defined in BGP route-reflection. These roles are the route-reflector, the client of the route-reflector, and non-clients of the route-reflector. A router is designated as a route-reflector by adding the route-reflector-client option onto a BGP peering statement. This option designates that the peer in question is a ‘client’ of the route-reflector. Other peering sessions configured on the route-reflector that do not have the route-reflector-client option attached are considered non-clients of the route-reflector. Route advertisement is processed differently depending on what type of peer a route is received from. If the client in question is an EBGP neighbor all prefixes learned from the peer will automatically be candidate to be advertised onto all other peers. When a route is received from a client peer, the route is candidate to be advertised on to all client peers and all non-client peers. When a route is received from a non-client peer, it is candidate to be advertised on to all client peers.



Pitfall

The term ‘candidate to be advertised’ is used here because although the route is eligible to be advertised on to another peer, there are certain cases when the prefix will not be advertised. Some of these include because the route is not a ‘best’ path, the route is part of a community that dictates it not to be advertised, distribute-list filtering is applied to a neighbor, etc. These cases will be covered in more detail later.

Based upon the above described reflection behavior and the design of the BGP peering sessions in this particular task, the following can be inferred:

1. R5 must be configured as a route-reflector for R3, R4, and R6.

2a. SW1 should be configured as a route-reflector for SW2, while R1 is

configured as a route-reflector for R2.

OR

2b. SW1 should be configured as a route-reflector for R1, while R1 is configured as a route-reflector for SW1.

Both of the aforementioned cases for AS 200 will result in all routes being candidate for propagation through AS 200.

Further Reading

BGP Case Studies: Route Reflectors

The next step in configuring BGP for this task states that the BGP peerings between R4 & R5 and R5 & R6 should remain active if R4’s connection to the Frame-Relay cloud is lost. Since BGP relies on TCP transport, a BGP peering session may route asynchronously (different forward path than return path) and may be rerouted due to changes in the IGP topology.

http://www.cisco.com/warp/public/459/bgp-toc.html



By default, when a BGP peering relationship is established, BGP packets destined for that particular peer are generated with the source IP address of the outgoing interface as listed in the IP routing table. This means that if R4 peers with the IP address of R5’s Frame Relay interface, the packet will always be generated from R4’s directly connected Frame-Relay interface. However, in order to reroute the BGP peering session due to a failure of the Frame Relay connection, the destination peering address must be independent of any physical interface. As a solution to this issue, the peering session between both R4 & R5 and R5 & R6 is configured to use their respective Loopback 0 interfaces as the destination address. When configured, this type of peering has additional implications. As mentioned above, the source IP address of a BGP packet by default is dependent on the interface that the packet leaves out of. Based on the IGP design of this network, the outgoing interface for R4 to reach R5’s Loopback 0 interface will be R4’s Serial interface connected to the Frame Relay cloud. However, since the peering relationship is configured to use the Loopback 0 IP addresses, the BGP process of R4 and R5 will reject packets from the respective peers if the source address does not match the configured peering address. In order to resolve this problem, the source IP address of BGP packets destined towards a particular BGP neighbor can be manually specified. This is accomplished by adding the update-source [interface] option to the BGP neighbor statement of the appropriate peer.

Pitfall

The time-to-live (TTL) of an EBGP packet defaults to one. When an EBGP peering relationship is established between Loopback addresses, an extra hop is added in the transit path for the BGP packet. Therefore, EBGP peering relationships that are established with the Loopback address as the update source, regardless of whether or not the neighbors are directly connected, will require modification of the TTL of the BGP packet. This is accomplished by issuing the neighbor [address] ebgp-multihop [ttl] BGP routing process subcommand. This command allows for the modification of the TTL of EBGP packets. If unspecified, the TTL value of this command defaults to the maximum (255).



Lastly, this above task states that the BGP peering session between SW2 and BB2 should be authenticated by using the password CISCO. BGP authentication uses an MD5 hash value derived from a configured password on the neighbor statement. This password is configured by simply adding the password [password] field onto the appropriate BGP neighbor statement.

Further Reading

BGP Case Studies: BGP and Loopback Interfaces Sample Configuration for iBGP and eBGP With or Without a Loopback Address Thwarting TCP-Reset Attacks At Public Peering Points

Standard

RFC 2385: Protection of BGP Sessions via the TCP MD5 Signature Option

Task 4.2 R6: ip as-path access-list 1 permit _54$ ! route-map LOCAL_PREFERENCE permit 10 match as-path 1 set local-preference 200 ! route-map LOCAL_PREFERENCE permit 1000 ! router bgp 100 neighbor 54.1.1.254 route-map LOCAL_PREFERENCE in

http://www.cisco.com/warp/public/459/bgp-toc.html

http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a0080093f25.shtml

http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a0080093f25.shtml

http://www.cisco.com/warp/public/779/servpro/promotions/bbip/volume_03_issue19.html

http://www.internetworkexpert.com/rfc/index.php?rfc=2385




Task 4.2 Breakdown To understand how to affect the BGP best path selection process, it is necessary to first understand the order of the best path selection process. Briefly, the order is as follows:

Weight (highest) Local-Preference (highest) Locally Originated AS-Path (shortest) Origin (IGP > EGP > ?) MED (lowest)

As a general rule, these attributes should be applied in the following manner to affect the following traffic flow:

Attribute Direction Applied Traffic Flow Affected Weight Inbound Outbound

Local-Preference Inbound Outbound AS-Path Outbound Inbound

MED Outbound Inbound Weight and Local-Preference are used to affect how traffic leaves the autonomous system. AS-Path and MED are used to affect how traffic enters the AS. Since Weight and Local-Preference are higher in the decision process than AS-Path and MED, you (generally) have control of how traffic leaves your AS. In the above task, AS 100 wants traffic destined for prefixes originated in AS 54 to exit the network through the Frame Relay circuit. Since AS 100 is trying to affect its outbound traffic flow, either the weight or local-preference of the prefixes in question should be modified to attain the desired behavior. Since this task specifically states to not use weight, the only option left to use is local-preference.

The first step in affecting a traffic flow is to match the prefixes in question. In the above case, the prefixes for which the traffic flow needs to be affected are those which are originated in AS 54. Since all of these prefixes will have the common attribute of AS 54 being last (right most) AS in the path, the easiest way to match all these prefixes at once is by matching on the AS-Path. This is accomplished by defining an as-path access-list. The regular expression specified in this list will match all routes originated in AS 54.

Next, the AS-Path list is matched inside a route-map, and the appropriate attribute is applied. Since a higher local-preference value is preferred, any value above the default of 100 is sufficient.



Lastly, the route-map is applied to the neighbor statement pointing towards BB1 inbound. Therefore, all routes learned from BB1 that were originated in AS 54 will have a more preferable local-preference value set.

Further Reading

BGP Best Path Selection Algorithm Regular Expressions

Task 4.3 R1: interface Loopback1 ip address 150.1.11.1 255.255.255.0 ! router bgp 200 network 150.1.11.0 mask 255.255.255.0 R2: ip prefix-list R1_BGP_LOOPBACK seq 5 permit 150.1.11.0/24 ! route-map MED permit 10 match ip address prefix-list R1_BGP_LOOPBACK set metric 200 ! route-map MED permit 1000 ! router bgp 200 neighbor 183.1.123.3 route-map MED out R5: router bgp 100 neighbor 183.1.0.3 next-hop-self SW2: ip prefix-list R1_BGP_LOOPBACK seq 5 permit 150.1.11.0/24 ! route-map MED permit 10 match ip address prefix-list R1_BGP_LOOPBACK set metric 100 ! route-map MED permit 1000 ! router bgp 200 neighbor 183.1.58.5 route-map MED out

http://www.cisco.com/warp/public/459/25.shtml

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fdial_c/fnsprt13/dafaapre.htm



Task 4.3 Breakdown The first step in originating a network into BGP is to issue the network command under the BGP process. Unlike the IGP network command, which specifies which interface to enable the protocol on, the network command in BGP advertises a network into the routing domain. Ensure to include the mask field in the network statement if the prefix that is being originated is not a classful network (either a subnet or a supernet). In this particular task, AS 200 is trying to affect how traffic is entering its AS and being forwarded towards the prefix originated by R1. Specifically, AS 200 would prefer traffic destined for this prefix to enter where SW2 connects to R5, as opposed to where R2 connects to R3. Recall from the previous section how to affect traffic flow through BGP policy:



MED Outbound Inbound

To affect how traffic enters your AS, modify either the AS-Path or MED attribute. Since this task says that modifying the AS-Path attribute is not allowed, modifying the MED attribute is the remaining option. The mechanism of setting the attribute is similar to how the local-preference value was modified in the previous section. First, the prefix or prefixes in question must be matched. Since in this case there is only one prefix, a prefix-list is created which specifies an exact match for the network. Next, the prefix-list is matched in a route-map, and the metric (MED) value is set accordingly. Since a lower MED value is preferred, a lower value is sent to R5 than is sent to R3. The actual metric values chosen are arbitrary, as long as they are both positive integers and the lower of the values is sent to R5.

Further Reading

How BGP Routers Use the Multi-Exit Discriminator for Best Path Selection

http://www.cisco.com/warp/public/459/37.html




2. IP Multicast Task 5.1 R2: ip multicast-routing ! interface FastEthernet0/0 ip pim sparse-dense-mode ! interface Serial0/0 ip pim sparse-dense-mode R3: ip multicast-routing ! interface Ethernet0/0 ip pim sparse-dense-mode ! interface Serial1/0 ip pim sparse-dense-mode ! interface Serial1/1 ip pim sparse-dense-mode R5: ip multicast-routing ! interface Ethernet0/0 ip pim sparse-dense-mode ! interface Serial0/0 ip pim sparse-dense-mode Task 5.1 Breakdown The first step in configuring multicast routing is to issue the global configuration command ip multicast-routing. Next, Protocol Independent Multicast (PIM) should be enabled on all interfaces in the transit path of the multicast network by issuing the interface level command ip pim [sparse | dense | sparse-dense] mode. See the following section breakdown for the reasoning as to why sparse-dense-mode has been configured in this section.



Task 5.2 R2: interface Loopback0 ip pim sparse-dense-mode ! ip pim send-rp-discovery Loopback0 scope 16 R3: interface Loopback0 ip pim sparse-dense-mode ! ip pim send-rp-announce Loopback0 scope 16 Task 5.2 Breakdown Protocol Independent Multicast (PIM) is a multicast routing protocol that is independent of the underlying unicast reachability mechanism. Therefore, as long as IP reachability is established through the usage of some IGP, PIM can be configured independently of this IGP. PIM runs in three ‘modes’, which are defined as sparse, dense, or sparse-dense which is a combination of both.

Dense mode PIM is designed for networks which have many multicast clients which are tightly spaced together. Dense mode PIM may be considered ‘implicit join’, as all devices in the PIM domain are assumed to be members of all multicast groups. If a device in the network does not wish to receive a multicast feed, it sends a ‘prune’ message towards the source. This prune message instructs upstream routers to stop sending the traffic for the particular group. This is commonly referred to as ‘flood and prune’ behavior.

Sparse mode PIM is designed for network which have multicast clients that are few and far between. Unlike PIM dense mode, devices in the sparse mode domain will not receive traffic for any multicast groups unless they send a join message for that group. Sparse mode is therefore considered to be an ‘explicit join’ mechanism. In order to optimize initial forwarding of streams through the sparse multicast domain, a central ‘rendezvous point’ (RP) is an integral part of PIM sparse mode.

When a client wishes to send a multicast feed into the network, the feed is first sent to the RP. Similarly, when a client wishes to join a multicast feed, a ‘register’ message is sent to the RP. Once the multicast feed has successfully propagated from the sender to the receiver, devices in the transit path will automatically optimize the transit path by converting from a shared multicast tree to a shortest path multicast tree.



An RP may be configured in the PIM domain manually or through an automatic advertisement method. Automatic advertisement methods include Auto-RP and bootstrap router (BSR).

Auto-RP defines two roles in the PIM domain, the candidate-RP and the mapping agent. The candidate RP uses multicast messages to advertise itself to the mapping agent. The mapping agent advertises itself through multicast messages, and is responsible for group to RP mappings.

Bootstrap router (BSR), much like Auto-RP, defines two roles in the PIM domain. The bootstrap router is responsible for group to RP mappings, while the candidate RP advertises itself to the BSR via unicast messages.

Although BSR would be a valid solution to this task, Auto-RP configuration is shown in the above code output. When configuring Auto-RP, is important understand the implications in the fact that both the RP announce and RP discovery messages are sent via multicast.

Routers in a sparse mode PIM domain must know about a RP in order to join a multicast group. However, since the Auto-RP advertisement messages are multicast, a sparse mode router must join the Auto-RP groups (224.0.1.39 & 224.0.1.40) in order to learn about candidate RPs that exist in the network. This results in a paradox like recursive error. To join a group, the router must first know who the RP is, but to know who the RP is, it must first join a group. To deal with this inherent design flaw, sparse-dense-mode PIM was conceived.

In sparse-dense-mode, groups which have a valid RP will be marked as sparse, while groups that do not have an RP will be marked as dense. Therefore, a sparse-dense device may be dense for groups 224.0.1.39 & 224.0.1.40, while at the same time it can be sparse for any groups advertised through Auto-RP.

In order to define the mapping agent, issue the ip pim send-rp-discovery [interface] scope [scope] global configuration command, where interface is the IP address to advertise as the mapping agent and scope is the TTL of the discovery message. In order to define a candidate RP, issue the ip pim send-rp-announce [interface] scope [scope] global configuration command, where interface is the IP address to advertise as the candidate RP and scope is the TTL of the advertisement message.

Pitfall

When using a Loopback interface for the discovery or candidate-RP advertisement, ensure to enable PIM on the Loopback interface.



Further Reading

Configuring a Rendezvous Point

Task 5.3 R5: interface Ethernet0/0 ip igmp join-group 226.26.26.26 ! ip mroute 0.0.0.0 0.0.0.0 183.1.0.3 Task 5.3 Breakdown In order to facilitate in testing IP multicast reachability throughout the network, a router can be instructed to receive multicast traffic. This is accomplished by issuing the interface command ip igmp join-group [group_address]. Unlike the ip igmp static interface command, when a router issues an IGMP ‘join’, the CPU must actually process the multicast group. Therefore, a router configured with an IGMP join statement will respond to ICMP echo requests sent to the group that is has joined. In order to prevent looping of multicast feeds the router performs a reverse-path forwarding (RPF) check whenever a multicast packet is received on an interface. If the outgoing interface for the unicast route to the source IP address of the multicast packet is different than the interface that the multicast packet was received on, the RPF check will fail. In the above task, R5’s unicast route to R2 is out its Ethernet interface. However, multicast packets sent from R2 to R5 will be received in R5’s serial interface. In order to prevent the RPF check from failing on these multicast packets, a static multicast route (mroute) has been configured on R5. Unlike a unicast static route, a static multicast route does not actually direct any traffic in or out a particular interface. Instead, a static mroute is used to change the interface for which the incoming multicast feed is expected. Therefore, configuring a default static mroute on R5 which encompasses both R2’s Loopback 0 and Ethernet interfaces (the source of the Auto-RP and ICMP messages) will force the RPF check to be successful.

Further Reading

IP Multicast Technology Overview: Reverse Path Forwarding (RPF)

http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/mcst_sol/rps.htm

http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/mcst_sol/mcst_ovr.htm



Task 5.4 R3: access-list 1 deny 239.0.0.0 0.255.255.255 access-list 1 permit any ! interface Ethernet0/0 ip igmp access-group 1 Task 5.4 Breakdown By default, a host can join any multicast group that it wishes to on a segment running IP multicast routing. To control which groups a host can join, create a standard IP access-list that permits or denies the groups in question, and apply it to the interface with the command ip igmp access-group [access-list].

Standard

RFC 2365: Administratively Scoped IP Multicast




3. IPv6 Task 6.1 R4: ipv6 unicast-routing ! interface Ethernet0/1 ipv6 address 2001:CC1E:1:404::/64 eui-64 R5: ipv6 unicast-routing ! interface Ethernet0/0 ipv6 address 2001:CC1E:1:505::/64 eui-64 Task 8.1 Breakdown The first step in enabling IPv6 is to issue the ipv6 unicast-routing command in global configuration mode. This not only allows the routing of IPv6 datagrams through dynamic protocols such as RIPng and OSPFv3, but also enables ICMPv6 processing on IPv6 enabled interfaces. Once IPv6 routing is enabled, global unicast IPv6 addressing is configured on the Ethernet interfaces of R4 and R5. The host portions of these addresses are derived from the modified EUI-64 addressing format. Per RFC 2373 all addresses the in the global unicast range (001 in the 3 most significant bits) are required to have 64-bit interface identifiers in this EUI-64 format. The modified EUI-64 address is derived from the MAC address of the interface, or if the interface does not have a MAC address (such as a serial or tunnel interface), from the MAC address pool of the router. In the above case the EUI-64 addresses are specifically derived as follows. First, the MAC address of the Ethernet interface is examined:

Rack1R4#show interface ethernet0/1 Ethernet0/1 is up, line protocol is up Hardware is AmdP2, address is 0050.8004.8e01 (bia 0050.8004.8e01) Next, the MAC address is split into two portions, the 24-bit vendor-id and the 24-bit extension-id. Between these fields the hex sequence 0xFFFE is inserted. In the above case this results in the address 0050.80FF.FE04.8E01.



Next, the 7th most significant bit, known as the universal/local bit, is inverted resulting in the address 0250.80FF.FE04.8E01:

0050.80FF.FE04.8E01

00 = 00000000 = 00000010 (inverted) = 02 Lastly the dots are replaced with colons to follow the IPv6 address notation and any leading zeros are dropped, resulting in the final host address 250:80FF:FE04:8E01. The host address is appended to the network prefix, resulting in the final global unicast address:

2001:CC1E:1:404:250:80FF:FE04:8E01

This address can be verified on the command line by issuing either the show ipv6 interface ethernet0/1 command or the show ipv6 interface brief command: Rack1R4#show ipv6 interface Ethernet0/1 Ethernet0/1 is up, line protocol is up IPv6 is enabled, link-local address is FE80::250:80FF:FE04:8E01 Description: - VLAN 4 Global unicast address(es): 2001:CC1E:1:404:250:80FF:FE04:8E01, subnet is 2001:CC1E:1:404::/64 <output omitted> Rack1R4#show ipv6 interface brief | begin Ethernet0/1 Ethernet0/1 [up/up] FE80::250:80FF:FE04:8E01 2001:CC1E:1:404:250:80FF:FE04:8E01 <output omitted> Task 6.2 R4: interface Tunnel0 ipv6 address 2001:CC1E:1:4545::4/64 tunnel source 150.1.4.4 tunnel destination 150.1.5.5 tunnel mode ipv6ip R5: interface Tunnel0 ipv6 address 2001:CC1E:1:4545::5/64 tunnel source 150.1.5.5 tunnel destination 150.1.4.4 tunnel mode ipv6ip



Task 6.2 Breakdown The above configuration demonstrates how to tunnel IPv6 datagrams over an existing IPv4 transit network using IPv6IP encapsulation. The default mode for tunnel interfaces is to use GRE encapsulation. With GRE tunneling, multiple layer 3 protocols are supported, such as IP, IPv6, IPX, and CLNS. With IPv6IP tunneling there is less overhead than GRE, but similar to IPIP tunneling only IPv6 can be in the payload of the IPv4 encapsulated packet. IPv6IP tunnels use IP protocol number 41, and can be enabled by issuing the statement tunnel mode ipv6ip on the tunnel interface. Task 6.3 R4: ipv6 host Rack1R5 2001:CC1E:1:505:206:D7FF:FEA8:3021 ! interface Tunnel0 ipv6 rip CISCO enable ! interface Ethernet0/1 ipv6 rip CISCO enable ! ipv6 router rip CISCO R5: ipv6 host Rack1R4 2001:CC1E:1:404:250:80FF:FE04:8E01 ! interface Tunnel0 ipv6 rip CISCO enable ! interface Ethernet0/0 ipv6 rip CISCO enable ! ipv6 router rip CISCO Task 6.3 Breakdown The first step in enabling RIP for IPv6 (RIPng) is to issue the ipv6 router rip [tag] command, where tag is a locally significant process-id name. Next, enable RIPng processing on the interface with the interface level command ipv6 rip [tag] enable, where tag is the process-id previously defined. To verify that the protocol is enabled, issue the show ipv6 protocols or show ipv6 rip. From the below output it can be seen that RIPng is enabled on the Ethernet0/1 and Tunnel0 interfaces of R4. RIPng uses IPv6 multicasts to the address FF02::9 using UDP port 521.

Quick Note R5’s global unicast address based off of EUI-64 host portion.

Quick Note R4’s global unicast address based off of EUI-64 host portion.



Rack1R4#show ipv6 protocols IPv6 Routing Protocol is "connected" IPv6 Routing Protocol is "static" IPv6 Routing Protocol is "rip CISCO" Interfaces: Ethernet0/1 Tunnel0 Redistribution: None Rack1R4#show ipv6 rip RIP process "CISCO", port 521, multicast-group FF02::9, pid 168 Administrative distance is 120. Maximum paths is 16 Updates every 30 seconds, expire after 180 Holddown lasts 0 seconds, garbage collect after 120 Split horizon is on; poison reverse is off Default routes are not generated Periodic updates 7, trigger updates 2 Interfaces: Ethernet0/1 Tunnel0 Redistribution: None Rack1R4#show ipv6 interface tunnel0 Tunnel0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::9601:404 Global unicast address(es): 2001:CC1E:1:4545::4, subnet is 2001:CC1E:1:4545::/64 Joined group address(es): FF02::1 FF02::2 FF02::9 FF02::1:FF00:4 FF02::1:FF01:404 MTU is 1480 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ND DAD is enabled, number of DAD attempts: 1 ND reachable time is 30000 milliseconds Hosts use stateless autoconfig for addresses. Rack1R4#show ipv6 route rip IPv6 Routing Table - 7 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 R 2001:CC1E:1:505::/64 [120/2] via FE80::9601:505, Tunnel0

Quick Note Tunnel is listening for RIPng multicast packets.



Note that in the above output the network 2001:CC1E:1:505::/64 recurses to the IPv6 next-hop address FE80:: 9601:505 out the Tunnel0 interface. This is the link-local IPv6 address of R5’s Tunnel0 interface. Since the tunnel is a point-to-point interface, layer 3 to layer 2 resolution for this address is not required. For situations where dynamic routing is enabled over multipoint NBMA interfaces, such as the main interface in Frame Relay or ATM, static layer 3 to layer 2 resolution is required for the link-local address of the remote end. This task also demonstrates how to configure static DNS entries for IPv6 with the ipv6 host command. To find the appropriate address to use issue the show ipv6 interface brief command to see the full global-unicast address assigned to the interface. Rack1R5#show ipv6 int brief | begin Ethernet0/0 Ethernet0/0 [up/up] FE80::206:D7FF:FEA8:3021 2001:CC1E:1:505:206:D7FF:FEA8:3021 <output omitted> Rack1R4#ping 2001:CC1E:1:505:206:D7FF:FEA8:3021 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:CC1E:1:505:206:D7FF:FEA8:3021, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms Rack1R4#conf t Enter configuration commands, one per line. End with CNTL/Z. Rack1R4(config)#ipv6 host Rack1R5 2001:CC1E:1:505:206:D7FF:FEA8:3021 Rack1R4(config)#do show hosts Default domain is not set Name/address lookup uses static mappings Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate temp - temporary, perm - permanent NA - Not Applicable None - Not defined Host Port Flags Age Type Address(es) Rack1R5 None (perm, OK) 0 IPv6 2001:CC1E:1:505:206:D7FF:FEA8:3021 Rack1R4(config)#do ping Rack1R5 Translating "Rack1R5" Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:CC1E:1:505:206:D7FF:FEA8:3021, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/8 ms



4. QoS Task 7.1 R5: map-class frame-relay DLCI_504 frame-relay cir 512000 frame-relay bc 25600 frame-relay be 51200 frame-relay mincir 384000 frame-relay adaptive-shaping becn ! map-class frame-relay DLCI_513 frame-relay cir 128000 frame-relay bc 6400 frame-relay be 0 frame-relay mincir 96000 frame-relay adaptive-shaping becn ! interface Serial0/0 frame-relay traffic-shaping frame-relay interface-dlci 504 class DLCI_504 frame-relay interface-dlci 513 class DLCI_513 Task 7.1 Breakdown Frame Relay Traffic Shaping is designed to control the amount of traffic the router sends out an interface or a particular DLCI. Common reasons for using Frame Relay Traffic Shaping are to force the router to conform to the rate subscribed with the Frame Relay service provider, or to throttle a higher speed site so that it does not overrun a lower speed site.

The first case is required when the physical interface clocking differs from the provisioned rate on the circuit. This is due to the fact that the router always sends traffic out an interface at the line rate. This rate is called the serialization delay. For example, a 100Mbps Ethernet interface will always send traffic at one-hundred million bits per second, or 1000 bits per millisecond. That means that a 64 byte packet will take .512 ms to be transmitted, and a 1500 byte packet will take 1.5 ms to be transmitted. Traffic sent in short bursts can quickly exceed a service providers policing interval if the serialization delay is much faster than the provisioned rate.

The second case typically occurs in a partial mesh environment. Suppose that there are four devices on an NBMA cloud, one of which is the hub for the other three devices. Each device has a T1 connection to the Frame Relay cloud (1.536 Mbps). If each spoke sends at line rate, the hub will be receiving three times T1, 6.144 Mbps. This is clearly beyond what the interface can support.



This is the case that is described in this scenario. R5 has a T1 connection to the Frame Relay cloud, but the spokes have differing port speeds that are much lower than 1.536 Mbps. For this reason shaping must be enabled on the hub in order to ensure that the spokes are not overwhelmed. Traffic-shaping differs from traffic-policing in that shaping is designed to buffer traffic in excess of the target rate, whereas policing is designed to drop traffic in excess of the target rate. To accomplish this, traffic-shaping uses a system of credits. Before a packet can be sent, the amount of credit equaling the packet’s size in bits must have been earned. Policing differs in that the router is allowed to borrow future credits, and in turn is permitted to go into a debt situation of having to “pay” back credits. Traffic-shaping does not permit the borrowing of future credits.

Note

When traffic-shaping is applied to an interface, the router is given a full allotment of credits. After this point all credits must be earned.

To understand Frame Relay Traffic Shaping it is first necessary to understand the terms used in FRTS: AR - Available Rate or Access Rate. This value is either the actual physical

speed of the interface, or the rate at which the Frame Relay service provider is policing all traffic received. Traffic cannot be sent in to the Frame Relay cloud at above this rate. When the AR is the physical speed of the interface, it is determined by the configured clock rate on the DCE end. AR is commonly referred to as “port speed”.

CIR - Committed Information Rate. This is the rate in bits per second that the

router will attempt to average over a one second period. The default CIR when traffic-shaping is enabled on an interface is 56kbps. CIR as also referred to as “target rate”.



Pitfall

The CIR configured on the router is not related to the rate at which the Frame Relay service provider has provisioned the circuit. Although the service provider may refer to the provisioned rate as the CIR, the CIR value in the FRTS algorithm is simply the average output rate. This may or may not equal the provider’s provisioned rate.

MINCIR - Minimum CIR. The rate at which the router will throttle down to at a

minimum if a BECN is received from the Frame Relay cloud. Typically this is set to the provisioned rate that the Frame Relay service provider guarantees to accept, as there should never be a reason to throttle down to a speed lower than is provisioned for the circuit in the provider cloud. Theoretically the Frame Relay provider will set the DE bit for all traffic above this rate. This value is also used to calculate the available bandwidth value used in the MQC. MINCIR defaults to half the configured CIR

Note

For more information on the MQC “available bandwidth” value see the Lab 3 QoS section

Bc - Committed Burst. The number of committed bits allowed to be sent

during a given interval. If Bc bits are sent per interval in every interval in that second, the output rate is CIR. Commonly this is referred to as the committed bits the Frame Relay service provider has agreed to accept, but this is only true if the configured CIR equals the provisioned CIR of the Frame Relay service provider.

Be - Excess Burst. The number of non-committed bits the router is allowed

to send above Bc if there is sufficient credit. The amount of Be “credits” is derived from unused Bc credits in previous intervals. Be defaults to zero bits.

Note

There is no limit to how long Be can “store” unused Bc credits. It is a common misconception that Be can only store credits from the previous interval or the previous second.



Tc – Time Committed. Time in milliseconds in which the second is divided. The shaping algorithm is allowed to send Bc bits out the interface per Tc interval. The Bc bucket is refilled at each new Tc. If there are bits left in the Bc bucket that were not used in the previous interval, they roll over to the Be bucket. If the Be bucket is full, the credits are lost. The largest amount of traffic that can be sent in a single interval is Bc + Be. The maximum value of Tc is 125ms (1/8th of a second), and the minimum value is 10ms (1/100th of a second).

The first step in configuring FRTS is to enable FRTS on the interface. This is accomplished by issuing the interface level command frame-relay traffic-shaping.

Pitfall

Once FRTS has been enabled on the interface, all DLCIs on that interface (including any subinterfaces) are assigned the default CIR value of 56000 bps. For DLCIs which require a different output rate than 56000 bps, the CIR must be adjusted.

R1# interface Serial0/0 encapsulation frame-relay frame-relay traffic-shaping R1#show traffic-shape Interface Se0/0 Access Target Byte Sustain Excess Interval Increment Adapt VC List Rate Limit bits/int bits/int (ms) (bytes) Active 103 56000 875 7000 0 125 875 - 104 56000 875 7000 0 125 875 - 105 56000 875 7000 0 125 875 - 113 56000 875 7000 0 125 875 - 102 56000 875 7000 0 125 875 -

VC – DLCI Target Rate – CIR Byte Limit – Bc * 8 Sustain bits – Bc Excess bits – Be Interval – Tc Adapt – BECN adapt



Next, FRTS parameters should be defined in a frame-relay map-class (not to be confused with the MQC class-map). To define the map-class issue the map-class frame-relay [name] global configuration command. R1(config)#map-class frame-relay FRTS R1(config-map-class)#frame-relay ? adaptive-shaping Adaptive traffic rate adjustment, Default = none bc Committed burst size (Bc), Default = 56000 bits be Excess burst size (Be), Default = 0 bits cir Committed Information Rate (CIR), Default = 56000 bps congestion Congestion management parameters custom-queue-list VC custom queueing end-to-end Configure frame-relay end-to-end VC parameters fair-queue VC fair queueing fecn-adapt Enable Traffic Shaping reflection of FECN as BECN fragment fragmentation - Requires Frame Relay traffic-shaping to be configured at the interface level holdq Hold queue size for VC idle-timer Idle timeout for a SVC, Default = 120 sec interface-queue PVC interface queue parameters ip Assign a priority queue for RTP streams mincir Minimum acceptable CIR, Default = CIR/2 bps priority-group VC priority queueing tc Policing Measurement Interval (Tc) traffic-rate VC traffic rate voice voice options

Once the map-class has been defined, the various FRTS parameters must be configured. These various options are:

frame-relay cir bps - Used to define the CIR for the map-class. This is the target

rate the router will attempt to send data at. frame-relay mincir bps - Used to define the mincir for the map-class. The

default mincir value is half of the configured CIR. Note that mincir is only used in conjunction with adaptive shaping. Mincir is the lowest rate at which the router will throttle down to in the event of congestion.

frame-relay bc bits - Used to define the committed burst size (Bc). Setting the

Bc indirectly sets the Tc, and is derived from the following formula: Bc = CIR * Tc/1000



frame-relay be bits - Used to define the excess burst size (Be). Be is typically derived from the formula: Be = (AR – CIR) * Tc/1000, where AR is the access rate of the interface.

frame-relay adaptive-shaping {becn | foresight} - Used to allow the router to throttle back in the event of congestion. The router will throttle back 25% per Tc when BECNs are received. The router will continue to throttle down 25% each Tc until BECNs are no longer received or until MINCIR is reached. frame-relay fecn-adapt - Used to have the router reflect FECNs as BECNs.

This is normally used in situations where one router is only sending and the other is only receiving. An example would be where one site is streaming video to another site.

The Frame Relay Traffic Shaping algorithm uses a token bucket to manage the flow of traffic. The token bucket revolves around the values of the CIR, Bc, and Tc. All of these values are mathematically related as follows:

CIR = Bc X 1000/Tc Bc = CIR X Tc/1000 Tc = Bc/CIR X 1000

Most FRTS references state that Bc = CIR X Tc. While this is true, it is commonly confusing because the Tc value as the frame-relay map-class accepts it is in milliseconds. As the CIR is in bits per second, milliseconds must be converted to seconds (1000ms per second). What the above relation basically says is that if you send Bc bits per Tc milliseconds you are averaging CIR bits per second.

The second formula that the shaping algorithm uses is the Be calculation. Be is effectively the difference between what the average output is (Bc per Tc, or CIR per second), and what the maximum output supported is (Be + Bc per interval, or AR per second) Be can be calculated as follows.

Be = (AR – CIR) X Tc/1000

Again, this value effectively specifies the difference between the average rate and the maximum rate per interval.



Now let’s apply the above calculation to the task in question. This task specifies that R5 supports a maximum transmission rate of 1536Kbps. R5 has two VCs into the Frame Relay cloud. The first, which connects to R3, is provisioned 128Kbps. The second, which connects to R4, is provisioned 512Kbps. Since the provisioned rate on the circuits are different than the access rate of the interface, shaping should be applied.

It is also specified that R5 should be allowed to burst up to the access rate for VC 504, but not for VC 513. The shaping interval (Tc) specified is 50ms. From this information we can infer that the following values should be configured on R5:

DLCI CIR (bps) Tc (ms) Bc (bits) Be (bits) 513 128000 50 6400 0 504 512000 50 25600 51200

Once the map-class has been defined, it can be applied in two ways, on a per interface basis or a per DLCI basis. When a class is applied with the interface level command frame-relay class [name], all DLCIs on that interface (and all DLCIs on all subinterfaces if configured on the main interface) will inherit the class.

R1(config)#map-class frame-relay FRTS R1(config-map-class)#frame-relay cir 640000 R1(config-map-class)#interface serial0/0 R1(config-if)#frame-relay traffic-shaping R1(config-if)#frame-relay class FRTS R1#show traffic-shape Interface Se0/0 Access Target Byte Sustain Excess Interval Increment Adapt VC List Rate Limit bits/int bits/int (ms) (bytes) Active 103 640000 10000 640000 0 125 10000 - 104 640000 10000 640000 0 125 10000 - 105 640000 10000 640000 0 125 10000 - 113 640000 10000 640000 0 125 10000 - 102 640000 10000 640000 0 125 10000 -



FRTS can also be applied on a per DLCI basis by issuing the class [class] command under the frame-relay interface-dlci [dlci] mode.

R1(config)#map-class frame-relay DLCI_103 R1(config-map-class)#frame-relay cir 512000 R1(config-map-class)#interface serial 0/0 R1(config-if)#frame-relay interface-dlci 103 R1(config-fr-dlci)#class DLCI_103 R1#show traffic-shape Interface Se0/0 Access Target Byte Sustain Excess Interval Increment Adapt VC List Rate Limit bits/int bits/int (ms) (bytes) Active 103 512000 8000 512000 0 125 8000 - 104 640000 10000 640000 0 125 10000 - 105 640000 10000 640000 0 125 10000 - 113 640000 10000 640000 0 125 10000 - 102 640000 10000 640000 0 125 10000 - Still confused? Try it some more! There are numerous examples of Frame Relay Traffic Shaping included in Internetwork Expert’s CCIE Routing & Switching Lab Workbook. Try the different sections on paper, and compare your answers to those provided.

Further Reading

Frame-Relay Traffic Shaping

http://www.internetworkexpert.com/resources/01700368.htm



Task 7.2 R1: ip cef ! class-map match-all ICMP match protocol icmp ! policy-map POLICE_ICMP class ICMP police cir 128000 bc 4000 ! interface FastEthernet0/0 service-policy output POLICE_ICMP Task 7.2 Breakdown Traffic policing is a very effective method to enforce a maximum threshold of bandwidth that a certain type of traffic cannot exceed. Traffic policing, also known as committed access rate (CAR) or rate-limiting, can be configured in two ways. The legacy application of CAR is to configure the rate-limit statement on the interface. CAR can also be configured using the modular quality of service command line interface (MQC) by issuing the police statement under the policy-map. In the above example, CAR is configured using the MQC. The first step in configuring traffic policing using the MQC is to define the traffic that will be policed. This is accomplished by creating a class-map. In the above task, it is requested that ICMP traffic be policed. ICMP can be matched using network based application recognition (NBAR) by issuing the match protocol command inside the class-map.

Note

NBAR requires Cisco Express Forwarding (CEF) switching. Ensure to issue the global configuration command ip cef whenever using the match protocol statement under a class-map.

The next step in configuring the MQC is to define the policy-map. The policy-map defines what QoS mechanisms will be applied to a particular traffic class. Under the policy-map, call the predefined class-map by issuing the class [name] command, and then specify the QoS mechanism to apply. In the case of CAR, the policy-map sub-command is police. By entering the police cir [bps] bc [burst] command, traffic that exceeds the configured burst per interval will be dropped.



Lastly, to apply the policy-map to the interface, issue the service-policy [input | output] [policy-map] interface command. The input or output keyword determines the direction that the policy-map is applied. To verify your configuration, issue the show policy interface [interface] command. R1#show policy-map interface fastethernet 0/0 FastEthernet0/0 Service-policy output: POLICE_ICMP Class-map: ICMP (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: protocol icmp police: cir 128000 bps, bc 4000 bytes conformed 0 packets, 0 bytes; actions: transmit exceeded 0 packets, 0 bytes; actions: drop conformed 0 bps, exceed 0 bps Class-map: class-default (match-any) 8 packets, 769 bytes 5 minute offered rate 0 bps, drop rate 0 bps

Match: any



5. Security Task 8.1 R3: ip access-list extended SYN_ATTACK permit tcp any host 183.1.2.100 eq www syn log-input permit ip any any ! interface Ethernet0/0 ip access-group SYN_ATTACK in SW2: ip access-list extended SYN_ATTACK permit tcp any host 183.1.2.100 eq www syn log-input permit ip any any ! interface Vlan82 ip access-group SYN_ATTACK in Task 8.1 Breakdown One way to track what type of traffic is being received in an interface is to apply an access-list that is being logged. By adding the log-input option to the end of an access-list, both the incoming interface and the source layer 2 address that the packet originated from on that particular segment will be included in the log message.



Task 8.2 R3: ip access-list extended SYN_ATTACK deny ip 183.1.0.0 0.0.255.255 any permit tcp any host 183.1.2.100 eq www syn log-input permit ip any any SW2: ip access-list extended SYN_ATTACK deny ip 183.1.0.0 0.0.255.255 any permit tcp any host 183.1.2.100 eq www syn log-input permit ip any any R6: ip access-list extended SYN_ATTACK deny ip 183.1.0.0 0.0.255.255 any permit ip any any ! interface Serial0/0/0 ip access-group SYN_ATTACK in Task 8.2 Breakdown A common practice to prevent address spoofing is to deny traffic that is originated from your IP address space from entering your network. Since your address space can only exist within your internal network, it is never valid when a packet is received on an outside interface of your network and it has been sourced from an address that is within your own address space. To prevent this, simply configure an extended IP access-list that denies traffic from your own address space, and apply it inbound on the outside interfaces of your network.



6. System Management Task 9.1 R2: rmon alarm 1 ifEntry.11.1 60 delta rising-threshold 15000 1 falling-threshold 5000 2 rmon event 1 trap IETRAP description "Above 15000 for ifInUcastPkts" rmon event 2 trap IETRAP description "Below 5000 for ifInUcastPkts" snmp-server host 183.17.1.100 IETRAP Task 9.1 Breakdown Remote Monitoring (RMON) can be used to create event driven SNMP traps based on arbitrary Management Information Bases (MIBs) that a particular device supports. RMON consists of two parts, events and alarms. Alarms define a particular situation that occurs on the router, such as an increase or decrease in a MIB value. In the above task, RMON is used to track interface utilization. An RMON alarm is defined by issuing the rmon alarm global configuration command, and tracks the value of a MIB based on the delta (relative change) of the variable, or the absolute change of the variable. In this example the alarm is used to track how many packets are received on the interface each minute. This is accomplished first by sampling the MIB ifEntry.11.1. The value is then again sampled 60 seconds later. The difference between these values are taken (delta), which shows us how many packets were received in that particular second. The second part of RMON consists of an event. An RMON event is the resulting action taken when an alarm is tripped. In the above case, an SNMP trap is generated when the amount of input packets on an interface exceeds 15000, and again when the amount of input packets falls below 5000. The SNMP trap is sent to a network management station (NMS) with the IP address 183.17.1.100 using the community string IETRAP.

Further Reading

Configuring RMON Support

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_c/fcfprt3/fcf016.htm



Task 9.2 R1 through R6: logging 183.1.17.100 logging facility local5 logging source-interface Loopback0 SW1 and SW2: logging 183.1.17.100 logging facility local6 logging source-interface Loopback0 Task 9.2 Breakdown Syslog is a service used to collect and store device logs. To configure syslog logging, simply enter the global configuration command logging [address], where address is the IP address of the server running the syslog service. By default, syslog messages are sourced from the IP address of the outgoing interface used to reach the syslog server. To adjust the source address of syslog packets, use the global configuration command syslog source-interface [interface]. The logging ‘facility’ is a way to format log messages so that they can be more easily parsed from the syslog server’s log files. To change the facility that syslog messages are generated in, issue the global command logging facility [facility].

Further Reading

Enabling Management Protocols: Syslog

http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/as5xipmo/sysmgt.htm



Task 9.3 R3: ntp server 204.12.1.254 ntp peer 150.1.6.6 R6: ntp server 54.1.1.254 R1, R2, and SW1: ntp server 150.1.3.3 R4, R5, and SW2: ntp server 150.1.6.6 Task 9.3 Breakdown Network Time Protocol (NTP) is a standards based protocol used to keep consistent time throughout the devices in the network. NTP uses a ‘stratum’, or hop count, to determine how far away neighboring devices are from the master time source in the network. Devices with a lower stratum are considered to be more reliable time sources. To enable NTP, issue the global configuration command ntp [server | peer] [address]. An NTP server relationship is when a client gets time from the server. An NTP peering relationship is when two devices can get time from each other depending on which device has the lower stratum.

Further Reading

Performing Basic System Management: Configuring NTP

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_c/fcfprt3/fcf012.htm



Task 9.4 R3: ntp authentication-key 1 md5 CISCO ntp authenticate ntp trusted-key 1 ntp server 204.12.1.254 key 1 R6: ntp authentication-key 1 md5 CISCO ntp authenticate ntp trusted-key 1 ntp server 54.1.1.254 key 1 Task 9.4 Breakdown

Further Reading

Understanding Network Time Protocol (NTP) Authentication

http://internetworkexpert.com/resources/01700369.htm



7. IP Services Task 10.1 R2: interface Serial0/0 ip accounting precedence input ip accounting precedence output ! ip accounting-threshold 50000 R3: interface Serial1/0 ip accounting precedence input ip accounting precedence output ! ip accounting-threshold 50000 Task 10.1 Breakdown IP accounting can be used to track how many packets are received or sent out an interface, how many packets violate an access-list policy configured on an interface, and track packets with an IP precedence value that are sent or received out an interface. To configure IP accounting, issue the ip accounting interface level command. To account for packets based on IP precedence values, add the precedence keyword to the accounting statement. To configure how many entries are kept in the local accounting table, issue the global command ip accounting-threshold. To show entries in the accounting table, issue the show ip accounting command.

Further Reading

Configuring Precedence Accounting

http://www.cisco.com/en/US/products/sw/iosswrel/ps1820/products_feature_guide09186a00800f4892.html



Task 10.2 R5: interface Ethernet0/0 standby 1 ip 183.1.58.254 standby 1 preempt standby 1 track Serial0/0 100 SW2: interface FastEthernet0/15 standby 1 ip 183.1.58.254 standby 1 priority 50 standby 1 preempt Task 10.2 Breakdown Hot Standby Routing Protocol (HSRP) is a method used to offer default gateway redundancy to end stations in the network. HSRP defines two roles, the active router and the standby router. The active router is responsible for replying for ARP requests sent to the virtual IP address. Therefore, when a hosts ARPs for the configured virtual default gateway, the active router responds on its behalf. In the case that the active router becomes unreachable, or relinquishes active status due to an interface going down, the standby router assumes the active role and begins to respond to traffic sent to the virtual address. HSRP uses a priority value to determine which device on the segment is the active router. A higher value is better, and the default value is 100. Once a router is elected the active router, its status cannot be taken away unless it becomes unreachable, or a device with a higher priority is configured to preempt the election. Preemption means that the router will forcibly take over the active status. In addition to losing active status due to becoming unreachable, HSRP offers the ability to decrement the device’s priority value when an interface goes down.

By issuing the track option of the standby statement, a router can be configured to watch the status of an interface. If the line protocol of the interface goes down, the router’s priority is decremented by a default value of 10. This value is configurable.

To verify HSRP configuration, issue the show standby command.

Further Reading

Using HSRP for Fault-Tolerant IP Routing

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/cs009.htm



Task 10.3 R3: access-list 2 permit 183.1.0.0 0.0.255.255 ! ip nat inside source list 2 interface Ethernet0/0 overload ! interface Ethernet0/0 ip nat outside ! interface Serial1/0 ip nat inside ! interface Serial1/1 ip nat inside Task 10.3 Breakdown Network Address Translation (NAT) is an effective way to hide the source IP address of a packet as it leaves your network. When NAT has been implemented, devices outside your network need not have specific reachability information about your internal network. For this reason, NAT can be considered a security mechanism, since sessions cannot be started from outside the network without specific routing information about your internal network. The first step in configuring NAT is to define the inside local address pool. Inside local addresses are those which will have their addresses translated as they leave the network. Next, the inside local address pool should be bound to the NAT process by issuing the ip nat inside source list [access-list] command. This instructs the NAT process to translate the source addresses of hosts matched in the access-list. The latter part of the ip nat statement includes the option of translating to a pool of addresses, or a single interface. In the above case, all traffic sourced from the 183.1.0.0 network is translated to the IP address that is shared with the interface Ethernet0/0. This is known as Port Address Translation (PAT), since a state table of port numbers must be maintained so that multiple inside hosts can share the same globally routable IP address. Finally, the ‘inside’ and ‘outside’ addresses of the NAT process should be defined. In the case of an ‘inside source’ translation, packets matched by the inside local access-list will have their source addresses translated as they come in the inside interface and exit the outside interface.

Further Reading

How NAT Works

http://www.cisco.com/warp/public/556/nat-cisco.shtml

IEWB-RS Solutions Guide Lab 2

Copyright © 2005 Internetwork Expert 2 - 1

1. Catalyst 3550 Task 1.1 SW1: vtp domain IE vtp password CISCO vtp pruning vlan 3,5,6,8,10,26,33,52,783 ! interface FastEthernet0/1 no switchport ip address 132.1.17.7 255.255.255.0 ! interface FastEthernet0/2 switchport access vlan 26 ! interface FastEthernet0/3 switchport access vlan 3 ! interface FastEthernet0/5 switchport access vlan 5 ! interface FastEthernet0/9 switchport access vlan 10 ! interface FastEthernet0/10 switchport access vlan 10 ! interface FastEthernet0/24 switchport access vlan 783 ! interface Vlan783 ip address 204.12.1.7 255.255.255.0 SW2: vtp domain IE vtp mode client vtp password CISCO ! interface FastEthernet0/3 switchport access vlan 33 ! interface FastEthernet0/5 switchport access vlan 52 ! interface FastEthernet0/24 switchport access vlan 52 ! interface Vlan8 ip address 132.1.8.8 255.255.255.0 ! interface Vlan783 ip address 204.12.1.8 255.255.255.0


2 - 2 Copyright © 2005 Internetwork Expert

Task 1.1 Breakdown In VTP there are three modes of operation. These modes are server, client, and transparent. A bridge in server mode can add, remove, or change parameters of the VTP domain. VTP clients listen for updates from servers, install parameters advertised, and pass these advertisements on. A bridge running in VTP transparent mode, as the name implies, passes VTP updates on transparently without installing them. A bridge running in transparent mode effectively does not participate in VTP with the rest of the domain, and keeps a separate local copy of the VTP database. The Catalyst 3550 series switch defaults to VTP server mode. To change the VTP operational mode issue the vtp [server | client | transparent] VLAN database or global configuration command. In the above task SW1 is left as server, as it “should be responsible for creating and modifying all VLAN parameters”, while SW2 is set to client mode so it is “not…able to create or modify any VLAN parameters” but is able to “install VLANs created or modified on SW1.” This task states that “traffic for VLANs not locally assigned should not be received over any trunk links throughout the VTP domain.” By default, all VLANs are allowed to be sent over any trunk link in the VTP domain. Therefore broadcast frames and frames destined for unknown unicast addresses will be sent over all trunks throughout the domain. This behavior is undesirable when one or more switches throughout the VTP domain receive traffic for VLANs that they do not have locally assigned and are not in the transit path for. In order to reduce this unnecessary traffic VTP offers a feature known as pruning. VTP pruning allows a switch to communicate with its directly connected neighbors about what VLANs they have locally assigned and are in the transit path for. Therefore VLANs that are unnecessary can be “pruned” off of the trunked interface. VTP pruning can be enabled by issuing the VLAN database or global configuration command vtp pruning.



Task 1.2 SW1: interface FastEthernet0/13 switchport trunk encapsulation isl channel-group 1 mode desirable ! interface FastEthernet0/14 switchport trunk encapsulation isl channel-group 1 mode desirable ! interface FastEthernet0/15 switchport trunk encapsulation isl channel-group 1 mode desirable ! interface Port-channel1 switchport trunk encapsulation isl SW2: interface FastEthernet0/13 switchport trunk encapsulation isl channel-group 1 mode auto ! interface FastEthernet0/14 switchport trunk encapsulation isl channel-group 1 mode auto ! interface FastEthernet0/15 switchport trunk encapsulation isl channel-group 1 mode auto ! interface Port-channel1 switchport trunk encapsulation isl


Task 1.2 Breakdown In order to increase bandwidth capacity between switches and high end servers, Cisco offers a feature known as EtherChannel. EtherChannel allows multiple Ethernet interfaces to be bound together as if they were one logical link, and be seen as a single interface from the spanning-tree process. To create an EtherChannel issue the interface command channel-group [num] mode [on | desirable | auto | active | passive]. The channel ‘mode’ determines which, if any, protocol is used to automatically negotiate the channel. The Cisco proprietary negotiation for EtherChannel is known as Port Aggregation Protocol (PAgP). PAgP is enabled by enabling a channel in either the ‘auto’ or ‘desirable’ mode. When an interface runs PAgP in auto mode it will listen for PAgP packets received on the interface, and agree to negotiate once these packets are received. An interface in auto mode will not initiate negotiation through PAgP. When an interface runs in desirable mode it will initiate PAgP negotiation. The open standard for EtherChannel negotiation is Link Aggregation Control Protocol (LACP), and is defined in IEEE 802.3ad. To disable both PAgP and LACP, set the channel mode to ‘on’ The channel modes are as follows:

Mode Result On PAgP and LACP disabled (no negotiation) Desirable Actively negotiate PAgP Auto Passively listen for PAgP Active Actively negotiate LACP Passive Passively listen for LACP

The following mode combinations will result in a successful channel:

Device A Device BOn On Desirable DesirableDesirable Auto Active Active Active Passive



Further Reading Configuring EtherChannels

Pitfall Typical problems with EtherChannel configurations involve the mismatch in compatible channel modes as well as a mismatch in the configuration of the member interfaces. To ensure that all member interfaces maintain the exact same configuration, put them in the channel with the channel-group interface command, and then apply all subsequent configuration to the port-channel interface. Note that for layer 3 EtherChannel configurations, member interfaces must first be designated as routed interfaces before being put them in the channel-group.


http://www.cisco.com/en/US/products/hw/switches/ps646/products_configuration_guide_chapter09186a00801a6b7f.html


Task 1.3 R6: interface GigabitEthernet0/0.6 encapsulation dot1Q 6 native ip address 132.1.6.6 255.255.255.0 ! interface GigabitEthernet0/0.26 encapsulation dot1Q 26 ip address 132.1.26.6 255.255.255.0 SW1: interface FastEthernet0/6 switchport trunk encapsulation dot1q switchport trunk native vlan 6 switchport mode trunk switchport nonegotiate Task 1.3 Breakdown The Catalyst 3550 is a layer 3 capable switch that can be used to route traffic between VLANs. However for layer 2 only platforms an external router must be used to route traffic between VLANs. In the latter setup traffic is sent over a trunk link to a router where is it de-encapsulated, routed, then re-encapsulated with the new VLAN header and sent back to the switch. Since only one physical interface is involved in this routing process the setup is typically referred to as “router-on-a-stick”. To configure router-on-a-stick, create a subinterface on the router and issue the encapsulation [isl | dot1q] [vlan] [native] command. When ISL is used, the native keyword is not required.

Further Reading Routing Between VLANs Overview Configuring Routing Between VLANs with ISL Encapsulation Configuring Routing Between VLANs with 802.1Q Encapsulation


http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fswtch_c/swprt6/xcfvl.htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fswtch_c/swprt6/xcfvlisl.htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fswtch_c/swprt6/xcfvl80q.htm



As previously mentioned the native VLAN on an 802.1q trunk link is not tagged with a VLAN header. To change the native VLAN issue the switchport trunk native vlan [num] interface level command.

Dynamic Trunking Protocol (DTP), as the name implies, is the protocol used to automatically negotiate a trunk link. DTP supports the auto negotiation of both ISL and 802.1q. By default all ports on the Catalyst 3550 are dynamic desirable ports, which will aggressively attempt to negotiate trunking through DTP. When an interface is statically set to ‘mode trunk’ on both sides there is no advantage of continuing to run DTP. To disable DTP and the auto negotiation of trunking issue the interface level command switchport nonegotiate. Interfaces running in ‘mode access’ automatically have DTP negotiation disabled. To verify whether DTP is enabled issue the show interface switchport command and look for the output Negotiation of Trunking.

Pitfall When configuring router-on-a-stick with 802.1q encapsulation ensure to add the native keyword on to the appropriate VLAN. Otherwise the router will not recognize the traffic since it is not encapsulated with a VLAN header as expected.


Task 1.4 SW1: aaa new-model aaa authentication login default none aaa authentication dot1x default group radius ! dot1x system-auth-control ! interface FastEthernet0/9 switchport mode access dot1x port-control auto ! interface FastEthernet0/10 switchport mode access dot1x port-control auto ! ip radius source-interface Loopback0 ! radius-server host 204.12.1.100 radius-server key CISCO Task 1.4 Breakdown In order to provide added security at the access layer of the network 802.1x defines username and password based authentication for Ethernet switches. To enable 802.1x authentication first issue the global configuration command dot1x system-auth-control (prior to 12.1(14)EA1 this command is not required). Next dot1x must be enabled on a per interface basis by issuing the interface level command dot1x port-control [mode], where mode is either auto, forced-authorized, or forced-unauthorized. Forced-authorized is the default mode, and indicates that authorization is not required for access into the network. Forced-unauthorized is the opposite, and dictates that clients can never access the network through this port. When the state is set to auto dot1x is enabled for username and password authentication. In order to centrally manage users dot1x integrates with Authentication Authorization and Accounting (AAA) to offload username and password databases to RADIUS or TACACS. Therefore to enable dot1x authentication AAA must be enabled. The first step in enabling AAA is to issue the global command aaa new-model. This command starts the AAA process. Next the RADIUS or TACACS server’s IP address must be defined along with its corresponding key value. This is accomplished with the radius-server global configuration command for RADIUS. Additionally since network devices typically have multiple interfaces running IP it is common practice to force the router/switch to generate radius packets from a single interface instead of relying on what the routing table dictates the outgoing interface to be. This is accomplished with the ip radius source-interface command for RADIUS based configurations.




After AAA is enabled the authentication policy must be defined. This is accomplished by issuing the aaa authentication dot1x command. In the above case the default group is used. The default group applies to all interfaces and lines of the device in question.

Pitfall Once AAA is enabled for dot1x it is automatically enabled for all lines and interfaces. This means that unless some other line authentication is defined for the console, aux, or vty, the username and password combination for dot1x must be used. In the above task no authentication is used for login by issuing the aaa authentication login default none command. Unless you have a username/password combination locally defined or some other type of login authentication enabled you will be locked out of the console if you exit! For this reason be sure to give yourself an out when configuring AAA for any application. Best practices usually dictates that this last resort method be the local user database.

Further Reading Configuring 802.1X Port-Based Authentication Doc CD: AAA

http://www.cisco.com/en/US/products/hw/switches/ps646/products_configuration_guide_chapter09186a00801a6b34.html

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_c/fsaaa/index.htm


2. Frame-Relay Task 2.1 R1: interface Serial0/0 ip address 132.1.0.1 255.255.255.0 encapsulation frame-relay R2: interface Serial0/0 ip address 132.1.0.2 255.255.255.0 e ncapsulation frame-relay

R3: interface Serial1/0 ip address 132.1.0.3 255.255.255.0 encapsulation frame-relay R4: interface Serial0/0 ip address 132.1.0.4 255.255.255.0 encapsulation frame-relay Task 2.1 Breakdown By default Frame Relay Inverse-ARP is enabled for all supported protocols on all VCs on an interface. Therefore to enable Frame Relay on a circuit utilizing Inverse-ARP the only configuration command required is encapsulation frame-relay. To ensure that this dynamic mapping was successful use the show frame-relay map command.

Verification R1#show frame-relay map Broadcast support by default Serial0/0 (up): ip 132.1.0.2 dlci 102(0x66,0x1860), dynamic, broadcast,, status defined, active Serial0/0 (up): ip 132.1.0.3 dlci 103(0x67,0x1870), dynamic, InARP broadcast,, status defined, active Serial0/0 (up): ip 132.1.0.4 dlci 104(0x68,0x1880), dynamic, broadcast,, status defined, active




Task 2.2 R3: interface Serial1/1 encapsulation frame-relay ! interface Serial1/1.1 point-to-point ip address 132.1.35.3 255.255.255.0 frame-relay interface-dlci 315 R5: interface Serial0/0 encapsulation frame-relay ! interface Serial0/0.1 point-to-point ip address 132.1.35.5 255.255.255.0 frame-relay interface-dlci 513 Task 2.2 Breakdown The reason that NBMA media requires explicit layer 3 to layer 2 resolution is that the network is in reality a collection of point-to-point links. When a packet is sent to an NBMA media the router must know which VC to send the packet out. However when there is only one VC on the interface (point-to-point) this is not an issue, therefore when using a point-to-point subinterface NBMA media does not require any explicit protocol mapping. To configure a point-to-point Frame-Relay interface first issue the encapsulation frame-relay command on the main interface. Next create a point-to-point subinterface by issuing the interface serial [slot/port] point-to-point. Next assign the virtual circuit to the interface by issuing the frame-relay interface-dlci [dlci] command. All additional logical configuration (IP addressing, etc) should be performed on this interface.

Pitfall Frame Relay Inverse-ARP only works between devices that have a direct VC between them. This means that spokes of a partial meshed topology can not use Inverse-ARP to resolve each others layer 3 addresses. Instead they must use some other method such as static frame-relay map statements, point-to-point subinterfaces (which don’t need layer 3 to layer 2 resolution), layer 3 routing, etc.



Note

The frame-relay interface-dlci command simply applies the VC to the interface. By default all VCs are assigned to the main interface. This command can be used to assign a VC to either a multipoint or point-to-point subinterface, or to apply specific parameters to a VC such as traffic-shaping. A common misconception is that this command relates to Frame Relay Inverse-ARP, which it in fact does not.

Verification R3#show frame-relay map

point-to-point circuit No protocol resolution required

Serial1/1.1 (up): point-to-point dlci, dlci 315(0x13B,0x4CB0),

broadcast status defined, active

Broadcast support by default

Task 2.3 R6: interface Serial0/0/0 ip address 54.1.2.6 255.255.255.0 encapsulation frame-relay frame-relay map ip 54.1.2.254 100 broadcast no frame-relay inverse-arp



3. HDLC/PPP Task 3.1 R2: interface Serial0/1 compress stac R3: interface Serial1/3 compress stac clockrate 64000 Task 3.2 R4: username ROUTER5 password 0 CISCO ! interface Serial0/1 encapsulation ppp ppp authentication chap ppp chap hostname ROUTER4 R5: username ROUTER4 password 0 CISCO ! interface Serial0/1 encapsulation ppp clockrate 64000 ppp chap hostname ROUTER5 Task 3.2 Breakdown Although this section did not explicitly ask for CHAP authentication the usage of the word ‘challenge’ implies that CHAP authentication is required. CHAP authentication uses the concept of a challenge and a response where as PAP authentication does not.

In this task R4 is configured to challenge R5 using CHAP, but R5 will not challenge R4. To enable a router to challenge a remote device using CHAP use the ppp authentication chap interface command. RFC 1994 (PPP Challenge Handshake Authentication Protocol) defines this role as the authenticator. By default a router will allow itself to be authenticated via CHAP authentication. The device that is being authenticated is defined by the RFC as the peer. To configure a router to refuse to be authenticated via CHAP use the ppp chap refuse interface command. When this command is enabled the router will refuse the Authentication-Protocol Configuration Option for CHAP during the Link Establishment phase. The default state for this command is to be disabled (no ppp chap refuse).



When R4 initiates the CHAP challenge the username sent comes from the interface level command ppp chap hostname ROUTER4. If this command were not to be configured the hostname of R4 would be used for the challenge. When R5 receives the challenge it looks in the local username database for an entry matching ROUTER4. The password associated with this entry is then passed through the CHAP MD5 hash algorithm along with a negotiated seed value known as the magic number. The resulting hash is then sent back to R4. When R4 receives this hash value it looks up the corresponding username (ROUTER5 based on R5’s interface ppp chat hostname command) and derives its own hash. Once the locally generated hash and the received hash are verified identical authentication is successful. For this reason the password must match on both sides of the link for CHAP authentication. 4. Interior Gateway Routing Task 4.1 R1: interface Serial0/0 ip ospf network point-to-multipoint ! router ospf 1 router-id 150.1.1.1 network 132.1.0.1 0.0.0.0 area 0 network 150.1.1.1 0.0.0.0 area 0 R2: interface Serial0/0 ip ospf network point-to-multipoint ! router ospf 1 router-id 150.1.2.2 network 132.1.0.2 0.0.0.0 area 0 R3: interface Serial1/0 ip ospf network point-to-multipoint ! router ospf 1 router-id 150.1.3.3 network 132.1.0.3 0.0.0.0 area 0 R4: interface Serial0/0 ip ospf network point-to-multipoint ! router ospf 1 router-id 150.1.4.4 network 132.1.0.4 0.0.0.0 area 0 network 150.1.4.4 0.0.0.0 area 0


Task 4.1 Breakdown As previously discussed the OSPF network types that support a DR/BDR election are broadcast and non-broadcast. Since the Frame Relay segment between R1, R2, R3, and R4 is a multipoint segment the OSPF network type point-to-point cannot be used. The two configurable network types that are left are point-to-multipoint and point-to-multipoint non-broadcast. Point-to-multipoint non-broadcast requires the unicasting of updates through the neighbor statement, and is therefore eliminated in this case. Hence the OSPF network-type choice for the segment between R1, R2, R3, and R4 should be point-to-multipoint. Task 4.2 R1: interface FastEthernet0/0 ip ospf authentication-key CISCO ! router ospf 1 area 17 authentication network 132.1.17.1 0.0.0.0 area 17 SW1: ip routing ! interface FastEthernet0/1 ip ospf authentication-key CISCO ! router ospf 1 router-id 150.1.7.7 area 17 authentication network 132.1.17.7 0.0.0.0 area 17 Task 4.2 Breakdown In the above configuration the adjacency between R1 and SW1 is authenticated with “area” authentication. Interface level authentication with the ip ospf authentication would also have been a valid option.




Task 4.3 R3: router ospf 1 passive-interface Ethernet0/0 passive-interface Ethernet0/1 network 132.1.3.3 0.0.0.0 area 3 network 132.1.33.3 0.0.0.0 area 33 Task 4.3 Breakdown In order to prevent hello packets from exiting an interface that is running OSPF use the passive-interface command under the OSPF process. Unlike distance vector protocols such as RIP configuring an interface as passive in OSPF will prevent the device from learning any network reachability information out the interface in question. This is due to the fact that OSPF, like IS-IS and EIGRP, uses periodic hello packets to establish and maintain active neighbor adjacencies.

Note To get the effect of the distance vector passive interface (i.e. receive routes but not send routes) in OSPF use the interface level command ip ospf database-filter all out. This command will allow adjacency to be established, but will not allow LSA advertisements to be sent out the interface.



Task 4.4 R2: router eigrp 10 network 132.1.23.2 0.0.0.0 network 150.1.2.2 0.0.0.0 no auto-summary eigrp router-id 150.1.2.2 R3: router eigrp 10 network 132.1.23.3 0.0.0.0 network 132.1.35.3 0.0.0.0 network 150.1.3.3 0.0.0.0 no auto-summary e igrp router-id 150.1.3.3

R4: router eigrp 10 network 132.1.45.4 0.0.0.0 no auto-summary e igrp router-id 150.1.4.4

R5: router eigrp 10 network 132.1.35.5 0.0.0.0 network 132.1.45.5 0.0.0.0 network 150.1.5.5 0.0.0.0 no auto-summary eigrp router-id 150.1.5.5 R6: router eigrp 10 network 54.1.2.6 0.0.0.0 network 150.1.6.6 0.0.0.0 no auto-summary eigrp router-id 150.1.6.6



Task 4.5 R2: router eigrp 10 network 132.1.26.2 0.0.0.0 neighbor 132.1.26.6 FastEthernet0/0 R6: router eigrp 10 network 132.1.26.6 0.0.0.0 neighbor 132.1.26.2 GigabitEthernet0/0.26 Task 4.6 R6: interface GigabitEthernet0/0.26 ip summary-address eigrp 10 200.0.0.0 255.255.252.0 5 Task 4.7 R5: router eigrp 10 redistribute connected metric 1 1 1 1 1 route-map CONNECTED_TO_EIGRP ! route-map CONNECTED_TO_EIGRP permit 10 match interface Ethernet0/0 Ethernet0/1 R6: router eigrp 10 redistribute connected metric 1 1 1 1 1 route-map CONNECTED_TO_EIGRP ! route-map CONNECTED_TO_EIGRP permit 10 match interface GigabitEthernet0/0.6 Task 4.8 R5: interface Serial0/0.1 point-to-point backup delay 60 300 backup interface Serial0/1



Task 4.9 SW1: router rip version 2 network 150.1.0.0 network 204.12.1.0 no auto-summary SW2: ip routing ! router rip version 2 network 132.1.0.0 network 150.1.0.0 network 204.12.1.0 no auto-summary Task 4.10 SW1: router rip offset-list EVEN_SECOND_OCTET in 16 Vlan783 ! ip access-list standard EVEN_SECOND_OCTET permit 0.0.0.0 255.254.255.255 Task 4.10 Breakdown The least significant bit of a binary number determines whether the number is even or odd. If the least significant bit is not set the number must be even. If the least significant bit is set the number must be odd. This always holds true since all other places in the binary table are even numbers, and any combination of even numbers plus an odd number results in an odd number. Likewise any combination of even numbers results in an even number.

Place 128 64 32 16 8 4 2 1 Even X X X X X X X 0 Odd X X X X X X X 1

Where “X” is either 0 or 1.



Since only the least significant bit determines whether a number is even or odd it is the only bit that needs to be checked. Therefore the resulting wildcard mask is 254, or in binary as follows:

Place 128 64 32 16 8 4 2 1 Wildcard 1 1 1 1 1 1 1 0

Where “0” is check and “1” is ignore.

The most common way to filter off a routing prefix in a distance vector protocol is to use the distribute-list command. A distribute-list is a way to apply an access-list to routing protocol updates. A routing prefix may also be filtered out by poisoning the metric or distance of the route. To change the metric of a distance vector prefix use the routing process level command offset-list. In RIP a metric of 16 is “infinite”. When a prefix has a metric of 16 it is considered unreachable, and cannot be installed in the routing table. The first solution to this task adds a metric of 16 to the incoming prefixes, hence invalidating them. The second solution is to use the distance command. A distance of 255 is infinite. Any prefix with a distance of 255 is considered unreachable, and cannot be installed in the routing table. To change the distance of a prefix use the distance [distance] [neighbor] [wildcard] [access-list] where distance is the desired distance, neighbor is the originating address of the prefix, wildcard is a wildcard mask used to check the neighbor field, and access-list is a standard access-list number.

Note

The distance of external EIGRP cannot be changed on a per prefix basis.



Caution

The neighbor field in the distance command may not always be the interface address of the directly connected neighbor. In the case of OSPF this address is the router-id of the originating router into the area. In the case of BGP it is the address used to establish the peering relationship. It is not necessary to remember which address is used in which protocol, but instead you must only know where this value is located. The address used in the neighbor field is the from w.x.y.z address in the sh ip route output: R3#sh ip route 1.1.1.1 Routing entry for 1.1.1.1/32 Known via "isis", distance 115, metric 10, type level-2 Redistributing via isis Last update from 13.0.0.1 on Ethernet0/0, 01:17:11 ago Routing Descriptor Blocks: * 13.0.0.1, from 1.1.1.1, via Ethernet0/0 Route metric is 10, traffic share count is 1



Task 4.11 R2: router eigrp 10 d istance eigrp 90 109

R3: router eigrp 10 redistribute ospf 1 metric 1 1 1 1 1 ! router ospf 1 r edistribute eigrp 10 subnets

R4: router eigrp 10 redistribute ospf 1 metric 1 1 1 1 1 ! router ospf 1 redistribute eigrp 10 subnets SW1: router ospf 1 redistribute rip subnets ! router rip redistribute ospf 1 metric 1 Task 4.11 Breakdown The above task instructs us to redistribute between OSPF and EIGRP on R3 and R4, but does not instruct us to redistribute on R2. The problem with this situation is that R2 will not advertise external EIGRP routes to R6, as their feasible distance will be inaccessible. This is due to the fact that OSPF’s administrative distance of 110 is preferred over external EIGRP’s administrative distance of 170. For example, R1 advertises the 132.X.17.0/24 network into OSPF. Both R2 and R3 learn this as an Inter-Area OSPF route with an administrative distance of 110. R3 then redistributes this OSPF route into EIGRP. R2 then learns about this external EIGRP prefix, which has a distance of 170, through the Serial0/1 link to R3. R2 then chooses to install the OSPF route due to the lower administrative distance. This in turn causes the EIGRP route to have an inaccessible feasible distance, as seen in the show ip eigrp topology output, and therefore not advertise the prefix to R6. In order to solve this the administrative distance must be modified on R2 in such a way that external EIGRP is preferred over OSPF. In the above configuration this is accomplish with the distance eigrp 90 109 command under R2’s EIGRP process.


5. Exterior Gateway Routing Task 5.1 R1: router bgp 300 neighbor 132.1.0.4 remote-as 300 neighbor 132.1.17.7 remote-as 400 R2: router bgp 300 neighbor 132.1.0.4 remote-as 300 neighbor 132.1.26.6 remote-as 100 R3: router bgp 300 neighbor 132.1.0.4 remote-as 300 neighbor 132.1.35.5 remote-as 200 R4: router bgp 300 neighbor 132.1.0.1 remote-as 300 neighbor 132.1.0.1 route-reflector-client neighbor 132.1.0.2 remote-as 300 neighbor 132.1.0.2 route-reflector-client neighbor 132.1.0.3 remote-as 300 neighbor 132.1.0.3 route-reflector-client neighbor 132.1.45.5 remote-as 200 R5: router bgp 200 neighbor 132.1.35.3 remote-as 300 neighbor 132.1.45.4 remote-as 300 R6: router bgp 100 neighbor 54.1.2.254 remote-as 54 neighbor 132.1.26.2 remote-as 300 SW1: router bgp 400 neighbor 132.1.17.1 remote-as 300 neighbor 204.12.1.8 remote-as 400 neighbor 204.12.1.254 remote-as 54 SW2: router bgp 400 neighbor 204.12.1.7 remote-as 400




Task 5.1 Breakdown Since R4 is the only device that establishes a peering relationship with all devices in AS 300 it is implied that R4 must perform route-reflection for these devices. Task 5.2 R5: router bgp 200 neighbor 192.10.1.254 remote-as 254 neighbor 192.10.1.254 password CISCO Task 5.3 SW1: router bgp 400 neighbor 204.12.1.254 remote-as 54 neighbor 204.12.1.254 local-as 100 no-prepend Task 5.3 Breakdown This task states that SW1 has recently been acquired from AS 100, but AS 54 has not updated its configuration yet. This is where the BGP local-AS feature comes into play. The BGP local-AS feature is typically used in a case similar to what is described here, when one of more devices are acquired from a different autonomous system. In order to keep traffic flowing while changes are made to various providers and customers, the newly configured device can be configured to make its peers believe it is in a different AS. By adding the neighbor 204.12.1.254 local-as 100 no-prepend statement on to SW1, BB2 will continue to see SW1 as being in AS 100. Additionally if the no-prepend option is not configured R6 will drop these routes, as its own AS number will be in the path of the routes is receives.

Further Reading Configuring the BGP Local-AS Feature BGP Hide Local-Autonomous System


http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t11/ft11bhla.htm


Task 5.4 SW1: router bgp 400 neighbor 204.12.1.254 route-map STOP_TRANSIT_TO_AS_254 out ! ip as-path access-list 1 permit _254$ ! route-map STOP_TRANSIT_TO_AS_254 deny 10 match as-path 1 ! route-map STOP_TRANSIT_TO_AS_254 permit 20 Task 5.4 Breakdown The above task states that AS 400 does not want to provide transit for AS 54 to get to 254. Assuming that AS 54 has not configured static routes to get to AS 254 through AS 400 the simplest way to accomplish this task is to stop advertising prefixes from AS 254 to AS 54. These prefixes can be matched in a single statement using a regular expression. Regular expressions are stings of special characters that can be used to search and find patterns in an AS path. The regular expression characters are as follows: Character Meaning ^ Start of string $ End of string [] Range of characters - Used to specify range ( i.e. [0-9] ) ( ) Logical grouping . Any single character * Zero or more instances + One or more instance ? Zero or one instance _ (underscore)

Comma, open or close brace, open or close parentheses, start or end of string, or space

In order to match one of these characters within the string the escape sequence \ may be used.



Some commonly used regular expressions include: Expression Meaning .* Anything ^$ Locally originated routes ^100_ Learned from AS 100 _100$ Originated in AS 100 _100_ Any instance of AS 100 ^[0-9]+$ Directly connected ASs ^[0-9]+(_[0-9]+)?$ Directly connected ASs and/or their customers ^$.*$$ Routes originated in confederation peers ^($.*$)?$ Locally originated and/or routes originated in confederation

peers

Note Since the question mark indicated context sensitive help in the IOS, the IOS escape sequence of CTRL-V must be entered before specifying a question mark in a regular expression.




Task 5.5 R5: router bgp 200 network 132.1.5.0 mask 255.255.255.0 aggregate-address 132.1.0.0 255.255.0.0 summary-only neighbor 132.1.35.3 route-map DENY_AGGREGATE out neighbor 132.1.45.4 route-map DENY_AGGREGATE out ! ip prefix-list DENY_AGGREGATE seq 5 permit 132.1.0.0/16 ! route-map DENY_AGGREGATE deny 10 match ip address prefix-list DENY_AGGREGATE ! route-map DENY_AGGREGATE permit 20 Task 5.5 Breakdown When a prefix is aggregated in BGP the default behavior is to advertise the all subnets of the aggregate, plus the aggregate to all BGP speaking neighbors. Since the main goal of BGP aggregation is to reduce the amount of routing prefixes required in the global BGP table this default behavior may not be desired. To prevent the advertisement of subnets that make up the aggregate add the summary-only keyword on to the aggregate-address statement. Once the summary-only keyword has been configured subnets of the aggregate are suppressed. This means that these subnets are not candidate to be advertised to other BGP speaking neighbors. In order to have complete control over which devices receive which prefixes the unsuppress-map can be used to selectively advertise previously suppressed routes on a per-neighbor basis. To accomplish the given task the above configuration first aggregates the prefixes in question with the summary-only keyword. Next the aggregate is denied from being advertised to all other BGP neighbors. This is accomplished by creating a prefix-list which is an exact match for the aggregate route. Finally an unsuppress-map is applied to the other BGP neighbors.

Further Reading Understanding Route Aggregation in BGP

http://www.cisco.com/warp/public/459/aggregation.html



6. IP Multicast Task 6.1 R1: ip multicast-routing ! interface Ethernet0/0 ip pim sparse-mode ! interface Serial0/0 ip pim sparse-mode ! ip pim rp-address 150.1.2.2 R2: ip multicast-routing ! interface Ethernet0/0 ip pim sparse-mode ! interface Serial0/0 ip pim sparse-mode ! ip pim rp-address 150.1.2.2 R3: ip multicast-routing ! interface Ethernet0/0 ip pim sparse-mode ! interface Ethernet0/1 ip pim sparse-mode ! interface Serial1/0 ip pim sparse-mode ! ip pim rp-address 150.1.2.2 ! ip mroute 0.0.0.0 0.0.0.0 132.1.0.2 R6: ip multicast-routing ! interface GigabitEthernet0/0.6 ip pim sparse-mode ! interface GigabitEthernet0/0.26 ip pim sparse-mode ! ip pim rp-address 150.1.2.2



SW1: ip multicast-routing ! interface FastEthernet0/1 ip pim sparse-mode ! interface Vlan783 ip pim sparse-mode ! ip pim rp-address 150.1.2.2 Task 6.1 Breakdown This above section states to configure IP multicast routing utilizing PIM sparse mode. Since sparse mode requires the definition of a rendezvous point (RP) static RP assignments were defined on each router pointing to R2’s Loopback 0 interface. This included using the ip pim rp-address command on the RP itself. Since R2 will be the RP it is important to ensure that all routers can reach R2’s Loopback 0 address. If any router can not reach R2’s Loopback 0 address that particular router will not be able to participate in the multicast routing process. If PIM spare-dense mode was used and the RP was unreachable the router would treat a multicast stream received on an interface as dense. To view the multicast group-to-RP mappings on a router use the show ip pim rp mapping exec mode command.

Verification

Rack1R1#show ip pim rp mapping PIM Group-to-RP Mappings Group(s): 224.0.0.0/4, Static RP: 150.1.2.2 (?)

Another important consideration in any multicast network is the possibility of a reverse-path forwarding (RPF) failure. When there is more than one possible route through the network to reach the RP, or more than one possible route between the source and destinations of the multicast streams, there is the possibility of an RPF failure. Since R1, R6, and SW1 only have one path to reach R2’s Loopback 0 there should not be an issue with an RPF failure. R3 uses its HDLC link to reach R2’s Loopback interface, however PIM is enabled on R3’s Frame Relay interface. This results in an RPF failure on all traffic received in the Frame Relay interface, hence the need for a static multicast route on R3.



Note

Understanding Reverse Path Forwarding

PIM uses the unicast routing table by default to determine the route to the source of the multicast stream. This behavior is called Reverse Path Forwarding (RPF). When a multicast stream is received inbound on an interface the router will look at the source IP address of the multicast stream and determine if the interface the multicast stream was received on is the interface the router would use to reach that particular IP address. If it is the interface the multicast stream will have passed the RPF check. If it is not the interface the unicast routing table would use to reach the source IP address the multicast stream would have failed the RPF check. If the unicast routing table does not have a route to the source of the multicast stream the stream would then fail the RPF check. Multicast streams that fail the RPF check will not be forwarded. By default PIM can use any unicast route in the routing table for this RPF check, hence the term Protocol Independent Multicast. If it is needed to accept a multicast stream that is not received on an interface that the unicast routing table would use to reach the source IP address of the stream a static multicast route can be configured. The ip mroute command is different than the ip route command in that the ip mroute command references the source of the multicast packet and not the destination. A multicast static route will be preferred over any unicast route.



Task 6.2 SW1: interface Vlan783 ip igmp join-group 228.28.28.28 Task 6.2 Breakdown To configure a multicast enabled router to respond to an ICMP echo sent to a particular multicast IP address use the ip igmp join-group interface command. This command is commonly used when troubleshooting a multicast routing issue or testing a new multicast deployment. This command is not needed to enable hosts on a segment to receive multicast traffic. If a host on a segment wants to receive traffic for a particular multicast group the host will respond to the router’s IGMP query messages or send an unsolicited IGMP report message. Task 6.3 R2: interface Serial0/0 ip pim nbma-mode Task 6.3 Breakdown When a multicast feed is sent out an interface PIM is not concerned if there is one client that would like to receive the multicast stream or thousand clients. The multicast routing table associates which interface to forward the multicast stream out, and not which particular IP address or addresses would like to receive the feed. This being the case when a multicast stream is sent out a NBMA interface it is replicated out all VCs that have broadcast support. In the case that not all endpoints of the NBMA network require a particular multicast feed this default behavior is undesirable. For this reason PIM can run in NBMA mode.

Verification Rack1R2#show ip mroute 226.26.26.26 IP Multicast Routing Table <snip> (150.1.2.2, 226.26.26.26), 00:00:15/00:03:17, flags: FT Incoming interface: Loopback0, RPF nbr 0.0.0.0, Registering Outgoing interface list: Serial0/0, Forward/Sparse, 00:00:14/00:03:17



By enabling PIM NBMA the default behavior of associating interfaces in the Outgoing Interface List (OIL) will be changed to unicast IP addresses. This enables the multicast stream to be sent only to the particular neighbor or neighbors that have requested the multicast stream.

Verification Rack1R2#show ip mroute 226.26.26.26 IP Multicast Routing Table <snip> (150.1.2.2, 226.26.26.26), 00:00:12/00:03:20, flags: FT Incoming interface: Loopback0, RPF nbr 0.0.0.0, Registering Outgoing interface list: Serial0/0, 132.1.0.3, Forward/Sparse, 00:00:12/00:03:18

7. IPv6 Task 7.1 R2: ipv6 unicast-routing ! interface Loopback0 ipv6 address 2001:CC1E:1::2/128 ! interface Serial0/0 ipv6 address 2001:CC1E:1:2323::2/64 frame-relay map ipv6 2001:CC1E:1:2323::3 203 broadcast ! ipv6 route 2001:CC1E:1::3/128 2001:CC1E:1:2323::3

R3: ipv6 unicast-routing ! interface Loopback0 ipv6 address 2001:CC1E:1::3/128 ! interface Serial1/0 ipv6 address 2001:CC1E:1:2323::3/64 frame-relay map ipv6 2001:CC1E:1:2323::2 302 broadcast ! ipv6 route 2001:CC1E:1::2/128 2001:CC1E:1:2323::2


Task 7.1 Breakdown Frame Relay is a non-broadcast multi-access (NBMA) media. This implies that for multipoint configurations layer 3 to layer 2 resolution must be obtained. Since only static routing is used a mapping is not required to the remote link-local address. If dynamic IPv6 routing were configured a mapping for the remote link-local address would be required. 8. QoS Task 8.1 R2: interface Serial0/0 frame-relay traffic-shaping frame-relay class REMAINING_BW frame-relay interface-dlci 204 class DLCI_204 ! map-class frame-relay DLCI_204 frame-relay cir 128000 frame-relay bc 1280 ! map-class frame-relay REMAINING_BW frame-relay cir 192000 frame-relay bc 24000 R4: interface Serial0/0 frame-relay class REMAINING_BW frame-relay traffic-shaping frame-relay interface-dlci 402 class DLCI_402 ! map-class frame-relay DLCI_402 frame-relay cir 128000 frame-relay bc 1280 ! map-class frame-relay REMAINING_BW frame-relay cir 192000 frame-relay bc 24000 Task 8.1 Breakdown Although the port speed is given in the task it is not normally needed unless there is a requirement to allow for bursts above CIR. In this section there is a requirement to limit the other DLCIs to only use the remaining bandwidth. This means that we need to subtract the CIR from the port speed to determine what value to shape the remaining traffic to.



The task states that R2 and R4 are not to exceed the provisioned CIR. This means that the value entered in the frame-relay cir map-class command will need to equal the provisioned CIR. This will ensure that R2 and R4 do not exceed the CIR as the default ‘Be‘ value for FRTS is always zero. The lowest Tc value supported by FRTS for normal platforms is 10ms, or 1/100th of a second. To alter the Tc we need to manipulate the Bc value. A Tc of 10ms means that we will have 100 intervals per second. By taking the CIR and dividing it by 100 it will give us the Bc value needed to indirectly set the Tc to 10ms. One of the benefits of have 100 intervals per second is that the router has more chances to prioritize certain traffic if needed.

Note The FRTS values are mathematically related.

Burst size = Bc Bc = CIR * TcAverage rate = CIR CIR = Bc / TcTime interval = Tc Tc = Bc / CIR



Task 8.2 R3: class-map match-all SMTP_FROM_SERVER match access-group name SMTP_FROM_SERVER ! policy-map CBWFQ class SMTP_FROM_SERVER bandwidth 256 ! interface Serial1/1 service-policy output CBWFQ ! ip access-list extended SMTP_FROM_SERVER permit tcp host 132.1.3.100 eq smtp any R5: class-map match-all SMTP_TO_SERVER match access-group name SMTP_TO_SERVER ! policy-map CBWFQ class SMTP_TO_SERVER bandwidth 256 ! interface Serial0/0 service-policy output CBWFQ ! ip access-list extended SMTP_TO_SERVER permit tcp any host 132.1.3.100 eq smtp Task 8.2 Breakdown To meet the requirements of this section the best solution will be to use the MQC. Technically custom queuing could be used to meet the requirements but using the MQC is a more appropriate and simpler solution. Both custom queuing and priority queuing have fallen out of favor in the more recent IOS versions. Cisco’s preferred solution for QoS is to use the MQC. The bandwidth guarantee is only active during times of congestion. When congestion occurs R3 and R5 will ensure packets matching the class-maps are allotted the configured bandwidth.

Caution Output queue calculations for the MQC are based on the configured bandwidth value of the interface and not the speed the interface is clocked at. Be sure to check the bandwidth value when configuring the MQC on an interface.



Task 8.3 R2: interface FastEthernet0/0 ip policy route-map POLICY-ROUTE ! ip access-list extended FTP_FROM_VLAN6 permit tcp 132.1.6.0 0.0.0.255 host 132.1.33.3 eq ftp permit tcp 132.1.6.0 0.0.0.255 host 132.1.33.3 eq ftp-data ! route-map POLICY-ROUTE permit 10 match ip address FTP_FROM_VLAN6 set ip next-hop 132.1.23.3 R3: interface Ethernet0/1 ip policy route-map POLICY-ROUTE ! ip access-list extended FTP_FROM_SERVER permit tcp host 132.1.33.3 eq ftp 132.1.6.0 0.0.0.255 permit tcp host 132.1.33.3 eq ftp-data 132.1.6.0 0.0.0.255 ! route-map POLICY-ROUTE permit 10 match ip address FTP_FROM_SERVER set ip next-hop 132.1.23.2 Task 8.3 Breakdown This section will require the use of policy routing. The first step is to configure the policy routing to ensure that FTP traffic transverses the HDLC link. Policy routing is enabled by creating a route-map to define match and set criteria. In the above task an access-list is used to match the traffic that will be policy routed. The set ip next-hop 132.1.23.2 will force packets that match the access-list to the next hop 132.1.23.2 regardless of what the IP routing table says. The policy is then bound to the interface using the ip policy route-map command. Policy routing applied to an interface only affects incoming traffic on the interface.

Note Policy routing can be used to affect packets sourced by the router itself by binding a route-map globally using the ip local policy route-map command.

Since policy routing occurs before normal routing it can be used to route packets based on more than just the normal destination IP address. In this task policy routing is used to route packets based on an extended access-list. Other criteria such as the length of the packet can also be used. Due to this flexibility that policy routing adds it is commonly referred to as the duct tape of routing.




Task 8.4 R2: class-map match-all FTP_FROM_VLAN6 match access-group name FTP_FROM_VLAN6 ! policy-map RESERVE_FTP class FTP_FROM_VLAN6 bandwidth 256 ! interface Serial0/1 service-policy output RESERVE_FTP R3: class-map match-all FTP_FROM_SERVER match access-group name FTP_FROM_SERVER ! policy-map RESERVE_FTP class FTP_FROM_SERVER bandwidth 256 ! interface Serial1/3 service-policy output RESERVE_FTP Task 8.4 Breakdown

Once the packets have been policy routed across the HDLC link, a QoS policy can be configured using the MQC that will guarantee 256Kbps for the FTP traffic. Since this FTP traffic will not be using PASV FTP we only need to match TCP ports 20 and 21 in the access-list.

Further Reading Internet Protocol Journal: Is Your FTP Active or Passive?

http://www.cisco.com/en/US/about/ac123/ac147/ac174/ac199/about_cisco_ipj_archive_article09186a00800c85a7.html


9. Security Task 9.1 R5: no ip source-route no ip bootp server ! interface Ethernet0/1 no ip proxy-arp no cdp enable ! banner login "Access to this device or the attached networks is prohibited without express written permission. Violators will be shot on sight." Task 9.1 Breakdown Source routing is enabled by default in the IOS. Source routing, as the name implies, allows the source to determine the route the packet will take through the network to reach the destination. There are two types of source routing defined by RFC 791 (Internet Protocol). The first type is called loose source routing. This is where the complete route is not included in the packet. The packet can take any path through the network to reach the destination as long as the packet is passed through the routers whose IP addresses are included in the header of the packet. The second type is called strict source routing. In strict source routing the packet must pass through the routers, and only the routers defined in the header of the packet to reach the destination.

Further Reading

RFC 791 - Internet Protocol

Source routing can be a security risk, but can also be a useful tool in troubleshooting routing problems. The IOS supports source routing packets using telnet, ping, and traceroute. Rack1R5#telnet 10.1.1.1 ? /debug Enable telnet debugging mode /ipv4 Force use of IP version 4 /ipv6 Force use of IP version 6 /line Enable telnet line mode /noecho Disable local echo /quiet Suppress login/logout messages /route: Enable telnet source route mode





Rack1R5#ping Protocol [ip]: Target IP address: 10.1.1.1 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Rack1R5#traceroute Protocol [ip]: Target IP address: 10.1.1.1 Source address: Numeric display [n]: y Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: By default a Cisco router will act as a bootstrap server (BOOTP). BOOTP was around before DHCP and was originally used to allow diskless workstations to determine their IP address, the address of the server from which a bootfile can be downloaded, and the name of the bootfile itself. BOOTP is outlined in RFC 951.

Even after disabling the BOOTP server in the global configuration, the output of the show ip socket command will still show that the router is listening to UDP port 67.

Rack1R5#show ip socket Proto Remote Port Local Port In Out Stat TTY OutputIF 17 0.0.0.0 0 150.1.5.5 67 0 0 2211 0

IP Protocol 17 (UDP) UDP Port 67 (BOOTP)



Proxy ARP is a technique in which a router will answer for an ARP request if the request is for an IP address that is not on the local segment and the router has a route for it. Proxy ARP is enabled by default. Rack2R5#show ip interface E0/0 | include Proxy ARP Proxy ARP is enabled Local Proxy ARP is disabled

Further Reading

Proxy ARP Local Proxy ARP Managing Connections, Menus, and System Banners

Task 9.2 R5: interface Ethernet0/1 ip access-group DENY_SNMP in ! ip access-list extended DENY_SNMP deny udp any any eq snmp permit ip any any R6: interface Serial0/0/0 ip access-group DENY_SNMP in ! ip access-list extended DENY_SNMP deny udp any any eq snmp permit ip any any Task 9.2 Breakdown The two UDP ports used by SNMP are 161 and 162. UDP port 161 is used by network management stations to poll managed devices. UDP port 162 is used by managed devices to send SNMP traps. Since this section stated R2 and R4 were being polled via SNMP only port UDP port 161 needs to be denied. If a rogue device was sending SNMP traps to the network management server than an access-list denying UDP port 162 can be used.

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094adb.shtml

http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_chapter09186a008017d169.html#1091091

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_c/ffcprt1/fcf004.htm#1000872


Task 9.3 R2 and R4: snmp-server community public RO 1 access-list 1 deny any log logging 132.1.33.100 Task 9.3 Breakdown The key to this section is to create an access-list that denies all IP address and includes the log keyword. The access-list is then bound to the RO community string of public. This is a useful technique to track down the source of a host attempting to poll a device. Task 9.4 R5: interface Ethernet0/1 ip access-group DENY_SNMP in ip access-group EVALUATE_ICMP out ! ip access-list extended DENY_SNMP deny udp any any eq snmp permit icmp any any time-exceeded permit icmp any any port-unreachable evaluate ICMP deny icmp any any permit ip any any ! ip access-list extended EVALUATE_ICMP permit icmp any any reflect ICMP permit ip any any Task 9.4 Breakdown Reflexive access-lists and content based access-control (CBAC) can be used to turn the router into a stateful firewall. A stateful firewall means that when traffic leaves the network it is noted in a state table. When traffic tries to come back into the network it is only allowed in if there is a previously created entry in the state table. A reflexive access-list uses the same principle. When traffic is leaving the network it is reflected to the state table. When traffic tries to come back in it is evaluated to see if there is a previous entry in the state table. If there is no entry (and no explicit permit statement) the traffic is denied. Without the reflect statement nothing would show up in the state table and everything would be effectively denied.



An important point to note about reflexive access-lists and CBAC is that an outbound access-list does not affect traffic locally generated by the router. This means that traffic the router originates (routing protocol traffic, telnet, ping, etc) will not get evaluated. There are two choices to deal with this problem. You can either explicitly permit this traffic to return, or you can policy route all locally generated traffic to another local interface first. The first method is easier, and the second is potentially more secure. Take the following example: R1 and R2 are directly connected over an Ethernet segment with the IP network 12.0.0.0/8. R1 is applying a reflexive access-list outbound towards R2. Its configuration is as follows: Rack1R1: interface Ethernet0/0 ip address 12.0.0.1 255.0.0.0 ip access-group INBOUND in ip access-group OUTBOUND out ! ip access-list extended INBOUND evaluate REFLEXIVE deny ip any any ip access-list extended OUTBOUND permit tcp any any reflect REFLEXIVE permit udp any any reflect REFLEXIVE permit icmp any any reflect REFLEXIVE Rack1R1#ping 12.0.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)


Rack1R1#show access-list INBOUND Extended IP access list INBOUND 10 evaluate REFLEXIVE 20 deny ip any any (10 matches)

Traffic is denied as it tries to re-enter the Ethernet interface connecting to R2



1st solution: Manually allow traffic back in. Rack1R1(config)#ip access-list extended INBOUND Rack1R1(config-ext-nacl)#1 permit icmp host 12.0.0.2 host 12.0.0.1 echo-reply Rack1R1#show access-list INBOUND Extended IP access list INBOUND 1 permit icmp host 12.0.0.2 host 12.0.0.1 echo-reply 10 evaluate REFLEXIVE 20 deny ip any any (10 matches) Rack1R1#ping 12.0.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds: !!!!! Rack1R1#

Now ICMP echo-replies are allowed to come back in from R2. 2nd solution: Policy route the locally generated traffic. Rack1R1#telnet 12.0.0.2 Trying 12.0.0.2 ... % Connection timed out; remote host not responding Rack1R1(config)#int loopback 0 Rack1R1(config-if)#ip address 1.1.1.1 255.255.255.255 Rack1R1(config-if)#exit Rack1R1(config)#route-map LOCAL_POLICY Rack1R1(config-route-map)#set interface loopback 0 Rack1R1(config-route-map)#exit Rack1R1(config)#ip local policy route-map LOCAL_POLICY Rack1R1(config)#end Rack1R1#telnet 12.0.0.2 Trying 12.0.0.2 ... Open Password required, but none set [Connection to 12.0.0.2 closed by foreign host] Rack1R1#show access-list REFLEXIVE Reflexive IP access list REFLEXIVE permit tcp host 12.0.0.2 eq telnet host 12.0.0.1 eq 11468 (22 matches) (time left 3) Now all locally generated traffic is treated as transit traffic. Be careful of using this method in production as it can have a negative impact on CPU utilization.

Telnet traffic denied from returning from R2.


10. System Management Task 10.1 R5 and R6: rmon event 1 trap IETRAP description "Five Minute CPU Average Above 75%" rmon event 2 trap IETRAP description "Five Minute CPU Average Below 40%" rmon alarm 1 lsystem.58.0 60 absolute rising-threshold 75 1 falling- threshold 40 2 ! snmp-server host 132.1.33.100 IETRAP Task 10.1 Breakdown In this section we have configured R5 and R6 to generate an SNMP trap whenever their 5 minute CPU utilization average crosses the defined thresholds. Although RMON is not commonly used in most networks this particular type of configuration is very useful to helping in detecting certain network related problems when they first start to appear.

Another real network usage would be to configure the router to generate an SNMP trap or log message whenever an interface’s utilization increases above the normal rate for an extended period. For example if a company’s Internet connection normally has a 25% utilization rate but starts to run at a 75% utilization rate there might be an issue that needs attention. Task 10.2 R4: username NOC password 0 CISCO ! line vty 0 4 exec-timeout 5 0 logout-warning 60 absolute-timeout 15 login local



Task 10.2 Breakdown The exec-timeout [minutes] [seconds] command is used to end an idle exec process. To disable the exec-timeout either set the timeout to 0 minutes and 0 seconds or issue the command no exec-timeout.

Caution If using the no exec-timeout command be careful not to issue the no exec command. If the no exec command is entered no one will be able to create an exec process and in turn will not be able to login.

The logout-warning command is self explanatory. A warning is issued 60 seconds prior to the user being logged out.

The absolute-timeout command will end an exec process and in turn log a user off after the configured time expires even if the process is not idle. This command is useful to limit the length a time a user can be logged in. Normally this command would be used to limit the amount of time a user can be dialed into a router as it is not common in a real network to limit the amount of time a user can be telneted into a router.




Task 10.3 R4: no username NOC password CISCO username NOC secret CISCO Task 10.3 Breakdown In IOS 12.2(8)T Cisco added the ability to store a password associated with a username as an MD5 hash. The standard encryption used by the service password-encryption command uses a weak reversible algorithm and was mainly designed to stop someone from being able to view the configurations and see the passwords.

Storing a password as an MD5 hash is far more secure but this method can not be used with PPP PAP or CHAP authentication. With PAP and CHAP the password needs to be known by the authentication process, but if the password is stored as a MD5 hash, the actual password is discarded after the hash has been generated. This makes the password stored in the username command unusable by PAP or CHAP.

Further Reading Enhanced Password Security

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087cb1.html



Task 10.4 R3: interface Serial1/0 no logging event link-status logging event dlci-status-change ! logging 132.1.33.100 logging trap debugging Task 10.4 Breakdown By default only severity 6 (informational) and below messages are sent to a remote syslog server. To include debugging messages, use the logging trap debugging command. This command could be also entered as logging trap 7. The logging trap command can either take the level in its numerical value or by entering the common name for the level.

Rack1R3(config)#logging trap ? <0-7> Logging severity level alerts Immediate action needed (severity=1) critical Critical conditions (severity=2) debugging Debugging messages (severity=7) emergencies System is unusable (severity=0) errors Error conditions (severity=3) informational Informational messages (severity=6) notifications Normal but significant conditions (severity=5) warnings Warning conditions (severity=4) <cr> Rack1R3(config)#logging trap 7 Rack1R3(config)#logging trap informational To verify the logging configuration, use the show logging exec command.

Rack1R3#show logging Syslog logging: enabled (0 messages dropped, 1 messages rate-limited, 0 flushes, 0 overruns, xml disabled) Console logging: level debugging, 26 messages logged, xml disabled Monitor logging: level debugging, 0 messages logged, xml disabled Buffer logging: disabled, xml disabled Logging Exception size (4096 bytes) Count and timestamp logging messages: disabled Trap logging: level debugging, 31 message lines logged Logging to 132.1.33.100, 2 message lines logged, xml disabled

Note

The logging level specifies that a particular level and all levels below are logged.



11. IP Services Task 11.1 R5: interface Ethernet0/1 ip accounting access-violations ! ip accounting-threshold 2500 R6: interface Serial0/0/0 ip accounting access-violations ! ip accounting-threshold 2500 Task 11.1 Breakdown Although IP accounting is normally used to track how many packets are received or sent out an interface in this section it is used to account for the number of access-list violations. This will account for packets that were denied by the access-list applied to the interface. To view the accounting records for access-list violations use the show ip accounting access-violations exec mode command.

To control the amount of memory that the IP account process uses, the number of accounting records stored is limited to 2500.



1. Catalyst 3550 Task 1.1 SW1: vtp domain IELAB vtp password CISCO vtp pruning ! vlan 2,3,4,16,36,44,52,57,63 ! interface FastEthernet0/1 switchport access vlan 16 ! interface FastEthernet0/2 switchport access vlan 2 ! interface FastEthernet0/3 switchport access vlan 3 ! interface FastEthernet0/4 switchport access vlan 4 ! interface FastEthernet0/5 switchport access vlan 52 ! interface FastEthernet0/24 switchport access vlan 63 ! interface Vlan7 ip address 136.1.7.7 255.255.255.0 ! interface Vlan57 ip address 136.1.57.7 255.255.255.0 SW2: vtp domain IELAB vtp mode client vtp password CISCO ! interface FastEthernet0/3 switchport access vlan 36 ! interface FastEthernet0/4 switchport access vlan 44 ! interface FastEthernet0/5 switchport access vlan 57 ! interface FastEthernet0/6 switchport access vlan 63 ! interface FastEthernet0/24 switchport access vlan 52


Task 1.2 R6: interface GigabitEthernet0/0.16 encapsulation dot1Q 16 ! interface GigabitEthernet0/0.36 encapsulation dot1Q 36 ! interface GigabitEthernet0/1 ip address 204.12.1.6 255.255.255.0 SW1: interface FastEthernet0/6 switchport trunk encapsulation dot1q switchport trunk allowed vlan 16,36 switchport mode trunk SW1 and SW2: interface FastEthernet0/13 switchport trunk encapsulation isl switchport mode trunk ! interface FastEthernet0/14 switchport trunk encapsulation isl switchport mode trunk ! interface FastEthernet0/15 switchport trunk encapsulation isl switchport mode trunk Task 1.2 Breakdown By default all VLANs are allowed to transit a trunk link. As previously mentioned, VTP pruning can automatically remove unnecessary VLAN traffic from a trunk interface. However, not all devices that support trunking also support pruning. This is the case in the above configuration when enabling router-on-a-stick with R6. Since R6 does not support the automatic removal of unnecessary VLAN traffic, unassigned VLANs must be manually removed from the interface by editing the ‘allowed’ list. The allowed VLAN list, as the name implies, specifies which VLANs are allowed to transit a trunk link. To edit the allowed VLAN list, issue to switchport trunk allowed vlan interface level command.

Note Although they are not assigned VLANs 1002-1005 are still in the allowed list. Depending on the software release these default VLANs cannot be removed from the interface.




Task 1.3 R6: interface GigabitEthernet0/0.16 bridge-group 1 ! interface GigabitEthernet0/0.36 bridge-group 1 ! interface BVI1 ip address 136.1.136.6 255.255.255.0 ! bridge irb bridge 1 protocol ieee bridge 1 route ip Task 1.3 Breakdown By default Cisco routers will route IP and bridge all other protocols on all interfaces. Additionally, a protocol can be either routed or bridged, but not both. By using either the concurrent routing and bridging (CRB) or integrated routing and bridging (IRB) features this limitation can be overcome.

With CRB, a protocol can be routed on one interface while being bridged on another interface. When CRB is used, traffic in the routed domain cannot be passed on to the bridge domain. With IRB, a protocol can be both routed and bridged on the same interface. Therefore traffic from the routed domain can be passed on to the bridge domain.

These features are useful when you want to extend the broadcast domain for one protocol, while maintaining it for another. For example, IPX can be bridged between two LAN segments, while IP is routed on those interfaces (CRB). Additionally a bridge virtual interface (BVI) can be configured with an IPX address so that other segments running IPX routing can communicate with the IPX bridged network (IRB). CRB is considered a legacy feature since IRB inherits all functionality of CRB, with the addition of the BVI.

In the above example two LAN segments running IP need to be bridged together. The first step in bridging is to create a transparent bridge group. This is accomplished by issuing the global configuration command bridge [num] protocol ieee. The ieee option specifies that IEEE spanning-tree will be enabled for the bridge group. To apply the bridge-group use the interface command bridge-group [num], where num is the bridge group previously created.


Since ip routing is enabled by default the above configuration will only enable transparent bridging for non-IP protocols. To enable the integrated routing and bridging process, use the global configuration command bridge irb. Next, choose which protocols you want to route and bridge for the bridge group. This is accomplished by issuing the bridge [num] route [protocol]. In the above case, IP is both routed and bridged for bridge group 1. Lastly, the BVI is created by issuing the interface bvi [num], where num is the bridge group number. All traffic that passes from the bridge domain to the routed domain and vice versa must pass through the BVI. This is the interface where logical configuration is placed, such as an IP address.

Verification R6#show interface irb Routed protocols on GigabitEthernet0/0: ip Not bridging this sub-interface. GigabitEthernet0/0.16 ip Routed protocols on GigabitEthernet0/0.16:

Bridged protocols on GigabitEthernet0/0.16: appletalk clns decnet ip Software MAC address filter on GigabitEthernet0/0.16 <output deleted> GigabitEthernet0/0.36 Routed protocols on GigabitEthernet0/0.36: ip Bridged protocols on GigabitEthernet0/0.36: appletalk clns decnet ip Software MAC address filter on GigabitEthernet0/0.36 <output deleted> BVI1 Routed protocols on BVI1: ip



Task 1.4 SW1: spanning-tree vlan 16 root primary ! interface FastEthernet0/14 spanning-tree vlan 16 port-priority 32 ! interface FastEthernet0/15 spanning-tree vlan 16 port-priority 16 Task 1.4 Breakdown Spanning-tree protocol is used to ensure one loop free path throughout the bridge domain. This single loop free path is a top down tree in which the source of the tree is the root bridge. Root bridge election is determined by the bridge-ID. Bridge-ID is a made up of a priority value along with a single burned in MAC address that the switch possesses. The bridge with the lowest bridge-ID will be elected the root bridge. To influence root bridge election change the bridge’s priority by issuing the spanning-tree vlan [num] priority [priority] command. The spanning-tree vlan [num] root [primary | secondary] command is a macro that automatically sets the bridge priority to an appropriate value.

Note By default Cisco switches run per-vlan spanning-tree protocol (PVST+) in which each VLAN runs a separate instance of spanning-tree. Therefore, there is one root bridge election per VLAN.

Caution Each switch’s priority defaults to half of the maximum value. This typically results in a tie in priority between all bridges in the spanning-tree domain (some switches such as the 3550 offset the priority value with a system-id-extension). The tie breaker for the root election is the lower MAC address. This implies that older switches have the tendency to be elected root. When designing a switch block be sure to carefully influence the root bridge election. Otherwise, all traffic will be forced to transit the older and most likely lower performing bridges due to spanning-tree.




Once the root bridge election has occurred, each bridge must decide on a single path it will use to get to the root bridge. The outgoing port used to reach the root bridge is known as the root port. There are four variables that affect the root port selection. These are cost, bridge-ID, port priority, and port-id in that order.

Cost is cumulative throughout the STP domain, and is the sum of all port costs in the path. Port cost is based on a non-linear inverse representation of the bandwidth of the interface (higher bandwidth equals lower cost). Lower total cost is better.

Bridge-ID is same as previously discussed.

Port priority is a value of 1-255, and defaults to half (128). Lower port priority is also better, but priority is only locally significant between two directly connected bridges.

The final tie breaker in the root port election is port ID. Port ID is based on the physical port number (ie Fa0/1 = port 1), and lower is better. To influence which port is elected the root port, the two user configurable values to change are port cost and port priority. Changing port cost will affect both the local bridge and all downstream bridges. Changing port priority will only affect the directly connected downstream bridge. Keep in mind that port priority is only taken into account if there is a tie in both cost and bridge-ID (a tie in bridge-ID implies that a bridge has multiple connections to the same upstream bridge).

Verification Switch#show spanning-tree vlan 1

VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 24577 priority of the root bridge Address 000a.f4f3.e780 MAC of the root bridge This bridge is the root this bridge is root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec local bridge priority Bridge ID Priority 24577 (priority 24576 sys-id-ext 1) Address 000a.f4f3.e780 local MAC Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 15


In the above example, port-priority is change on the root bridge (SW1) in order to influence how the downstream bridge (SW2) elects its root port.

Verification SW2#show spanning-tree vlan 16 VLAN0016 Spanning tree enabled protocol ieee Root ID Priority 24592 Address 000a.f4f3.e780 Cost 19 cost to root Port 15 (FastEthernet0/15) root port Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 32784 (priority 32768 sys-id-ext 16) Address 000a.f4f3.e400 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 15 Interface Role Sts Cost Prio.Nbr Type ---------------- ---- --- --------- -------- ------------------------ Fa0/13 Altn BLK 19 tie 128.13 P2p Fa0/14 Altn BLK 19 in 128.14 P2p Fa0/15 Root FWD 19 cost 128.15 P2p root port SW2#sh spanning-tree vlan 16 detail Port 13 (FastEthernet0/13) of VLAN0016 is blocking <output deleted> Designated port id is 128.13, designated path cost 0 <output deleted> upstream port priority Port 14 (FastEthernet0/14) of VLAN0016 is blocking <output deleted> Designated port id is 32.14, designated path cost 0 <output deleted> upstream port priority Port 15 (FastEthernet0/15) of VLAN0016 is forwarding <output deleted> Designated port id is 16.15, designated path cost 0 <output deleted> upstream port priority lowest wins




Task 1.5 SW2: spanning-tree uplinkfast Task 1.5 Breakdown Spanning-tree uplinkfast provides fast reconvergence in the event of a direct failure of the root port. During the initial root port election, a bridge running uplinkfast notes which ports can be used as alternate paths to the root bridge. When the root port fails the alternate port immediately comes out of blocking state and transitions to forwarding. Also, to ensure convergence of the upstream CAM table all known MAC addresses are flooded out the new root port as dummy multicast frames. This process typically takes three to five seconds, and reduces convergence time considerably. Uplinkfast is only supported when running PVST+. To configure uplinkfast, use the global configuration command spanning-tree uplinkfast.

Further Reading Configuring Optional Spanning-Tree Features: Understanding Uplinkfast

Further Reading Configuring STP






2. Frame-Relay Task 2.1 R2: interface Serial0/0 ip address 136.1.245.2 255.255.255.0 encapsulation frame-relay frame-relay map ip 136.1.245.5 205 broadcast no frame-relay inverse-arp R4: interface Serial0/0 ip address 136.1.245.4 255.255.255.0 encapsulation frame-relay frame-relay map ip 136.1.245.5 405 broadcast no frame-relay inverse-arp R5: interface Serial0/0 encapsulation frame-relay ! interface Serial0/0.245 multipoint ip address 136.1.245.5 255.255.255.0 frame-relay map ip 136.1.245.2 502 broadcast frame-relay map ip 136.1.245.4 504 broadcast Task 2.1 Breakdown Since R5 has multiple IP subnets on the Frame Relay network it requires separate subinterfaces for each network. Additionally, since the subnet connecting to R1 and R2 has multiple VCs, this interface must be a multipoint subinterface. A multipoint subinterface behaves the same way as the physical Frame Relay interface, as they are both by definition multipoint.



Task 2.2 R1: interface Serial0/0 ip address 136.1.15.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 136.1.15.5 105 broadcast no frame-relay inverse-arp R5: interface Serial0/0.15 point-to-point ip address 136.1.15.5 255.255.255.0 frame-relay interface-dlci 501 Task 2.2 Breakdown The above task states that neither the Frame Relay map command nor Frame Relay Inverse-ARP can be used on R5. Therefore, the only option left is to configure a point-to-point subinterface on R5, since this interface will not require protocol resolution. Whether or not R4 uses the main interface or a subinterface is independent of the method used on R5. Task 2.3 R6: interface Serial0/0/0 encapsulation frame-relay frame-relay map ip 54.1.3.254 51 broadcast no frame-relay inverse-arp Task 2.3 Breakdown This task states that static layer 3 to layer 2 address resolution should be used which means that the frame-relay map command is needed. The disabling of inverse-ARP although not required by the task should be done. The reason it is not technically required is that the router will not perform inverse-ARP for DLCI 51 since there is a static mapping but we would not want inverse-ARP to automatically map to BB1 for other DLCIs.



3. HDLC/PPP Task 3.1 R2: username Rack1R3 password 0 CISCO ! interface Serial0/1 encapsulation ppp ppp authentication pap ppp pap sent-username Rack1R2 password 0 CISCO R3: username Rack1R2 password 0 CISCO ! interface Serial1/3 encapsulation ppp clockrate 64000 ppp authentication pap ppp pap sent-username Rack1R3 password 0 CISCO R4: username Rack1R5 password 0 CISCO ! interface Serial0/1 encapsulation ppp ppp authentication pap ppp pap sent-username Rack1R4 password 0 CISCO R5: username Rack1R4 password 0 CISCO ! interface Serial0/1 encapsulation ppp clockrate 64000 ppp authentication pap ppp pap sent-username Rack1R5 password 0 CISCO Task 3.1 Breakdown R2, R3, R4, and R5 will need to be configured with PAP authentication for this task. The task is implying PAP due to the fact the wording specified a “clear-text” password is to be used.

It’s important to remember that in order for a router to be a client in the PAP authentication process two conditions must be met. First off before a router will be authenticated by PAP, the router will check to see if the ppp pap refuse command is enabled. By default this command is disabled (no ppp pap refuse). Secondly the router must have the ppp pap sent-username command configured. If either of these two conditions is not met, the router will refuse to be authenticated via PAP. See debug below:



Rack1R5#show run int s0/1 Building configuration... Current configuration : 124 bytes ! interface Serial0/1 ip address 190.1.45.5 255.255.255.0 encapsulation ppp clockrate 64000 ppp authentication pap end Rack1R5# Rack1R5#debug ppp negotiation Se0/1 LCP: TIMEout: State REQsent Se0/1 LCP: O CONFREQ [REQsent] id 96 len 14 Se0/1 LCP: AuthProto PAP (0x0304C023) Se0/1 LCP: MagicNumber 0x081EA4C0 (0x0506081EA4C0) Se0/1 LCP: I CONFREQ [REQsent] id 137 len 14 Se0/1 LCP: AuthProto PAP (0x0304C023) Se0/1 LCP: MagicNumber 0x30C74F42 (0x050630C74F42) Se0/1 LCP: O CONFREJ [REQsent] id 137 len 8 Se0/1 LCP: AuthProto PAP (0x0304C023) Se0/1 LCP: I CONFACK [REQsent] id 96 len 14 Se0/1 LCP: AuthProto PAP (0x0304C023) Se0/1 LCP: MagicNumber 0x081EA4C0 (0x0506081EA4C0) Se0/1 LCP: I CONFREQ [ACKrcvd] id 138 len 14 Se0/1 LCP: AuthProto PAP (0x0304C023) Se0/1 LCP: MagicNumber 0x30C74F42 (0x050630C74F42) Se0/1 LCP: O CONFREJ [ACKrcvd] id 138 len 8 Se0/1 LCP: AuthProto PAP (0x0304C023) Se0/1 LCP: I CONFREQ [ACKrcvd] id 139 len 14 Se0/1 LCP: AuthProto PAP (0x0304C023) Se0/1 LCP: MagicNumber 0x30C74F42 (0x050630C74F42) Se0/1 LCP: O CONFREJ [ACKrcvd] id 144 len 8 Se0/1 LCP: AuthProto PAP (0x0304C023) Se0/1 LCP: I CONFREQ [ACKrcvd] id 145 len 14 Se0/1 LCP: AuthProto PAP (0x0304C023) Se0/1 LCP: MagicNumber 0x30C74F42 (0x050630C74F42) Se0/1 LCP: O CONFREJ [ACKrcvd] id 145 len 8 Se0/1 LCP: AuthProto PAP (0x0304C023) Se0/1 LCP: I CONFREQ [ACKrcvd] id 146 len 14 Se0/1 LCP: AuthProto PAP (0x0304C023) Se0/1 LCP: MagicNumber 0x30C74F42 (0x050630C74F42) Se0/1 LCP: O CONFREJ [ACKrcvd] id 146 len 8 Se0/1 LCP: AuthProto PAP (0x0304C023) Se0/1 LCP: I TERMREQ [ACKrcvd] id 147 len 4 Se0/1 LCP: O TERMACK [ACKrcvd] id 147 len 4


4. Interior Gateway Routing Task 4.1 R2: interface Serial0/0 ip ospf network point-to-multipoint ! router ospf 1 router-id 150.1.2.2 network 136.1.245.2 0.0.0.0 area 0 R4: interface Serial0/0 ip ospf network point-to-multipoint ! router ospf 1 router-id 150.1.4.4 network 136.1.245.4 0.0.0.0 area 0 R5: interface Serial0/0.245 multipoint ip ospf network point-to-multipoint ! router ospf 1 router-id 150.1.5.5 network 136.1.245.5 0.0.0.0 area 0 Task 4.1 Breakdown OSPF network type point-to-multipoint eliminates many of the problems associated with running OSPF over a non-broadcast media. By understanding that an NBMA media is actually a collection of point-to-point links, OSPF network point-to-multipoint eliminates the need for endpoints in the NBMA cloud which do not have direct layer 2 connectivity to each other to maintain layer 2 to layer 3 resolution to each other. To configure OSPF network point-to-multipoint use the interface level command ip ospf network point-to-multipoint.



Understanding why OSPF network point-to-multipoint is advantageous is most easily seen through its comparison to the network types non-broadcast or broadcast when used on an NBMA media. In the above task R2, R4, and R5 share the IP subnet 136.1.245.0/24 over the Frame Relay cloud. Since all three of these devices are on the same logical network routing protocols such as OSPF will assume by default that all endpoints of the network have direct layer 2 connectivity to each other, such as in the case of a true broadcast media like Ethernet. However, in the above case R2 and R4 only have a layer 2 circuit provisioned to R5 (hub-and-spoke topology). Therefore when R2 wants to reach R4, and vice-versa, they have to physically go through R5. This implies that the spokes of the network must maintain layer 3 to layer 2 resolution to each other or use a layer 3 routing mechanism to reach each other.

Note If the spokes of the network used point-to-point subinterfaces layer 3 to layer 2 protocol resolution is not required.

First let's take a look at what happens on this segment when these devices are configured for OSPF network type broadcast or non-broadcast: R2#show ip ospf interface serial0/0 | include Network Type Process ID 1, Router ID 150.1.2.2, Network Type NON_BROADCAST, Cost: 64 R2#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 150.1.5.5 1 FULL/DR 00:01:31 136.1.245.5 Serial0/0 R2#show ip route ospf 136.1.0.0/24 is subnetted, 2 subnets O IA 136.1.4.0 [110/74] via 136.1.245.4, 00:07:16, Serial0/0 From the above output it is seen that this segment is running the default network type non-broadcast and R5 is the designated router for the segment. The important point to note about the above output is the next hop value that R2 sees for VLAN 4 which is advertised by R4. This value is the IP address of R4 itself, 136.1.245.4. In order for R2 to send traffic towards this next hop address it must do a recursive lookup in the routing table. A recursive lookup means that another routing lookup is done on the next hop IP address in order to determine the outgoing interface for the packet.




R2#show ip route 136.1.245.4 Routing entry for 136.1.245.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: * directly connected, via Serial0/0 Route metric is 0, traffic share count is 1 When R2 does its recursive lookup on this route it sees that it is directly connected out the Serial interface to the Frame Relay cloud. Since this is a multipoint NBMA interface R2 must now determine the appropriate layer 2 circuit to use when sending traffic toward this destination. Since Frame Relay Inverse-ARP cannot be used to resolve layer 3 addresses of devices not directly connected, this resolution must come in the form of a static Frame Relay mapping statement. However, since the previous Frame Relay section dictated to "not configure static layer 3 to layer 2 mappings between R2 and R4" there is going to be an issue. R2#show run int s0/0 Building configuration... Current configuration : 186 bytes ! interface Serial0/0 ip address 136.1.245.2 255.255.255.0 encapsulation frame-relay frame-relay map ip 136.1.245.5 205 broadcast no frame-relay inverse-arp R2#debug ip packet IP packet debugging is on R2#ping 136.1.4.4 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 136.1.4.4, timeout is 2 seconds: . Success rate is 0 percent (0/1) IP: s=136.1.245.2 (local), d=136.1.4.4 (Serial0/0), len 100, sending IP: s=136.1.245.2 (local), d=136.1.4.4 (Serial0/0), len 100, encapsulation failed From the above output it can be seen that the encapsulation of the IP packet destined for 136.1.4.4 is failing. When a failure of encapsulation at layer 3 is seen it is usually helpful to debug the layer 2 encapsulation. Since in this case the circuit is running Frame Relay we will debug frame-relay packet.

Quick Note No Frame Relay map for 136.1.245.4.


R2#debug frame-relay packet Frame Relay packet debugging is on R2#ping 136.1.4.4 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 136.1.4.4, timeout is 2 seconds: . Success rate is 0 percent (0/1) Serial0/0:Encaps failed--no map entry link 7(IP) From the above output it is evident that the encapsulation is failing because there is "no map entry link". This indicates the lack of an appropriate frame-relay map statement. By configuring the OSPF network as point-to-multipoint the need for layer 3 to layer 2 mappings between the spokes of an NBMA network is eliminated. R2#show ip ospf interface serial0/0 | include Network Type Process ID 1, Router ID 150.1.2.2, Network Type POINT_TO_MULTIPOINT, Cost: 64 R2#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 150.1.5.5 0 FULL/ - 00:01:49 136.1.245.5 Serial0/0 R2#show ip route ospf 136.1.0.0/16 is variably subnetted, 4 subnets, 2 masks O 136.1.245.4/32 [110/128] via 136.1.245.5, 00:00:06, Serial0/0 O 136.1.245.5/32 [110/64] via 136.1.245.5, 00:00:06, Serial0/0 O IA 136.1.4.0/24 [110/138] via 136.1.245.5, 00:00:06, Serial0/0 There are three major changes that should be noted from the above output. The first and most obvious is that the network type has been changed from non-broadcast to point-to-multipoint. Next we can see that R5 is no longer the designated router for this segment. OSPF network point-to-multipoint does not implement a DR/BDR election. Lastly, and most importantly, the IP routing table output has changed. From the previous output when running network non-broadcast the next hop IP address for the 136.1.4.0/24 network was 136.1.245.4 (R4). However, in the above case we can see that this value has been changed to 136.1.245.5 (R5). Now OSPF understands that although R2, R4, and R5 share the same IP subnet, R2 and R4 are not directly connected, and that all traffic between R2 and R4 must pass through R5. Additionally we can see that there are now host routes for the endpoints of the network. Since R4's address 136.1.245.4/32 is now seen with a next hop value of R5, no layer 3 to layer 2 resolution is required. This can be seen when the recursive lookup is done on R4's IP address.




R2#show ip route 136.1.245.4 Routing entry for 136.1.245.4/32 Known via "ospf 1", distance 110, metric 128, type intra area Last update from 136.1.245.5 on Serial0/0, 00:05:40 ago Routing Descriptor Blocks: * 136.1.245.5, from 150.1.4.4, 00:05:40 ago, via Serial0/0 Route metric is 128, traffic share count is 1 Previously this output listed that 136.1.245.4 was directly connected out the Serial interface. However now it is listed as reachable through R5. As long as all the spoke endpoints of the NBMA cloud maintain layer 2 to layer 3 mappings for the hub, layer 3 routing will take care of reachability amongst themselves.

Note When OSPF is running network type point-to-multipoint only the endpoints are advertised as host routes to the rest of the OSPF domain. Other devices in the OSPF network will not have a route for the transit subnet itself. This is the required behavior per RFC 2328 and this is the desired behavior. Do not attempt to remove the host routes from the routing table as they are providing reachability information to the endpoints of the NBMA network.



Task 4.2 R1: interface Serial0/0 ip ospf network point-to-point ! router ospf 1 router-id 150.1.1.1 network 136.1.15.1 0.0.0.0 area 0 R4: router ospf 1 network 136.1.4.4 0.0.0.0 area 4 network 136.1.44.4 0.0.0.0 area 44 R5: router ospf 1 network 136.1.15.5 0.0.0.0 area 0 Task 4.2 Breakdown In order to met the requirement of not using the ip ospf network command on R5 we will need to ensure that the OSPF network type on R1 will work with R5’s default OSPF network type of point-to-point. In this case the OSPF network type on R1 could be changed to either point-to-point or point-to-multipoint. The optimal solution is to use point-to-point as point-to-multipoint would require the OSPF timers to be adjusted to sync with R5. The default hello timer for point-to-point is 10 with a dead timer of 40. The default hello timer for point-to-multipoint is 30 with a dead timer of 120. Adjusting the hello interval on either router will allow them to sync up if using point-to-multipoint on R1. Rack1R1#show run int s0/0 Building configuration... Current configuration : 228 bytes ! interface Serial0/0 ip address 136.1.15.1 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint ip ospf hello-interval 10 frame-relay map ip 136.1.15.5 105 broadcast no frame-relay inverse-arp end



Rack1R1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 150.1.5.5 0 FULL/ - 00:00:35 136.1.15.5 Serial0/0 Rack1R1#show ip route ospf 136.1.0.0/16 is variably subnetted, 4 subnets, 2 masks O 136.1.245.4/32 [110/128] via 136.1.15.5, 00:01:51, Serial0/0 O 136.1.245.5/32 [110/64] via 136.1.15.5, 00:01:51, Serial0/0 O 136.1.245.2/32 [110/128] via 136.1.15.5, 00:01:51, Serial0/0 It is important to remember that although you can get OSPF network types that do not use a DR (broadcast and non-broadcast) to become adjacent with network types that do not use a DR (point-to-point and point-to-multipoint) they will not become true neighbors. This can be verified by the fact the routers will not install the OSPF routes into their routing table.

Rack1R1#show run int s0/0 Building configuration... Current configuration : 191 bytes ! interface Serial0/0 ip address 136.1.15.1 255.255.255.0 encapsulation frame-relay ip ospf network broadcast frame-relay map ip 136.1.15.5 105 broadcast no frame-relay inverse-arp end Rack1R1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 150.1.5.5 1 FULL/DR 00:00:35 136.1.15.5 Serial0/0 Rack1R1#show ip route ospf Rack1R1#


Another way to detect this problem is to look in the OSPF database. In the database the LSAs will show that the advertising router is not reachable. Rack1R1#show ip ospf database router OSPF Router with ID (150.1.1.1) (Process ID 1) Router Link States (Area 0) LS age: 191 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 150.1.1.1 Advertising Router: 150.1.1.1 LS Seq Number: 80000005 Checksum: 0x681D Length: 36 Number of Links: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 136.1.15.5 (Link Data) Router Interface address: 136.1.15.1 Number of TOS metrics: 0 TOS 0 Metrics: 64 Adv Router is not-reachable LS age: 587 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 150.1.2.2 Advertising Router: 150.1.2.2 LS Seq Number: 80000003 Checksum: 0xAFC Length: 48 Number of Links: 2 The issues with mixing and matching various OSPF network types are covered in more detail in the lab 4 solutions.



Task 4.3 R1, R2, R4, and R5: interface Loopback0 ip ospf network point-to-point R1: router ospf 1 network 150.1.1.1 0.0.0.0 area 0 R2: router ospf 1 network 150.1.2.2 0.0.0.0 area 0 R4: router ospf 1 network 150.1.4.4 0.0.0.0 area 0 R5: router ospf 1 network 150.1.5.5 0.0.0.0 area 0 Task 4.3 Breakdown In addition to the normal configurable OSPF network types, the network type loopback is a special case reserved for loopback interfaces. Loopback interfaces are considered stub networks, and are advertised into the OSPF domain as host routers (/32) regardless of the configured subnet mask on the interface. To advertise the configured mask of the interface into the OSPF domain issue the ip ospf network point-to-point command on the loopback interface.

Standard RFC 2328: OSPF Version 2 9.1. Interface states

Loopback In this state, the router's interface to the network is looped back. …such interfaces are advertised in router-LSAs as single host routes, whose destination is the IP interface address

The key part of the task that allows us to determine that the ip ospf network point-to-point command is to be used as opposed to redistributing the loopbacks into OSPF via connected is that the task states that the loopbacks should be advertised into area 0. If we redistributed them into OSPF they would come in with the /24 subnet mask but they would not belong to area 0.




Task 4.4 R4: interface Serial0/1 ip ospf cost 9999 ! router ospf 1 area 45 virtual-link 150.1.5.5 network 136.1.45.4 0.0.0.0 area 45 R5: interface Serial0/1 ip ospf cost 9999 ! router ospf 1 area 45 virtual-link 150.1.4.4 network 136.1.45.5 0.0.0.0 area 45 Task 4.4 Breakdown When R4 loses its connection to the Frame Relay cloud OSPF areas 4 and 44 lose their connection to area 0. Additionally, since R4’s Loopback 0 interface is advertised into OSPF area 0, area 0 becomes discontiguous when the Frame Relay connection of R4 is down. Frame Relay RFC 2328 dictates that OSPF area 0 must be contiguous throughout the OSPF domain. In addition to this requirement all other areas must be connected to area 0. For situations where physical connectivity cannot be obtained a virtual-link can be used as a logical connection to area 0. Virtual-links can be used to repair broken connections to area 0, connect to discontiguous areas to area 0, and connect discontiguous area 0s. To configure a virtual-link use the routing process subcommand area [transit_area] virtual-link [ABR_router-ID], where transit_area is the area the virtual-link will transit and ABR_router-ID is the router-ID of the area border router on the other side of the link.

Caution A virtual-link is an interface in area 0. Therefore all attributes of area 0 are inherited by routers attached to the virtual-link. This includes area 0 authentication and stipulations on area summarization. Remember that a router that terminates a virtual-link is an area 0 router.



Task 4.5 R1: interface Serial0/0 ip ospf message-digest-key 1 md5 CISCO ! router ospf 1 area 0 authentication message-digest R2: interface Serial0/0 ip ospf message-digest-key 1 md5 CISCO ! router ospf 1 area 0 authentication message-digest R4: interface Serial0/0 ip ospf message-digest-key 1 md5 CISCO ! router ospf 1 area 0 authentication message-digest area 45 virtual-link 150.1.5.5 message-digest-key 1 md5 CISCO R5: interface Serial0/0.15 point-to-point ip ospf message-digest-key 1 md5 CISCO ! interface Serial0/0.245 multipoint ip ospf message-digest-key 1 md5 CISCO ! router ospf 1 area 0 authentication message-digest area 45 virtual-link 150.1.4.4 message-digest-key 1 md5 CISCO Task 4.5 Breakdown OSPF supports both clear text and MD5 authentication. Both of these authentication types can be applied to an OSPF area as a whole or on an individual interface basis. When area authentication is enabled all adjacencies in the area must be authenticated with the defined authentication type. In the above case MD5 authentication is enabled in area 0. This implies that all area 0 adjacencies must authenticate using MD5 unless otherwise overridden.

Pitfall A virtual-link is an area 0 adjacency. If authentication is configured in OSPF area 0 then it must also be configured on all virtual-links.



To enable OSPF area authentication, issue the routing process subcommand area 0 authentication [message-digest]. Adding the message-digest keyword indicates MD5 authentication. Without this command authentication will be clear-text. Next, specify the authentication key on the interface with either the ip ospf authentication-key or the ip ospf message-digest-key depending on whether clear-text or MD5 authentication is enabled. To authenticate a virtual-link add the keyword authentication-key or message-digest-key to the virtual-link statement. Authentication keys are locally significant to an interface, and therefore may differ on a per interface basis.

Note Interface authentication overrides area authentication. Therefore an area may be configured for clear-text authentication while a specific interface is configured for MD5 authentication or NULL (no) authentication. To enable interface authentication issue the interface level command ip ospf authentication or ip ospf authentication message-digest. Note that interface authentication is also available on a virtual-link.



Task 4.6 R1, R2, R4, and R5: router ospf 1 auto-cost reference-bandwidth 20000 Task 4.6 Breakdown OSPF cost calculation is based on the following formula:

Reference_BandwitdhCOST = Interface_Bandwidth

Where Reference_Bandwidth defaults to 100Mbps and Interface_Bandwidth is the configured bandwidth statement of an interface. If Interface_Bandwidth is greater than Reference_Bandwidth, the resulting cost value is 1. Since the reference bandwidth defaults to 100Mbps this implies that all interfaces with a bandwidth above 100Mbps (OC3, GigE, etc) will have a cost of 1. In networks with high speed links this calculation may result in suboptimal forwarding. To adjust how OSPF calculates its cost change the reference bandwidth value by using the routing process subcommand auto-cost reference-bandwidth [Reference_Mbps].




Task 4.7 R1: router eigrp 100 eigrp router-id 150.1.1.1 network 136.1.136.1 0.0.0.0 no auto-summary R2: router eigrp 100 eigrp router-id 150.1.2.2 network 136.1.23.2 0.0.0.0 no auto-summary R3: router eigrp 100 eigrp router-id 150.1.3.3 network 136.1.23.3 0.0.0.0 network 136.1.136.3 0.0.0.0 network 150.1.3.3 0.0.0.0 no auto-summary R6: router eigrp 100 eigrp router-id 150.1.6.6 network 136.1.136.6 0.0.0.0 network 150.1.6.6 0.0.0.0 no auto-summary Task 4.7 Breakdown As of IOS release 12.0(4)T the network-mask argument was added to the EIGRP network statement. To reference a specific interface to run EIGRP on simply use a wildcard mask of 0.0.0.0 in the network statement.

Note The IGP network statement does not specify what networks you are advertising, but instead specifies what interface the routing protocol is running on. A network 0.0.0.0 255.255.255.255 statement would specify that all interfaces are running the protocol in question. This wildcard mask is completely independent of the subnet mask on the interface.



Task 4.8 R5: key chain RIP key 1 key-string CISCO ! interface Ethernet0/0 ip rip authentication mode md5 ip rip authentication key-chain RIP ! router rip version 2 passive-interface default no passive-interface Ethernet0/0 no passive-interface Ethernet0/1 network 136.1.0.0 network 192.10.1.0 no auto-summary R6: router rip version 2 network 54.0.0.0 network 204.12.1.0 no auto-summary SW1: ip routing ! router rip version 2 passive-interface default no passive-interface Vlan57 network 136.1.0.0 no auto-summary


Task 4.9 R1: router eigrp 100 redistribute ospf 1 metric 10000 1000 100 1 1500 ! router ospf 1 redistribute eigrp 100 subnets route-map EIGRP2OSPF distance ospf external 171 ! route-map EIGRP2OSPF permit 10 match tag 1 set metric 1 ! route-map EIGRP2OSPF permit 1000 R2: router eigrp 100 redistribute ospf 1 metric 10000 1000 100 1 1500 ! router ospf 1 redistribute eigrp 100 subnets route-map EIGRP2OSPF distance ospf external 171 ! route-map EIGRP2OSPF permit 10 match tag 3 set metric 1 ! route-map EIGRP2OSPF permit 1000 R5: router ospf 1 redistribute rip subnets ! router rip distance 109 redistribute ospf 1 metric 1




R6: router eigrp 100 redistribute rip metric 10000 1000 100 1 1500 route-map RIP2EIGRP ! router rip redistribute eigrp 100 metric 1 ! ip prefix-list RIP_FROM_BB1 seq 5 permit 212.18.0.0/22 ge 24 le 24 ! ip prefix-list RIP_FROM_BB3 seq 5 permit 30.0.0.0/14 ge 16 le 16 ip prefix-list RIP_FROM_BB3 seq 10 permit 31.0.0.0/14 ge 16 le 16 ! ! route-map RIP2EIGRP permit 10 match ip address prefix-list RIP_FROM_BB1 set tag 1 ! route-map RIP2EIGRP permit 20 match ip address prefix-list RIP_FROM_BB3 set tag 3 ! route-map RIP2EIGRP permit 30 Task 4.9 Breakdown The above redistribution configuration utilizes routing tags to distinguish where the prefixes in question originated from. To set a routing tag simply issue the set tag [tag] command under a route-map used for redistribution.

The above task states that R5 should use R1 to get to the routes learned from BB1 while using R2 to get to the routes learned form BB3. In order to accomplish this routes from BB1 and BB3 are set will separate tag values when redistributed into EIGRP on R6. As EIGRP is redistributed into OSPF on both R1 and R2, these tag values are matched, and an appropriate OSPF cost value is assigned.

Note Tags are not supported in RIPv1 or IGRP. Tags are not supported in IS-IS until IOS release 12.3(2)T.



5. Exterior Gateway Routing Task 5.1 R1: router bgp 100 no synchronization bgp router-id 150.1.1.1 neighbor 136.1.15.5 remote-as 200 neighbor 136.1.136.3 remote-as 100 neighbor 136.1.136.6 remote-as 100 R2: router bgp 300 bgp router-id 150.1.2.2 neighbor 136.1.23.3 remote-as 100 neighbor 136.1.245.5 remote-as 200 R3: router bgp 100 no synchronization bgp router-id 150.1.3.3 neighbor 136.1.23.2 remote-as 300 neighbor 136.1.136.1 remote-as 100 neighbor 136.1.136.6 remote-as 100 R4: router bgp 400 bgp router-id 150.1.4.4 neighbor 150.1.5.5 remote-as 200 neighbor 150.1.5.5 ebgp-multihop neighbor 150.1.5.5 update-source Loopback0 R5: router bgp 200 no synchronization bgp router-id 150.1.5.5 neighbor 136.1.15.1 remote-as 100 neighbor 136.1.57.7 remote-as 200 neighbor 136.1.245.2 remote-as 300 neighbor 150.1.4.4 remote-as 400 neighbor 150.1.4.4 ebgp-multihop neighbor 150.1.4.4 update-source Loopback0 neighbor 192.10.1.254 remote-as 254 neighbor 192.10.1.254 password CISCO R6: router bgp 100 no synchronization bgp router-id 150.1.6.6 neighbor 54.1.3.254 remote-as 54 neighbor 136.1.136.1 remote-as 100 neighbor 136.1.136.3 remote-as 100 neighbor 204.12.1.254 remote-as 54


SW1: router bgp 200 no synchronization bgp router-id 150.1.7.7 neighbor 136.1.57.5 remote-as 200 Task 5.2 R6: router bgp 100 neighbor 54.1.3.254 route-map NO_EXPORT in neighbor 136.1.136.1 send-community neighbor 136.1.136.3 send-community neighbor 204.12.1.254 route-map NO_EXPORT in ! route-map NO_EXPORT permit 10 set community no-export Task 5.2 Breakdown In order to prevent your AS from being used as transit, prefixes which are learned from your providers should not be advertised on to each other. In the above case R6 is learning prefixes from AS 54 through two entry points. In order to prevent other ASs such as AS 300 from using AS 100 as transit to reach these prefixes, AS 100 must prevent them from being advertised. However the task in question states that this “configuration should be done only on R6.” Since R6 is not peering with AS 300 or AS 200, this poses a problem. Therefore in order to affect whether or not other peers in AS 100 advertise these prefixes, R6 is setting the community to no-export. Communities are special tag values that can be applied to prefixes in order to group them in common categories. In addition to these arbitrary numerical communities various well-known communities have been defined.

Well Known Community Behavior Internet All routes belong to this community by default. The

Internet community has no special behavior. No-advertise Do not advertise to any BGP neighbor. No-export Do not advertise to any EBGP neighbor. Local-AS Do not advertise outside of sub-AS. This is a special

case of no-export for use inside of a confederation. By setting the prefixes learned from AS 54 to no-export, R1 and R3 will not advertise them to their EBGP neighbors. This will prevent AS 100 from being used as transit to reach these prefixes.




Task 5.3 R1: router bgp 100 network 136.1.3.0 mask 255.255.255.0 R3: router bgp 100 neighbor 136.1.15.5 route-map TO_R5 out ! ip prefix-list VLAN3 seq 5 permit 136.1.3.0/24 ! route-map TO_R5 permit 10 match ip address prefix-list VLAN3 set as-path prepend 100 100 ! route-map TO_R5 permit 1000 Task 5.3 Breakdown In the above task AS 100 is trying to affect the inbound traffic flow from its BGP peers. Recall which attribute should be set to affect BGP path selection:



MED Outbound Inbound To affect inbound traffic flow you must either prepend the AS-path attribute or set the multi-exit discriminator (MED) value as the prefix is advertised outside the AS. However, since MED is only compared by default on prefixes learned from the same AS, AS-path prepending must be used in this case.

Pitfall BGP community attributes are not included in advertisements by default. In order to enable the sending of the community attribute along with a prefix, use the BGP routing process subcommand neighbor [neighbor] send-community. Unless this command is included the community value will be stripped from an advertisement, regardless of whether it is going to an iBGP or EBGP neighbor.



Since AS 100 wants traffic to come in from AS 300, it is prepending its own AS number out twice when sending updates to AS 200. Therefore when AS 200 compares the AS-path length on the prefixes learned from AS 100 and AS 300, it will prefer the path through AS 300. Task 5.4 R2: router bgp 300 network 136.1.2.0 mask 255.255.255.0 R5: router bgp 200 neighbor 136.1.245.2 route-map FROM_R2 in ! ip prefix-list VLAN2 seq 5 permit 136.1.2.0/24 ! route-map FROM_R2 permit 10 match ip address prefix-list VLAN2 set weight 100 ! route-map FROM_R2 permit 1000 Task 5.5 R2: router bgp 300 network 136.1.23.0 mask 255.255.255.0 neighbor 136.1.245.5 advertise-map ADVERTISE non-exist-map NON_EXIST ! ip prefix-list HDLC seq 5 permit 136.1.23.0/24 ! ip prefix-list VLAN2 seq 5 permit 136.1.2.0/24 ! route-map NON_EXIST permit 10 match ip address prefix-list HDLC ! route-map ADVERTISE permit 10 match ip address prefix-list VLAN2


Task 5.5 Breakdown The order of the BGP best-path selection algorithm dictates that you have absolute control over how traffic leaves your autonomous system. This is due to the fact that the attributes used to affect outbound traffic (weight and local-preference) are higher in the decision process than those used to affect inbound traffic (AS-path and MED). By setting either the weight or local-preference on a prefix you can affect how traffic leaves your AS to get to that prefix. Under certain circumstances this behavior may be undesirable. Therefore BGP conditional advertisement offers an alternative way to affect how traffic enters your AS. By not advertising a prefix to a specific neighbor it is forced to route through a peer that does have a route to it. This feature is typically used when you have multiple connections of varying speeds to one or more providers. By controlling which prefixes get advertised to which neighbors, traffic can be forced to route in the appropriate link. In the case of a link failure, conditional advertisement will begin advertising the prefixes in question to the configured neighbor. BGP conditional advertisement consists of two parts, the prefix or prefixes to watch, and the prefix or prefixes to advertise. It is applied by issuing the BGP process subcommand neighbor [neighbor] advertise-map [advertise-map] non-exist-map [non-exist-map] where advertise-map is a route-map that matches the prefix that will be conditionally advertised, and non-exist-map is a route-map that matches the prefix to be watched. Once the prefix in the non-exist-map leaves the BGP table, the prefix in the advertise-map is advertised to the configured neighbor. Note that both of these prefixes must exist in the BGP table before configuring conditional advertisement. In the above task AS 300 wants all traffic for the prefix 136.1.2.0/24 to come in the HDLC link 136.1.23.0/24 unless it is down. To accomplish this, the 136.1.2.0/24 prefix should only be advertised to from R2 to R5 if the HDLC link 136.1.23.0/24 is down. 136.1.2.0/24 will therefore be matched in the advertise-map, while 136.1.23.0/24 is matched in the non-exist-map.




Verification R2#show ip bgp neighbors 136.1.245.5 | include Condition Condition-map NON_EXIST, Advertise-map ADVERTISE, status: Withdraw Prefix Not Advertised

R2#show ip bgp neighbors 136.1.245.5 advertised-routes BGP table version is 4, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best,

i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 136.1.23.0/24 0.0.0.0 0 32768 i R2(config)#interface Serial0/1 R2(config-if)#shutdown Serial link fails R2#show ip bgp 136.1.23.0 BGP routing table entry for 136.1.23.0/24, version 5 Paths: (0 available, no best path) Prefix no longer exists Flag: 0x820 Not advertised to any peer R2#show ip bgp neighbors 136.1.245.5 | include Condition Condition-map NON_EXIST, Advertise-map ADVERTISE, status: Advertise Prefix Now Advertised R2#show ip bgp neighbors 136.1.245.5 advertised-routes BGP table version is 6, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 136.1.2.0/24 0.0.0.0 0 32768 i Prefix Now Advertised

Further Reading Configuring and Verifying the BGP Conditional Advertisement Feature

http://www.cisco.com/warp/public/459/cond_adv.html


6. IP Multicast Task 6.1 R1 and R2: ip multicast-routing ! interface FastEthernet0/0 ip pim sparse-dense-mode ! interface Serial0/0 ip pim sparse-dense-mode R3: ip multicast-routing ! interface Ethernet0/0 ip pim sparse-dense-mode ! interface Ethernet0/1 ip pim sparse-dense-mode R4: ip multicast-routing ! interface Ethernet0/0 ip pim sparse-dense-mode ! interface Serial0/0 ip pim sparse-dense-mode R5: ip multicast-routing ! interface Loopback0 ip pim sparse-dense-mode ! interface Serial0/0.15 ip pim sparse-dense-mode ! interface Serial0/0.245 ip pim sparse-dense-mode ! ip pim send-rp-announce Loopback0 scope 16 group-list 50 ip pim send-rp-discovery Loopback0 scope 16 ! access-list 50 permit 225.0.0.0 0.255.255.255 access-list 50 permit 226.0.0.0 0.255.255.255 access-list 50 permit 227.0.0.0 0.255.255.255




Task 6.1 Breakdown Since this section did not dictated sparse or dense mode, Auto-RP or static RP could have been used. Auto-RP announce and discovery messages use multicast groups 224.0.1.39 and 224.0.1.40. 224.0.1.39 is used by RPs to send their RP announce messages. Mapping agents send group-to-RP mapping messages using 224.0.1.40. In order for a device to learn about an RP and about the group to RP mappings, it must first join 224.0.1.39 and 224.0.1.40. However, in order to join these groups, the device must know which RP to send these join messages to. In other words, the device needs to know where the RP is in order to discover where the RP is, and the device needs to discover where the RP is in order to know where the RP is. In order to overcome this issue, dense mode needs to be enabled, specifically sparse-dense. Groups 224.0.1.39 and 224.0.1.40 will use dense mode to disseminate announcement and discovery messages. The drawback of enabling sparse-dense mode on all interfaces is if the RP becomes unreachable, multicast groups that were mapped to that particular RP will failover to being treated as dense. It is important to remember that the determining factor if a particular multicast group will be treated as sparse or dense is not based on how the interface is configured. When a particular multicast group is received by a multicast enabled device, the device will treat the group as sparse if there is an RP for that group. If there is not an RP for that particular multicast group, the group will be treated as dense. The flood and prune mechanism of dense mode is normally undesirable in a production network, and is the reason sparse mode is commonly the recommended mode for multicast. As of IOS 12.2.7, PIM sparse-dense mode is not required for Auto-RP. Cisco implemented the ip pim autorp listener global configuration command to overcome the need to enable sparse-dense mode when using Auto-RP. When this command is enabled, only sparse mode will need to be enabled. This eliminates the potential problems of dense mode failover.

Documentation CD ip pim autorp listener

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fiprmc_r/mult/1rfmult2.htm#1090395



Task 6.2 R2: interface FastEthernet0/0 ip igmp static-group 228.22.22.22 Task 6.2 Breakdown The ip igmp static-group command is different than the ip igmp join-group command in that the static-group command does not cause the devices to process the multicast packets themselves. Instead the device will just forward the multicast packets out the interface. With the ip igmp static-group command a device will not respond to ICMP echo requests sent to the multicast group as with the ip igmp join-group command. If a particular multicast group needs to be sent out an interface, the static-group command would be preferred over the join-group command. The static-group command causes the group to be fast switched, where as the join-group command will cause the device to process switch the group. Both commands are not needed to enable hosts on a segment to receive multicast traffic as long as the host supports IGMP. Task 6.3 R4: interface Ethernet0/0 ip igmp access-group 50 ! access-list 50 permit 225.25.25.25 access-list 50 permit 226.26.26.26 Task 6.3 Breakdown To limit which multicast groups clients on a segment can join, use the ip igmp access-group interface command. In this task clients will only be allowed to join multicast groups 225.25.25.25 and 226.26.26.26.



Task 6.4 R1: interface FastEthernet0/0 ip multicast ttl-threshold 12 Task 6.4 Breakdown Whenever a multicast packet is sent by a server, the TTL of the packet is set. The TTL can be set anywhere from 0 to 255. A multicast packet sent with a TTL of 1, or technically 0, will not allow a multicast router to forward the packet. This is the mechanism that OSPF uses to ensure that its packets are never sent across a router. By using TTL, a multicast implementation can limit where the multicast traffic can be sent in the network or stop the multicast traffic from being sent out of a network. This is commonly referred to as multicast scoping. Multicast scoping can be difficult to implement reliably in a medium or large sized network. Issues like alternate paths in the network or tunnels used to carry multicast traffic can make scoping nearly impossible to properly implement. The ip multicast ttl-threshold interface command stops the forwarding of multicast packets that do not have a TTL value greater than what is defined by the command.


7. IPv6 Task 7.1 R2: interface Ethernet0/0 ipv6 address 2001:CC1E:1:202::/64 eui-64 R4: interface Ethernet0/0 ipv6 address 2001:CC1E:1:404::/64 eui-64 Task 7.2 R2: interface Tunnel0 ipv6 address FEC0::2/64 tunnel source 150.1.2.2 tunnel destination 150.1.4.4 ! ipv6 route 2001:CC1E:1:404::/64 Tunnel0 R4: interface Tunnel0 ipv6 address FEC0::4/64 tunnel source 150.1.4.4 tunnel destination 150.1.2.2 ! ipv6 route 2001:CC1E:1:202::/64 Tunnel0 Task 8.3 – 8.5 Breakdown Site-local IPv6 addresses are similar to private addresses defined in RFC 1918 for IPv4, as they are designed to be used as address space only routable within a private network. Site-local IPv6 addresses start with the bit pattern 1111111011, expressed as FEC0::/10 in IPv6 address format (not to be confused with the link-local FE80::/10 address space). By identifying the site-local address space with a unique prefix (FEC0::/10) ingress and egress filtering can be easily applied to prevent traffic from/to hosts using this address space moving between site boundaries at the network edge. The above example illustrates how to tunnel IPv6 datagrams over the IPv4 network using GRE encapsulation. This configuration is similar to that of IPv6IP tunneling, however GRE tunneling supports the tunneling of multiple non-IP protocol stacks simultaneously (IPX, CLNS, etc).




8. QoS Task 8.1 R1, R2, R4, and R5: interface Serial0/0 frame-relay class FRTS frame-relay traffic-shaping ! map-class frame-relay FRTS frame-relay cir 256000 frame-relay bc 32000 frame-relay mincir 192000 frame-relay adaptive-shaping becn frame-relay fecn-adapt Task 8.1 Breakdown Forward Explicit Congestion Notification (FECN) is used by the Frame Relay switch to notify a router that the remote router is causing congestion in the network. Backward Explicit Congestion Notification (BECN) is use to notify a router that it is the source of the congestion. OSI and DECnet Phase V are the only protocols that will automatically map the FECN bit to their own congestion experienced bit. This allows the devices to decrease their window size and in turn will theoretically decrease network utilization. This method of slowing down by using windowing is similar to TCP decreasing the window size when a packet is lost.

It is important to note that the BECN and FECN bits are set in normal data frames, and are not explicit frames generated by the Frame Relay switch. This makes it theoretically possible that a router will never receive a frame with the BECN bit set if the remote router never sends data to it. A realistic example would be where a DLCI is used exclusively to send multicast traffic. In this case the vast majority of frames will be in one direction, source toward the receivers. If congestion occurs the Frame Relay switch will start marking frames. The majority of the frames will of course be marked in the opposite direction of the congestion as most traffic will flow from the source toward the receivers. The frame-relay fecn-adapt map-class command is useful in this type of situation as the receiving router can generate a frame with the BECN bit set upon receipt of a frame with the FECN bit set. This will allow the source of the congestion to throttle its sending rate down if the frame-relay adaptive-shaping becn map-class command is configured on the router causing the congestion.

Optional

Data should be sent at a sustained rate of 256Kbps per DLCI

In the event of congestion notification, fallback to no lower than 192Kbps

Any FECNs received should be reflected as BECNs


Task 8.2 R4: class-map match-all HTTP_CLASS match access-group 150 ! policy-map HTTP_POLICY class HTTP_CLASS police cir 256000 ! interface Ethernet0/1 service-policy output HTTP_POLICY ! access-list 150 permit tcp any eq www any time-range HTTP_TIMERANGE ! time-range HTTP_TIMERANGE periodic weekdays 8:00 to 17:00 Task 8.2 Breakdown In this task a common mistake made is to configure the access-list incorrectly. Be careful to closely read the wording of tasks in regards to the direction of the traffic flow when configuring access-lists. This task mentioned that HTTP responses send out R4’s interface E0/0 be limited. This means that the below access-list would be incorrect as it would match HTTP packets destined to a web server in VLAN 44. access-list 150 permit tcp any any eq www time-range HTTP_TIMERANGE The access-list needs to match the HTTP server’s responses and is why the access-list is configured as below. access-list 150 permit tcp any eq www any time-range HTTP_TIMERANGE The time-range option of the extended access-list allows for selective filtering based on the clock of the local router. Time based access-lists are created by first defining the time-range in global configuration mode. The keywords absolute and periodic determine whether the event will occur at one specific (absolute) time, or will recur at a certain (periodic) interval. Once the local time is within the specified time-range, the access-list entry or entries which reference the time-range are active. When the time range is inactive, it is as if the access-list entries do not exist.




Further Reading Time-Based Access Lists Using Time Ranges

Verification R4: access-list 150 permit tcp any eq www any time-range HTTP_TIMERANGE ! time-range HTTP_TIMERANGE periodic weekdays 8:00 to 17:00 R4#clock set 00:00:00 1 Jan 2004 R4#show clock 00:00:01.322 UTC Thu Jan 1 2004 R4#show access-lists Extended IP access list 150 10 permit tcp any eq www any time-range HTTP_TIMERANGE (inactive)

time-range is inactive on a Thursday at 12am R4#clock set 10:00:00 1 Jan 2004 R4#show clock 10:00:03.069 UTC Thu Jan 1 2004 R4#show access-lists Extended IP access list 150 10 permit tcp any eq www any time-range HTTP_TIMERANGE (active)

time-range is active on a Thursday at 10am R4#clock set 10:00:00 3 Jan 2004 R4#show clock 10:00:02.480 UTC Sat Jan 3 2004 R4#show access-lists Extended IP access list 150 10 permit tcp any eq www any time-range HTTP_TIMERANGE (inactive) time-range is inactive at the same time on a Saturday

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t1/timerang.htm


Task 8.3 R4 and R5: map-class frame-relay FRTS frame-relay fair-queue R4: interface Serial0/0 ip rsvp bandwidth 128 64 ! dial-peer voice 4 voip req-qos guaranteed-delay R5: interface Serial0/0 ip rsvp bandwidth 128 64 ! interface Serial0/0.245 multipoint ip rsvp bandwidth 128 64 Task 8.3 Breakdown Resource Reservation Protocol (RSVP) is used to dynamically request specific QoS from the network for a particular data flow. A data flow is defined as sequence of packets that have the same QoS requirements and have the same source and destination. Note that the destination could possibly be more than one host in the case of IP multicast. RSVP requests will normally result in resources being reserved by each router along the path between the source and destination. There are three possible requests that R4 can make for its VoIP traffic. The first is best effort. Best effort does just want is says, supplies a best effort QoS policy for particular data flow. Best effort is commonly used with general application traffic. The second is controlled load. Controlled load is used for rate sensitive traffic. Rate sensitive traffic will be guaranteed bandwidth (rate) through RSVP. The third is guaranteed delay. Guaranteed delay is used to help ensure a minimum amount of jitter. Delay is normally one of the more important QoS requirements in relation to VoIP. Although this is a basic configuration in regards to RSVP, it is important to note that when using subinterfaces that the ip rsvp bandwidth command will need to be applied to the physical along with the subinterface. If more than one subinterface is using RSVP, the physical interface’s ip rsvp bandwidth command will be the sum of all the subinterface’s ip rsvp bandwidth commands.




Pitfall Weighted Fair Queuing (WFQ) needs to be enabled for RSVP. Although WFQ is normally enabled by default on the Serial interfaces (2.048 Mbps and below), once Frame Relay Traffic Shaping is enabled, WFQ is disabled. Rack1R1#show run interface s1/0 Building configuration... Current configuration : 113 bytes ! interface Serial1/0 no ip address encapsulation frame-relay end Rack1R1#show queueing interface s1/0 Interface Serial1/0 queueing strategy: fair Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/1/32 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 96 kilobits/sec Rack1R1(config)#int s1/0 Rack1R1(config-if)#frame-relay traffic-shaping Rack1R1(config-if)#^Z Rack1R1#show queueing interface s1/0 Interface Serial1/0 queueing strategy: none Rack1R1#show run interface s1/0 Building configuration... Current configuration : 113 bytes ! interface Serial1/0 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping end Rack1R1#


10. Security Task 9.1 R6: interface Serial0/0/0 ip access-group IN_ACL in ip access-group OUT_ACL out ! ip access-list extended IN_ACL permit icmp any any time-exceeded permit icmp any any port-unreachable permit udp any any eq rip permit tcp any any eq bgp permit tcp any eq bgp any evaluate MY_REFLECT ip access-list extended OUT_ACL permit tcp any any reflect MY_REFLECT permit udp any any reflect MY_REFLECT permit icmp any any reflect MY_REFLECT Task 9.1 Breakdown A reflexive access-list is used to meet the requirements of this section. Remember that by default, packets generated by the router itself will not be reflected. This is why BGP is ‘statically’ permitted inbound. To permit traceroute, we first need to fully understand how traceroute works. First off, it is important to think of traceroute as a technique and not necessarily an application. The goal of traceroute is the find the path the packets take between the source and destination. To do this traceroute needs to accomplish two tasks. The first task is to discover any routers along the path. This is done by manipulating the time-to-live (TTL). The second task is to have the destination respond so that traceroute knows that the destination has been reached. Depending on the particular implementation of traceroute, this response could be an ICMP echo reply, ICMP port unreachable, or in the case of TCP based traceroute, a ‘SYN, ACK’. TTL is used by routers to ensure a packet will not remain on the network indefinitely due to issues like a routing loop. When a packet is received by a router, the router must decrement the TTL by at least1 before forwarding it on. Technically, a router must decrement the TTL for each second that the router holds the packet. Of course holding a packet for more than a few milliseconds much less a few seconds would be rare in today’s networks. When the TTL has been decremented to 0, the router must discard the packet. When a packet is discarded due to the TTL expiring, an ICMP time-exceeded message is sent by the router that discarded the packet, to the source notify it that the packet expired in transit. This is the particular message that a traceroute application is looking to receive by the routers in the path between the source and destination. When




the router generates the ICMP time-exceeded, the traceroute application discovers the router and the traceroute application now knows that the packet should transit that particular router. Now that the routers in the path have been discovered, the source needs to know when the destination has been reached. So traceroute needs to send a packet that will entice the destination to reply. Technically this could be any type of packet that will cause the destination to send a return packet to the source. The packet type will depend on the particular implementation of the traceroute application. Now that we know how traceroute works and what traceroute is trying to do, we can look at how traceroute is implemented. There are implementations of traceroute that use ICMP, UDP and even TCP. The Cisco IOS uses UDP, Microsoft uses ICMP, and new versions of Linux use ICMP or UDP. There are also various TCP traceroute applications available for different operating systems. Here is an example of TCP traceroute to www.cisco.com port 80. [root@Homer bdennis]# tcptraceroute -n www.cisco.com 80 Selected device eth0, address 172.16.1.250, port 32795 for outgoing packets Tracing the path to www.cisco.com (198.133.219.25) on TCP port 80, 30 hops max 1 64.172.154.254 (64.172.154.254) 38.485 ms 13.425 ms 39.358 ms 2 63.234.16.33 (63.234.16.33) 13.793 ms 15.680 ms 26.380 ms 3 63.234.16.8 (63.234.16.8) 15.852 ms 28.993 ms 13.263 ms 4 151.164.181.73 (151.164.181.73) 34.957 ms 36.938 ms 31.576 ms 5 151.164.240.134 (151.164.240.134) 31.983 ms 34.405 ms 31.756 ms 6 144.228.44.49 (144.228.44.49) 33.196 ms 34.641 ms 31.970 ms 7 144.232.0.225 (144.232.0.225) 31.998 ms 36.637 ms 31.794 ms 8 144.232.3.138 (144.232.3.138) 31.458 ms 34.687 ms 31.498 ms 9 144.228.44.14 (144.228.44.14) 32.125 ms 34.090 ms 31.759 ms 10 128.107.239.89 (128.107.239.89) 31.990 ms 34.416 ms 31.970 ms 11 128.107.239.98 (128.107.239.98) 34.473 ms 36.888 ms 31.753 ms 12 198.133.219.25 (198.133.219.25) [open] 31.808 ms 39.538 ms 37.105 ms [root@Homer bdennis]#

Note One of the reasons many traceroute applications do not use ICMP echos is in accordance with RFC 792 (Internet Control Message Protocol). RFC 792 states that since ICMP is typically used to report errors, that ICMP messages should not be send about other ICMP messages.



Remember that traceroute is trying to discover the routers along the path by manipulating the TTL. The TTL field is in the header of the IP packet, so this means that ICMP, UDP and TCP packets can be used. Any of these protocols can have a packet sent with a TTL of 1. When the first router in the path receives the packet and decrements the TTL to 0, an ICMP time-exceeded message is generated and the packet is discarded. When the traceroute application receives the ICMP time-exceeded, the application will then generate another packet with a TTL of 2. This cycle will continue till the final destination is reached. After the final destination has been reached, the reply from the destination will depend on the packet type used by the traceroute application. If the packet generated by the traceroute application is an UDP packet as in the case of a Cisco router, the destination of the packet will normally be sent to a UDP port that is not being used by the destination. When the UDP packet arrives at the destination device, and sent to the unused UDP port, the destination device will generate an ICMP port unreachable message. When that ICMP port unreachable is received by the source’s traceroute application, the source will then know it has reached the destination. Below is the output from traceroute on a Cisco router. IE#traceroute Protocol [ip]: Target IP address: 198.133.219.25 Source address: Numeric display [n]: y Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 198.133.219.25 1 63.115.78.1 4 msec 4 msec 4 msec 2 157.130.213.37 12 msec 12 msec 12 msec 3 65.208.80.242 16 msec 16 msec 16 msec 4 128.107.239.5 16 msec 16 msec 16 msec 5 128.107.239.106 16 msec 12 msec 12 msec 6 198.133.219.25 16 msec 16 msec 16 msec IE# As we can see, the router did not perform DNS lookups on the replies. This is desirable in a lab environment were DNS lookups can not be resolved. It generated 3 packets per TTL as indicated by the ‘probe count’. The first packet was sent with a TTL of 1 and a destination UDP port of 33434.


If the packet generated by the traceroute application is an ICMP echo request packet, as in the case of Microsoft Windows, the destination will reply with an ICMP echo reply. The same process as described before happens in regards to sending the first packet with a TTL of 1, second packet with a TTL of 2, etc. The traceroute application will know that the destination has been reached when an ICMP echo-reply is received. Now we can look at our configuration and understand why we ‘statically’ permitted ICMP time-exceeded and ICMP port-unreachable messages. The time-exceeded messages are needed when a router in the path discards a packet due to the TTL expiring. The port unreachable messages are needed by UDP based traceroute (i.e. Cisco IOS). If ICMP echo based traceroute was used we would not need to permit the ICMP port-unreachables as the reflective access-list will detect the ICMP echo request and dynamically allow the ICMP echo reply. Task 9.2 R4: ip tcp intercept list 125 ip tcp intercept watch-timeout 15 ip tcp intercept mode watch ! access-list 125 permit tcp any host 136.1.4.100 Task 9.2 Breakdown TCP intercept is used to help prevent a TCP SYN flood DoS attack. In a SYN flood DoS attack, a source or in most cases many sources, send a flood of TCP SYN packets usually containing bogus (i.e. fake) source IP addresses.

The SYN packet is the first part of the TCP 3-way handshake. When a server receives the TCP SYN (synchronization) packet from a client, the server replies with a ‘SYN ACK’ (synchronization acknowledgement). The server will then wait for the client to complete the handshake process. For the process to be completed, the client will send an ACK in response to the server’s ‘SYN, ACK’. At this point the TCP session will be established. If the ACK is not received from the client, the session will timeout and in turn will be torn down. Once the session is torn down, the server’s resources will be released.




A TCP SYN flood DoS attack uses this 3-way handshake process to cause the server to allocate resources for sessions that will never become established. The source or sources of the attack in most cases send thousands of TCP SYN packets per second to the server using bogus source IP addresses. The server, which does not know that the source IP addresses are bogus, receives the SYN packets, and replies with the ‘SYN ACK’. The server then begins to allocate resources for the anticipated TCP session. After 10’s of thousands of these SYN packets have been received by the server within a few seconds, the server will run out of resources to allocate for additional TCP sessions. The server now has thousands of half open TCP sessions that will eventually timeout after failing to receive the ACK from the client. Since most, if not all of the server’s resources are tied up replying to the SYN packets generated by the source/sources of the attack, legitimate users will not be able to establish a TCP session with the server.

TCP intercept can be used to enable the router to intercept the TCP SYN packets. The router will proxy for the server, and send the SYN ACK to the client. If the router receives an ACK from the client, the router knows that the session is valid and connects the session with the server. In theory TCP intercept is a good solution in that the attack is offloaded from the server, but in reality it is not a good solution as the burden of the attack is now taken on by the router. In a real network, it is normally easier to just install more and faster servers to deal with the burden of a DoS attack.

There are two modes of TCP intercept. The first is intercept mode and the second is watch mode. With intercept mode the router will actively intercept the TCP sessions. In watch mode, the router will not intercept the TCP sessions but will monitor the TCP sessions and if a session does not reach the established state within 30 seconds (default time), the router will send a RST to the server so the server can release the resources allocated for that particular session. This is the intercept mode used by this section. In this section a TCP RST packet will be sent to the server for TCP sessions that do not become established within 15 seconds. An access-list is additionally used to restrict which hosts are being ‘watched’.

Interesting Reading The Strange Tale of the Denial of Service

http://grc.com/DoS/grcDoS.htm



10. System Management Task 10.1 SW1: access-list 50 permit 136.1.2.100 ! snmp-server community CISCORO RO 50 snmp-server community CISCORW RW 50 snmp-server location San Jose, CA US snmp-server contact CCIE Lab SW1 snmp-server chassis-id 221-787878 snmp-server enable traps vtp snmp-server host 136.1.2.100 CISCOTRAP vtp Task 10.1 Breakdown SNMP is the de facto standard management protocol for the IP protocol suite. Developed in the late 1980s by the Internet Engineering Task Force (IETF), SNMP enables a simple means for vendors to provide management capabilities to their networking devices. The SNMP protocol is actually a grouping of standards, defined by the following RFCs:

• RFC 1155: Structure and Identification of Management Information

for TCP/IP-based Internets

• RFC 1157: A Simple Network Management Protocol (SNMP)

• RFC 1212: Concise MIB (Management Information Base)

• RFC 1213: Management Information Base for Network Management of TCP/IP-based Internets: MIB-II

SNMPv2 additionally is defined by the following RFCs:

• RFC 1901: Introduction to Community-Based SNMPv2

• RFC 1902: Structure of Management Information for SNMPv2

• RFC 1903: Textual Conventions for SNMPv2

• RFC 1904: Conformance Statements for SNMPv2

• RFC 1905: Protocol Operations for SNMPv2

• RFC 1906: Transport Mappings for SNMPv2

• RFC 1907: Management Information Base for SNMPv2

• RFC 1908: Coexistence Between Version 1 and Version 2 of the Internet-Standard Network Management Framework.


Perhaps one of the SNMP protocol’s greatest assets is its extendibility, meaning vendors can enhance SNMP to encompass the proprietary features of their products and technologies. In a Cisco environment, for example, Cisco Discovery Protocol (CDP) information can be queried utilizing SNMP, even though CDP is a proprietary Cisco protocol. SNMP defines a manager/agent relationship for network management. In this relationship, a manager device queries the network devices (agents) for performance, configuration and status information. An example of an SNMP manager could be a network management station (NMS) running CiscoWorks, while an agent could be a Cisco 2600 router. The NMS, acting as manager, communicates with the 2600, acting as agent, for information about its performance, configuration, and status. Tasks like configuration changes and reloading of the agent can be performed by the manager. The communication between the manager and agent is carried in what is called a Protocol Data Unit (PDU). As SNMP is a simple, request/reply protocol, the messages between the manager and agent are “carried” in a PDU. SNMP uses the User Datagram Protocol (UDP) as its transport layer protocol for IP. PDUs essentially transmit messages between agents and managers. The following messages are used by SNMP:

• GetRequest - Retrieves information from a networking device’s SNMP agent.

• GetResponse - This is the response from the SNMP agent to the SNMP manager’s request messages.

• GetNextRequest - Retrieves the next object instance from the networking device’s SNMP agent.

• SetRequest - Sent by an SNMP manager to perform remote configuration on a networking device.

• Trap - Issued by the SNMP agent to inform the SNMP manager about a change of state on the networking device.

Not all messages can be sent by certain devices in the managed environment. The NMS (manager) sends a PDU to a router (agent), in this case a SNMP GetRequest. The router will respond with a PDU of its own, the SNMP GetResponse. Essentially, an agent can only respond to requests and cannot initiate SNMP requests of its own. The only message initiated by an agent is the SNMP trap message.



SNMPv2 includes several additional PDU messages, including:

• GetBulk – This enables an SNMP manager to access large chunks of data. GetBulk allows an agent to respond with as much information as will fit in the response PDU. Agents that cannot provide values for all variables in a list will send partial information.

• Inform – Allows NMS stations to share Trap information.

Note A Management Information Base (MIB) is a database of network management objects that are used and maintained by the SNMP protocol.

The SNMP community strings that can be configured on the 3550 are Read-Only (RO) and Read-Write (RW) strings. The RO community string allows read access to all MIBs except the community strings themselves. The RW community string allows read and write access to all MIBs except the community strings themselves. Although not available on the 3550s, there is a third community string named Read-Write-All. This community string allows read and write access to all MIBs including the community strings themselves. Some Cisco devices allow access to this community string (i.e. Catalyst 5000). The task asked that SNMP traps relating to VTP be generated. This will enable SW1 to generate a SNMP trap for VLAN Trunking Protocol (VTP) changes. In a stable network, there theoretically should not be any changes related to the trunking status of a trunk port. By enabling VTP traps, the network management station will be notified when there is a change. SNMP vlancreate and vlandelete traps may also be useful to have generated in a real network.

The snmp-server enable traps vtp is used to enable traps relating to VTP changes. Next the snmp-server host command must be configured to specify where to send traps. The vtp option on the end of the host command specifies that only VTP traps will be sent to that particular host. By default all traps that are enabled will be sent to the configured host or hosts.




Task 10.2 R4: username WEB secret CISCO ! ip http server ip http port 8080 ip http access-class 75 ip http authentication local ! access-list 75 permit 136.1.2.0 0.0.0.255 Task 10.2 Breakdown Although commonly not used, the IOS supports management and configuration through a web browser. In this section the router has been configured to listen to HTTP requests on TCP port 8080. An access-list has been additional defined to permit on devices from the 136.1.2.0/24 subnet from accessing the router via HTTP. This is similar to applying an access-class inbound under the VTY lines. Newer IOS versions support HTTP configuration using Secure Socket Layer (SSL).

Further Reading HTTP 1.1 Web Server and Client HTTPS - HTTP Server and Client with SSL 3.0

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t15/fthttp1s.htm#wp1027129

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t15/ftsslsht.htm



Task 10.3 R3: tftp-server flash:c2600-iuo-mz.122-13.bin alias cisco2-C2600 Task 10.3 Breakdown The key to this section is the alias portion of the tftp-server command. When a router starts to boot up, it will look in its global configuration for any boot commands. If there are not any boot commands specified, the router will fall over to using the first image in flash. If an image is not found in flash, the router will then try to boot a default image via TFTP. The default IOS image name for the 2600 used in this lab is ‘cisco2-C2600’. The image name is hardware dependant in that a 3600 will attempt to boot a different default IOS image. To determine which IOS image a router will attempt to boot, reload the router and then send control-break to get into ROMMON mode. Once in ROMMON mode, type confreg, assuming you are using a 2600 series or higher router. You will then be able to see the default IOS image. Rack1R1#reload Proceed with reload? [confirm] *Mar 5 07:18:49.086: %SYS-5-RELOAD: Reload requested by console. System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1) Copyright (c) 1999 by cisco Systems, Inc. TAC:Home:SW:IOS:Specials for info C2600 platform with 65536 Kbytes of main memory PC = 0xfff0a530, Vector = 0x500, SP = 0x83fff8b0 monitor: command "boot" aborted due to user interrupt rommon 1 > confreg Configuration Summary enabled are: load rom after netboot fails console baud: 9600 boot: image specified by the boot system commands or default to: cisco2-C2600 do you wish to change the configuration? y/n [n]:


Task 10.4 R2: interface FastEthernet0/0 ip directed-broadcast R5: interface Serial0/0.555 point-to-point ip address 136.1.5.1 255.255.255.252 ip helper-address 136.1.2.255 frame-relay interface-dlci 555 protocol ip 136.1.5.2 Task 10.4 Breakdown The solution for this section is auto-install over Frame Relay. As mentioned previously, a router is a BOOTP server by default. In this case R5 will give the new router the IP address of 136.1.5.2 via BOOTP. One issue with this section is that the IP address of the TFTP was not given. The only information given is that the TFTP server is located in VLAN 2. The solution is to configure the ip helper-address command to point to the directed broadcast for the subnet. To allow for successful transmission ensure that the last hop interface supports directed-broadcast, which is disabled by default.




11. System Management Task 11.1 enable secret level 1 CISCO ! privilege exec level 0 traceroute privilege exec level 0 ping ! line vty 0 4 privilege level 0 Task 11.1 Breakdown Privilege levels are used to restrict user access to certain commands. There are 16 privilege levels available on the router (0-15). The privilege levels that by default have commands assigned to them are 0, 1, and 15. Privilege level 1 is commonly referred to as user mode, and privilege level 15 is commonly referred to as enable mode. When first logging into a router, the privilege level will be 1 as the default privilege level assigned to all lines (VTY, console, etc) is privilege level 1.

To change the default privilege level for a line, the privilege level line command is used. If the privilege level is set to 15 for a particular line the user will automatically be placed into enable mode (privilege level 15).

Rack1R1#show run | include (vty)|(privilege) line vty 0 4 privilege level 15 Rack1R1# Rack1R1#telnet 150.1.1.1 Trying 150.1.1.1 ... Open User Access Verification Password: Rack1R1#show privilege Current privilege level is 15 Rack1R1#

Note When in privilege level 0 or 1, the router’s prompt will be ‘>’. Any level above level 1 will have a prompt of ‘#’.



Privilege level 0 is the lowest level on the router. There are only a few commands available to a user in privilege level 0. Rack1R1>? Exec commands: <1-99> Session number to resume disable Turn off privileged commands enable Turn on privileged commands exit Exit from the EXEC help Description of the interactive help system logout Exit from the EXEC voice Voice Commands Rack1R1> Normally when privilege level 0 is used, additional commands are moved down to privilege level 0 from privilege level 1 or 15. To move a command from one privilege level to another, the privilege global configuration command is used. Commands in lower privilege levels are automatically available to users in higher privilege levels.

To switch between privilege levels, use the enable command. The default option on the enable command is ‘15’.

Rack2R3#enable ? <0-15> Enable level <cr> Rack2R3#enable When switching from a higher privilege level to a lower privilege level, a password is not required. Only when switching from a lower level to a higher level is a password required. To configure a password for particular privilege level, use the enable secret level or the enable password level commands. Task 11.2 R5: privilege exec level 1 debug ip rip privilege exec level 1 undebug all Task 11.2 Breakdown Ensure in a real network when allowing users access to debugging command that the users are also given access to the undebug command.



1. Catalyst 3550 Task 1.1 SW1: vtp domain ETHERNET vtp password CISCO vtp pruning vlan 6,7,8,12,36,43,45,77,88,258 ! interface FastEthernet0/1 switchport access vlan 12 ! interface FastEthernet0/2 switchport access vlan 258 ! interface FastEthernet0/3 no switchport ip address 141.1.37.7 255.255.255.0 ! interface FastEthernet0/4 switchport access vlan 45 ! interface FastEthernet0/5 switchport access vlan 45 ! interface FastEthernet0/6 switchport access vlan 36 ! interface FastEthernet0/24 switchport access vlan 43 no ip address ! interface Vlan7 ip address 141.1.7.7 255.255.255.0 ! interface Vlan77 ip address 141.1.77.7 255.255.255.0



SW2: vtp domain ETHERNET vtp password CISCO vtp pruning ! interface FastEthernet0/3 switchport access vlan 36 ! interface FastEthernet0/4 switchport access vlan 43 ! interface FastEthernet0/5 switchport access vlan 258 ! interface FastEthernet0/24 switchport access vlan 12 ! interface Vlan8 ip address 141.1.8.8 255.255.255.0 ! interface Vlan88 ip address 141.1.88.8 255.255.255.0 ! interface Vlan258 ip address 141.1.0.8 255.255.255.0 Task 1.2 SW1: interface FastEthernet0/13 switchport trunk encapsulation dot1q switchport trunk native vlan 36 switchport mode trunk ! interface FastEthernet0/14 switchport trunk encapsulation dot1q switchport trunk native vlan 36 switchport mode trunk ! interface FastEthernet0/15 switchport trunk encapsulation dot1q switchport trunk native vlan 36 switchport mode trunk SW2: interface FastEthernet0/13 switchport trunk encapsulation dot1q switchport trunk native vlan 36 switchport mode trunk ! interface FastEthernet0/14 switchport trunk encapsulation dot1q switchport trunk native vlan 36 switchport mode trunk !


interface FastEthernet0/15 switchport trunk encapsulation dot1q switchport trunk native vlan 36 switchport mode trunk Task 1.3 SW1: switchport trunk pruning vlan 2-7,9-1001 Task 1.3 Breakdown As previously mentioned when a trunk is created all VLANs throughout the VTP domain may transit the trunk link. These VLANs are said to be in the allowed vlan list. In the same manner when VTP pruning is enabled all non-default VLANs can be pruned off of a trunk link (default VLANs such as 1 and 1002-1005 cannot be pruned). These VLANs are said to be prune eligible. In certain cases, such as when dealing with switches in transparent mode, it is not desirable to have a switch send pruning information out a specific trunk link. Since pruning can only be enabled or disabled globally, manually editing the prune eligible list is the only way to achieve the desired effect. To edit the prune eligible list use the interface level command switchport trunk pruning vlan [add | remove | none | except] [num]. To verify what is prune eligible on an interface, issue the show interface [int] switchport command. By default VLANs 2-1001 are prune eligible.

Verification SW1#show interface fa0/13 switchport | include Pruning Pruning VLANs Enabled: 2-1001 Prune eligible list SW1#conf t Enter configuration commands, one per line. End with CNTL/Z. SW1(config)#int fa0/13 SW1(config-if)#switchport trunk pruning vlan remove 10 Delete vlan 10 from the prune eligible list SW1(config-if)#do show interface fa0/13 switchport | include Pruning Pruning VLANs Enabled: 2-9,11-1001 VLAN 10 can no longer be pruned



Task 1.4 SW1: spanning-tree vlan 258 root primary SW2: interface FastEthernet0/14 spanning-tree vlan 258 cost 15 ! interface FastEthernet0/15 spanning-tree vlan 258 cost 10 Task 1.4 Breakdown As previously discussed the two user defined variables that can be used to affect the spanning-tree root port selection are port-cost and port-priority. The above task specifies that the “configuration should be done on SW2.” Since SW1 is the root of the spanning-tree, the appropriate value to change on SW2 is the port-cost.

Note To affect how the local switch elects its root port change the spanning-tree port-cost. Cost is cumulative throughout the STP domain. To affect how a downstream switch elects its root port change the spanning-tree port-priority. Port-priority is only locally significant between two directly connected bridges.



Verification SW2#show spanning-tree vlan 258 VLAN0258 Spanning tree enabled protocol ieee Root ID Priority 24834 Address 000a.f4f3.e780 Cost 10 Port 15 (FastEthernet0/15) Root port Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec <output deleted> Interface Role Sts Cost Prio.Nbr Type ---------------- ---- --- --------------- -------- ----------------- Fa0/13 Altn BLK 19 3rd choice 128.13 P2p Fa0/14 Altn BLK 15 2nd choice 128.14 P2p Fa0/15 Root FWD 10 1st choice 128.15 P2p

Task 1.5 SW1: interface FastEthernet0/15 udld port aggressive spanning-tree guard loop SW2: interface FastEthernet0/15 udld port aggressive Task 1.5 Breakdown Unidirectional Link Detection (UDLD) is used to detect when the send channel of a cable is down, but not the receive channel, and vice versa. This situation typically can occur in a fiber optic cable when there is a break in one side of the cable run. When UDLD detects this situation the interface is brought down and a log message is generated. This feature is useful to prevent against spanning-tree loops and traffic black holes due to unidirectional links. To enable UDLD on fiber optic interfaces issue the global configuration command udld enable or udld aggressive. To enable UDLD on a copper interface issue the interface command udld port aggressive.



In certain cases a spanning-tree loop can occur when the send channel of a designated port is damaged. This in turn will cause the bridge on the other side of the link to stop receiving STP BPDUs. When this occurs, the non-designated port assumes that it should become the designated port, and can eventually result in a loop in the topology. In order to prevent this case, spanning-tree loopguard will transition the non-designated port to loop-inconsistent state, and will not pass user traffic when this problem occurs. To enable loopguard use the interface level command spanning-tree guard loop.

Pitfall The global command udld enable only applies to fiber interfaces. Ensure to use the interface command udld port aggressive for copper interfaces.

Further Reading Spanning-Tree Protocol Enhancements using Loop Guard Configuring Optional Spanning-Tree Features Understanding and Configuring the Unidirectional Link Detection Protocol Feature Configuring UDLD



http://www.cisco.com/en/US/products/hw/switches/ps646/products_configuration_guide_chapter09186a00801cdf30.html






2. Frame-Relay Task 2.1 R1: interface Serial0/0 encapsulation frame-relay no frame-relay inverse-arp ! interface Serial0/0.1 point-to-point ip address 141.1.123.1 255.255.255.0 frame-relay interface-dlci 102 R2: interface Serial0/0 ip address 141.1.123.2 255.255.255.0 encapsulation frame-relay frame-relay map ip 141.1.123.1 201 broadcast frame-relay map ip 141.1.123.3 203 broadcast no frame-relay inverse-arp R3: interface Serial1/0 encapsulation frame-relay no frame-relay inverse-arp ! interface Serial1/0.1 point-to-point ip address 141.1.123.3 255.255.255.0 frame-relay interface-dlci 302 Task 2.2 R4: interface Serial0/0 ip address 141.1.54.4 255.255.255.0 encapsulation frame-relay frame-relay map ip 141.1.54.5 405 broadcast no frame-relay inverse-arp R5: interface Serial0/0 ip address 141.1.54.5 255.255.255.0 encapsulation frame-relay frame-relay map ip 141.1.54.4 504 broadcast no frame-relay inverse-arp



Task 2.3 R6: interface Serial0/0/0 ip address 54.1.1.6 255.255.255.0 encapsulation frame-relay frame-relay map ip 54.1.1.254 101 broadcast no frame-relay inverse-arp

3. HDLC/PPP Task 3.1 R4: username Rack1R5 password 0 CISCO ! interface Serial0/1 encapsulation ppp ppp authentication pap R5: username Rack1R4 password 0 CISCO ! interface Serial0/1 encapsulation ppp clockrate 64000 ppp authentication chap ppp pap sent-username Rack1R5 password 0 CISCO Task 3.2 R4 and R5: interface Serial0/1 compress predictor Task 3.2 Breakdown There are two common types of compression used with PPP, stacker and predictor. Stacker is more CPU intensive but more forgiving on memory utilization. Predictor is less CPU intensive but utilizes more memory. The key to determining which to use here is based on the word “guessing” that is used in the task. Predictor will try to predict the next sequence of characters in the data stream. Although “predicting” is not the same as “guessing” the use of the word leads us to interrupt the task to want predictor to be used over stac.



Verification

Rack1R4#show compress Serial0/1 Software compression enabled uncompressed bytes xmt/rcv 1560/1530 compressed bytes xmt/rcv 642/646 Compressed bytes sent: 642 bytes 0 Kbits/sec ratio: 2.429 Compressed bytes recv: 646 bytes 0 Kbits/sec ratio: 2.368 1 min avg ratio xmt/rcv 0.634/0.668 5 min avg ratio xmt/rcv 0.362/0.471 10 min avg ratio xmt/rcv 0.362/0.471 no bufs xmt 0 no bufs rcv 0 resyncs 0 Rack1R4#

4. Interior Gateway Routing Task 4.1 R1: interface Serial0/0.1 point-to-point ip ospf network non-broadcast ip ospf priority 0 ! router ospf 1 router-id 150.1.1.1 network 141.1.123.1 0.0.0.0 area 0 R2: router ospf 1 router-id 150.1.2.2 network 141.1.123.2 0.0.0.0 area 0 neighbor 141.1.123.1 neighbor 141.1.123.3 R3: interface Serial1/0.1 point-to-point ip ospf network non-broadcast ip ospf priority 0 ! router ospf 1 router-id 150.1.3.3 network 141.1.123.3 0.0.0.0 area 0



Task 4.1 Breakdown The OSPF network type and the underlying layer 2 interface type are mutually exclusive, however there are certain default OSPF network type values that should be kept in mind. Frame Relay physical and multipoint subinterfaces default to OSPF network type non-broadcast, while Frame Relay point-to-point subinterfaces default to OSPF network type point-to-point. Due to the restrictions previously placed on the Frame Relay network configuration between R1, R2, and R3, R1 and R3 must be configured with point-to-point interfaces while R2 is configured with a physical interface. This setup implies that there will be an OSPF network type mismatch. R1 and R3 will be using the OSPF network type point-to-point while R2 is using OSPF network type non-broadcast. For this reason these neighbors cannot be adjacent without extra manual configuration. Additionally the above task states that the ip ospf network command should not be used on R2. This implies that the OSPF network type that must be used on this segment is non-broadcast. R1 and R3 must therefore be configured with the interface level command ip ospf network non-broadcast while R2 is configured with two neighbor statements under the OSPF process pointing to R1 and R3 respectively. Since R2 is the only device on the segment that has direct layer 2 reachability to R1 and R3 it is also required that R2 be elected the DR for the segment. As the ip ospf priority of R1 and R3 has been set to zero in the above code sample it is implied that R2 is automatically elected the designated router. Task 4.2 R1: interface Ethernet0/0 ip ospf network non-broadcast ip ospf hello-interval 10 ! router ospf 1 network 192.10.1.1 0.0.0.0 area 51 neighbor 192.10.1.254



Task 4.2 Breakdown By default OSPF transmits hello packets as IP multicasts. This implies that any device on a broadcast segment can listen for these OSPF hello packets by joining the appropriate multicast groups. A simple way to prevent this case from happening is to unicast hello packets between neighbors. Assuming that devices on the broadcast segment are in separate collision domains hello packets would only be received by devices with the appropriate layer 3 address. To accomplish this the neighbor statement should be configured under the OSPF process. The neighbor statement in IGP causes the protocol in question send hellos or routing updates as an IP unicast as opposed to the default broadcast or multicast for said protocol. In the case of OSPF this stops hello packets from being transmitted as multicast and only sends unicast hello packets to configured neighbors.

Pitfall

Configuring the neighbor statement in RIPv1 or RIPv2 does not stop the transmission of the respective broadcast or multicast update packets, but instead sends an additional unicast update for any statically configured neighbors. To stop the transmission of broadcast or multicast updates and send only unicast updates include the passive-interface command along with the neighbor command under the RIP process.

As the underlying layer 2 protocol between R1 and BB2 is Ethernet, the OSPF network type will default to broadcast. The neighbor statement under the OSPF process is only supported on interfaces configured with the OSPF network type non-broadcast and point-to-multipoint, as well as the combination of these two, point-to-multipoint non-broadcast. Therefore the above task also requires that one of these network types must be configured on the Ethernet interface of R1, and implies that this choice be network type non-broadcast. The reasoning of this choice is as follows.

In order for adjacency to be established in OSPF there must be a match in compatible network type between neighbors. Additionally there must be a match in various other variables as such as area, hello timer, dead timer, and authentication. The term “compatible” network type is used here because there may be a mismatch in OSPF network type as long as the DR/BDR election is consistent and there is a match amongst all other variables. The following combinations of OSPF network types can result in successful adjacency:


Network Type 1 Network Type 2 DR/BDR Election

broadcast broadcast YES non-broadcast non-broadcast YES broadcast non-broadcast YES point-to-multipoint point-to-multipoint NO point-to-point point-to-point NO point-to-multipoint non-broadcast point-to-multipoint non-broadcast NO point-to-multipoint point-to-point NO point-to-multipoint point-to-multipoint non-broadcast NO point-to-point point-to-multipoint non-broadcast NO Therefore assuming that BB2 is using the default OSPF network type of broadcast for Ethernet (which can be seen because adjacency would have been established by default without modifying network type or timers) it is evident that the only two compatible network types for the segment are broadcast or non-broadcast. Furthermore, since the only network type of these two that supports the neighbor statement is non-broadcast, it is implied that non-broadcast is the only choice.

Lastly since the default hello/dead timers for non-broadcast differ from that of the broadcast network type they must be adjusted to compensate. This is seen by the ip ospf hello-interval 10 command issued on R1’s Ethernet interface. Setting the hello-interval to 10 automatically adjusts the dead interval to 40 (four times the hello-interval).

Caution Changing the ip ospf hello-interval automatically adjusts the dead-interval for the interface to four times the specified hello-interval. However, adjusting ip ospf dead-interval does not automatically adjust the hello-interval.




Task 4.3 R1: router ospf 1 network 150.1.1.1 0.0.0.0 area 0 R2: router ospf 1 network 150.1.2.2 0.0.0.0 area 0 n etwork 141.1.0.2 0.0.0.0 area 1

R3: router ospf 1 network 150.1.3.3 0.0.0.0 area 0 R5: router ospf 1 router-id 150.1.5.5 network 141.1.0.5 0.0.0.0 area 1 SW2: router ospf 1 router-id 150.1.8.8 redistribute connected subnets route-map CONNECTED2OSPF network 141.1.0.8 0.0.0.0 area 1 network 141.1.8.8 0.0.0.0 area 1 network 141.1.88.8 0.0.0.0 area 1 ! route-map CONNECTED2OSPF permit 10 match interface Loopback0 Task 4.4 R2: router ospf 1 area 1 nssa no-summary R5: router ospf 1 area 1 nssa no-summary SW2: router ospf 1 area 1 nssa


Task 4.5 R2:


interface Tunnel0 ip address 141.1.25.2 255.255.255.0

Quick Note Virtual-Link cannot be created over a stub area, see task 4.5 for further information. tunnel source Ethernet0/0

tunnel destination 141.1.0.5 ! router ospf 1 network 141.1.25.2 0.0.0.0 area 0 R4: interface Serial0/0 ip ospf network point-to-point ! router ospf 1 router-id 150.1.4.4 network 141.1.45.4 0.0.0.0 area 2 network 141.1.54.4 0.0.0.0 area 2 network 141.1.145.4 0.0.0.0 area 2 network 150.1.4.4 0.0.0.0 area 2 R5: ! interface Serial0/0 ip ospf network point-to-point ! Quick Note

Virtual-Link cannot be created over a stub area, see task 4.5 for further information.

interface Tunnel0 ip address 141.1.25.5 255.255.255.0 tunnel source Ethernet0/1 tunnel destination 141.1.0.2 ! router ospf 1 router-id 150.1.5.5 network 141.1.25.5 0.0.0.0 area 0 network 141.1.45.5 0.0.0.0 area 2 network 141.1.54.5 0.0.0.0 area 2 network 141.1.145.5 0.0.0.0 area 2 network 150.1.5.5 0.0.0.0 area 2 Task 4.4 - 4.5 Breakdown In order to properly compute the shortest path first (SPF) algorithm routers within a link-state area must have a consistent view of the link state topology. For this reason link-state protocols such as OSPF and IS-IS do not support the removal of a link state advertisement (LSA) from the link-state database on a per router basis. Instead this must be done on a per link-state area basis. In OSPF this is accomplished by the various stub area definitions.



By preventing certain types of LSAs from entering an area the various stub area types can be used to reduce the amount of forwarding information required to be in both the OSPF database and the IP routing table. Such cases may be advantageous when there is only one exit point out of an area, or only one exit point out of the autonomous system. In such a design it may be feasible to replace specific forwarding information with default information, hence reducing memory utilization and speeding up the routing table lookup process. There are four OSPF stub area definitions. These are stub, totally stubby, not-so-stubby (NSSA), and not-so-totally-stubby. To understand why certain LSAs are removed from an area you must first understand what each LSA type accomplishes. LSA types are defined as follows:

LSA Name Description

1 Router LSA Generated by all routers in an area to describe their directly attached links (intra-area routes). Does not leave the area.

2 Network LSA

Generated by the DR of a broadcast or non-broadcast segment to describe the neighbors connected to that segment. Does not leave the area.

3 Summary LSA Generated by the area border router (ABR) to describe a route to neighbors outside the area (inter-area route).

4 Summary LSA Generated by the ABR to describe a route to an autonomous system border router (ASBR) to neighbors outside the area.

5 External LSA

Generated by the ASBR to describe routes redistributed into the area. These routes appear as E1 or E2 in the IP routing table. E2 (default) uses a static cost throughout the OSPF domain, as it only takes the cost into account that is reported at redistribution. E1 uses a cumulative cost of the cost reported into the OSPF domain at redistribution plus the local cost to the ASBR.

6 Multicast LSA Used in multicast OSPF. Not supported by Cisco.

7 NSSA External LSA

Generated by an ASBR inside a not-so-stubby (NSSA) area to describe routes redistributed into the NSSA area. LSA 7 is translated into LSA 5 as it leaves the NSSA area. These routes appear as N1 or N2 in the IP routing table inside the NSSA area. Much like LSA 5, N2 is a static cost while N1 is a cumulative cost that includes the cost up to the ASBR.


A stub area blocks OSPF external routes (LSA 5) from entering the area. The ABR of a stub area automatically generates a default route (LSA 3) into the stub area. A stub area is defined by issuing the area [area_id] stub routing process subcommand on all devices in the stub area.

A totally stubby area is a stub area that in addition to blocking OSPF external routes blocks OSPF inter-area routes (LSAs 3 & 4). The ABR of a totally stubby area automatically generates a default route (LSA 3) into the stub area. Redistribution into stub and totally stubby areas is not permitted. A totally stubby area is defined by issuing the area [area_id] stub no-summary routing process subcommand on all ABRs of the stub area.

The not-so-stubby area (NSSA) overcomes the problem of not being able to redistribute into a stub area. Like a stub area a not-so-stubby area blocks OSPF external routes (LSA 5) from entering the area. However, redistribution is allowed into the NSSA area. These routes are redistributed as NSSA external (LSA 7) and are different than normal LSA 5 external routes. As these LSA 7 prefixes leave the NSSA area the ABR translates them into LSA 5. In other words, routers outside the NSSA area do not know that these routes were redistributed into an NSSA area, but instead simply see them as LSA 5 external routes. A not-so-stubby area is defined by issuing the area [area_id] nssa routing process subcommand on all routers in the stub area.

Another difference between the stub area and the not-so-stubby area is that the ABR of the NSSA does not automatically originate a default route into the area. A default route may be originated into an NSSA by adding the default-originate keyword onto the area [area_id] nssa statement. This default is type 7 LSA.

The not-so-totally-stubby area combines the concept of the totally stubby area and the not-so-stubby area. The not-so-totally-stubby area blocks both OSPF external (LSA 5) and inter-area (LSA 3 & 4) routes from entering the area. The ABR of the not-so-totally-stubby area automatically generates a default route (LSA 3) into the not-so-totally-stubby area. Redistribution into the not-so-totally-stubby area is permitted. A not-so-totally-stubby area is defined by issuing the area [area_id] nssa no-summary routing process subcommand on all ABRs in the stub area.

Note All routers in a stub or not-so-stub are must agree on the stub or NSSA flag. It is the ABR(s) of the stub area or NSSA area that determine if it is totally stubby or not-so-totally stubby by adding the no-summary keyword on to the appropriate stub command.



The stub area types can be summarized as follows:

Stub Type Keyword LSAs Default Injected

Stub area x stub 1,2,3,4 YES Totally Stubby area x stub no-summary 1,2, default of 3 YES Not-So-Stub area x nssa 1,2,3,4,7 NO Not-So-Totally-Stubby area x nssa no-summary 1,2, default of 3, 7 YES

Pitfall A stub area cannot be used a transit for a virtual-link. In the previous task it is seen that a GRE tunnel configured with OSPF area 0 was created between R2 and R5. This is due to the fact that OSPF area 2 is discontiguous from OSPF area 0. Typically this problem is fixed by creating a virtual-link back to connect area 0 with the discontiguous area. However, since in this case area 1 (the transit area) is stub, this method will not work. Therefore a virtual connection (GRE tunnel) is created between R2 and R5 to run OSPF area 0.

Task 4.6 R4 and R5: interface Serial0/0 bandwidth 10000 Task 4.6 Breakdown OSPF does support load balancing between multiple paths throughout the network. However this load balancing can only occur when these paths are of equal cost. As the OSPF cost value is dependent on the configured bandwidth value of an interface, changing the bandwidth value on the interface will in turn change the OSPF cost. In the above example the bandwidth of the Serial interfaces of R4 and R5 that connect to the Frame Relay cloud are adjusted to match that of the Ethernet interfaces between them. Therefore as long as the maximum-paths option (automatically defaults to 4 paths) is configured under the routing process multiple paths may be installed in the routing table.




Note

A router’s load balancing method is not directly related to the routing process. The routing process involves the act of installing one or more routes in the routing table and resolving the outgoing interface for this route(s). The actual moving of traffic from the incoming interface to the outgoing interface(s) is handled by the switching process. Switching processes include, but are not limited to, process switching, fast switching, and Cisco Express Forwarding (CEF) switching. Since the switching process handles moving traffic from one interface to another it also handles load balancing. For more information on switching paths and load balancing see for following links. How Does Load Balancing Work? Troubleshooting Load Balancing Over Parallel Links Using CEF

Task 4.7 R4: interface Ethernet0/0 ip ospf hello-interval 2 ! interface Serial0/0 ip ospf hello-interval 2 R5: interface Ethernet0/0 ip ospf hello-interval 2 ! interface Serial0/0 ip ospf hello-interval 2 Task 4.7 Breakdown In order to speed up the convergence process in the case that both of these circuits are inactive, the OSPF hello interval has been reduced to 2 seconds. As mentioned in the previous task, the OSPF dead interval is automatically adjusted to four times the hello interval when the ip ospf hello-interval interface level command is issued. This implies that the maximum time it will take to notice an indirect failure of either of these circuits is 8 seconds, and is therefore within the 10 second threshold as required by this task.


http://www.cisco.com/warp/public/105/loadbal_cef.html



Task 4.8 R3: router rip version 2 passive-interface default no passive-interface Ethernet0/0 no passive-interface Ethernet0/1 network 141.1.0.0 no auto-summary R4: router rip version 2 network 204.12.1.0 no auto-summary R6: router rip version 2 passive-interface default no passive-interface GigabitEthernet0/0 network 141.1.0.0 no auto-summary SW1: router rip version 2 network 141.1.0.0 network 150.1.0.0 no auto-summary Task 4.8 Breakdown The passive-interface command tells the routing process not to send update or hello packets out the specified interface (with the exception of IS-IS, in which case it dictates that the interface should be advertised into the process). If the amount of interfaces that are passive outnumber the amount of interfaces that are not passive, the passive-interface default command is available. This command dictates that all interfaces are passive. Interfaces that should not be passive are then selectively taken out of passive mode by issuing the no passive-interface [interface] routing process subcommand.


Task 4.9 R6: router rip network 150.1.0.0 no passive-interface Serial0/0/0 offset-list 1 in 9 Serial0/0/0 network 54.0.0.0 ! access-list 1 permit 0.0.0.0 255.255.254.255 Task 4.9 Breakdown The important point to not about this section is that the requirement states that certain routes learned from BB1 “should be seen with a metric of 10 on R6.” This question is a perfect example of very plain wording that is easily misinterpreted. Note that the above code sample specifies an offset value of 9 instead of 10. This is due to the fact that the routes received from BB1 already have a hop count of 1. In order for them to be locally seen as 10 they must be offset 9.

Note For questions such as this where interpretation is an issue, do not hesitate to as the CCIE proctor. When presented with an intelligently formed question the proctor of the exam is typically helpful in pointing you in the right direction.




Task 4.10 R3: router ospf 1 redistribute rip subnets ! router rip redistribute ospf 1 metric 1 R4: router ospf 1 summary-address 30.0.0.0 255.252.0.0 summary-address 31.0.0.0 255.252.0.0 redistribute rip subnets route-map RIP2OSPF ! router rip version 2 redistribute ospf 1 metric 1 ! ip prefix-list VLAN43 seq 5 permit 204.12.1.0/24 ! route-map RIP2OSPF permit 10 match ip address prefix-list VLAN43 set metric 100 ! route-map RIP2OSPF permit 20 set metric-type type-1 Task 4.10 Breakdown The following networks are learned from BB3 via RIP:

30.0.0.0/16 30.1.0.0/16 30.2.0.0/16 30.3.0.0/16 31.0.0.0/16 31.1.0.0/16 31.2.0.0/16 31.3.0.0/16

The requirement for this section states that the above networks should be summarized into two routes without overlapping any address space. It should be evident that these two summaries will be 30.X.X.X and 31.X.X.X. In order solve for the most specific summary of the above networks they must first be written out in binary. As we already know that the first octet will be consistent we will start with the second octet.



Binary Decimal 128 64 32 16 8 4 2 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 2 0 0 0 0 0 0 1 0 3 0 0 0 0 0 0 1 1

Now that all the numbers in the second octet are written out in binary we count from the left how many binary places are equal

Binary Decimal 128 64 32 16 8 4 2 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 2 0 0 0 0 0 0 1 0 3 0 0 0 0 0 0 1 1

1 2 3 4 5 6 It is evident that the first six bit places of the second octet are identical. Therefore these four networks can be summarized as far as /14 (/8 from the first octet plus the 6 bit positions in the second octet). Therefore the summary of the first four networks is 30.0.0.0/14. As the second set of four networks are identical except for the first octet it is evident that these networks can be summarized in the same fashion. The summary of the second set of four networks is 31.0.0.0/14. In order to summarize these networks as they enter the OSPF process on R4 the summary-address command is issued under the OSPF process.

The second portion of this requirement states that these two summaries should have a cumulative metric throughout the OSPF domain. As previously stated LSA 5 has two distinctive types, E1 (external type-1) and E2 (external type-2). External type-2 is default and only defines a static metric for redistribution into the OSPF domain. Regardless of the cost to the ASBR all routers throughout the OSPF domain see the exact same cost for the E2 route. An E1 route takes the cost as reported into the OSPF domain plus the cost to get to the ASBR.

The above task states that the two summary routes should have a cumulative cost while the route to VLAN 43 has a static metric of 100. This is accomplished by passing these routes through a route-map at redistribution. A prefix-list is created to match VLAN 43. Next the prefix-list is matched inside the route-map and the metric is set to 100. As metric-type 2 is default it need not be set. Lastly there is another route-map statement that simply says set metric-type type-1. As there is no match statement all other routes (the summaries) are set to E1 routes.



5. Exterior Gateway Routing Task 5.1 R1: router bgp 200 no synchronization neighbor 141.1.123.2 remote-as 200 neighbor 192.10.1.254 remote-as 254 neighbor 192.10.1.254 password CISCO R2: router bgp 200 no synchronization neighbor 141.1.0.5 remote-as 300 neighbor 141.1.36.6 remote-as 100 neighbor 141.1.36.6 ebgp-multihop neighbor 141.1.123.1 remote-as 200 R4: router bgp 400 neighbor 150.1.5.5 remote-as 300 neighbor 150.1.5.5 ebgp-multihop neighbor 150.1.5.5 update-source Loopback0 R5: router bgp 300 no synchronization neighbor 141.1.0.2 remote-as 200 neighbor 141.1.0.8 remote-as 300 neighbor 150.1.4.4 remote-as 400 neighbor 150.1.4.4 ebgp-multihop neighbor 150.1.4.4 update-source Loopback0 R6: router bgp 100 neighbor 54.1.4.254 remote-as 54 neighbor 141.1.123.2 remote-as 200 neighbor 141.1.123.2 ebgp-multihop 255 SW2: router bgp 300 no synchronization neighbor 141.1.0.5 remote-as 300



Task 5.2 R6: router bgp 100 neighbor 141.1.123.2 filter-list 1 out ! ip as-path access-list 1 permit _54$ Task 5.2 Breakdown The above task states that AS 100 does not want to provide transit services to get to the customers of AS 54. However, AS 100 still wants to provide transit to get to AS 54 itself, and AS 100 still wants to be able to send traffic to the customers of AS 54. This is accomplished by only advertising prefixes originated in AS 54 to AS 200. Therefore since AS 200 has no reachability information through AS 100 except for prefixes originated in AS 54, it cannot transit past AS 54. The above solution shows an as-path access-list which matches all prefixes originated in AS 54. This as-path access-list is then applied directly to R2 as a filter-list.



Task 5.3 R1: router ospf 1 redistribute bgp 200 subnets route-map BGP2OSPF ! ip prefix-list BGP2OSPF seq 5 permit 205.90.31.0/24 ip prefix-list BGP2OSPF seq 10 permit 220.20.3.0/24 ip prefix-list BGP2OSPF seq 15 permit 222.22.2.0/24 ! route-map BGP2OSPF permit 10 match ip address prefix-list BGP2OSPF R6: router rip redistribute bgp 100 metric 1 route-map BGP2RIP ! ip prefix-list BGP2RIP seq 5 permit 28.119.16.0/24 ip prefix-list BGP2RIP seq 10 permit 28.119.17.0/24 ip prefix-list BGP2RIP seq 15 permit 114.0.0.0/8 ip prefix-list BGP2RIP seq 20 permit 115.0.0.0/8 ip prefix-list BGP2RIP seq 25 permit 116.0.0.0/8 ip prefix-list BGP2RIP seq 30 permit 117.0.0.0/8 ip prefix-list BGP2RIP seq 35 permit 118.0.0.0/8 ip prefix-list BGP2RIP seq 40 permit 119.0.0.0/8 ! route-map BGP2RIP permit 10 match ip address prefix-list BGP2RIP



Task 5.3 Breakdown In order to provide transit services it is necessary that all devices in the transit path have specific (or at least default) reachability information about the prefix in question. In the above case R3 is used as transit between AS 100 and AS 200. However, R3 is not running BGP. Therefore from the perspective of AS 100 and AS 200, full reachability is possible. However, when packets are sent across the network and reach R3 they are black holed (dropped). The BGP synchronization rule was designed to prevent this case scenario. BGP synchronization states that in order to consider an iBGP learned route for BGP best path selection, there must be a matching IGP route in the IP routing table. While the principle logic behind this rule is sound, it is generally accepted that the BGP synchronization rule is obsolete and not required. However, the fundamental problem that synchronization tries to prevent is still an issue that must be resolved. There are three generally accepted workarounds for the above issue. The first, and most obvious, is to ensure that all devices in the BGP transit path are in fact running BGP. By running BGP it is assumed that a device in the transit path will have the same view of the BGP network as the rest of the autonomous system, and therefore have reachability everywhere. Of course this is not a valid solution for the above task, as arbitrarily enabling extra routing protocols than specified is not allowed. The second solution involves hiding the final destination of the packet from the transit device in question. This can be accomplished by creating a GRE tunnel between two BGP speaking devices, such as R2 and R6, or in more advanced designs, running Multiprotocol Label Switching (MPLS) in the network core. The latter solution is typically seen in provider networks (those of which by nature are transit networks), and can significantly reduce the amount of reachability information required on transit devices. MPLS however is outside of the scope of the CCIE Routing & Switching Lab Exam. GRE tunneling is not a valid solutions for the presented task, as the general requirements state that additional addressing cannot be added. The last solution, and that which has been chosen in this case, is to redistribute BGP into IGP. Redistribution of BGP into IGP has been generally held as bad practice in a network, simply due to the volume of prefixes in the global BGP table (currently about 170,000). However, in certain circumstances it may be permissible (with great care) to redistribute a limited view of the BGP table into IGP.


From the proposed solution it can be seen that the routes learned from AS 54 are redistributed from BGP into IGP on R6, while the routes learned from AS 254 are redistributed from BGP into IGP on R1. Careful placement of these redistribution points is necessary in order to avoid another traffic black hole. The filtering applied to the redistribution on both R1 and R6 is implemented in order to prevent problems with administrative distance on R3 which would lead to this black hole. If these filters were not implemented R3 would prefer to route to R1 for all BGP prefixes. This is due to the fact that OSPF has a lower administrative distance (110) than RIP (120).

Pitfall Although only EBGP learned routes are redistributed into IGP in the above task, it is important to note the following limitation. By default, iBGP learned prefixes are not candidate to be redistributed into IGP. This safeguard has been put into place to avoid a traffic black hole, or at a minimum sub-optimum routing, due to the higher administrative distance of iBGP as opposed to IGP. In order to enable the redistribution of iBGP learned prefixes into IGP issue the BGP routing process subcommand bgp redisitrubte-internal.




6. IP Multicast Task 6.1 R1: ip multicast-routing ! interface Ethernet0/0 ip pim sparse-mode ! interface Serial0/0.1 point-to-point ip pim sparse-mode R2: ip multicast-routing ! interface Ethernet0/0 ip pim sparse-mode ! interface Serial0/0 ip pim sparse-mode R3: ip multicast-routing ! interface Ethernet0/0 ip pim sparse-mode ! interface Ethernet0/1 ip pim sparse-mode ! interface Serial1/0.1 point-to-point ip pim sparse-mode R4: ip multicast-routing ! interface Ethernet0/0 ip pim sparse-mode ! interface Serial0/0 ip pim sparse-mode R5: ip multicast-routing ! interface Ethernet0/0 ip pim sparse-mode ! interface Ethernet0/1 ip pim sparse-mode ! interface Serial0/0 ip pim sparse-mode



SW1: ip multicast-routing ! interface FastEthernet0/3 ip pim sparse-mode ! interface Vlan7 ip pim sparse-mode SW2: ip multicast-routing ! interface Vlan258 ip pim sparse-mode Task 6.2 R1, R2, R3, R4, R5, SW1, and SW2: ip pim autorp listener R2, R5, and SW2: interface Loopback0 ip pim sparse-mode R2: ip pim send-rp-announce Loopback0 scope 16 group-list 50 ! access-list 50 permit 225.0.0.0 0.255.255.255 R5: ip pim send-rp-announce Loopback0 scope 16 group-list 50 ! access-list 50 permit 239.0.0.0 0.255.255.255 SW2: ip pim send-rp-discovery Loopback0 scope 16 Task 6.2 Breakdown Since PIM sparse mode was required in task 6.1 and this section asks for Auto-RP, the ip pim autorp listener command will need to be used on all multicast devices to enable the 224.0.1.39 and 224.0.1.40 groups to be distributed in dense mode. For more information concerning the ip pim autorp listener command, refer to lab 3, section 6.1 breakdown.


Verification Rack1SW2#show ip pim rp mapping PIM Group-to-RP Mappings This system is an RP-mapping agent (Loopback0) Group(s) 225.0.0.0/8 RP 150.1.2.2 (?), v2v1 Info source: 150.1.2.2 (?), via Auto-RP Uptime: 00:16:32, expires: 00:02:26 Group(s) 239.0.0.0/8 RP 150.1.5.5 (?), v2v1 Info source: 150.1.5.5 (?), via Auto-RP Uptime: 00:09:15, expires: 00:02:45 Rack1SW2#

Task 6.3 R2: interface Serial0/0 ip pim nbma-mode ! interface Tunnel0 ip pim sparse-mode R3: interface Ethernet0/0 ip igmp join-group 225.25.25.25 ! interface Ethernet0/1 ip igmp join-group 239.39.39.39 R5: interface Tunnel0 ip pim sparse-mode Task 6.3 Breakdown The problem encountered with this task is R2 will not forward multicast packets received on an interface S0/0 back out interface S0/0. This will cause the multicast pings from R1 to not reach R3. To overcome this issue PIM NBMA mode can be configured.



Verification Before the NBMA mode is configured: Rack1R1#ping 225.25.25.25 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 225.25.25.25, timeout is 2 seconds: . Rack1R1#ping 239.39.39.39 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 239.39.39.39, timeout is 2 seconds: . Rack1R1# After the NBMA mode is configured: Rack1R1#ping 225.25.25.25 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 225.25.25.25, timeout is 2 seconds: Reply to request 0 from 141.1.13.3, 36 ms Rack1R1#ping 239.39.39.39 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 239.39.39.39, timeout is 2 seconds: Reply to request 0 from 141.1.13.3, 36 ms Rack1R1#




Task 6.4 SW1: interface FastEthernet0/3 ip multicast rate-limit out 1000 Task 6.4 Breakdown Although standard QoS methods could be used to meet the requirements for this section, the ip multicast rate-limit command is the simplest solution. Other options for this command can be configured to limit the amount of multicast traffic inbound, from a specific source address, and/or multicast traffic sent to a specific multicast group. If a value of 0 is used, all multicast traffic will be dropped.



7. IPv6 Task 7.1 R1: ipv6 unicast-routing ! interface FastEthernet0/0 ipv6 address 2001:192:10:1::/64 eui-64 ipv6 ospf 1 area 0 Task 7.1 Breakdown The first step in enabling OSPF for IPv6 (OSPFv3) is to enable IPv6 routing globally with the ipv6 unicast-routing command, followed by the ipv6 router ospf 1 [process-id] command, where process-id is a locally significant number similar to OSPFv2 for IPv4. Unlike OSPFv2, OSPFv3 does not use the network statement to enable the process on an interface. Instead the interface level command ipv6 ospf [process-id] area [area-id] command is used. Once OSPFv3 has been configured issue the show ipv6 ospf neighbor command to verify adjacency status. Rack1R1#show ipv6 ospf neighbor Neighbor ID Pri State Dead Time Interface ID Interface 222.22.2.1 1 FULL/DR 00:00:30 12 Ethernet0/0

In the above output we can see that R1 has formed an adjacency with an OSPFv3 router with the router-id 222.22.2.1. This router has a priority of 1 and has been elected the designated router. Although the above output relates specifically to IPv6 routing, the OSPFv3 router-id still uses the 32-bit dotted decimal format as used in OSPFv2. To get more detailed information about interfaces running OSPFv3 issue the show ipv6 ospf interface command.



Rack1R1#show ipv6 ospf interface Ethernet0/0 is up, line protocol is up Link Local Address FE80::2D0:58FF:FE6E:B720, Interface ID 3 Area 0, Process ID 1, Instance ID 0, Router ID 150.1.1.1 Network Type BROADCAST, Cost: 10 Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) 222.22.2.1, local address FE80::205:5EFF:FE0F:B8E0 Backup Designated router (ID) 150.1.1.1, local address FE80::2D0:58FF:FE6E:B720 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:01 Index 1/1/2, flood queue length 0 Next 0x0(0)/0x0(0)/0x0(0) Last flood scan length is 2, maximum is 2 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 222.22.2.1 (Designated Router) Suppress hello for 0 neighbor(s) Loopback0 is up, line protocol is up Link Local Address FE80::2D0:58FF:FE6E:B720, Interface ID 7 Area 1, Process ID 1, Instance ID 0, Router ID 150.1.1.1 Network Type LOOPBACK, Cost: 1 Loopback interface is treated as a stub Host

From the above output we can see more detailed information about the OSPF adjacency that has formed on interface Ethernet0/0, such as the area, process-id, local router-id, network type, interface cost, local state (DR, BDR, or DROTHER), local priority, router-id of the DR and BDR, link-local address of the DR and BDR, and interface timers.

Rack1R1#show ipv6 route ospf IPv6 Routing Table - 7 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 OE2 2001:51:51:51::/64 [110/20] via FE80::205:5EFF:FE0F:B8E0, Ethernet0/0

Note that when the routing table is examined the next-hop address for OSPFv3 learned routes is the remote link-local address of the advertising router. Since the Ethernet interface used for this adjacency is a broadcast media, ICMPv6 neighbor discovery will automatically resolve the remote link-local IPv6 address to the remote layer 2 (MAC) address. This can be verified by issuing the show ipv6 neighbors command in global configuration mode.



Rack1R1#show ipv6 neighbors IPv6 Address Age Link-layer Addr State Interface FE80::205:5EFF:FE0F:B8E0 17 0005.5e0f.b8e0 STALE Et0/0 2001:192:10:1::254 17 0005.5e0f.b8e0 STALE Et0/0

Had the interface used for adjacency been a multipoint non-broadcast interface, such as the main interface in Frame Relay or ATM, an explicit layer 3 to layer 2 resolution statement would have been required for the remote link-local IPv6 address. Task 7.2 R1: interface Serial0/0.1 point-to-point ipv6 address 2001:141:1:12::1/64 ipv6 ospf 1 area 1 R2: ipv6 unicast-routing ! interface FastEthernet0/0 ipv6 address 2001:141:1:25::2/64 ipv6 ospf 1 area 1 ! interface Serial0/0 ipv6 address 2001:141:1:12::2/64 ipv6 ospf network point-to-point ipv6 ospf 1 area 1 frame-relay map ipv6 FE80::204:27FF:FEB5:2F60 201 frame-relay map ipv6 2001:141:1:12::1 201 broadcast R5: ipv6 unicast-routing ! interface Ethernet0/1 ipv6 address 2001:141:1:25::5/64 ipv6 ospf 1 area 1


Task 7.3 R1: ipv6 router ospf 1 area 1 range 2001:141:1::/58 Task 7.3 Breakdown Similar to OSPFv2, OSPFv3 supports both internal and external summarization. Internal summarization occurs as LSAs are moving between areas, and is configured with the interface level command area [area-id] range [summary], where area-id is the area you are summarizing from and summary is the summary prefix. For external summaries the process level command summary-prefix is used. 8. QoS Task 8.1 R1: interface FastEthernet0/0 random-detect random-detect precedence 0 15 40 10 Task 8.1 Breakdown The section will require Weighted Random Early Detection (WRED) to be configured. Random early detection is designed to avoid tail drop by randomly dropping packets prior to the output queue of an interface actually becoming full. When the output queue becomes full, all packets that attempt to enter the tail (end) of the queue will have to be dropped, hence the term tail drop. If these dropped packets were all TCP packets, then theoretically all TCP sessions that had dropped packets will back off and perform TCP slow start. With TCP slow start, a TCP session will start with a small TCP window size and gradually increase the window size until congestion or delay is experienced. If all TCP sessions back off and then start up again in synchronization with each other, the same situation will occur once the interface’s queue to become full again. This results in periods of high congestion followed by periods of low utilization. This type of behavior is called global synchronization, and is what random early detection is designed to prevent.

Note Weighted RED is the process of using different queues and thresholds for packets with different IP precedence values.



Random detection is enabled by issuing the interface level command random detect. Once enabled random detect applies various low and high threshold values based on the IP precedence value of the packet trying to exit the interface. To change these threshold values use the interface level command random-detect precedence [precedence] [minimum threshold] [maximum threshold] [mark probability demonitator]. The precedence option references the IP precedence value for which the thresholds will be modified. The minimum threshold is the threshold value at which RED will become active. The maximum threshold is the threshold value at which all packets above this threshold will be dropped. The mark probability denominator is used to determine how aggressively packets will be dropped. The lower the number, the more aggressively packets will be dropped. When the number of packets in the queue matches the maximum threshold, 1/(mark probability denominator) will be dropped. If the mark probability denominator is 10 as in this section, when the average queue size equals 40 IP precedence 0 packets, 1 of every 10 packets will be dropped. With an average queue size between 15 and 39 packets, less than 1 of every 10 packets will be dropped. The closer the average queue size gets to 40, the closer the number of dropped packets will equal 1 of every 10. Once the average queue exceeds 40, all packets above 40 will be dropped.

Verification Rack1R1#show queueing interface FastEthernet0/0 Interface FastEthernet0/0 queueing strategy: random early detection (WRED) Exp-weight-constant: 9 (1/512) Mean queue depth: 0 class Random drop Tail drop Minimum Maximum Mark pkts/bytes pkts/bytes thresh thresh prob 0 0/0 0/0 15 40 1/10 1 0/0 0/0 22 40 1/10 2 0/0 0/0 24 40 1/10 3 0/0 0/0 26 40 1/10 4 0/0 0/0 28 40 1/10 5 0/0 0/0 31 40 1/10 6 0/0 0/0 33 40 1/10 7 0/0 0/0 35 40 1/10 rsvp 0/0 0/0 37 40 1/10 Rack1R4#



As seen from the above output the default values of WRED dictate that the higher the IP Precedence value the higher the minimum threshold. This means that a larger volume of packets with a high precedence value must be stuck in the output queue before they start to get dropped. Assuming a relatively equal distribution of packet precedence these values imply that packets with a higher precedence value are less likely to get dropped than packets with a lower precedence value. Task 8.2 R5: ip cef ! class-map match-all SMTP match protocol smtp ! policy-map QoS class SMTP bandwidth 1500 ! interface Ethernet0/1 service-policy output QoS Task 8.2 Breakdown This is a standard MQC configuration, and dictates that SMTP traffic will be guaranteed 1500Kbps of the output queue of the Ethernet0/1 interface in the case of congestion. SMTP may use more than 1500Kbps, however only 1500Kbps is guaranteed in the case of congestion.

Note When matching a protocol in a class-map, CEF should be enabled globally.

Previous Reference Modular Quality of Service Command Line (MQC): Lab 1 Task 8



Task 8.3 R5: class-map match-all ABOVE_1250_BYTES match packet length min 1250 ! policy-map QoS class ABOVE_1250_BYTES police cir 2500000 Task 8.3 Breakdown Policing packets based on the packet’s size can be useful in situations where framentation is not possible (i.e. an HDLC link). Large packets can cause excessive delay on slow speed links due to serization delay. In this section, packets larger than 1250 bytes will be limited to 2.5 Mbps.

Pitfall The IOS is not consistent in how QoS parameters are entered. Some commands take values in as bits, some in as bytes, and some in as kilobytes. When in the real lab, use the ‘?’ with the command to view how the parameter is accepted. Entering a value in as bytes when the command takes bits will cause you to lose points for that section.




9. Security Task 9.1 R6: interface Serial0/0/0 ip access-group TRAFFIC_FILTER in ip access-group ORIGINATED_INSIDE out ! ip access-list extended ORIGINATED_INSIDE permit tcp any any reflect REFLEXIVE permit udp any any reflect REFLEXIVE permit icmp any any echo-reply ! ip access-list extended TRAFFIC_FILTER permit icmp any any echo permit tcp any 141.1.7.0 0.0.0.255 eq telnet permit tcp any 141.1.77.0 0.0.0.255 eq telnet permit tcp any host 141.1.88.100 eq www permit tcp any host 141.1.88.100 eq 443 permit tcp any any eq domain permit udp any any eq domain permit tcp any any eq bgp permit tcp any eq bgp any permit udp any any eq rip evaluate REFLEXIVE Task 9.1 Breakdown Reflexive access-lists were covered in lab 2 task 10.8 - 10.10. When creating an access-list with complicated requirements as in this section, look at each requirement individually and then create an entry for it.

• Permit ICMP echo requests ip access-list extended ORIGINATED_INSIDE permit icmp any any echo-reply ip access-list extended TRAFFIC_FILTER permit icmp any any echo

• Permit telnet to servers in VLAN 7 and VLAN 77 ip access-list extended TRAFFIC_FILTER permit tcp any 141.1.7.0 0.0.0.255 eq telnet permit tcp any 141.1.77.0 0.0.0.255 eq telnet

• Permit HTTP and SSL access to a web server at 141.X.88.100 ip access-list extended TRAFFIC_FILTER permit tcp any host 141.1.88.100 eq www permit tcp any host 141.1.88.100 eq 443


• Permit DNS lookups and zone transfers ip access-list extended TRAFFIC_FILTER permit tcp any any eq domain permit udp any any eq domain

NoteZone transfers between DNS servers use TCP port 53, whereas DNS lookups use UDP port 53. Although most protocols reserve the same TCP and UDP port numbers (telnet, http, etc), DNS is one of the few applications that actually utilize them.

• Permit any TCP and UDP sessions initiated from behind R6 to return ip access-list extended ORIGINATED_INSIDE permit tcp any any reflect REFLEXIVE permit udp any any reflect REFLEXIVE ip access-list extended TRAFFIC_FILTER evaluate REFLEXIVE

• Permit all necessary routing protocol traffic ip access-list extended TRAFFIC_FILTER permit tcp any any eq bgp permit tcp any eq bgp any permit udp any any eq rip

A common mistake with complex access-list is to omit an entry or create the entry with that permits or denies the reverse of what the requirement is asking. To avoid this problem, be sure to pay attention to the direction. This can be indicated by giving information regarding the client or server.



Task 9.2 R4: ip cef ! interface Ethernet0/1 ip verify unicast reverse-path Task 9.2 Breakdown Unicast reverse path forwarding was developed to help solve issues concerning DoS attacks. Commonly with DoS attacks, the source IP address of the packet is spoofed. Basically unicast reverse path forwarding checks the source IP address of all packets received inbound on an interface to see if that particular interface is the interface the router would use to route a packet to that source IP address. Theoretically this is a good idea and in some situations can be helpful, but in a real network this can cause problems with asymmetrical routing. Let’s look at this example:

A packet with a source IP address of 141.X.37.100 is received inbound on R4 interface E0/1. With unicast RPF enabled, R4 would assume the source IP address must be spoofed as R4 will normally route via R5 to reach that particular subnet. This will cause R4 to drop this packet. Although this might be the action we want, what if R3 is routing through BB1 & BB3 (AS 54) to reach the networks behind R4, while R4 is routing through R5 & R2 to reach R3. In this situation unicast RPF would cause packets to be incorrectly dropped. Another example would be for a remote site with one connection to the rest of the network. Normally to prevent spoofed IP addresses from being sent by the remote site, an access-list is created to only permit packets with the remote site’s network as the source IP address. This access-list is applied inbound on the main site’s router. Whenever a new network is added to the remote site, an additional route is added in the hub router and the access-list will need to be updated. For an enterprise network that does not make a lot of changes, this might not mean a lot of additional work, but for a large ISP this could possibly mean a lot of additional work. A simpler solution would be to use unicast RPF as the access-list is not needed. For reasons we can see from the examples, unicast RPF is normally implemented on the edge of the network where symmetrical routing is more likely to occur. If unicast RPF is used in the core of a network, ensure that asymmetric routing does not occur.

NoteUnicast RPF requires CEF to be enabled globally.




10. System Management Task 10.1 R3 and R6: snmp-server community CISCO_RO RO 2 snmp-server community CISCO_RW RW 2 snmp-server enable traps hsrp snmp-server host 141.1.7.100 CISCO tty snmp-server host 141.1.77.100 version 2c CISCO hsrp ! access-list 2 permit 141.1.77.100 access-list 2 permit 141.1.7.100 Task 10.1 Breakdown This configuration is similar to SNMP configurations from earlier labs with the exception of the version option. The default SNMP version is version 1. Also note that SNMP traps relating to HSRP will only be sent to host 141.1.77.100. Task 10.2 R2: username NOC password 0 CISCO username NOC autocommand menu NOC ! menu NOC title "Menu for NOC users" menu NOC prompt "Choose your selection: " menu NOC text 1. Ping R5 menu NOC command 1. ping 150.1.5.5 menu NOC options 1. pause menu NOC text 2. Ping R6 menu NOC command 2. ping 150.1.6.6 menu NOC options 2. pause menu NOC text 3. Traceroute to R5 menu NOC command 3. trace 150.1.5.5 menu NOC options 3. pause menu NOC text 4. Traceroute to R6 menu NOC command 4. trace 150.1.6.6 menu NOC options 4. pause menu NOC text 5. Exit menu NOC command 5. exit menu NOC clear-screen ! line vty 0 4 login local


Task 10.2 Breakdown This is a standard menu configuration. Ensure that login local is configured under the VTY lines to prompt for the username along with the password. Also the autocommand is needed to activate the menu once the NOC user logs in. Technically the autocommand could have been configured under the VTY line itself to meet the requirements of this section. However, binding the autocommand to the username allows more flexibility as to which users must use the menu.

Note When using menus, ensure that the user is given an option to exit the menu.

Further Reading Creating Menus





11. IP Services Task 11.1 R2: ip alias 141.1.0.22 23 Task 11.1 Breakdown The ip alias command will allow the router to answer for the aliased IP address. Although this command is not commonly used, it could be useful in a situation where users need to access a particular async line by telneting to the DNS name along with the standard TCP port of 23. Rack1AS#conf t Enter configuration commands, one per line. End with CNTL/Z. Rack1AS(config)#ip alias 172.16.2.122 2008 Rack1AS(config)#ip host AS-Line8 172.16.2.122 Rack1AS(config)#^Z Rack1AS#telnet AS-Line8 Trying AS-Line8 (172.16.2.122)... Open Rack1SW2# Rack1AS#sho sessions Conn Host Address Byte Idle Conn Name * 8 AS-Line8 172.16.2.122 0 0 AS-Line8 Rack1AS# Task 11.2 R3: interface Ethernet0/1 standby 1 ip 141.1.36.1 standby 1 priority 150 standby 1 preempt standby 2 ip 141.1.36.2 R6: interface FastEthernet1/0/0 standby 1 ip 141.1.36.1 standby 2 ip 141.1.36.2 standby 2 priority 150 standby 2 preempt


Task 11.2 Breakdown This section will require HSRP with R3 active for one IP address (141.1.36.1) and R6 active for another IP address (141.1.36.2). Therefore the appropriate DHCP server for this segment can assign one address as the default gateway to a certain pool of clients, while assigning the other address as the default gateway for another pool of clients. Note that these addresses have been arbitrarily chosen. If R3 becomes unavailable, R6 will take over for 141.1.36.1 and vice versa. The HSRP priority is set above the default of 100 along with the preempt option so that R3 and R6 can take back over for their HSRP group after becoming available again.

Note Without the HSRP preempt option a router will not take over for an HSRP group even if its own priority is higher than the current active router.

Task 11.3 R3: ip host R4 150.1.4.4 ! busy-message R4 “Connection Unsuccessful” Task 11.3 Breakdown The “host failed” message (aka busy-message) is used to display a custom message with a telnet connection fails to a particular host. The key to the busy-message is that the busy-message is configured on the host attempting to make the connection, and not the host that actually refused the connection. To have the router that refused the connection display a “line in use” message, use the refuse-message under the remote router’s VTY line.

The busy-message only takes a hostname and will not take an IP address. This means the ip host command will need to be configured in conjunction with the busy-message command assuming a DNS server has not been defined.

Further Reading Configuring a "Host Failed" Message





1. Catalyst 3550 Task 1.1 SW1: vtp domain CCIE vtp mode transparent vtp password CISCO ! vlan 4,27,38,162,2005 ! interface FastEthernet0/1 switchport access vlan 162 ! interface FastEthernet0/2 switchport access vlan 27 ! interface FastEthernet0/3 switchport access vlan 38 ! interface FastEthernet0/4 switchport access vlan 4 ! interface FastEthernet0/5 switchport access vlan 2005 ! interface FastEthernet0/6 switchport access vlan 162 ! interface FastEthernet0/15 switchport access vlan 38 ! interface FastEthernet0/24 switchport access vlan 4 SW2: vtp domain CCIE vtp password CISCO ! vlan 3,6,8,55,88,188 ! interface FastEthernet0/3 switchport access vlan 3 ! interface FastEthernet0/5 switchport access vlan 55 ! interface FastEthernet0/6 switchport access vlan 6 ! interface FastEthernet0/24 switchport access vlan 162



Task 1.2 SW1 and SW2: interface Port-channel1 switchport trunk encapsulation isl switchport mode trunk ! interface FastEthernet0/13 switchport trunk encapsulation isl switchport mode trunk channel-group 1 mode on ! interface FastEthernet0/14 switchport trunk encapsulation isl switchport mode trunk channel-group 1 mode on Task 1.2 Breakdown The first step in creating a layer 2 EtherChannel is to apply the channel-group command to the interface. As previously discussed, the on mode of the channel will disable the usage of both PAgP and LACP. Next, configuration that should apply to both the channel interface and the member interfaces should be placed on the port-channel interface. In the above example the trunking configuration is shown on both the physical and logical interfaces for clarity. Options configured on the port-channel interface will be automatically inherited by the physical member interfaces. The phase ‘Do not issue any global configuration commands’ implies that ISL trunking must be used. By default only ISL tags all VLANs sent over the trunk link with a VLAN header (remember dot1q uses the native VLAN). However, in certain circumstances such as 802.1q tunneling, the native VLAN can carry a VLAN header by issuing the global command vlan dot1q tag native. This case will be covered in later labs.


Task 1.3 SW1 and SW2: port-channel load-balance dst-mac Task 1.3 Breakdown By default all traffic sent over an EtherChannel interface is load balanced based on the source MAC address of the frame. This can sometimes be a problem when a large amount of traffic is coming from the same source, such as a file server, media server, etc. If traffic monitoring shows that one interface inside a channel group is highly utilized and the others are not, this usually indicates the above case. To change the load balancing method to be based on the destination MAC address of the frame, use the global configuration command port-channel load-balance dst-mac.

Further Reading Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches

Task 1.4 SW2: mac-address-table aging-time 10 vlan 8 mac-address-table aging-time 10 vlan 88 Task 1.4 Breakdown The Content Addressable Memory (CAM) table is where the switch stores learned MAC addresses. This table is used as a “routing” table for the switch, and is used to determine the outgoing interface for a frame. When a unicast frame comes in that does not have an entry in the CAM table, it is treated as a broadcast frame. A broadcast frame is sent out all interfaces except the one it was received on. When the CAM table is full, all excess unicast frames are treated as broadcast frames. When this occurs it is possible for traffic to leak between VLANs. The mac-address-table aging-time determines how long an idle MAC address can remain in the CAM table, and defaults to five minutes. In the above task this value is adjusted to flush inactive entries out of VLANs 8 and 88 after just 10 seconds.






2. Frame-Relay Task 2.1 R2: interface Serial0/0 encapsulation frame-relay ! interface Serial0/0.1 point-to-point ip address 162.1.0.2 255.255.255.0 frame-relay interface-dlci 203 R3: interface Serial1/0 ip address 162.1.0.3 255.255.255.0 encapsulation frame-relay frame-relay map ip 162.1.0.2 302 broadcast frame-relay map ip 162.1.0.4 304 broadcast frame-relay map ip 162.1.0.5 305 broadcast no frame-relay inverse-arp R4: interface Serial0/0 ip address 162.1.0.4 255.255.255.0 encapsulation frame-relay frame-relay map ip 162.1.0.2 403 frame-relay map ip 162.1.0.3 403 broadcast frame-relay map ip 162.1.0.5 405 broadcast no frame-relay inverse-arp R5: interface Serial0/0 ip address 162.1.0.5 255.255.255.0 encapsulation frame-relay frame-relay map ip 162.1.0.2 504 frame-relay map ip 162.1.0.3 503 broadcast frame-relay map ip 162.1.0.4 504 broadcast no frame-relay inverse-arp Task 2.1 Breakdown The first step in configuring the about Frame Relay network should be to determine what type of interface to use on R2. Note that the task states that to “not use any dynamic Frame Relay mappings on any of these circuits.”, as well as “do not use any static Frame Relay mappings on R2.” These leaves R2 with the only option of using a point-to-point subinterface. Next, how to deal with protocol resolution between the rest of the network must be determined.



Since Inverse-ARP cannot be used to resolve mappings between spokes of a partial mesh it cannot be an option in this task. The task additionally states that “traffic from R5 destined for R2 should transit R4.” Therefore R5’s layer 3 resolution statement for the 162.X.0.2 address should point to VC 504 via R4.

Since “all other traffic should take the most direct path through the Frame Relay network”, R3 should resolve directly to R2, R4, and R5 through VCs 302, 304, and 305 respectively, R4 should resolve to R2 and R3 through VC 403, and through VC 405 to get to R5, and lastly R5 should resolve to R4 via 504 and R3 via 503. Task 2.2 R1: interface Serial0/0 ip address 162.1.13.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 162.1.13.3 113 broadcast no frame-relay inverse-arp R3: interface Serial1/1 ip address 162.1.13.3 255.255.255.0 encapsulation frame-relay frame-relay map ip 162.1.13.1 311 broadcast no frame-relay inverse-arp Task 2.3 R6: interface Serial0/0/0 encapsulation frame-relay ! interface Serial0/0/0.1 multipoint ip address 54.1.1.6 255.255.255.0 frame-relay interface-dlci 101 Task 2.3 Breakdown This task will require that a multipoint subinterface be used. This is due to the fact that if inverse-ARP is used on the main physical interface there would be more dynamic mappings between R6 and BB1. This would mean that the output of the show frame-relay map command would differ. If a point-to-point interface was used the mapping would not be dynamic.


3. HDLC/PPP Task 3.1 R4: interface Serial0/1 encapsulation ppp ppp reliable-link R5: interface Serial0/1 encapsulation ppp clockrate 64000 ppp reliable-link

Standard RFC 1663: PPP Reliable Transmission

Verification Rack1R5#sho int s0/1 Serial0/1 is up, line protocol is up Hardware is QUICC Serial Internet address is 136.1.45.5/24 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, LCP Open Open: CDPCP, CCP, IPCP LAPB DCE, state CONNECT, modulo 8, k 7, N1 12048, N2 3 T1 3000, T2 0, interface outage (partial T3) 0, T4 0, PPP over LAPB VS 3, VR 6, tx NR 6, Remote VR 3, Retransmissions 0 Queues: U/S frames 0, I frames 0, unack. 0, reTx 0 IFRAMEs 19/22 RNRs 0/0 REJs 0/0 SABM/Es 1/1 FRMRs 0/0 DISCs 0/0,


http://www.internetworkexpert.com/rfc/rfc1663.txt



5. Interior Gateway Routing Task 4.1 R2: interface Serial0/0.1 point-to-point ip ospf network non-broadcast ip ospf priority 0 ! router ospf 1 router-id 150.1.2.2 network 150.1.2.2 0.0.0.0 area 0 network 162.1.0.2 0.0.0.0 area 0 R3: router ospf 1 router-id 150.1.3.3 network 150.1.3.3 0.0.0.0 area 0 network 162.1.0.3 0.0.0.0 area 0 neighbor 162.1.0.2 neighbor 162.1.0.4 neighbor 162.1.0.5 R4: interface Serial0/0 ip ospf priority 0 ! router ospf 1 router-id 150.1.4.4 network 150.1.4.4 0.0.0.0 area 0 network 162.1.0.4 0.0.0.0 area 0 R5: interface Serial0/0 ip ospf priority 0 ! router ospf 1 router-id 150.1.5.5 network 150.1.5.5 0.0.0.0 area 0 network 162.1.0.5 0.0.0.0 area 0 network 162.1.5.5 0.0.0.0 area 0 network 162.1.55.5 0.0.0.0 area 0


Task 4.1 Breakdown The above task dictates that the “ip ospf network command” should not be used on R3. Since the Frame Relay configuration of R3 uses the main interface, the OSPF network type will default to non-broadcast. This implies that R2, R4, and R5 will have to be configured with the network type non-broadcast. As R3 is the only device on the network with direct layer 2 connectivity to all endpoints of the network, R3 must be elected the DR. This is accomplished by setting the OSPF priority of the spokes to 0, as this dictates that they will not attempt to participate in the election process.

Note As seen in the previous scenario is it possible to form adjacency between different OSPF network types. Therefore it is permissible for R2, R4, and R5 to be configured with OSPF network type broadcast; however the timers would then have to be adjusted to match that of R3.




Task 4.2 R2: router ospf 1 area 27 stub no-summary network 162.1.27.2 0.0.0.0 area 27 SW1: ip routing ! router ospf 1 area 27 stub network 150.1.7.7 0.0.0.0 area 27 network 162.1.27.7 0.0.0.0 area 27 Task 4.2 Breakdown

The above task dictates that SW1 does not meet specific reachability information about the rest of the network. As previously discussed an LSA cannot be removed from the OSPF database on a per device basis. Instead this must be accomplished by defining a stub area.

Since the above task as states that SW2 should only see a default route

as generated by R2 it is evident that external or inter-area routing information should not be allowed into OSPF area 27. This requirement immediately eliminates the stub and not-so-stubby area types, as these two do allow inter-area reachability information to enter the area. Therefore the only two options remaining are a totally stubby area or a not-so-totally-stubby area. As there is no redistribution occurring into OSPF area 27, the totally-stubby area has been chosen in the above sample solution. However as there is no restriction to eliminate a not-so-totally-stubby area, this is still a valid solution.



Task 4.3 R1: router eigrp 200 eigrp router-id 150.1.1.1 network 150.1.1.1 0.0.0.0 network 162.1.13.1 0.0.0.0 no auto-summary R3: router eigrp 200 eigrp router-id 150.1.3.3 network 162.1.3.3 0.0.0.0 network 162.1.13.3 0.0.0.0 network 162.1.38.3 0.0.0.0 no auto-summary SW2: router eigrp 200 eigrp router-id 150.1.8.8 network 0.0.0.0 no auto-summary Task 4.3 Breakdown The above requirement of “do not use more than one network statement” under the EIGRP process of SW2 is used to illustrate the true nature of the IGP network statement. Contrary to popular belief, the IGP network statement does not dictate what networks will be advertised into the IGP domain. Instead, the network statement in IGP dictates which interfaces will participate in the IGP protocol in question. The distinction is a fine line; however the above exercise illustrates this. Both EIGRP and OSPF support a wildcard mask option in the IGP network statement. This wildcard mask allows complete control over which interface will or will not run the IGP protocol. The address portion of the network statement indicates the IP address of the interface or range of interfaces to run the IGP protocol on. Take the following examples: router ospf 1 network 1.2.3.4 0.0.0.0 area 0 This means that only the interface 1.2.3.4 is participating in OSPF area 0. router eigrp 1 network 1.2.3.4 0.0.0.255 area 0 This means that all interfaces within the range of 1.2.3.0 - 1.2.3.255 are participating in EIGRP AS 1.


router ospf 1 network 0.0.0.0 255.255.255.255 area 0 This means that all interfaces are participating in OSPF area 0. In the case of OSPF, the most specific network statement will dictate which area the interface in question will participate in. router ospf 1 network 0.0.0.0 255.255.255.255 area 0 network 1.2.3.0 0.0.0.0 area 1 network 1.2.3.4 0.0.0.0 area 2 The above statements dictate that interface 1.2.3.4 will participate in OSPF area 2. Any other interfaces that have 1.2.3 in the first three octets will participate in OSPF area 1, while all other interfaces will participate in OSPF area 0. The wildcard that accompanies the network statement has nothing to do with the subnet mask of the interface. It is simply an address and wildcard pair that specifies which interfaces are participating in the protocol.

Further Reading Preventing Duplicate EIGRP Router IDs


http://www.cisco.com/warp/public/103/eigrp-dup-id.html


Task 4.4 R1: router eigrp 200 metric weights 0 3 1 1 0 0 R3: router eigrp 200 metric weights 0 3 1 1 0 0 SW2: router eigrp 200 metric weights 0 3 1 1 0 0 Task 4.4 Breakdown EIGRP metric calculation uses a composite of four values, bandwidth, delay, load, and reliability. By default EIGRP only uses bandwidth and delay in its metric calculation; however this behavior can be modified by changing the metric weights under the EIGRP process.

Doc CD EIGRP Commands: metric weights


http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fiprrp_r/1rfeigrp.htm


Pitfall Metric weighting must match between devices in the EIGRP domain in order to establish adjacency. Therefore if you modify the metric weights parameter on one EIGRP device you must do so on all EIGRP devices in that autonomous system.

The EIGRP metric calculation formula is as follows:

(k1 * bandwidth + (k2 * bandwidth)/(256 - load) + k3 * delay) * (k5/(reliability + k4))

The latter half of the calculation is only performed if k5 does not equal 0. The variable definitions of the above formula are as follows:

Bandwidth: The inverse of the lowest bandwidth along the path for the prefix times 2.56 x 1012 in bits per second.

Delay: The cumulative interface delay along the entire path of the prefix in tens of microseconds.

Reliability: Reliability of local interface as a fraction of 255.

Load: Load of local interface as a fraction of 255.

The above values can be determined for a prefix as follows:

Rack1R6#sh ip route eigrp D 200.0.0.0/24 [90/146432] via 54.1.1.254, 00:00:09, Serial0/0/0 D 200.0.1.0/24 [90/146432] via 54.1.1.254, 00:00:09, Serial0/0/0 D 200.0.2.0/24 [90/146432] via 54.1.1.254, 00:00:09, Serial0/0/0 D 200.0.3.0/24 [90/146432] via 54.1.1.254, 00:00:09, Serial0/0/0 Rack1R6#sh ip route 200.0.0.0 Routing entry for 200.0.0.0/24 Known via "eigrp 10", distance 90, metric 2297856, type internal Redistributing via eigrp 10 Last update from 54.1.1.254 on Serial0/0/0, 00:00:19 ago Routing Descriptor Blocks: * 54.1.1.254, from 54.1.1.254, 00:00:19 ago, via Serial0/0/0 Route metric is 2297856, traffic share count is 1 Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1




Task 4.5 R3: router ospf 1 default-information originate always Task 4.5 Breakdown The default-information originate OSPF routing process subcommand will generate a default route into the OSPF domain. By default this default cannot be advertised unless the local device actually has a default route installed in the routing table. This stipulation is added to prevent the case where default reachability is lost from an upstream peer, but default reachability is still advertised into the OSPF domain. An example of this case is as follows.

Suppose that your OSPF domain has two or more connections to an upstream Internet provider. At these exit points from your internal network the border routers are learning a default from the ISP. Additionally these border routers are generating default routes into the OSPF domain by issuing the default-information originate routing process subcommand. Now suppose that one of these connections to the upstream provider is lost. If the border router with the lost upstream connection is still advertising default reachability into the OSPF domain some of the traffic will be blackholed. Instead the router with the lost connection should withdraw the default route from the OSPF domain, which in turn would cause all internal devices to reroute out a still valid exit point from the network.

In the above task as there is only one connection point between the OSPF

domain and the EIGRP domain, this case does not present an issue. Instead a default route can be generated regardless of the condition of the upstream link, as the internal routers have no choice to exit the OSPF domain except through R3. Therefore R3 adds the always keyword on to the default-information originate statement. This causes R3 to generate the default route regardless of whether or not it has it locally installed in its own IP routing table.


Task 4.6 R4: ip route 150.1.5.5 255.255.255.255 162.1.45.5 111 ip route 162.1.5.0 255.255.255.0 162.1.45.5 111 ip route 162.1.55.0 255.255.255.0 162.1.45.5 111 ! router ospf 1 redistribute static subnets R5: ip route 0.0.0.0 0.0.0.0 162.1.45.4 111 Task 4.6 Breakdown Static default routes are a very simple and effective way to replace more specific routing information when it is lost. A default route that is only installed in the IP routing table when another route (either dynamically learned or statically configured) is lost is called a floating static route. A floating static route is a route with the same longest match as another route in the IP routing table, but which has a higher administrative distance. Therefore the floating route will not get installed unless the primary route with the lower administrative distance leaves the IP routing table. In the above scenario R5 is learning a default route from R3 via OSPF. OSPF routes have an administrative distance of 110. There has also been a static default route configured on R5 pointing to R4 over the serial link with an administrative distance on 111. Unless the route with the lower administrative distance (the OSPF route with AD of 110) leaves the IP routing table the static route will not get installed. This case will occur when R5 loses its connection to the Frame Relay cloud. Therefore the above configured default route is a simple yet effective backup solution for R5. In order to maintain full reachability back to R5, R4 has configured three static routes pointing to the directly connected networks of R4. As these routes have an administrative distance of 111 (higher than OSPF) they will not be installed in the routing table unless R4 loses the route through OSPF. Note that these routes must be redistributed into the OSPF domain to ensure that all other devices have a route when the Frame Relay circuit of R5 is down.

Further Reading Using Floating Static Routes and Dial-on Demand Routing





Task 4.7 R1: key chain RIP key 1 key-string CISCO ! interface FastEthernet0/0 ip rip authentication mode md5 ip rip authentication key-chain RIP ! router rip version 2 passive-interface default network 192.10.1.0 neighbor 192.10.1.254 neighbor 192.10.1.6 no auto-summary R4: router rip version 2 network 204.12.1.0 no auto-summary R6: key chain RIP key 1 key-string CISCO ! interface GigabitEthernet0/0 ip rip authentication mode md5 ip rip authentication key-chain RIP ! router rip version 2 passive-interface default no passive-interface Serial0/0/0.1 network 54.0.0.0 network 150.1.0.0 network 192.10.1.0 network 162.1.0.0 neighbor 192.10.1.1 neighbor 192.10.1.254 no auto-summary


Task 4.7 The above task illustrates a standard straightforward configuration of RIPv2 routing. BB2 is authenticated using MD5 authentication. Additionally, the neighbor statement is used under the RIP process in order to direct unicast RIP updates between R1, R6 and BB2. Note that the passive-interface command must be added to the RIP process in order to stop the transmission of multicast RIP packets.

Verification R1# interface Ethernet0/0 ip address 10.0.0.1 255.0.0.0 ! router rip version 2 network 10.0.0.0 R1#debug ip rip RIP protocol debugging is on RIP: sending v2 update to 224.0.0.9 via Ethernet0/0 (10.0.0.1) RIPv2 Multicast Update R1(config)#router rip R1(config-router)#neighbor 10.0.0.2 R1#debug ip rip RIP protocol debugging is on R1# RIP: sending v2 update to 224.0.0.9 via Ethernet0/0 (10.0.0.1) Multicast & Unicast Update RIP: sending v2 update to 10.0.0.2 via Ethernet0/0 (10.0.0.1) R1(config)#router rip R1(config-router)#passive-interface ethernet0/0 R1(config-router)#end R1#debug ip rip RIP protocol debugging is on RIP: sending v2 update to 10.0.0.2 via Ethernet0/0 (10.0.0.1) Only Unicast Update




Task 4.8 R1: router eigrp 200 redistribute rip metric 10000 1000 100 1 1500 ! router rip version 2 redistribute eigrp 200 metric 1 R3: router eigrp 200 redistribute ospf 1 metric 10000 1000 100 1 1500 ! router ospf 1 redistribute eigrp 200 subnets route-map EIGRP_TO_OSPF ! ip prefix-list VLAN162 seq 5 permit 192.10.1.0/24 ! route-map EIGRP_TO_OSPF permit 10 match ip address prefix-list VLAN162 R4: interface Ethernet0/0 ip summary-address rip 162.1.0.0 255.255.0.0 ip summary-address rip 150.1.0.0 255.255.240.0 ! router ospf 1 redistribute connected subnets route-map CONNECTED2OSPF redistribute rip subnets summary-address 30.0.0.0 255.252.0.0 summary-address 31.0.0.0 255.252.0.0 ! router rip version 2 redistribute ospf 1 metric 1 ! route-map CONNECTED2OSPF permit 10 match interface Serial0/1 Ethernet0/0



5. Exterior Gateway Routing Task 5.1 R1: router bgp 200 no synchronization bgp router-id 150.1.1.1 neighbor 162.1.13.3 remote-as 300 neighbor 192.10.1.6 remote-as 200 neighbor 192.10.1.254 remote-as 254 neighbor 192.10.1.254 password CISCO R2: router bgp 300 no synchronization bgp router-id 150.1.2.2 neighbor 162.1.0.3 remote-as 300 neighbor 162.1.27.7 remote-as 65001 R3: router bgp 300 no synchronization bgp router-id 150.1.3.3 neighbor 162.1.0.2 remote-as 300 neighbor 162.1.0.4 remote-as 100 neighbor 162.1.13.1 remote-as 200 neighbor 162.1.38.8 remote-as 65002 R4: router bgp 100 bgp router-id 150.1.4.4 neighbor 150.1.5.5 remote-as 500 neighbor 150.1.5.5 ebgp-multihop neighbor 150.1.5.5 update-source Loopback0 neighbor 162.1.0.3 remote-as 300 neighbor 204.12.1.254 remote-as 54 R5: router bgp 500 bgp router-id 150.1.5.5 neighbor 150.1.4.4 ebgp-multihop neighbor 150.1.4.4 remote-as 100 neighbor 150.1.4.4 update-source Loopback0 R6: router bgp 200 no synchronization bgp router-id 150.1.6.6 neighbor 192.10.1.1 remote-as 200



SW1: router bgp 65001 bgp router-id 150.1.7.7 neighbor 162.1.27.2 remote-as 300 SW2: router bgp 65002 bgp router-id 150.1.8.8 network 162.1.18.0 mask 255.255.255.0 neighbor 162.1.38.3 remote-as 300 Task 5.2 R2: router bgp 300 neighbor 162.1.27.7 remove-private-AS R3: router bgp 300 neighbor 162.1.0.4 remove-private-AS neighbor 162.1.13.1 remove-private-AS neighbor 162.1.38.8 remove-private-as SW1: interface Loopback1 ip address 162.1.7.7 255.255.255.0 ! router bgp 65001 network 162.1.7.0 mask 255.255.255.0 SW2: interface Loopback1 ip address 162.1.18.8 255.255.255.0 ! router bgp 65002 network 162.1.18.0 mask 255.255.255.0 Task 5.2 Breakdown Applying for a public BGP AS number requires the justification of the need for the AS number. For networks that do not have their own block of address space, this may not be possible. For this reason the top 1024 addresses in the BGP AS range are marked as private. Suppose that your network has multiple connections to the same Internet Service Provider. Due to complex routing policy, you want to run BGP with this upstream provider. However, as this provider is your only connection to the Internet, you are using their address space, and do not have your own provider independent block. In the case the provider can assign you a locally significant AS number in the range of 64512 – 65535. However, as these AS numbers are


not valid on the Internet, they must be removed from the AS-Path of routes you are originating when the provider passes them upstream.

This is accomplished by adding the remove-private-as keyword on to the

neighbor statement of the upstream connection. In order for the private AS number to be removed, it must be the only AS in the path. In other words, the private AS must be directly connected to the AS that is trying to remove it.

Verification R1#show ip bgp BGP table version is 14, local router ID is 150.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 162.1.18.0/24 162.1.13.3 0 300 65002 i Without remove-private-as on R3

R3(config-if)#router bgp 300 R3(config-router)#neighbor 162.1.13.1 remove-private-AS R3#clear ip bgp 162.1.13.1 out R1#show ip bgp BGP table version is 15, local router ID is 150.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete

Further Reading Removing Private Autonomous System Numbers in BGP





Task 5.3 R5: interface Loopback2 ip address 162.1.15.5 255.255.255.0 ! router bgp 500 network 162.1.15.0 mask 255.255.255.0 neighbor 150.1.4.4 send-community neighbor 150.1.4.4 route-map NO_ADVERTISE out ! ip as-path access-list 1 permit ^$ ! route-map NO_ADVERTISE permit 10 match as-path 1 set community no-advertise route-map NO_ADVERTISE permit 1000 Task 5.3 Breakdown By setting the well known community attributes of no-export, no-advertise, or local-as, how a route is processed by an upstream neighbor can be controlled downstream. In the above task it asks that network 162.1.15.0/24 be advertised into BGP on R5. This network then gets passed on to R4 via BGP. The requirement also states that R4 should not pass this on. By setting the community value to one of the aforementioned, R4 will not advertise the route on. Recall the well-known communities: Well Known Community Behavior Internet All routes belong to this community by default. The

Internet community has no special behavior. No-advertise Do not advertise to any BGP neighbor. No-export Do not advertise to any EBGP neighbor. Local-AS Do not advertise outside of sub-AS. This is a special

case of no-export for use inside of a confederation.



Task 5.4 R4: router bgp 100 bgp dampening route-map DAMPENING ! route-map DAMPENING permit 10 set dampening 15 1000 3000 30 Task 5.4 Breakdown BGP route flap dampening (damping) is the process of suppressing consistently unstable routes from being used or advertised to BGP neighbors. Dampening is (and must be) used to minimize the amount of route recalculation performed in the global BGP table as a whole. Command Syntax: bgp dampening [half-life reuse suppress max-suppress-time] To understand dampening, the following terms must first be defined: Penalty: Every time a route flaps, a penalty value of 1000 is added to the

current penalty. All prefixes start with a penalty of zero. Half-life: Configurable time it takes the penalty value to reduce by half. Defaults

to 15 minutes. Suppress Limit: Threshold at which a route is suppressed if the penalty

exceeds. Defaults to 2000. Reuse Limit: Threshold at which a suppressed route is unsuppressed if the

penalty drops below. Defaults to 750. Max Suppress: Maximum time a route can be suppressed if it has been

stable. Defaults to four times the half-life value.

Each time a route flaps (leaves the BGP table and reappears) it is assigned a penalty of 1000. As soon as this occurs, the penalty of the route starts to decay based on the half-life timer. As the penalty increases, as does the rate of decay. For example, after a single flap, it will take 15 minutes for a prefix to reduce its penalty to 500.


Once the penalty of a prefix exceeds the suppress limit, the prefix is suppressed. A suppressed prefix cannot be used locally or advertised to any BGP peer. Once the penalty decay has resulted in the penalty decreasing below the reuse limit, the prefix is unsuppressed.

Lastly, the max-suppress timer dictates the maximum amount of time a

prefix can be suppressed if it has been stable. This value is useful if a number of flaps have occurred in a short period of time, after which the route has been stable.

To enable BGP route flap dampening, simply enter the command bgp

dampening under the BGP process.

Standard RIPE Routing-WG Recommendations for Coordinated Route-flap Damping Parameters

Documentation CD BGP Command Reference: bgp dampening


ftp://ftp.ripe.net/ripe/docs/ripe-229.txt


http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fiprrp_r/bgp_r/1rfbgp1.htm



6. IP Multicast Task 6.1 R1: ip multicast-routing ! interface FastEthernet0/0 ip pim sparse-dense-mode ! interface Serial0/0 ip pim sparse-dense-mode R2: ip multicast-routing ! interface FastEthernet0/0 ip pim sparse-dense-mode ! interface Serial0/0.1 ip pim sparse-dense-mode R3: ip multicast-routing ! interface Ethernet0/0 ip pim sparse-dense-mode ! interface Ethernet0/1 ip pim sparse-dense-mode ! interface Serial1/0 ip pim sparse-dense-mode ! interface Serial1/1 ip pim sparse-dense-mode R5: ip multicast-routing ! interface Ethernet0/0 ip pim sparse-dense-mode ! interface Ethernet0/1 ip pim sparse-dense-mode ! interface Serial0/0 ip pim sparse-dense-mode



SW2: ip multicast-routing ! interface FastEthernet0/15 ip pim sparse-dense-mode ! interface Vlan8 ip pim sparse-dense-mode ! interface Vlan88 ip pim sparse-dense-mode Task 6.2 R1: interface Loopback0 ip pim sparse-dense-mode ! ip pim send-rp-discovery Loopback0 scope 16 ip pim rp-announce-filter rp-list 25 group-list 26 ip pim rp-announce-filter rp-list 50 group-list 51 ! access-list 25 permit 150.1.3.3 access-list 26 permit 239.0.0.0 0.255.255.255 access-list 50 permit 150.1.5.5 access-list 51 deny 224.0.0.0 1.255.255.255 access-list 51 deny 239.0.0.0 0.255.255.255 access-list 51 permit 224.0.0.0 15.255.255.255 R3: interface Loopback0 ip pim sparse-dense-mode ! ip pim send-rp-announce Loopback0 scope 16 group-list 50 ! access-list 50 permit 239.0.0.0 0.255.255.255 R5: interface Loopback0 ip pim sparse-dense-mode ! ip pim send-rp-announce Loopback0 scope 16 group-list 50 ! access-list 50 permit 226.0.0.0 1.255.255.255 access-list 50 permit 228.0.0.0 3.255.255.255 access-list 50 permit 232.0.0.0 3.255.255.255 access-list 50 permit 236.0.0.0 1.255.255.255 access-list 50 permit 238.0.0.0 0.255.255.255



Task 6.2 Breakdown In previous labs there was not a requirement to have the mapping agent control which specific groups were mapped with which candidate RPs (cRP). The requirement is given to have R1 map only specific multicast groups to R3 and R5. This will require the use of the ip pim rp-announce-filter command on the mapping agent (MA). The rp-announce filter will need to match the send-rp-announce filter used by the cRPs. If the groups requested by the RP do not match the mapping agent’s filters, the cRPs requests that do not match will be discarded. Example: If the cRP asks for 228.0.0.0/8 and 229.0.0.0/8 but the MA is allowing only 228.0.0.0/8 then the MA will filter the 229.0.0.0/8 and the cRP will be the RP for just 228/8. If the cRP asks for say 224.0.0.0/4 (all multicast groups) but the MA is only allowing 228.0.0.0/8 then the cRP's 224.0.0.0/4 announcement will be filtered by the MA and the cRP will not be the RP for any groups. The logic of the access-list 51 used is as follows. The first step in finding out how to match all these addresses is to write them out in binary:

226 11100010 227 11100011 228 11100100 229 11100101 230 11100110 231 11100111 232 11101000 233 11101001 234 11101010 235 11101011 236 11101100 237 11101101 238 11101110

From the above addresses it's evident that it's very close to a complete

range, but is missing the 224, 225, and 239. If these numbers were included, then the range would be a contiguous block of 16 addresses (224 to 239). This address block would be matched as:

access-list 51 permit 224.0.0.0 15.255.255.255

However, now it overlaps 224, 225, and 239. These three can be removed

with deny statements:

access-list 51 deny 224.0.0.0 0.255.255.255 access-list 51 deny 225.0.0.0 0.255.255.255 access-list 51 deny 239.0.0.0 0.255.255.255




The total list is four lines now. Since we want the minimum number of lines, let's try to consolidate some of the deny statements. To do this we write out the three denied addresses in binary:

224 - 11100000 225 - 11100001 239 - 11101111

From the above address space, it is easily seen that 224 and 225 can be

consolidated in one line (only the least significant bit is different), but the 239 cannot. Therefore these can be rewritten as:

224 - 11100000 225 – 11100001

Wildcard - 00000001 239 - 11101111 Wildcard - 00000000

These groupings result in the following list:

access-list 51 deny 224.0.0.0 1.255.255.255 access-list 51 deny 239.0.0.0 0.255.255.255


Now we have three lines. This may be the least amount of lines, but let's use just permit statements to be sure. Remember the addresses are as follows:

226 11100010 227 11100011 228 11100100 229 11100101 230 11100110 231 11100111 232 11101000 233 11101001 234 11101010 235 11101011 236 11101100 237 11101101 238 11101110



Now lets group them together in ranges that can be checked without overlap:

226 11100010 227 11100011

228 11100100 229 11100101 230 11100110 231 11100111

232 11101000 233 11101001 234 11101010 235 11101011

236 11101100 237 11101101

238 11101110

This gives us five permit statements.

226 11100010 227 11100011 230 11100110 231 11100111

228 11100100 229 11100101 236 11101100 237 11101101

232 11101000 233 11101001 234 11101010 235 11101011

238 11101110

This gives us four. Better, but still not three. There's no way to get under four statements just by using permits. Therefore the correct answer for this section should be: access-list 51 deny 224.0.0.0 1.255.255.255 access-list 51 deny 239.0.0.0 0.255.255.255 access-list 51 permit 224.0.0.0 15.255.255.255


Verification Here is the output from the debug ip pim auto-rp command on R1 with R5 configured to request all groups (no group-list on R5’s ip pim send-rp-announce command), and R1 is configured with the ip pim rp-announce-filter shown above. Rack1R1#debug ip pim auto-rp PIM Auto-RP debugging is on Rack1R1# Auto-RP: Received RP-announce, from 150.1.5.5, RP_cnt 1, ht 181 Auto-RP: Filtered 224.0.0.0/4 for RP 150.1.5.5 Rack1R1# As we can see R5 request all multicast groups. This request does not match R1’s filters and in turn was discarded (filtered). Now we will add the group-list option to R5’s ip pim send-rp-announce command that matches R1’s ip pim rp-announce-filter group-list. Rack1R1# Auto-RP: Received RP-announce, from 150.1.5.5, RP_cnt 1, ht 181 Auto-RP: Update (226.0.0.0/7, RP:150.1.5.5), PIMv2 v1 Auto-RP: Update (228.0.0.0/6, RP:150.1.5.5), PIMv2 v1 Auto-RP: Update (232.0.0.0/6, RP:150.1.5.5), PIMv2 v1 Auto-RP: Update (236.0.0.0/7, RP:150.1.5.5), PIMv2 v1 Auto-RP: Update (238.0.0.0/8, RP:150.1.5.5), PIMv2 v1 Rack1R1#show ip pim rp mapping PIM Group-to-RP Mappings This system is an RP-mapping agent (Loopback0) Group(s) 226.0.0.0/7 RP 150.1.5.5 (?), v2v1 Info source: 150.1.5.5 (?), via Auto-RP Uptime: 00:03:13, expires: 00:02:47 Group(s) 228.0.0.0/6 RP 150.1.5.5 (?), v2v1 Info source: 150.1.5.5 (?), via Auto-RP Uptime: 00:03:13, expires: 00:02:45 Group(s) 232.0.0.0/6 RP 150.1.5.5 (?), v2v1 Info source: 150.1.5.5 (?), via Auto-RP Uptime: 00:03:14, expires: 00:02:44 Group(s) 236.0.0.0/7



Further Reading How to Implement a Filtering Policy for Rendezvous Points

Task 6.3 R1: interface FastEthernet0/0 ip pim neighbor-filter 75 ! access-list 75 deny 192.10.1.254 access-list 75 permit any Task 6.3 Breakdown To restrict PIM neighbor relationship, the ip pim neighbor-filter interface command was used for this section. This will not allow BB2 to become a PIM neighbor with R1, but will still allow clients on the Ethernet segment to join any multicast group as this command only affects PIM neighbor relationships and not IGMP.

This configuration can be verified by using the show ip pim neighbors command. Task 6.4 R3: interface Ethernet0/0 ip multicast boundary 51 ! access-list 51 deny 239.0.0.0 0.255.255.255 access-list 51 permit 224.0.0.0 15.255.255.255 Task 6.4 Breakdown Although other methods can be used the control multicast traffic, the preferred method is to use the ip multicast-boundary interface command. The command requires an access-list that defines what groups are deny or permitted out the interface.


http://www.cisco.com/en/US/tech/tk828/tk363/technologies_configuration_example09186a00801cb923.shtml



Task 6.5 R1, R2, R3, R5, SW2: ip pim spt-threshold infinity group-list 52 ! access-list 52 permit 239.0.0.0 0.255.255.255 Task 6.5 Breakdown With multicasting there normally is more than one receiver and in turn there can be more than one path the packets take through the network to reach the various receivers. These paths are commonly referred to as branches on the multicast tree. There are two types of multicast trees that can be formed in regards to this section’s configuration. The default tree type is a source based tree. A source based tree is rooted at the source of the multicast stream. The tree is built using the least cost path between the source and destination or destinations. This is sometimes referred to a shortest path tree. The second type of tree, the one that this configuration will actually use, is called a shared tree. With a shared tree all multicast packets are sent to the RP and then down to the receivers. It is interesting to note how routers perform the RPF check in regards to the two different types of tree. With a source based tree, the RPF check is done against the source of the multicast packets. With a shared tree, the RPF check is done against the RP and not against the source of the multicast stream. Using a shared tree as opposed to the default of a source based tree could possibly be used to workaround an issue with an RPF failure where static mroutes could not be used and the unicast routing could also not be easily changed.



7. IPv6 Task 7.1 R1: interface FastEthernet0/0 ipv6 address 2001:CC1E:1:1::1/64 R2: interface FastEthernet0/0 ipv6 address 2001:CC1E:1:2::2/64 R3: interface Ethernet0/1 ipv6 address 2001:CC1E:1:3::3/64 R4: interface Ethernet0/0 ipv6 address 2001:204:12:1::100/64 Task 7.2 R1: interface Serial0/0 ipv6 address 2001:CC1E:1::1/64 frame-relay map ipv6 2001:CC1E:1::3 113 broadcast R2: interface Serial0/0.1 point-to-point ipv6 address FEC0:234::2/64 R3: interface Serial1/0 ipv6 address FEC0:234::3/64 frame-relay map ipv6 FEC0:234::2 302 broadcast frame-relay map ipv6 FEC0:234::4 304 broadcast ! interface Serial1/1 frame-relay map ipv6 2001:CC1E:1::1 311 broadcast frame-relay map ipv6 FE80::204:27FF:FEB5:2F60 311 R4: interface Serial0/0 frame-relay map ipv6 FEC0:234::2 403 frame-relay map ipv6 FEC0:234::3 403 broadcast Task 7.2 Breakdown Like ATM and ISDN, Frame Relay is a non-broadcast multi-access (NBMA) media. This implies that layer 3 to layer 2 resolution is required for multipoint configurations. As of current Cisco IOS releases, Inverse Neighbor



Discovery is not supported. Therefore, static layer 3 to layer 2 resolution must be configured with the frame-relay map ipv6 statement. The host portion of the configured site-local networks can be determined by issuing either the show ipv6 interface command or the show ipv6 interface brief command. Rack1R1#show ipv6 interface serial0/0 Serial0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::2D0:58FF:FE6E:B720 Global unicast address(es): FEC0::13:2D0:58FF:FE6E:B720, subnet is FEC0:0:0:13::/64 <output omitted> Rack1R3#show frame-relay map Serial1/1 (up): ipv6 FEC0::13:2D0:58FF:FE6E:B720 dlci 311 (0x137,0x4C70), static, broadcast, CISCO, status defined, active <output omitted>



Task 7.3 R1: ipv6 unicast-routing ! interface Serial0/0 frame-relay map ipv6 FE80::250:73FF:FE1C:7761 113 ! router bgp 200 neighbor 2001:CC1E:1::3 remote-as 300 ! address-family ipv6 neighbor 2001:CC1E:1::3 activate R2: ipv6 unicast-routing ! router bgp 300 neighbor FEC0:234::3 remote-as 300 ! address-family ipv6 neighbor FEC0:234::3 activate R3: ipv6 unicast-routing ! interface Serial1/0 frame-relay map ipv6 FE80::230:94FF:FE7E:E581 304 frame-relay map ipv6 FE80::204:27FF:FEB5:2FA0 302 ! interface Serial1/1 frame-relay map ipv6 FE80::204:27FF:FEB5:2F60 311 ! router bgp 300 neighbor 2001:CC1E:1::1 remote-as 200 neighbor FEC0:234::2 remote-as 300 neighbor FEC0:234::4 remote-as 100 ! address-family ipv6 neighbor 2001:CC1E:1::1 activate neighbor FEC0:234::2 activate neighbor FEC0:234::4 activate



R4: ipv6 unicast-routing ! interface Serial0/0 frame-relay map ipv6 FE80::204:27FF:FEB5:2FA0 403 frame-relay map ipv6 FE80::250:73FF:FE1C:7761 403 ! router bgp 100 neighbor 2001:204:12:1::254 remote-as 54 neighbor FEC0:234::3 remote-as 300 ! address-family ipv6 neighbor 2001:204:12:1::254 activate neighbor FEC0:234::3 activate Task 7.3 Breakdown The above configuration dictates how to configure Multiprotocol BGP for IPv6. The first step is to issue the BGP neighbor command, followed by the destination peer’s IPv6 address and AS number. Next, enable IPv6 unicast processing for the neighbor by issuing the address-family ipv6 command under the BGP process, followed by the neighbor [ipv6 address] activate command.

Rack1R3#show bgp ipv6 summary BGP router identifier 162.1.13.3, local AS number 300 BGP table version is 2, main routing table version 2 1 network entries using 133 bytes of memory 1 path entries using 72 bytes of memory 1 BGP path attribute entries using 60 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 289 total bytes of memory BGP activity 1/0 prefixes, 1/0 paths, scan interval 60 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd FEC0::13:2D0:58FF:FE6E:B720 4 200 24 23 2 0 0 00:19:52 1



To check the status of the MBGP peering issue the show bgp ipv6 summary command. In the above output R3 has formed a MBGP peering relationship with R1 using the destination address FEC0::13:2D0:58FF:FE6E:B720, and is learning one IPv6 prefix. Rack1R3#show bgp ipv6 BGP table version is 2, local router ID is 162.1.13.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 2001:CC1E:1:162::/64 FEC0::13:2D0:58FF:FE6E:B720

0 0 200 i

Note that in the above output the prefix 2001:CC1E:1:162::/64 has been learned via BGP per the show bgp ipv6 output, and has an associated next-hop value of FEC0::13:2D0:58FF:FE6E:B720. Rack1R3#show ipv6 route FEC0::13:2D0:58FF:FE6E:B720 IPv6 Routing Table - 5 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 C FEC0:0:0:13::/64 [0/0] via ::, Serial1/1

When a recursive lookup is performed on this next-hop value, per the above show ipv6 route FEC0::13:2D0:58FF:FE6E:B720 output, the outgoing interface is seen to be Serial1/1, which is a multipoint interface running Frame Relay. However when traffic is encapsulated on the interface the layer 2 address is resolved per the link-local address of the next-hop interface, not the global unicast address. This can be seen by the below show ipv6 route bgp output. Rack1R3#show ipv6 route bgp IPv6 Routing Table - 5 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 B 2001:CC1E:1:162::/64 [20/0] via FE80::2D0:58FF:FE6E:B720, Serial1/1

This implies that layer 3 to layer 2 resolution via the frame-relay map ipv6 command must be configured for the remote link-local address FE80::2D0:58FF:FE6E:B720.



Rack1R1#show ipv6 int brief Ethernet0/0 [up/up] FE80::230:19FF:FE69:81A0 2001:CC1E:1:162:230:19FF:FE69:81A0

Quick Note Global unicast address

Serial0/0 [up/up] FE80::2D0:58FF:FE6E:B720 FEC0::13:2D0:58FF:FE6E:B720

Quick Note Link-local address

<output omitted> Rack1R3#debug ipv6 packet IPv6 unicast packet debugging is on Rack1R3#debug frame-relay packet Frame Relay packet debugging is on Rack1R3#ping Protocol [ip]: ipv6 Target IPv6 address: 2001:CC1E:1:162:230:19FF:FE69:81A0 Repeat count [5]: 1 Datagram size [100]: Timeout in seconds [2]: Extended commands? [no]: Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 2001:CC1E:1:162:230:19FF:FE69:81A0, timeout is 2 seconds: IPv6: SAS picked source FEC0::13:201:96FF:FE63:96C0 for 2001:CC1E:1:162:230:19FF:FE69:81A0 IPv6: nexthop FE80::2D0:58FF:FE6E:B720, IPV6: source FEC0::13:201:96FF:FE63:96C0 (local) dest 2001:CC1E:1:162:230:19FF:FE69:81A0 (Serial1/1) traffic class 0, flow 0x0, len 100+0, prot 58, hops 64, originating Serial1/1:Encaps failed--no map entry link 79(IPV6) IPv6: Encapsulation failed.

Quick Note Encapsulation fails because R3 does not have a layer 3 to layer 2 mapping for the next-hop address FE80::2D0:58FF:FE6E:B720s

Success rate is 0 percent (0/1) Rack1R3#conf t Enter configuration commands, one per line. End with CNTL/Z. Rack1R3(config)#interface serial1/1 Rack1R3(config-if)#frame-relay map ipv6 FE80::2D0:58FF:FE6E:B720 311 Rack1R3(config-if)#do ping 2001:CC1E:1:162:230:19FF:FE69:81A0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:CC1E:1:162:230:19FF:FE69:81A0, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/20 ms



Task 7.4 R1: router bgp 200 ! address-family ipv6 network 2001:CC1E:1:1::/64 R2: router bgp 300 ! address-family ipv6 network 2001:CC1E:1:2::/64 R3: router bgp 300 ! address-family ipv6 network 2001:CC1E:1::/64 network 2001:CC1E:1:3::/64 network FEC0:234::/64 R4: router bgp 100 ! address-family ipv6 network 2001:204:12:1::/64 Task 7.5 R3: router bgp 300 ! address-family ipv6 neighbor 2001:CC1E:1::1 unsuppress-map UNSUPPRESS neighbor FEC0:234::2 unsuppress-map UNSUPPRESS aggregate-address 2001:CC1E:1::/62 summary-only ! route-map UNSUPPRESS permit 10


8. QoS Task 8.1 R1: interface Serial0/0 frame-relay class FRTS frame-relay traffic-shaping ! map-class frame-relay FRTS frame-relay cir 384000 frame-relay bc 38400 frame-relay be 12800 frame-relay mincir 256000 frame-relay adaptive-shaping becn Task 8.1 Breakdown The following values on R1 can be inferred from this task’s description:

AR (port speed) = 512000 bps CIR (average rate) = 384000bps Tc (interval length) = 100 ms

The following values are then calculated based on the given values and the below formula:

Bc = CIR * Tc/1000 Bc = 38400 bits Be = (AR – CIR) * Tc/1000 Be = 12800 bits

Previous Reference Frame Relay Traffic Shaping: Lab 1 Task 8.1



Task 8.2 R3: interface Serial1/0 frame-relay map ip 162.1.0.4 304 broadcast rtp header-compression passive connections 15 R4: interface Serial0/0 frame-relay map ip 162.1.0.3 403 broadcast rtp header-compression connections 15 Task 8.2 Breakdown RTP header compression allows the reduction of the header inside an RTP packet to be reduced from 40 bytes to 2 – 5 bytes. RTP compression is best used on low speed links for real time traffic with small data payloads, such as VoIP. To configure RTP on a serial link use the ip rtp header-compression command. For Frame Relay links RTP compression can be configured on a per VC basis as in the above example. The passive keyword of the RTP statement means that the router will not start sending RTP compressed headers unless RTP headers are received.

Further Reading Configuring Compressed Real Time Protocol


http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/qos_c/qcpart6/qcrtphc.htm



Task 8.3 R2: ip cef ! class-map match-all SQL match protocol sqlserver ! ! policy-map SQL_POLICY class SQL shape average 256000 shape max-buffers 2048 ! interface Serial0/0.1 point-to-point service-policy output SQL_POLICY Task 8.3 Breakdown The above task uses Network Based Application Recognition to match SQL traffic (TCP port 1433). As SQL traffic leaves the serial interface it is shaped to 256Kbps. The shaping buffers are modified to allow up to 2048 packets to sit in the shaping queue while waiting to be sent out. A large shaping queue is advantageous for delay insensitive data traffic for which you do not want to be dropped. The above configuration is known as Generic Traffic Shaping. GTS uses the same principles and calculations as does Frame Relay Traffic Shaping, but does not adaptively shape, and is supported on non-Frame Relay interfaces.


Verification Rack1R1#show policy-map SQL_POLICY Policy Map SQL_POLICY Class SQL Traffic Shaping Average Rate Traffic Shaping CIR 256000 (bps) Max. Buffers Limit 2048 (Packets) Rack1R1#show policy interface ethernet 0/0 Ethernet0/0 Service-policy output: SQL_POLICY Class-map: SQL (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: protocol sqlserver Traffic Shaping Target/Average Byte Sustain Excess Interval Increment Rate Limit bits/int bits/int (ms) (bytes) 256000/256000 1984 7936 7936 31 992 Adapt Queue Packets Bytes Packets Bytes Shaping Active Depth Delayed Delayed Active - 0 0 0 0 0 no Class-map: class-default (match-any) 136 packets, 12610 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any

Further Reading Network Based Application Recognition

Previous Reference Modular Quality of Service: Lab 1 Task 8


http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/dtnbarad.htm



9. Security Task 9.1 R4: interface Ethernet0/0 ip access-group IN_ACL in ip access-group OUT_ACL out ! ip access-list extended IN_ACL permit icmp any any echo-reply permit tcp any eq telnet any established permit tcp any any eq bgp permit tcp any eq bgp any permit udp any any eq rip evaluate MY_REFLECT ip access-list extended OUT_ACL permit tcp any any reflect MY_REFLECT permit udp any any reflect MY_REFLECT permit icmp any any reflect MY_REFLECT Task 9.1 Breakdown

Reflexive access-lists were covered in lab 2 task 9.4.

This task requires that ping and telnet packets be permitted to return. Since by default traffic originated by the router itself will not be reflected, the following static entries are needed:

ip access-list extended IN_ACL permit icmp any any echo-reply permit tcp any eq telnet any established

These access-list entries will allow telnet and ICMP echo replies inbound even if they were not reflected. A workaround for this can be to policy route all ICMP and telnet traffic originated by the router out a loopback interface. When this occurs, the traffic will be reflected and in turn can by evaluated. Here is an example: interface Ethernet0/0 ip access-group IN_ACL in ip access-group OUT_ACL out ! ip access-list extended IN_ACL evaluate MY_REFLECT ip access-list extended OUT_ACL permit tcp any any reflect MY_REFLECT permit udp any any reflect MY_REFLECT permit icmp any any reflect MY_REFLECT



Rack1R4#ping 204.12.1.254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 204.12.1.254, timeout is 2 seconds: ICMP: dst (204.12.1.4) administratively prohibited unreachable sent to 204.12.1.254. ICMP: dst (204.12.1.4) administratively prohibited unreachable sent to 204.12.1.254. ICMP: dst (204.12.1.4) administratively prohibited unreachable sent to 204.12.1.254. ICMP: dst (204.12.1.4) administratively prohibited unreachable sent to 204.12.1.254. ICMP: dst (204.12.1.4) administratively prohibited unreachable sent to 204.12.1.254. Success rate is 0 percent (0/5) Rack1R4#

As we can see from the output of the debug ip icmp command, the echo replies were not allowed to return. R4 denied the replies and in turn sent an administratively prohibited message to the source of the reply (BB3). Of course in a real network we normally do not want the router telling the source that a packet was denied by an access-list and disable these replies by using the no ip unreachables command under the interfaces.

The workaround will involve policy routing the ICMP echo requests and

telnet packets out the loopback 0 interface.

route-map LOCAL_TRAFFIC permit 10 match ip address ORIGINATED set interface Loopback0 ! ip access-list extended ORIGINATED permit icmp any any permit tcp any any eq telnet

This configuration will allow the packets originated by the router itself to be reflected. Rack1R4#ping 204.12.1.254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 204.12.1.254, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/9 ms Rack1R4#



To further verify that the policy routing is working, below is the same ping with the debug ip policy command enabled. Rack1R4#debug ip policy Policy routing debugging is on Rack1R4#ping 204.12.1.254 repeat 1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 204.12.1.254, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms Rack1R4# IP: s=204.12.1.4 (local), d=204.12.1.254, len 100, policy match IP: route map LOCAL_TRAFFIC, item 10, permit IP: s=204.12.1.4 (local), d=204.12.1.254 (Loopback0), len 100, policy routed IP: local to Loopback0 204.12.1.254 Rack1R4#


Task 9.2


SW1: vlan access-map ICMP_FILTER 10 action drop match ip address 100 vlan access-map ICMP_FILTER 20 action forward vlan filter ICMP_FILTER vlan-list 162

The sequence of the action and match commands within a vlan filter are irrelevant. The IOS will always show the action before the match irrespective to the order they are entered.

! access-list 100 permit icmp 205.90.31.0 0.0.0.255 any echo Task 9.2 Breakdown

A VLAN access-list, commonly referred to as a VACL, uses the same basic logic as a route-map. A VACL contains sequence numbers along with match and action criteria like a route-map with its match and set criteria. In a VACL the match can be an IP or MAC access-list. The action will always be forward of drop. The action will either forward the traffic that is matched, or drop the traffic that is matched. If the vlan access-map sequence does not contain a match statement, all traffic will match.

This means that the logic of the access-list is important in that traffic that you want to deny will need to be permitted in your access-list. By permitting the traffic in you access-list it will match and in turn the action will be taken. Of course you could reverse the logic and match traffic that you want to permit and use the action of forward on it. Then create another vlan access-map sequence that just has an action drop and not match statement. Here is an example:


vlan access-map ICMP_FILTER 10 action forward match ip address 100 vlan access-map ICMP_FILTER 20 action drop vlan filter ICMP_FILTER vlan-list 162 ! access-list 100 deny icmp 205.90.31.0 0.0.0.255 any echo access-list 100 permit ip any any

Pitfall Because VACLs are compiled to improve performance, changes made to an access-map will not take affect till the vlan filter is removed and reapplied. Be sure to remove and then reapply the vlan filter command whenever changes are made to the vlan access-map commands.

In the above configuration the access-list logic is reversed. Here access-list 100 denies ICMP sourced from 205.90.31.0/24 and permits all other IP traffic. Since the ICMP traffic from 205.90.31.0/24 is not ‘positive’ in the access-list, it will not match and in turn not get forwarded. The ICMP traffic will match vlan access-map sequence number 20 since there is not a match statement. This will in turn cause the ICMP traffic to be dropped.

Although this configuration appears fine, it will cause problems. The

problem is that access-list 100 does not permit ARP. The IP Ethernet and ARP Ethernet types are not the same. ARP will not match vlan access-map sequence number 10 but will match 20, which has a default action of drop. This configuration will appear to work for a few hours or until a reboot, assuming the devices have already created an ARP entry before the vlan filter was applied. Someone could leave the lab with the assumption that their configurations are correct but once the devices are reloaded and need to ARP, everything that relies on ARP will stop working (routing protocols, ping, etc). Here is an example:

Rack1R1#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 192.10.1.254 1 00e0.1ece.4a68 ARPA Ethernet0/0 Internet 192.10.1.1 - 00d0.586e.b720 ARPA Ethernet0/0 Rack1R1#ping 192.10.1.254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.10.1.254, timeout is 2 seconds: !!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms




Now the ARP cache is cleared so that R1 will need to ARP for BB2. Then we try to ping from R1 (192.10.1.1) to BB2 (192.10.1.254) again. Rack1R1#clear arp Rack1R1#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 192.10.1.1 - 00d0.586e.b720 ARPA Ethernet0/0 Rack1R1#ping 192.10.1.254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.10.1.254, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Rack1R1#

As we can see this configuration broke ARP. To permit ARP, a MAC access-list will need to be created that matches the ARP Ethernet type. A new vlan filter sequence will also need to be added. Do not forget to remove the vlan filter and reapply it. mac access-list extended PERMIT_ARP permit any any 0x806 0x0 ! ! vlan access-map ICMP_FILTER 10 action forward match ip address 100 vlan access-map ICMP_FILTER 15 action forward match mac address PERMIT_ARP vlan access-map ICMP_FILTER 20 action drop vlan filter ICMP_FILTER vlan-list 162 ! access-list 100 deny icmp 205.90.31.0 0.0.0.255 any echo access-list 100 permit ip any any Rack1SW2#conf t Enter configuration commands, one per line. End with CNTL/Z. Rack1SW2(config)#no vlan filter ICMP_FILTER vlan-list 162 Rack1SW2(config)#vlan filter ICMP_FILTER vlan-list 162 Rack1SW2(config)#^Z Rack1SW2# Rack1R1#ping 192.10.1.254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.10.1.254, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/3/4 ms Rack1R1#



10. System Management Task 10.1 R6: access-list 25 permit 192.10.1.101 access-list 25 deny any log ! snmp-server community CISCORO RO 25 snmp-server community CISCORW RW 25 snmp-server trap-source Loopback0 snmp-server location San Jose, CA US snmp-server contact CCIE Lab R6 snmp-server chassis-id 556-123456 snmp-server host 192.10.1.101 CISCOTRAP Task 10.1 Breakdown

Although this is a relatively standard SNMP configuration, task requiring to configure logging could be difficult to interpret. This key is the word “logged”. Even though the router could notify the NMS via an SNMP trap by using the snmp-server enable traps snmp authentication command, the tasked requested that the failed attempts be logged. To log the failed attempts, an access-list entry was used that denied all other IP addresses and logged them. Of course in a real network a remote syslog server would also be configured or at least logging buffered would have been enabled.



Task 10.2 R4 and R5: logging trap notifications logging origin-id hostname logging facility sys10 logging source-interface Loopback0 logging 192.10.1.101 Task 10.2 Breakdown

Syslog has been explained in lab 1 task 9.2 and lab 2 task 10.4.

By default, syslog messages do not include the hostname of the device in them. In a real network this can be real useful when viewing the syslog messages on the syslog server itself. The logging origin-id command enables the hostname, IP address, or even as of 12.3(1), a user defined string in the log messages.


11. IP Services Task 11.1 R6: ip name-server 192.10.1.100 ! ip domain-lookup ! line con 0 transport preferred none Task 11.1 Breakdown

Although this could be considered a Stupid Router Trick (SRT), it is a very useful command to have enabled in a lab environment or even real network when DNS is being used. The transport preferred none line command will stop the router from trying to resolve a mistyped command via DNS.

The router is technically attempting to resolve the string entered via DNS

as it’s trying to telnet to a device with that particular name. Once the transport preferred none command is enabled, you will need to use the telnet exec mode command to telnet to another device. Verification

Rack1R6#shw Translating "shw"...domain server (192.10.1.100) Rack1R6#conf t Enter configuration commands, one per line. End with CNTL/Z. Rack1R6(config)#line console 0 Rack1R6(config-line)#transport preferred none Rack1R6(config-line)#^Z Rack1R6#shw ^ % Invalid input detected at '^' marker. Rack1R6#150.1.6.6 ^ % Invalid input detected at '^' marker. Rack1R4#telnet 150.1.6.6 Trying 150.1.6.6 ... Open Password required, but none set [Connection to 150.1.6.6 closed by foreign host] Rack1R6#



Task 11.2 R6: enable secret level 2 CISCO ! privilege interface level 2 ip access-group privilege interface level 2 encapsulation privilege configure level 2 hostname privilege configure level 2 interface privilege exec level 2 show run Task 11.2 Breakdown Privilege levels we previously explained in lab 3 task 11.1.

Verification Rack1R6>enable 2 Password: Rack1R6#show privilege Current privilege level is 2 Rack1R6#show run Building configuration... Current configuration : 111 bytes ! ! hostname Rack1R6 ! ! ! ! ! interface Loopback0 ! interface GigabitEthernet0/0 ! interface GigabitEthernet0/1 ! interface Serial0/0/0! ! end

Rack1R6#




1. Catalyst 3550 Task 1.1 SW1: vtp domain CISCO vtp password CISCO ! vlan 4,5,6,7,10,32,77,363,777 ! interface FastEthernet0/2 no switchport ip address 191.1.27.7 255.255.255.0 ! interface FastEthernet0/3 switchport access vlan 32 ! interface FastEthernet0/4 switchport access vlan 4 ! interface FastEthernet0/5 switchport access vlan 5 ! interface FastEthernet0/6 switchport access vlan 6 ! interface FastEthernet0/24 switchport access vlan 363 ! interface Vlan7 ip address 191.1.7.7 255.255.255.0 ! interface Vlan77 ip address 191.1.77.7 255.255.255.0 ! interface Vlan777 ip address 191.1.177.7 255.255.255.0



SW2: vtp domain CISCO vtp password CISCO ! interface FastEthernet0/3 switchport access vlan 363 ! interface FastEthernet0/4 no switchport ip address 191.1.48.8 255.255.255.0 ! interface FastEthernet0/6 switchport access vlan 363 ! interface FastEthernet0/16 switchport access vlan 10 ! interface FastEthernet0/24 switchport access vlan 32



Task 1.2 SW1 and SW2: interface Port-channel1 switchport trunk encapsulation isl switchport mode trunk ! interface FastEthernet0/13 switchport trunk encapsulation isl switchport mode trunk channel-group 1 mode on ! interface FastEthernet0/14 switchport trunk encapsulation isl switchport mode trunk channel-group 1 mode on ! interface FastEthernet0/15 switchport trunk encapsulation isl switchport mode trunk channel-group 1 mode on


Task 1.3 SW2: interface FastEthernet0/16 switchport mode access switchport port-security switchport port-security maximum 4 switchport port-security violation restrict switchport port-security mac-address 0050.7014.8ef0 switchport port-security mac-address 00c0.144e.07bf switchport port-security mac-address 00d0.341c.7871 switchport port-security mac-address 00d0.586e.b710 ! logging 191.1.7.100 Task 1.3 Breakdown Layer 2 security based on source MAC address of a frame is controlled by port security. Port security allows you to define either specific MAC addresses that can send traffic into a port or how many MAC addresses can send traffic into a port. The first step in enabling port security is to set the port mode to access. Port security is not supported on dynamic ports. This is accomplished by issuing the switchport mode access command. Next, enable port security by issuing the switchport port-security interface command. By default port security only allows one MAC address to use a port. Since the above task states that four MAC address should be allowed entry, and specifically lists their addresses. Therefore the maximum allowed addresses must be increased by issuing the switchport port-security maximum [num] command. Next the addresses are defined by issuing the switchport port-security mac-address [address] command.

Next, the task states that other hosts which try to access the port should be logged. By default the violate action of port security is shutdown. This means that the port it is sent to err-disabled state when either an insecure MAC is heard, or the maximum MAC addresses is exceeded. In addition to shutdown, restrict and protect are included as additional violate actions. When the violation mode is set to protect, traffic from MAC addresses that are not secure or are in excess of the maximum value is discarded. When violation is set to restrict the behavior is the same as protect, but a syslog message an SNMP trap is generated as well. Use the interface level command switchport port-security violation command to change the violation mode.

Further Reading Configuring Port-Based Traffic Control





Task 1.4 SW2: interface FastEthernet0/16 spanning-tree portfast spanning-tree bpdufilter enable



2. Frame-Relay Task 2.1 R1: interface Serial0/0 ip address 191.1.125.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 191.1.125.5 105 broadcast frame-relay map ip 191.1.125.2 102 broadcast no frame-relay inverse-arp R2: interface Serial0/0 ip address 191.1.125.2 255.255.255.0 encapsulation frame-relay frame-relay map ip 191.1.125.5 201 frame-relay map ip 191.1.125.1 201 broadcast no frame-relay inverse-arp R5: interface Serial0/0 ip address 191.1.125.5 255.255.255.0 encapsulation frame-relay frame-relay map ip 191.1.125.1 501 broadcast frame-relay map ip 191.1.125.2 501 no frame-relay inverse-arp Task 2.2 R3: interface Serial1/0 ip address 191.1.34.3 255.255.255.0 encapsulation frame-relay frame-relay map ip 191.1.34.3 304 frame-relay map ip 191.1.34.4 304 broadcast no frame-relay inverse-arp R4: interface Serial0/0 ip address 191.1.34.4 255.255.255.0 encapsulation frame-relay frame-relay map ip 191.1.34.3 403 broadcast no frame-relay inverse-arp


Task 2.2 Breakdown Since all traffic sent to a multipoint NBMA circuit requires layer 3 to layer 2 resolution, a device using either a main interface or a multipoint subinterface in Frame Relay cannot send traffic to itself (i.e. cannot ping itself). In order to enable this behavior traffic destined for the local interface must be sent to the other end of the circuit, and then redirected back. This configuration is the same as any other layer 3 to layer 2 resolution in Frame Relay, and can be used to ensure that the layer 2 circuit is up end to end.

Verification R3#show frame-relay map Serial1/0 (up): ip 191.1.34.3 dlci 304(0x130,0x4C00), static, CISCO, status defined, active Serial1/0 (up): ip 191.1.34.4 dlci 304(0x130,0x4C00), static, broadcast, CISCO, status defined, active R3#ping 191.1.34.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 191.1.34.3, timeout is 2 seconds: !!!!! R4#debug ip packet detail IP packet debugging is on (detailed) IP: s=191.1.34.3 (Serial0/0), d=191.1.34.3 (Serial0/0), len 100, redirected packet must be redirected back to R3 ICMP type=8, code=0 ICMP: redirect sent to 191.1.34.3 for dest 191.1.34.3, use gw 191.1.34.3 IP: s=191.1.34.4 (local), d=191.1.34.3 (Serial0/0), len 56, sending ICMP type=5, code=1 Redirect Datagram for the Host ICMP type 5 is redirect



Task 2.3 R6: interface Serial0/0/0 encapsulation frame-relay no frame-relay inverse-arp IP 100 no frame-relay inverse-arp IP 101 no frame-relay inverse-arp IP 201 no frame-relay inverse-arp IP 301 no frame-relay inverse-arp IP 401 Task 2.3 Breakdown Inverse-ARP can be disabled on an interface for all DLCIs using the no frame-relay inverse-arp command or for a particular DLCI by using the no frame-relay inverse-arp ip <DCLI> command.

Verification Rack1R6#debug frame-relay packet Frame Relay packet debugging is on Serial0/0/0(o): dlci 51(0xC31), pkt encaps 0x0300 0x8000 0x0000 0x806 (ARP), datagramsize 34 FR: Sending INARP Request on interface Serial0/0/0 dlci 51 for link 7(IP) broadcast dequeue Serial0/0/0(o):Pkt sent on dlci 51(0xC31), pkt encaps 0x300 0x8000 0x0 0x806 (ARP), datagramsize 34 Serial0/0/0(i): dlci 51(0xC31), pkt encaps 0x0300 0x8000 0x0000 0x806 (ARP), datagramsize 34 Serial0/0/0: frame relay INARP received Rack1R6#show frame-relay map Serial0/0/0 (up): ip 54.1.3.254 dlci 51(0x33,0xC30), dynamic, broadcast,, status defined, active Rack1R6#




3. HDLC/PPP Task 3.1 R1: interface Serial0/1 encapsulation ppp R2: interface Serial0/1 encapsulation ppp R3: interface Serial1/2 encapsulation ppp clockrate 64000 ! interface Serial1/3 encapsulation ppp clockrate 64000 R4: interface Serial0/1 encapsulation ppp ip tcp header-compression ip tcp compression-connections 256 R5: interface Serial0/1 encapsulation ppp ip tcp header-compression ip tcp compression-connections 256 clockrate 64000


Verification Rack1R4#sho ip tcp header-compression TCP/IP header compression statistics: Interface Serial0/1 (compression on, VJ) Rcvd: 0 total, 0 compressed, 0 errors, 0 status msgs 0 dropped, 0 buffer copies, 0 buffer failures Sent: 0 total, 0 compressed, 0 status msgs, 0 not predicted 0 bytes saved, 0 bytes sent Connect: 256 rx slots, 256 tx slots, 0 misses, 0 collisions, 0 negative cache hits, 256 free contexts Rack1R4#telnet 191.1.45.5 Trying 191.1.45.5 ... Open User Access Verification Password: Rack1R5>exit [Connection to 191.1.45.5 closed by foreign host] Rack1R4#sho ip tcp header-compression TCP/IP header compression statistics: Interface Serial0/1 (compression on, VJ) Rcvd: 28 total, 27 compressed, 0 errors, 0 status msgs 0 dropped, 0 buffer copies, 0 buffer failures Sent: 31 total, 30 compressed, 0 status msgs, 0 not predicted 1019 bytes saved, 274 bytes sent 4.71 efficiency improvement factor Connect: 256 rx slots, 256 tx slots, 1 misses, 0 collisions, 0 negative cache hits, 255 free contexts 96% hit ratio, five minute miss rate 0 misses/sec, 0 max Rack1R4#




4. Interior Gateway Routing Task 4.1 R1: router ospf 1 router-id 150.1.1.1 network 191.1.125.1 0.0.0.0 area 0 neighbor 191.1.125.2 neighbor 191.1.125.5 R2: interface Serial0/0 ip ospf priority 0 ! router ospf 1 router-id 150.1.2.2 network 191.1.125.2 0.0.0.0 area 0 R5: interface Serial0/0 ip ospf priority 0 ! router ospf 1 router-id 150.1.5.5 network 191.1.125.5 0.0.0.0 area 0 Task 4.1 Breakdown As the Frame Relay section dictates that R1, R2, and R5 must use the main interface for their hub-and-spoke configuration, the default OSPF network type will be non-broadcast. Additionally since this section dictates that the ip ospf network command cannot be used on any of these devices, the default of non-broadcast must remain. Therefore R1 has been configured to specify its unicast neighbors, R2 and R5, and R2 and R5 have adjusted their OSPF priority value to take themselves out of the DR/BDR election. As R1 is the only device on this segment that has a direct layer 2 connection to all endpoints of the network, it is mandatory that R1 be elected the DR.



Task 4.2 R1: router ospf 1 network 191.1.13.1 0.0.0.0 area 13 R2: router ospf 1 network 191.1.23.2 0.0.0.0 area 23 network 191.1.27.2 0.0.0.0 area 27 R3: router ospf 1 router-id 150.1.3.3 network 191.1.13.3 0.0.0.0 area 13 network 191.1.23.3 0.0.0.0 area 23 R4: router ospf 1 router-id 150.1.4.4 network 191.1.45.4 0.0.0.0 area 45 R5: router ospf 1 network 191.1.5.5 0.0.0.0 area 5 network 191.1.45.5 0.0.0.0 area 45 SW1: ip routing ! router ospf 1 router-id 150.1.7.7 network 191.1.27.7 0.0.0.0 area 27 network 191.1.7.7 0.0.0.0 area 27 network 191.1.77.7 0.0.0.0 area 27 network 191.1.177.7 0.0.0.0 area 27 R1, R2, R3, R4, R5 and SW1: router ospf 1 redistribute connected subnets route-map CONNECTED2OSPF ! route-map CONNECTED2OSPF permit 10 match interface Loopback0 Task 4.2 Breakdown

This task requires that the Loopback 0 interfaces of all devices be advertised into the OSPF domain, but to accomplish this without using the network statement under the OSPF process. Therefore these networks are originated through redistribution. Note that a route-map is called on each of these devices to ensure that the Loopback 0 network is the only interface that is redistributed into the OSPF domain.



Task 4.3 R2: router ospf 1 a rea 23 virtual-link 150.1.3.3

R3: interface Serial1/0 ip ospf network point-to-point ! interface Serial0/1 ip ospf cost 9999 ! router ospf 1 area 23 virtual-link 150.1.2.2 area 34 virtual-link 150.1.4.4 network 191.1.34.3 0.0.0.0 area 34 R4: interface Serial0/0 ip ospf network point-to-point ! interface Serial0/1 ip ospf cost 9999 ! router ospf 1 area 34 virtual-link 150.1.3.3 area 45 virtual-link 150.1.5.5 network 191.1.34.4 0.0.0.0 area 34 n etwork 191.1.48.4 0.0.0.0 area 48

SW2: ip routing ! router ospf 1 router-id 150.1.8.8 network 150.1.8.8 0.0.0.0 area 48 network 191.1.48.8 0.0.0.0 area 48 Task 4.3 Breakdown From the above configuration it is evident that multiple OSPF areas are discontiguous from OSPF area 0. Specifically these areas are area 34 between R3 and R4, and area 48 between R4 and SW2. To deal with this issue multiple virtual-links have been created throughout the domain. A virtual-link between R2 and R3 over area 23 connects area 34 with area 0. This virtual-link is then further extended over area 34 between R3 and R4 to connect area 48 to area 0 (virtual-links can be cascaded as in this scenario). An additional virtual-link is configured between R4 and R5 to ensure reachability to the rest of the routing domain when R4 loses its connection to R3 over the Frame Relay cloud.



Next, the stipulation is placed on R3 and R4 that neither of these devices should be elected the DR for their Frame Relay segment. As the default OSPF network type for their interfaces is non-broadcast, which does have a DR/BDR election, this must be modified. In the above output the OSPF network-type has been changed to point-to-point; however the network types point-to-multipoint or point-to-multipoint non-broadcast would have also been acceptable.



Task 4.4 R2: router ospf 1 area 27 nssa no-redistribution no-summary SW1: router ospf 1 area 27 nssa Task 4.4 Breakdown The above task states that SW1 does not require specific reachability information to the rest of the IGP domain, as its only connection out is through R2. As previously demonstrated this can be accomplished by defining the area in question as a type of stub area. The next issue that must be addressed is which type of stub area to configure.

Stub Type Keyword LSAs Default Injected

Stub area x stub 1,2,3,4 YES Totally Stubby area x stub no-summary 1,2, default of 3 YES Not-So-Stub area x nssa 1,2,3,4,7 NO Not-So-Totally-Stubby area x nssa no-summary 1,2, default of 3, 7 YES Recall the previously defined stub areas. The above task states that the only IGP route it should see is a default route generated by R2, the ABR. The only stub area type that does not automatically generate a default route into the area is the not-so-stubby area. However, a default route can be manually generated into the NSSA area by adding the default-originate keyword on to the end of the area [area] nssa statement. Therefore the requirement of a default route alone does not narrow our choices. The keyword for the above ask is that SW1 should not see any other IGP routes except this default. This requirement implies that inter-area or external reachability information should not be injected into area 27. This narrows our choices down to two stub types, the totally stubby area and the not-so-totally-stubby area.

Recall from the previous task that the Loopback 0 interfaces of all routers were injected into the OSPF domain by issuing the redistribute connected command. This implies that redistribution must be allowed into area 27. This furthermore eliminates the stub area type of totally stubby, and leaves us with our last choice of not-so-totally-stubby.

The last two stipulations on this task give us a twist that has not been previously seen. The last two requirements state that SW1 should not see a specific route to R2’s Loopback 0 network. As redistribution is allowed into a not-so-totally-stubby area, this route will be seen by SW1 unless additional


configuration is performed. This prefix can be removed from SW1’s routing table in a variety of ways. These include filtering the route out from the IP routing table with a distribute-list or a route-map, poisoning the distance of the prefix, or stopping the route from coming into the area by disallowing redistribution into the NSSA area on the ABR. The first two options cannot be used, as the requirement specifically denies their usage. Changing the distance of the prefix is a valid solution; however it was not the intended solution for the requirement.

The no-redistribution keyword on the end of the area [area] nssa

statement is specifically designed to deal with the above scenario. When redistribution is performed on an OSPF device, the route is propagated into all areas unless it is manually blocked with a stub definition or filtering. This is also true of the ABR of an NSSA area. When a route is redistributed on the ABR or an NSSA it also becomes an ASBR. This route is therefore propagated into the NSSA area as LSA 7 (N1 or N2 route), and as LSA 5 into all other areas. The no-redistribution keyword allows us to stop this default behavior. Although redistribution into the NSSA is still allowed, routes redistributed into the OSPF domain on the NSSA ABR itself are not propagated into the NSSA area. As in the above case this behavior is advantageous.

Since SW1’s only connection to the rest of the routing domain is through

R2, it does not need specific routing information about other areas. Instead, this information can be replaced by a default route generated by R2. Therefore SW1 does not require the amount of memory to hold the OSPF database as well as the IP routing table as other devices in the OSPF domain. This memory usage is further reduced by disallowing routes redistributed on R2 to go into area 27, as devices in area 27 will already have default reachability through R2.

Further Reading OSPF Not-So-Stubby Area (NSSA): Filtering in NSSA


http://www.cisco.com/warp/public/104/nssa.html



Task 4.5 R1: interface Serial0/0 ip ospf message-digest-key 1 md5 CISCO ! interface Serial0/1 ip ospf authentication-key CCIE ! router ospf 1 area 0 authentication message-digest area 13 authentication R2: interface FastEthernet0/0 ip ospf authentication-key CCIE ! interface Serial0/0 ip ospf message-digest-key 1 md5 CISCO ! interface Serial0/1 ip ospf authentication-key CCIE ! router ospf 1 area 0 authentication message-digest area 23 authentication area 23 virtual-link 150.1.3.3 authentication message-digest area 23 virtual-link 150.1.3.3 message-digest-key 1 md5 CISCO area 27 authentication R3: interface Serial1/0 ip ospf authentication-key CCIE ! interface Serial1/2 ip ospf authentication-key CCIE ! interface Serial1/3 ip ospf authentication-key CCIE ! router ospf 1 area 0 authentication message-digest area 13 authentication area 23 authentication area 23 virtual-link 150.1.2.2 authentication message-digest area 23 virtual-link 150.1.2.2 message-digest-key 1 md5 CISCO area 34 authentication area 34 virtual-link 150.1.4.4 authentication message-digest area 34 virtual-link 150.1.4.4 message-digest-key 1 md5 CISCO


R4: interface Serial0/0 ip ospf authentication-key CCIE ! interface Ethernet0/1 ip ospf authentication-key CCIE ! interface Serial0/1 ip ospf authentication-key CCIE ! router ospf 1 area 0 authentication message-digest area 34 authentication area 34 virtual-link 150.1.3.3 authentication message-digest area 34 virtual-link 150.1.3.3 message-digest-key 1 md5 CISCO area 45 authentication area 45 virtual-link 150.1.5.5 authentication message-digest area 45 virtual-link 150.1.5.5 message-digest-key 1 md5 CISCO area 48 authentication R5: interface Serial0/0 ip ospf message-digest-key 1 md5 CISCO ip ospf priority 0 ! interface Serial0/1 ip ospf authentication-key CCIE ! router ospf 1 area 0 authentication message-digest area 45 authentication area 45 virtual-link 150.1.4.4 authentication message-digest area 45 virtual-link 150.1.4.4 message-digest-key 1 md5 CISCO SW1: interface FastEthernet0/2 ip ospf authentication-key CCIE ! router ospf 1 area 27 authentication SW2: interface FastEthernet0/4 ip ospf authentication-key CCIE ! router ospf 1 area 48 authentication

Previous Reference OSPF Authentication: Lab 3 Task 4.5



Task 4.6 R3: router ospf 1 default-information originate always route-map CONDITION ! ip prefix-list BB2 seq 5 permit 192.10.1.0/24 ! ip prefix-list BB3 seq 5 permit 204.12.1.0/24 ! route-map CONDITION permit 10 match ip address prefix-list BB2 ! route-map CONDITION permit 20 match ip address prefix-list BB3 Task 4.6 Breakdown The above task dictates that R3 should originate a default route into the OSPF domain. However, a stipulation is placed on its generation of this default. This default should only be generated if its connections to either BB2 or BB3 are up. This type of stipulation is known as conditional advertisement. To enable the conditional advertisement of a default route in OSPF a route-map is added onto the default-information originate statement. If the route-map indicated is true, a default route is originated. If the route-map is false, a default route is not originated. In the above example the route-map CONDITION specifies that either the prefix 192.10.1.0/24 or 204.12.1.0/24 must exist in the IP routing table. If this condition is true, the default route is originated.

Pitfall When the default-information originate statement has a conditional route-map attached to it, the condition must be met in order to originate a default regardless of whether the always keyword is included. If the above route-map CONDITION is not met no default will be generated even if the always keyword is added.




Task 4.7 R3: router rip version 2 redistribute ospf 1 metric 1 network 204.12.1.0 distance 255 204.12.1.254 0.0.0.0 1 no auto-summary ! access-list 1 permit 1.0.0.0 254.255.255.255 R6: router rip version 2 network 150.1.0.0 network 204.12.1.0 redistribute connected metric 1 route-map CONNECTED2RIP no auto-summary ! route-map CONNECTED2RIP permit 10 match interface Loopback0 Task 4.7 Breakdown The above task states that routes with an odd number in the first octet should not be accepted from BB3 via RIP. The first step in accomplishing this task is to match the prefixes in question through an access-list. In the above output access-list 1 has been used to match routes with an odd number in the first octet (least significant bit must be a zero). Next, the access-list can be applied in a number of ways. The above list could be applied as a distribute-list. A distribute-list is used to filter prefixes either sent or received from a specific neighbor, interface, or routing protocol. The list can also be matched in an offset list. An offset list is used to modify the metric of prefixes as they are sent or received. By offsetting the metric of these routes received from BB3 to an infinite metric (16), they will be filtered out of the routing table. Both of the aforementioned methods are prohibited by the task. Lastly the access-list can be matched in a distance statement. By altering the administrative distance of these routes to infinite (255), they will be removed from the IP routing table. This is the method used in the above code output. The distance 255 204.12.1.254 0.0.0.0 1 statement means that prefixes learned from the neighbor 204.12.1.254 that are matched in access-list 1 will have their distances changed to 255.


Task 4.8 R3: router ospf 1 redistribute rip subnets route-map RIP2OSPF ! router rip redistribute connected metric 1 route-map CONNECTED2RIP redistribute ospf 1 metric 1 ! ip prefix-list R6_LOOPBACK0 seq 5 permit 150.1.6.0/24 ! route-map CONNECTED2RIP permit 10 match interface Ethernet0/0 Loopback0 Serial1/2 Serial1/3 Serial1/0 ! route-map RIP2OSPF permit 10 match ip address prefix-list R6_LOOPBACK0 Task 4.8 Breakdown While worded in a rather elusive manner, the above task simply means that RIP should be redistributed into OSPF, but when OSPF is redistributed into RIP the only prefix that should be allowed is R6’s Loopback 0 network. This is accomplished by matching R6’s loopback in a prefix-list, then matching the prefix-list in a route-map, and using this route-map to filter the redistribution of RIP into OSPF.

Pitfall R3’s Loopback 0 interface has been advertised into the OSPF domain through redistribution. Although OSPF is redistributed into RIP, this does not imply that R3’s Loopback 0 interface is redistributed into RIP. Indirect redistribution between two protocols cannot be accomplished on the same local devices. For example, suppose that protocol A is redistributed into protocol B. Protocol B is then redistributed into protocol C. This does not imply that protocol A was redistributed into protocol C. Instead, protocol A must be manually redistributed into protocol C to achieve the desired effect. This can be seen in the above output since R3’s Loopback 0 network is redistributed as connected into the RIP domain.




Task 4.9 R6: interface serial0/0/0 ip access-group EIGRP_FROM_BB1_ONLY in ! router eigrp 10 eigrp router-id 150.1.6.6 network 54.1.6.6 0.0.0.0 no auto-summary ! ip access-list extended EIGRP_FROM_BB1_ONLY permit eigrp host 54.1.6.254 any deny eigrp any any permit ip any any Task 4.10 R4: interface Tunnel0 ip address 191.1.46.4 255.255.255.0 tunnel source Loopback0 tunnel destination 150.1.6.6 tunnel checksum ! router eigrp 10 eigrp router-id 150.1.4.4 network 191.1.4.4 0.0.0.0 network 191.1.46.4 0.0.0.0 no auto-summary R6: interface Tunnel0 ip address 191.1.46.6 255.255.255.0 tunnel source Loopback0 tunnel destination 150.1.4.4 tunnel checksum ! router eigrp 10 network 191.1.46.6 0.0.0.0 Task 4.10 Breakdown A virtual private network is defined as private network traffic being passed over a public network infrastructure. A VPN does not necessarily imply encryption. Although it is typically thought that VPNs use encryption, even IPSec VPNs do not necessarily use encryption. Types of VPNs may include Frame Relay PVCs, ATM PVCs, IPSec VPNs, GRE tunnels, and MPLS VPNs.


In the above scenario a VPN is created between R4 and R6/BB1 by using a GRE tunnel over the rest of the routing domain. From the perspective of devices in the transit path, all traffic sent over this VPN is simply IP traffic being passed between the tunnel source and tunnel destination. The first step in creating a GRE tunnel is to issue the interface tunnel [num] global configuration command, where num is a locally significant interface number. Tunnel interfaces default to Generic Route Encapsulation (GRE); however this may by adjusted by issuing the tunnel mode [mode] interface level command. Next, specify the source and destination IP addresses that the tunnel will use for control traffic. From the perspective of devices in the transit path, these addresses are the source and final destination of the GRE traffic. This is accomplished by issuing the tunnel source [address] and tunnel destination [address] interface level commands.

Pitfall The most common problem seen with using GRE tunnels is an error in route recursion. This error occurs when the outgoing interface for the route to the tunnel destination is the tunnel interface itself. This results in an infinite route recursion, which is eventually detected and causes the tunnel to be disabled. In order to avoid this scenario, ensure that the route to the tunnel destination is either filtered or poisoned as it is sent or received out the tunnel interface. Troubleshooting the "%TUN-5-RECURDOWN" Error Message and Flapping EIGRP/OSPF/BGP Neighbors Over a GRE Tunnel

As GRE is not a reliable transport protocol, an additional checksum has been added in the above configuration to ensure reliability. Packets received without the proper checksum are dropped. Therefore it is assumed that the application itself will perform retransmission when an acknowledgement is not received. Although this will only be the case if the underlying protocol sent over the tunnel is reliable (TCP for example), it will reduce the unnecessary forwarding of packets that would eventually be dropped by the destination regardless.


http://www.cisco.com/warp/public/105/gre_flap.html

http://www.cisco.com/warp/public/105/gre_flap.html



5. Exterior Gateway Routing Task 5.1 R3: router bgp 200 bgp router-id 150.1.3.3 neighbor 192.10.1.254 remote-as 254 neighbor 192.10.1.254 password CISCO neighbor 204.12.1.6 remote-as 100 R4: router bgp 100 no synchronization bgp router-id 150.1.4.4 neighbor 191.1.46.6 remote-as 100 R6: router bgp 100 no synchronization bgp router-id 150.1.6.6 neighbor 54.1.6.254 remote-as 54 neighbor 191.1.46.4 remote-as 100 neighbor 204.12.1.3 remote-as 200 neighbor 204.12.1.254 remote-as 54 Task 5.1 Breakdown By creating the BGP peering session between R4 and R6 based on the IP addresses of their tunnel interfaces, all traffic destined for BGP learned networks will be forced to traverse the GRE tunnel. This method may be used as a workaround for device in the transit path not running BGP, as seen in this scenario. However, it is not a requirement for devices throughout the network to have IP reachability to BGP learned networks. GRE tunneling as a BGP workaround will be explored further in later lab scenarios.



Task 5.2 R6: router bgp 100 neighbor 54.1.6.254 route-map SET_WEIGHT in ! route-map SET_WEIGHT permit 10 set weight 100 Task 5.2 Breakdown Recall the four common attributes used to affect the BGP best path selection, and how they are applied:



MED Outbound Inbound As a general rule, weight and local-preference are used to affect how traffic leaves the autonomous system, while AS-Path and MED are used to affect how traffic enters the AS. The above task requires that all traffic leaving towards AS 54 to exit to BB1. Therefore as prefixes are learned from AS 54, either the weight or local-preference attribute should be modified to obtain the desired effect. As this task specifically states that local-preference should not be used, it is evident that the weight should be modified instead. Prefixes with a higher weight value are preferred. The default weight value for all prefixes is 0, with the exception of locally originated prefixes which receive a weight of 32768 (half of maximum). Therefore, to prefer the exit point to BB1, the only configuration step necessary is to change the weight of prefixes received from BB1 to any number greater than zero. In the above code output this has been done in a route-map, however weight can also be modified directly on the neighbor by issuing the neighbor [address] weight [weight] BGP process subcommand.



Task 5.3 R6: router bgp 100 neighbor 204.12.1.254 route-map FROM_BB3 in ! route-map SET_WEIGHT permit 10 match ip address prefix-list SLASH_20_AND_UNDER ! route-map FROM_BB3 permit 10 match ip address prefix-list SLASH_20_AND_UNDER ! ip prefix-list SLASH_20_AND_UNDER seq 5 permit 0.0.0.0/0 le 20 Task 5.3 Breakdown Unlike the IP access-list, which was designed to match traffic, the IP prefix-list was designed specifically with network reachability information in mind. Prefix-lists are used to match on prefix (network) and prefix-length (subnet mask) pairs. The prefix-list has dual syntax meanings. The syntax is straightforward once you understand what it means; unfortunately the prefix-list is very sparsely documented. Normal prefix-list syntax is as follows:

ip prefix-list [name] [permit | deny] [prefix]/[len]

Where name is any name or number, prefix is the exact routing prefix (network), and len is the exact prefix-length (subnet mask). Take the following examples:

ip prefix-list LIST permit 1.2.3.0/24 The above is an exact match for the network 1.2.3.0 with the exact subnet mask of 255.255.255.0. This list does not match 1.2.0.0/24, nor does it match 1.2.3.4/32, nor anything in between.

ip prefix-list LIST permit 0.0.0.0/0

The above is an exact match for the network 0.0.0.0 with the exact subnet mask of 0.0.0.0. This is used to match a default route.



Typical confusion about the prefix-list comes into play when the keywords "GE" (greater than or equal to) and "LE" (less than or equal to) are added to the prefix-list. This is due to the fact that the "len" value changes meaning when the GE or LE keywords are used. This alternate syntax is as follows:

ip prefix-list [name] [permit | deny] [prefix]/[len] ge [min_length] le [max_length]

Where name is any name or number, prefix is the routing prefix to be checked against, len is the amount of bits starting from the most significant (left most) to check, min_length is the minimum subnet mask value, and max_length is the maximum subnet mask value. When using the GE and LE values, the following condition must be satisfied:

len < GE <= LE

The above syntax, while confusing at first, simply means that a range of addresses will be matched based on the prefix and the subnet mask range. Take the following examples:

ip prefix-list LIST permit 1.2.3.0/24 le 32

The above syntax means that the first 24 bits of the prefix 1.2.3.0 must match. Additionally, the subnet mask must be less than or equal to 32.

ip prefix-list LIST permit 0.0.0.0/0 le 32

The above syntax means that zero bits of the prefix must match. Additionally, the subnet mask must be less than or equal to 32. Since all networks have a subnet mask less than or equal to 32, and no bits of the prefix are matched, this statement equates to an explicit permit any.

ip prefix-list LIST permit 10.0.0.0/8 ge 21 le 29

The above syntax means that the first 8 bits of the prefix 10.0.0.0 must match. Additionally, the subnet mask is between 21 and 29 inclusive.


The above task states that prefixes with a subnet mask greater than /20 should not be accepted from AS 54. Therefore, zero bits of the actual prefix need to be checked. Instead, it must only be true that the subnet mask is less than or equal to /20. The syntax for this list is therefore as follows:

ip prefix-list SLASH_20_AND_UNDER seq 5 permit 0.0.0.0/0 le 20

Note A prefix-list cannot be used to match on arbitrary bit patterns like an access-list can. Prefix-lists cannot be used to check if a number is even or odd, nor check if a number is divisible by 15, etc... Bit checking in a prefix-list is sequential, and must start with the most significant (leftmost) bit.

Task 5.4 R3: router bgp 200 redistribute static ! ip route 150.1.0.0 255.255.240.0 Null0 ip route 191.1.0.0 255.255.0.0 Null0 Task 5.4 Breakdown There are four (previously three) ways to originate prefixes in BGP. The first is to use the network statement. Secondly, a route may be originated through the redistribute statement. Next, the aggregate-address command can originate a summary route based on more specific routes in the BGP table. A new method of BGP route generation is the inject-map, and will be covered in later scenarios. By creating two static routes that point to Null0 and redistributing them into BGP, traffic that reaches R3 which is destined for a subset of these networks will only be forwarded if there is a more specific subnet installed in the IP routing table. Many protocols automatically generate a summary route to Null0 when aggregation is performed. This behavior is the desired behavior, and would rarely be modified for any practical reason.



Task 5.5 R6: router bgp 100 bgp dampening route-map DAMPENING ! ip prefix-list AS54_CUSTOMERS seq 5 permit 112.0.0.0/8 ip prefix-list AS54_CUSTOMERS seq 10 permit 113.0.0.0/8 ! route-map DAMPENING permit 10 match ip address prefix-list AS54_CUSTOMERS set dampening 15 750 2000 60 Quick Note

Default values. Route-map requires values to be set.

Task 5.5 Breakdown BGP route flap dampening (damping) is the process of suppressing consistently unstable routes from being used or advertised to BGP neighbors. Dampening is (and must be) used to minimize the amount of route recalculation performed in the global BGP table as a whole. To understand dampening, the following terms must first be defined: Penalty: Every time a route flaps, a penalty value of 1000 is added to the

current penalty. All prefixes start with a penalty of zero. Half-life: Configurable time it takes the penalty value to reduce by half. Defaults

to 15 minutes. Suppress Limit: Threshold at which a route is suppressed if the penalty

exceeds. Defaults to 2000. Reuse Limit: Threshold at which a suppressed route is unsuppressed if the

penalty drops below. Defaults to 750. Max Suppress: Maximum time a route can be suppressed if it has been

stable. Defaults to four times the half-life value.

Each time a route flaps (leaves the BGP table and reappears) it is assigned a penalty of 1000. As soon as this occurs, the penalty of the route starts to decay based on the half-life timer. As the penalty increases, as does the rate of decay. For example, after a single flap, it will take 15 minutes for a prefix to reduce its penalty to 500.



Once the penalty of a prefix exceeds the suppress limit, the prefix is suppressed. A suppressed prefix cannot be used locally or advertised to any BGP peer. Once the penalty decay has resulted in the penalty decreasing below the reuse limit, the prefix is unsuppressed.

Lastly, the max-suppress timer dictates the maximum amount of time a

prefix can be suppressed if it has been stable. This value is useful if a number of flaps have occurred in a short period of time, after which the route has been stable.

To enable BGP route flap dampening, simply enter the command bgp

dampening under the BGP process.

Standard RIPE Routing-WG Recommendations for Coordinated Route-flap Damping Parameters

Documentation CD BGP Command Reference: bgp dampening




http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fiprrp_r/bgp_r/1rfbgp1.htm



6. IP Multicast Task 6.1 R1: ip multicast-routing ! interface Serial0/0 ip pim dense-mode ! interface Serial0/1 ip pim dense-mode R2: ip multicast-routing ! interface Ethernet0/0 ip pim dense-mode ! interface Serial0/1 ip pim dense-mode R3: ip multicast-routing ! interface Ethernet0/0 ip pim dense-mode ! interface Ethernet0/1 ip pim dense-mode ! interface Serial1/2 ip pim dense-mode ! interface Serial1/3 ip pim dense-mode R5: ip multicast-routing ! interface Ethernet0/0 ip pim dense-mode ! interface Serial0/0 ip pim dense-mode SW1: ip multicast-routing ! interface FastEthernet0/2 ip pim dense-mode ! interface Vlan7 ip pim dense-mode


Task 6.1 Breakdown This is a basic multicast configuration. This section only requires that multicast routing be enabled globally and PIM dense mode be configured under each interface in the table. Task 6.2 R1: interface Serial0/0 ip pim neighbor-filter 1 ! access-list 1 deny 191.1.125.5 access-list 1 permit any R5: interface Ethernet0/0 ip pim dense-mode ip igmp helper-address 191.1.125.1 Task 6.2 Breakdown This configuration is called multicast stub routing. With multicast stub routing a stub router will not be allowed to become a PIM neighbor. This is accomplished by using the ip pim neighbor-filter interface command. The ip pim neighbor-filter command takes an access-list as an option. The access-list should deny the IP addresses of the neighboring multicast devices that should not become PIM neighbors and permit all other IP addresses. Another option could be to use the reverse logic and permit only the IP addresses that are allowed to become PIM neighbors. Since R5 will not form a PIM neighbor relationship, R5 will need to proxy for multicast clients connected to its Ethernet0/0 interface by forwarding their IGMP host reports and IGMP leave messages to R1.

Further Reading Stub IP Multicast Example


http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmulti.htm#1003543


Task 6.3 R3: interface Ethernet0/1 ip igmp version 1 Task 6.3 Breakdown The default IGMP version is 2. The Cisco IOS supports IGMP versions 1, 2, and 3. To change the IGMP version, the ip igmp version interface command is needed. The basic difference between IGMP version 1 and IGMP version 2 is that IGMP version 2 incorporated an IGMP leave message to allow a host to notify the multicast router that it does not want to receive traffic for a particular multicast group. In IGMP version 1 there is not an explicit IGMP leave message. When a host wants to leave a multicast group, it just stops sending IGMP reports for the IGMP queries sent by the multicast router.

IGMP Message Types There are three types of IGMP message that relate to multicast router and multicast client interaction. 1 = Host Membership Query 2 = Host Membership Report 3 = Leave Group The IGMP query messages are sent by multicast enabled routers every 60 seconds (default) to all-hosts (224.0.0.1) in order to discover which multicast groups have hosts that would like to receive a particular multicast group. The IGMP report messages are sent by hosts in response to IGMP queries reporting each multicast group to which they belong. The IGMP leave messages are sent by hosts to notify a multicast router that it no longer wants to receive traffic for a particular multicast group. RFC 2236 (Internet Group Management Protocol, Version 2) states that the leave message is only mandatory if the host responded to the last IGMP query message for the group it wanted to leave. If the host was not the last to respond, RFC 2236 states that it is not mandatory to send an IGMP leave message.




Task 6.4 SW1: interface Vlan7 ip igmp static-group 225.25.25.25

Note Technically in IGMP version 2 there is a forth message type, a version 1 membership report. This message is used for backward compatibility with IGMP version 1 clients.

Previous Reference ip igmp static-group command: Lab 3 Task 6.2



7. IPv6 Task 7.1 R1: ipv6 unicast-routing ! interface Serial0/0 ipv6 address 2001:CC1E:1:125::1/64 frame-relay map ipv6 2001:CC1E:1:125::2 102 broadcast frame-relay map ipv6 2001:CC1E:1:125::5 105 broadcast R2: ipv6 unicast-routing ! interface Serial0/0 ipv6 address 2001:CC1E:1:125::2/64 frame-relay map ipv6 2001:CC1E:1:125::1 201 broadcast frame-relay map ipv6 2001:CC1E:1:125::5 201 ! interface Serial0/1 ipv6 address 2001:CC1E:1:23::2/64 R3: ipv6 unicast-routing ! interface Ethernet0/0 ipv6 address 2001:192:10:1::/64 eui-64 ! interface Serial1/3 ipv6 address 2001:CC1E:1:23::3/64 R5: ipv6 unicast-routing ! interface Ethernet0/0 ipv6 address 2001:CC1E:1:5::5/64 ! interface Serial0/0 ipv6 address 2001:CC1E:1:125::5/64 frame-relay map ipv6 2001:CC1E:1:125::1 501 broadcast frame-relay map ipv6 2001:CC1E:1:125::2 501 Task 7.2 R1: interface Serial0/0 ipv6 rip RIPng enable frame-relay map ipv6 FE80::207:EBFF:FEDE:5621 105 frame-relay map ipv6 FE80::204:27FF:FEB5:2FA0 102 ! ipv6 router rip RIPng n o split-horizon



R2: interface Serial0/0 ipv6 rip RIPng enable frame-relay map ipv6 FE80::207:EBFF:FEDE:5621 201 frame-relay map ipv6 FE80::204:27FF:FEB5:2F60 201 ! interface Serial0/1 ipv6 rip RIPng enable ! ipv6 router rip RIPng R3: interface Ethernet0/0 ipv6 rip RIPng enable ! interface Serial1/3 ipv6 rip RIPng enable ipv6 rip RIPng default-information only ! ipv6 router rip RIPng R5: interface Ethernet0/0 ipv6 rip RIPng enable ! interface Serial0/0 ipv6 rip RIPng enable frame-relay map ipv6 FE80::204:27FF:FEB5:2F60 501 frame-relay map ipv6 FE80::204:27FF:FEB5:2FA0 501 ! ipv6 router rip RIPng Task 7.2 Breakdown

The above exercise demonstrates how to originate an IPv6 default route via RIPng with the interface level command ipv6 rip [process-id] default-information [originate | only]. When the only keyword is used all other more specific networks are suppressed in RIPng advertisements on the interface. As seen in the below output an IPv6 default route is expressed as the prefix ::/0.



Rack1R2#show ipv6 route rip IPv6 Routing Table - 11 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 R ::/0 [120/2] via FE80::250:73FF:FE1C:7761, Serial0/1 R 2001:CC1E:1:5::/64 [120/3] via FE80::204:27FF:FEB5:2F60, Serial0/0 Task 7.3 R3: interface Ethernet0/0 ipv6 rip RIPng summary-address 2001:CC1E:1::/48 Task 7.3 Breakdown RIPng summarization, similar to RIP summarization in IPv4, is configured at the interface level and uses the command ipv6 rip [process-id] summary-address [prefix]. Once the summary prefix has been configured the more specific prefixes will be suppressed, as seen in the output below.


Rack1R3#conf t Enter configuration commands, one per line. End with CNTL/Z. Rack1R3(config)#interface Ethernet0/0 Rack1R3(config-if)#ipv6 rip RIPng summary-address 2001:CC1E:1::/48 Rack1R3(config-if)#end Rack1R3# BB2#show ipv6 route rip IPv6 Routing Table - 13 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 R 2001:CC1E:1::/48 [120/2] via FE80::250:73FF:FE5C:A1C0, Ethernet0/0




8. QoS Task 8.1 R3 and R4: class-map match-all RTP match protocol rtp ! policy-map QOS class RTP priority percent 25 R3: interface Serial1/0 service-policy output QOS R4: interface Serial0/0 service-policy output QOS Task 8.1 Breakdown This type of priority queueing is known as Low Latency Queueing. Unlike the legacy priority-list, LLQ can prioritize traffic, while at the same time ensure that other traffic gets serviced. In the legacy priority queue, all packets in the upper queues are serviced before lower queues are checked for packets. This can, and does, result in packets in the lower queues being starved of bandwidth. The LLQ prevents this case by setting a maximum bandwidth threshold for which traffic will be prioritized.

The above MQC configuration dictates that RTP packets will always be dequeued first out the Frame Relay connections of R3 and R4 up to 25% of the bandwidth. When RTP traffic that exceeds 25% of the output queue, the excess of 25% does not receive low latency. In the case that there is congestion on the link, traffic in excess of this 25% may be dropped.

Prior to IOS 12.2, the bandwidth percent and the priority percent commands were relative reservations based on what the available bandwidth of the interface. In newer IOS releases, these reservations are absolute reservations. The difference between these reservations can be seen as follows.

Caution The bandwidth value that this percentage reservation is based off of is the configured bandwidth value of the interface. For a practical implementation, the bandwidth value of the interface should be modified to reflect the provisioned rate of the layer 2 circuit.



The available bandwidth of an interface is calculated as:

Available_Bandwidth = (Configured_Bandwidth * max-reserved-bandwidth/100) - (LLQ - RTP - RSVP)

Where Configured_Bandwidth is the bandwidth value of the interface as

specified by the bandwidth command, and where max-reserved-bandwidth is the configured max-reserved-bandwidth of the interface (defaults to 75%). This reservable value is put into place to ensure that necessary network traffic (layer 2 keepalives, layer 3 routing) gets the service that it requires.

To see what the available bandwidth of an interface is issue the show

queue [interface] command: Rack1R1#show queue e0/0 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/1/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 7500 kilobits/sec From the above output it is evident that this interface is a 10Mbps Ethernet interface (default configured bandwidth value of 10Mbps). The available bandwidth is 7500Kbps, which is 75% of the default interface bandwidth of 10Mbps. This above router is running 12.2(15)T5, in which a reservation is always absolute. The following demonstrates so: ip cef ! class-map match-all FTP match protocol ftp ! policy-map QOS class FTP bandwidth percent 25 ! interface Ethernet0/0 service-policy output QOS Rack1R1#sh queue e0/0 | in Available Available Bandwidth 5000 kilobits/sec Notice from the above output that the available bandwidth value just decreased by 2.5Mbps, or 25% of 10Mbps. This is an absolute reservation. This has the same effect as if the bandwidth percent 25 statement actually said bandwidth 2500, as seen as follows:



policy-map QOS class FTP bandwidth 2500 Rack1R1#sh queue e0/0 | in Available Available Bandwidth 5000 kilobits/sec Notice the same output. This is still an absolute reservation. In older IOS releases, percentage reservations were relative, as follows: Rack1R1#sh queue e0/0 | in Available Available Bandwidth 7500 kilobits/sec Here we see the same Ethernet interface with no prior reservations. As max-reserved-bandwidth is 75 by default there is an available bandwidth of 7.5Mbps. Now apply the same configuration as before: class-map match-all FTP match protocol ftp ! policy-map QOS class FTP bandwidth percent 50 ! interface FastEthernet0/0 service-policy output QOS ! R1#sh queue e0/0 | in Available Available Bandwidth 7500 kilobits/sec Although 50% of the bandwidth on this interface is reserved for FTP, it is a relative reservation of what is available. Since the available bandwidth on the interface is 7.5Mbps, FTP is effectively guaranteed a minimum of 3.75Mbps (50% of 75% of 10Mbps). In order to actually reserve 5Mbps for FTP in this case there are three options. 1. Set 'max-reserved-bandwidth' to 100 interface Ethernet0/0 max-reserved-bandwidth 100 service-policy output QOS R1#sh queue e0/0 | in Available Available Bandwidth 10000 kilobits/sec Since 10Mbps is now available on the interface, FTP is guaranteed 5Mbps (50% of 10Mbps). This method should be used with caution, as reserving too much of the output queue of an interface can result in delay or loss of necessary layer 2 and layer 3 network control packets.



2. Do an absolute bandwidth [kbps] reservation class-map match-all FTP match protocol ftp ! policy-map QOS class FTP bandwidth 5000 ! interface Ethernet0/0 service-policy output QOS R1#sh queue fa0/0 | in Available Available Bandwidth 2500 kilobits/sec bandwidth [kbps] and priority [kbps] are always absolute reservations regardless of the IOS version, and are not based on the available bandwidth of the interface. It is evident that after configuring bandwidth 5000 under the FTP class, only 2.5Mbps is now available on the interface. 3. Change the configured bandwidth value on the interface While not very practical, the bandwidth value on the interface can be adjusted so that the following would be true: Interface_bandwidth = configured_bandwidth * max-reserved-bandwidth/100 Configured_bandwidth = interface_bandwidth * 100/max-reserved-bandwidth interface FastEthernet0/0 bandwidth 133334 service-policy output QOS R1#sh queue fa0/0 | in Available Available Bandwidth 100000 kilobits/sec While the third option is a roundabout solution, the point of the exercise is to show that the available bandwidth is based on the configured bandwidth keyword, and not a function of the physical interface.



Task 8.2 R3 and R4: class-map match-all NOT_HTTP match not protocol http ! policy-map QOS class NOT_HTTP class class-default fair-queue random-detect Task 8.2 Breakdown The above exercise is designed to show the usage of the match not keyword in the class-map, and to illustrate how random early detection works within the modular quality of service. To configure WRED in the MQC, one of two conditions must be met. There must either be a bandwidth reservation made within a class, or the default-class must be running weighted fair queuing. As the above task states that HTTP traffic should not be reserved any bandwidth, the only way to accomplish this task is to remove all non-HTTP traffic from the default class, and run WRED on the default class in which only HTTP remains. Task 8.3 SW2: mls qos ! interface FastEthernet0/16 wrr-queue cos-map 1 0 1 2 3 4 6 7 wrr-queue cos-map 4 5 priority-queue out



9. Security Task 9.1 SW1 and SW2: vlan access-map NO_DEC-SPANNING 10 action drop match mac address DEC-SPANNING ! vlan access-map NO_DEC-SPANNING 20 action forward ! vlan filter NO_DEC-SPANNING vlan-list 363 ! mac access-list extended DEC-SPANNING permit any any dec-spanning Task 9.1 Breakdown

The basics of VLAN access-lists (VACLs) were covered in lab 5. This section is requiring a VACL to be configured within VLAN 363 that filters off any DECnet spanning tree BPDUs.

Ensure that there is an additional vlan access-map that forwards all other

traffic or at least all other DECnet traffic. If this is not added, all DECnet traffic would be denied. The logic of the VACL is that as long as you do not deny a certain protocol or all protocols, it will not be affected by the VACL. Task 9.1 R2: username CLI password 0 CISCO username TELNET password 0 CISCO username TELNET autocommand access-enable timeout 5 ! interface Serial0/0 ip access-group DYNAMIC in ! interface Serial0/1 ip access-group DYNAMIC in ! ip access-list extended DYNAMIC dynamic PERMIT_TELNET permit tcp any any eq telnet deny tcp any host 191.1.27.7 eq telnet deny tcp any host 191.1.7.7 eq telnet deny tcp any host 191.1.77.7 eq telnet deny tcp any host 191.1.177.7 eq telnet deny tcp any host 150.1.7.7 eq telnet permit ip any any


10. System Management Task 10.1 R3: access-list 25 permit 191.1.7.100 access-list 25 permit 191.1.77.100 access-list 50 permit 191.1.7.100 ! snmp-server community CISCORO RO 25 snmp-server community CISCORW RW 50 snmp-server system-shutdown snmp-server host 191.1.7.100 CISCOTRAP snmp-server host 191.1.77.100 CISCOTRAP snmp-server enable traps Task 10.1 Breakdown Although this section does not explicitly state that SNMP traps need to be enabled, the wording of the task indicated that not only should the community be set to CISCOTRAP but SNMP traps should be enabled. To enable SNMP traps the snmp-server enable traps command was configured.

To allow a device to be reloaded via SNMP, the snmp-server system-

shutdown will need to be configured. Technically the device will not be shutdown, but will be reloaded. The network management station will also need RW access via SNMP to reload the device. This is why the first network management station was given RW access in this section. Task 10.2 R1: logging 191.1.7.100 ! rmon event 1 log rmon alarm 1 ifEntry.10.3 60 delta rising-threshold 80000 1 falling-threshold 40000 1 R3: logging 191.1.7.100 ! rmon event 1 log owner config rmon alarm 1 ifEntry.10.5 60 delta rising-threshold 840000 1 falling-threshold 40000 1



Task 10.2 Breakdown

The key to this section is the reference to the word ‘average’. RMON can monitor two values, absolute or delta. The absolute value is the value since the last reload of a device or resetting (if available) of the value’s counters. Delta on the other hand is monitoring the rate of change in a value.

Certain values like CPU utilization are normally monitored for the absolute value and not the delta value. It would be more useful to know when the one minute CPU utilization rises above 75% (absolute), than it is when the one minute CPU utilization changes 10% in value (delta). Input or output interface values (i.e. input octets) normally are monitored for their rate of change. This is done by taking the delta value. In this section a log message will be generated whenever the delta values rise above 80000 or falls below 40000.

Previous Reference RMON: Lab 1 Task 9.1



11. IP Services Task 11.1 R4: cdp source-interface Loopback0 cdp timer 5 cdp holdtime 15 SW1: cdp timer 5 cdp holdtime 15 Task 11.1 Breakdown Cisco Discovery Protocol is a media and protocol independent layer 2 protocol. CDP advertisements include useful information such as device type, device name, and local and remote interface connections. CDP can also be used to transport routing information when used with On Demand Routing (ODR). CDP is enabled on all Cisco devices by default, and can be globally disabled with the no cdp run command, or disabled on a per interface basis with the no cdp enable interface level command. CDP advertisement intervals are controlled by the global configuration commands cdp timer and cdp holdtime. The cdp source-interface command can be used to modify which IP address information is included with CDP advertisements.

Further Reading Configuring Cisco Discovery Protocol on Cisco Routers and Switches Running Cisco IOS


http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a00801aa000.shtml

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a00801aa000.shtml



Task 11.2 SW2: service udp-small-servers ! interface FastEthernet0/4 ip access-group 100 in ! access-list 100 deny udp any any eq discard access-list 100 deny udp any any eq 19 access-list 100 permit ip any any Task 11.2 Breakdown TCP and UDP small servers are simple diagnostic utilities for testing network reachability. These services include echo, chargen, discard, and daytime for TCP, and echo, chargen, and discard for UDP. Typically these services are disabled in order to avoid various security vulnerabilities that are associated with them. To enable these services issue the service tcp-small-servers or service udp-small-servers global configuration commands.

Further Reading TCP and UDP Small Servers


1. Catalyst 3550 Task 1.1 SW1: vtp domain IE vtp password CISCO vlan 4,5,6,7,10,18,38,42,57,263 ! interface FastEthernet0/1 switchport access vlan 18 ! interface FastEthernet0/2 switchport access vlan 263 ! interface FastEthernet0/3 switchport access vlan 38 ! interface FastEthernet0/4 switchport access vlan 42 ! interface FastEthernet0/5 switchport access vlan 5 ! interface FastEthernet0/6 switchport access vlan 6 ! interface FastEthernet0/14 switchport access vlan 38 ! interface FastEthernet0/15 switchport access vlan 18 ! interface FastEthernet0/24 switchport access vlan 263 ! interface Vlan7 ip address 163.1.7.7 255.255.255.0 ! interface Vlan57 ip address 163.1.57.7 255.255.255.0 SW2: vtp domain IE vtp password CISCO ! interface FastEthernet0/4 switchport access vlan 4 ! interface FastEthernet0/5 switchport access vlan 57 ! interface FastEthernet0/6 switchport access vlan 263 ! interface FastEthernet0/14

no switchport ip address 163.1.38.8 255.255.255.0 ! interface FastEthernet0/15 no switchport ip address 163.1.18.8 255.255.255.0 ! interface FastEthernet0/24 switchport access vlan 42 Task 1.2 SW1: interface FastEthernet0/13 switchport trunk encapsulation dot1q SW2: interface FastEthernet0/13 switchport trunk encapsulation dot1q

Task 1.3 SW1: mls qos ! interface FastEthernet0/7 switchport access vlan 7 switchport voice vlan 10 switchport priority extend cos 1 mls qos trust cos ! interface FastEthernet0/8 switchport access vlan 7 switchport voice vlan 10 switchport priority extend cos 1 mls qos trust cos Task 1.3 Breakdown Since ports on the 3550 series switch default to dynamic mode, installing Cisco IP Phones into the network is a very straightforward process. When a phone is connected the 3550 will automatically form an 802.1q trunk to the phone. Traffic destined for the PC attached to the IP phone will be carried in the access VLAN. Voice traffic destined for the phone itself will be carried in the voice VLAN. These VLANs are defined with the switchport access vlan and switchport voice vlan command respectively.

Pitfall Unlike a data VLAN a voice VLAN will not automatically be created when it is assigned. Be sure to create the voice VLAN in the VLAN database before assigning it.

Since VoIP traffic requires special treatment throughout the network, a carefully designed end-to-end QoS policy is required in a network utilizing voice over data. In order to facilitate in creating this policy, QoS must extend down to the access layer. Traffic marking at the access layer is supported through layer 2 Class of Service (CoS) values. By default the 3550 does not process CoS values, and rewrites all frames with a CoS value of zero. To enable the processing of CoS, QoS must be enabled globally by issuing the mls qos global configuration command. One QoS is enabled you must decide how the switch will process frames that already have a CoS value set. Typically you would want to set the switch to trust the CoS value that is coming from the IP phone. This is accomplished by issuing the mls qos trust cos interface level command.

In order to prevent the device attached to the phone from getting better service throughout the network and interfering with VoIP traffic, the Cisco IP phone by default will re-tag all frames received from its extension with a CoS value of zero. To tag them with a different value or to leave them untagged, use the interface level command switchport priority extend [ trust | cos (value) ]. In the above case all traffic received from the PC attached to the IP phone is remarked with a CoS value of one.

Further Reading Configuring Voice VLAN

http://www.cisco.com/en/US/products/hw/switches/ps646/products_configuration_guide_chapter09186a0080115951.html

2. Frame-Relay Task 2.1 R3: interface Serial1/0 ip address 163.1.35.3 255.255.255.0 encapsulation frame-relay frame-relay map ip 163.1.35.5 305 broadcast no frame-relay inverse-arp R4: interface Serial0/0 ip address 163.1.54.4 255.255.255.0 encapsulation frame-relay frame-relay map ip 163.1.54.5 405 broadcast no frame-relay inverse-arp R5: interface Serial0/0 encapsulation frame-relay no frame-relay inverse-arp ! interface Serial0/0.35 point-to-point ip address 163.1.35.5 255.255.255.0 frame-relay interface-dlci 503 ! interface Serial0/0.54 point-to-point ip address 163.1.54.5 255.255.255.0 frame-relay interface-dlci 504 Task 2.1 Breakdown Although this task can be solved by using the solution above it is important to remember that that there are four methods to deal with layer 3 to layer 2 mappings. The first and simplest is to use inverse-ARP. The second is to use the frame-relay map command. The third is to use point-to-point subinterfaces. Finally the last option would be to use PPP over Frame Relay (PPPoFR). By using PPP over Frame Relay you now are running IP over PPP over Frame Relay. So as far as IP is concerned there isn’t any layer 3 to layer 2 mapping needed since it’s now running over PPP.

Task 2.2 R4: interface Serial0/0 frame-relay interface-dlci 405 class DLCI_405 ! map-class frame-relay PVC_405 frame-relay end-to-end keepalive mode reply R5: interface Serial0/0.54 point-to-point frame-relay interface-dlci 504 class DLCI_504 ! map-class frame-relay PVC_504 frame-relay end-to-end keepalive mode request Task 2.2 Breakdown Since Frame Relay uses virtual circuits a failure in the Frame Relay cloud may not be detected by all switches in the transit path. Therefore, it is the end node’s (i.e. router’s) responsibility to check the availability of the circuit by using Frame Relay end-to-end keepalives (EEK). To enable EEK, use the map-class subcommand frame-relay end-to-end keepalive mode [mode], where mode is request, reply, bidirectional, or passive-reply.

Verification R4#show frame-relay end-to-end keepalive End-to-end Keepalive Statistics for Interface Serial0/0 (Frame Relay DTE) DLCI = 405, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK UP) status RECEIVE SIDE STATISTICS Send Sequence Number: 254, Receive Sequence Number: 254 Configured Event Window: 3, Configured Error Threshold: 2 Total Observed Events: 6, Total Observed Errors: 3 Monitored Events: 1, Monitored Errors: 0 Successive Successes: 1, End-to-end VC Status: UP status

Further Reading Frame Relay End-to-End Keepalives

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/frkeep.htm

Task 2.3 R1: interface Serial0/0 ip address 163.1.12.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 163.1.12.2 102 no frame-relay inverse-arp R2: interface Serial0/0 ip address 163.1.12.2 255.255.255.0 encapsulation frame-relay frame-relay map ip 163.1.12.1 201 no frame-relay inverse-arp Task 2.4 R6: interface Serial0/0/0 encapsulation frame-relay frame-relay interface-dlci 201 ppp Virtual-Template1 no frame-relay inverse-arp ! interface Virtual-Template1 ip address 54.1.7.6 255.255.255.0 ppp chap hostname ROUTER6 ppp chap password 0 CISCO Task 2.4 Breakdown Since Frame Relay does not natively support features such as authentication, link quality monitoring, and reliable transmission, it is sometimes advantageous to run PPP over Frame Relay in order to enable these features.

Pitfall

When using a virtual-template interface it’s important to understand that a virtual-access interface is cloned from the virtual-template interface when the PPP connection comes up. The virtual-template interface itself will always be in the down/down state.

Rack1R6#show ip interface brief | in 54.1.7.6 Virtual-Access1 54.1.7.6 YES TFTP up up Virtual-Template1 54.1.7.6 YES manual down down Rack1R6#


3. HDLC/PPP Task 3.1 R1: username Rack1R3 password 0 CISCO ! interface Serial0/1 encapsulation ppp ppp authentication pap ppp pap sent-username Rack1R1 password 0 CISCO R3: username Rack1R1 password 0 CISCO ! interface Serial1/2 encapsulation ppp clockrate 64000 ppp authentication pap ppp pap sent-username Rack1R3 password 0 CISCO R4: username Rack1R5 password 0 CISCO ! interface Serial0/1 encapsulation ppp ppp authentication pap ppp pap sent-username Rack1R4 password 0 CISCO R5: username Rack1R4 password 0 CISCO ! interface Serial0/1 encapsulation ppp clockrate 64000 ppp authentication pap ppp pap sent-username Rack1R5 password 0 CISCO



4. Interior Gateway Routing Task 4.1 R1: router rip version 2 passive-interface default no passive-interface FastEthernet0/0 network 163.1.0.0 no auto-summary R2: router rip version 2 network 204.12.1.0 no auto-summary R3: router rip version 2 passive-interface default no passive-interface Ethernet0/0 network 163.1.0.0 no auto-summary R4: router rip version 2 passive-interface default no passive-interface Serial0/1 network 163.1.0.0 no auto-summary R5: router rip version 2 passive-interface default no passive-interface Serial0/1 network 163.1.0.0 no auto-summary R6: router rip version 2 network 54.0.0.0 network 150.1.0.0 network 163.1.0.0 network 204.12.1.0 no auto-summary



SW2: router rip version 2 network 150.1.0.0 network 163.1.0.0 no auto-summary Task 4.2 R2: router rip distribute-list gateway R6 in ! ip prefix-list R6 seq 5 permit 204.12.1.6/32 R6: router rip distribute-list gateway R2 in distribute-list prefix RIP out GigabitEthernet0/1 distribute-list 1 in Virtual-Template1 ! ip prefix-list R2 seq 5 permit 204.12.1.2/32 ! ip prefix-list RIP seq 5 permit 163.1.6.0/24 ip prefix-list RIP seq 10 permit 150.1.6.0/24 ! access-list 1 deny any Task 4.2 Breakdown An alternate application of the IP prefix-list is in the distribute-list gateway statement. This allows prefixes to be filtered as they are received based on the source of the update. In the above task this syntax is used on both R2 and R6 to only accept RIP updates from each other. This allows updates learned from both BB1 and BB3 to be denied, but still allows updates to be received from R2 and R6 respectively.

Documentation CD RIP Commands: distribute-list in


http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_r/iprprt2/1rdrip.htm


Task 4.3 R5: router rip no passive-interface Ethernet0/1 default-information originate distribute-list prefix DEFAULT out Ethernet0/1 no auto-summary ! ip prefix-list DEFAULT seq 5 permit 0.0.0.0/0 SW1: router rip version 2 network 150.1.0.0 network 163.1.0.0 no auto-summary Task 4.3 Breakdown To advertise a default route into RIP simply issue the default-information originate routing process subcommand. In the above case a prefix-list matching a default route is used to filter R5’s advertisement to SW1. By only permitting 0.0.0.0/0, SW1 only has default reachability to the rest of the IGP domain.



Task 4.4 R4: key chain RIP key 1 key-string CISCO ! interface Ethernet0/0 ip rip authentication mode md5 ip rip authentication key-chain RIP ip summary-address rip 163.1.0.0 255.255.192.0 ip summary-address rip 150.1.0.0 255.255.240.0 ! router rip version 2 network 192.10.1.0 no passive-interface Ethernet0/0 distribute-list prefix RIP_SUMMARY out Ethernet0/0 distribute-list 1 in Ethernet0/0 no auto-summary ! ip prefix-list RIP_SUMMARY seq 5 permit 163.1.0.0/18 ip prefix-list RIP_SUMMARY seq 10 permit 150.1.0.0/20 ! access-list 1 deny any Task 4.4 Breakdown The first step in properly summarizing the internal address space is to list all known addresses sequentially. The addresses used in this network are as follows:

163.1.4.0/24 163.1.5.0/24 163.1.6.0/24 163.1.7.0/24 163.1.12.0/24 163.1.13.0/24 163.1.18.0/24 163.1.35.0/24 163.1.38.0/24 163.1.45.0/24 163.1.54.0/24 163.1.57.0/24

From this list it is evident that the first two octets are the same. Therefore the minimum summary that will encompass all of this address space is 163.1.0.0/16. To determine what the maximum summarization is that will encompass all of the above address space, next write out all addresses in the third octet in binary:



128 64 32 16 8 4 2 1 4 0 0 0 0 0 1 0 0 5 0 0 0 0 0 1 0 1 6 0 0 0 0 0 1 1 0 7 0 0 0 0 0 1 1 1 12 0 0 0 0 1 1 0 0 13 0 0 0 0 1 1 0 1 18 0 0 0 1 0 0 1 0 35 0 0 1 0 0 0 1 1 38 0 0 1 0 0 1 1 0 45 0 0 1 0 1 1 0 1 54 0 0 1 1 0 1 1 0 57 0 0 1 1 0 1 0 1

Next, count how many bit positions are consistent. From the above output it is evident that two places, the 128 and 64 bits, are consistent. Add these two bits onto the previous summarization of /16, and are resulting summary is /18. Therefore the final summary for this task is 163.1.0.0/16

Task 4.5 R3: interface Serial1/0 ip ospf network point-to-point ! router ospf 1 router-id 150.1.3.3 network 163.1.35.3 0.0.0.0 area 1 R4: interface Serial0/0 ip ospf network point-to-point ! router ospf 1 router-id 150.1.4.4 network 163.1.54.4 0.0.0.0 area 0 R5: router ospf 1 router-id 150.1.5.5 network 163.1.35.5 0.0.0.0 area 1 network 163.1.54.5 0.0.0.0 area 0



Task 4.6 R4: router ospf 1 network 150.1.4.4 0.0.0.0 area 0 R5: router ospf 1 area 0 range 150.1.4.0 255.255.254.0 network 150.1.5.5 0.0.0.0 area 0 Task 4.7 R1: interface Serial0/1 ip ospf network non-broadcast ! router ospf 1 router-id 150.1.1.1 area 1 virtual-link 150.1.5.5 network 163.1.12.1 0.0.0.0 area 2 network 163.1.13.1 0.0.0.0 area 1 neighbor 163.1.13.3 neighbor 163.1.12.2 R2: interface Serial0/0 ip ospf priority 0 ! router ospf 1 router-id 150.1.2.2 network 163.1.12.2 0.0.0.0 area 2 R3: interface Serial1/2 ip ospf network non-broadcast ip ospf priority 0 ! router ospf 1 router-id 150.1.3.3 network 163.1.13.3 0.0.0.0 area 1 R5: router ospf 1 area 1 virtual-link 150.1.1.1



Task 4.8 R1, R2 and R3: router ospf 1 redistribute connected subnets route-map CONNECTED_TO_OSPF ! route-map CONNECTED_TO_OSPF permit 10 match interface Loopback0 Task 4.8 Breakdown Although a route-map permitting only the loopback interface to be redistributed into OSPF isn’t explicitly asked for in this task, it is good practice to only redistribute the interface the task is asking for. Technically putting the loopback interface into another routing protocol and then redistributing that protocol into OSPF would also work, redistributing the connected interface into OSPF directly is a better solution.



Task 4.9 R1: router ospf 1 redistribute rip subnets route-map RIP_TO_OSPF ! router rip redistribute connected metric 1 redistribute ospf 1 metric 1 route-map OSPF_TO_RIP ! route-map OSPF_TO_RIP deny 10 match tag 120 ! route-map OSPF_TO_RIP permit 20 set tag 110 ! route-map RIP_TO_OSPF deny 10 match tag 110 ! route-map RIP_TO_OSPF permit 20 set tag 120 R2: router ospf 1 redistribute rip subnets ! router rip redistribute ospf 1 metric 1 R3: router ospf 1 redistribute rip subnets route-map RIP_TO_OSPF ! router rip redistribute connected metric 1 redistribute ospf 1 metric 1 route-map OSPF_TO_RIP ! route-map OSPF_TO_RIP deny 10 match tag 120 ! route-map OSPF_TO_RIP permit 20 set tag 110 ! route-map RIP_TO_OSPF deny 10 match tag 110 ! route-map RIP_TO_OSPF permit 20 set tag 120



R4: router ospf 1 redistribute rip subnets ! router rip redistribute ospf 1 metric 1 distance 109 163.1.45.5 0.0.0.0 RIP_ROUTES ! ip access-list standard RIP_ROUTES permit 150.1.7.0 permit 163.1.57.0 permit 163.1.7.0 R5: router rip distance 109 0.0.0.0 255.255.255.255 RIP_ROUTES ! ip access-list standard RIP_ROUTES permit 150.1.7.0 permit 163.1.7.0 permit 163.1.4.0 permit 192.10.1.0 SW2: router rip offset-list 1 in 2 FastEthernet0/14 offset-list 0 in 1 FastEthernet0/15 ! access-list 1 permit 150.1.6.0 access-list 1 permit 150.1.2.0 access-list 1 permit 150.1.1.0 access-list 1 permit 163.1.6.0 access-list 1 permit 163.1.12.0 access-list 1 permit 204.12.1.0 Task 4.9 Breakdown Previous routing exercises have focused on path selection between two or more different protocols. The above exercise focuses on route selection within a single protocol. This path selection is accomplished by altering routing metrics. The above requirement states that SW2 should use the optimal IGP path for all routes throughout the network. SW2 has two connections to the rest of the routing domain, one through R1 and the other through R3. Behind R1 exists R2 and R6. All other networks will be optimally reached through R3. Since there are many more routes learned from behind R3 than from behind R1, the easiest way to achieve optimal routing is to match the routes learned from behind R1 and prefer the metric for these through R1. This is accomplished in the above solutions by creating a standard access-list which matches these prefixes. Next, the metric of these routes is offset by 2



when they are learned from R3. Next, all other routes learned from R1 are offset by 1. Therefore SW2 will prefer the routes accordingly. 5. Exterior Gateway Routing Task 5.1 R1: router bgp 100 no synchronization bgp router-id 150.1.1.1 neighbor 163.1.12.2 remote-as 100 neighbor 163.1.13.3 remote-as 300 neighbor 163.1.13.3 send-community neighbor 163.1.18.8 remote-as 300 neighbor 163.1.18.8 send-community R2: router bgp 100 no synchronization bgp router-id 150.1.2.2 neighbor 163.1.12.1 remote-as 100 neighbor 163.1.12.1 route-reflector-client neighbor 204.12.1.6 remote-as 100 neighbor 204.12.1.6 route-reflector-client neighbor 204.12.1.254 remote-as 54 R3: router bgp 300 no synchronization bgp router-id 150.1.3.3 neighbor 163.1.13.1 remote-as 100 neighbor 163.1.35.5 remote-as 200 neighbor 163.1.38.8 remote-as 300 neighbor 163.1.38.8 send-community no auto-summary R6: router bgp 100 no synchronization bgp router-id 150.1.6.6 neighbor 54.1.7.254 remote-as 54 neighbor 204.12.1.2 remote-as 100 neighbor 204.12.1.254 remote-as 54 no auto-summary SW1: router bgp 65007 no synchronization bgp router-id 150.1.7.7 bgp confederation identifier 200 bgp confederation peers 65005

neighbor 163.1.57.5 remote-as 65005



Task 5.2 R4: router bgp 65004 no synchronization bgp router-id 150.1.4.4 bgp confederation identifier 200 bgp confederation peers 65005 neighbor 150.1.5.5 remote-as 65005 neighbor 150.1.5.5 ebgp-multihop neighbor 150.1.5.5 update-source Loopback0 neighbor 192.10.1.254 remote-as 254 neighbor 192.10.1.254 password CISCO no auto-summary R5: router bgp 65005 no synchronization bgp router-id 150.1.5.5 bgp confederation identifier 200 bgp confederation peers 65004 65007 neighbor 150.1.4.4 remote-as 65004 neighbor 150.1.4.4 ebgp-multihop neighbor 150.1.4.4 update-source Loopback0 neighbor 163.1.35.3 remote-as 300 neighbor 163.1.57.7 remote-as 65007 no auto-summary SW2: router bgp 300 no synchronization bgp router-id 150.1.8.8 neighbor 163.1.18.1 remote-as 100 neighbor 163.1.38.3 remote-as 300 neighbor 163.1.38.3 send-community Task 5.2 Breakdown BGP confederation is used in large scale BGP implementations in order to reduce the amount of iBGP peering sessions required to transport Network Layer Reachability Information (NLRI) throughout the AS. By subdividing the autonomous system into smaller sub-autonomous systems, the amount of iBGP peering sessions can be dramatically reduced. The first step in defining a confederation is to enable the BGP process by issuing the router bgp [sub-ASN] command. Note that the AS number specified when the process is initiated is the sub-AS number. Next, the bgp confederation identifier [public-AS] command is issued in order to define the public autonomous system number. All routers within the confederation must specify this option. Next, for routers that are on the edge of the sub-autonomous system and are peering with other sub-autonomous



systems, the bgp confederation peers [peer sub-ASs] command is used. Only the sub-ASs that are directly peered with need be listed in this statement. Lastly, BGP neighbors are established as usual. The sub-AS number should be referenced for any peers that are within the confederation. Inter sub-AS peerings exhibit both EBGP and iBGP characteristics. The most notable difference between a normal iBGP peering relationship and an inter sub-AS peering is that iBGP mesh need not be maintained between sub-ASs. However, each sub-AS exhibits normal iBGP behavior within the sub-AS. This means that within each sub-AS there must either be full iBGP mesh or route-reflection. The majority of other attributes between inter sub-AS peers behave as normal iBGP peers. For example, next-hop, local-preference, and MED maintain their values as they are passed between sub-ASs. However, AS-Path information does not.

Confederation sub-AS path information is denoted within parentheses in the AS-path list. However when it comes to best path selection, all sub-ASs within the parentheses count as a single AS.

Further Reading BGP Case Studies: BGP Confederation


http://www.cisco.com/en/US/tech/tk365/tk80/technologies_tech_note09186a00800c95bb.shtml


Task 5.3 R6: router bgp 100 neighbor 54.1.7.254 route-map BB1 in neighbor 204.12.1.254 route-map BB3 in ! ip as-path access-list 1 permit _54$ ! route-map BB1 permit 10 match as-path 1 set local-preference 200 ! route-map BB1 permit 20 ! route-map BB3 permit 10 match as-path 1 ! route-map BB3 permit 20 set local-preference 200 Task 5.3 Breakdown Recall the four common attributes used to affect the BGP best path selection, and how they are applied:



MED Outbound Inbound As a general rule, weight and local-preference are used to affect how traffic leaves the autonomous system, while AS-Path and MED are used to affect how traffic enters the AS. The above task requires that all traffic leaving AS 100 going to prefixes originated in AS 54 exits to BB1, while traffic going to AS 54’s customers exits to BB3. Therefore as prefixes are learned from AS 54, either the weight or local-preference attribute should be modified to obtain the desired effect. However, since the above task states that the configuration should be done only on R6, weight cannot be used. Weight is only local to the router, and is not passed on with BGP updates.



Task 5.4 R6: router bgp neighbor 204.12.1.2 next-hop-self Task 5.4 Breakdown Two conditions must be met before a route can be considered for BGP best-path selection. The synchronization rule must be met, and there must be a route to the next-hop IP address of the prefix in question. When a BGP update is passed on to an EBGP neighbor, the next-hop value of the prefix is updated to the local address used to peer with that neighbor. However, when an update is passed on to an iBGP neighbor, the next-hop value is not updated. In certain cases this may cause a problem. In the above scenario R6 is learning BGP prefixes from BB1. As this is an EBGP peering relationship, the next-hop IP address that R6 sees for these prefixes is the address it uses to peer with BB1, 54.1.7.254. When these routes are propagated on to R2, the next hop value is not updated, as R2 is an iBGP neighbor of R6. However, since R2 does not have an IGP route to the network 54.1.7.0/24, it cannot consider any prefixes learned from BB1 passed on via R6 for the BGP best path selection. In such a case there are two options. The first option is to inject the transit network into the IGP domain of the BGP network. This will allow all iBGP speaking neighbors to do an IGP lookup on the next-hop values of any prefixes learned from the external system. This method may be inefficient for networks with an exorbitant amount of EBGP neighbors, as these transit networks take up unnecessary space in the IGP table. This is due to the fact that traffic is never sent to a transit network, only past it. The second option is to modify the next-hop value as the prefix is advertised into the iBGP domain. This is accomplished by issuing the neighbor [address] next-hop-self BGP process subcommand. This command overrides the default next-hop processing behavior, and modifies the next-hop value to the local address when an EBGP learned prefix is advertised to an iBGP neighbor. This way all internal BGP speaking routers only need to maintain IGP reachability information about the internal network. Specifically in this scenario’s case, when R6 uses the neighbor 204.12.1.2 next-hop-self command, updates learned from BB1 have the next-hop value adjusted to 204.12.1.6 when advertised on to R2, as this is the address that R2 is peering with. Since this network is advertised into the IGP (RIP) domain, R1 can do an IGP lookup on all BGP routes learned from AS 54.



Further Reading BGP Case Studies: BGP Next Hop Attribute

Task 5.5 R6: router bgp 100 no bgp fast-external-fallover neighbor 54.1.7.254 timers 10 30 Task 5.5 Breakdown By default, when a directly connected interface goes down, any EBGP peers which are directly connected on that interface have their BGP session reset. This in turn will cause the router to withdrawn any BGP prefixes learned from that neighbor from all other BGP peers. This behavior may be undesired in certain cases, as in the case that this task describes. To disable this behavior and wait for the dead time to expire before declaring a directly connected EBGP down, use the no bgp fast-external-fallover bgp subcommand. Additionally, the BGP timers have been adjusted for this neighbor by using the neighbor [address] timers [hello] [dead] command.


http://www.cisco.com/en/US/tech/tk365/tk80/technologies_tech_note09186a00800c95bb.shtml


Task 5.6 R1: router bgp 100 aggregate-address 28.119.16.0 255.255.254.0 summary-only aggregate-address 112.0.0.0 248.0.0.0 summary-only Task 5.6 Breakdown By default when configuring aggregation, the aggregate plus all subnets of the aggregate are advertised. By adding the summary-only keyword, only the aggregate is advertised.

Previous Reference BGP Aggregation: Lab 2 Task 5.5



Task 5.7 R1: router bgp 100 neighbor 163.1.13.3 send-community neighbor 163.1.13.3 unsuppress-map UNSUPPRESS_TO_R3 neighbor 163.1.18.8 send-community neighbor 163.1.18.8 unsuppress-map UNSUPPRESS_TO_SW2 ! ip prefix-list UNSUPPRESS_TO_R3 seq 5 permit 28.119.17.0/24 ip prefix-list UNSUPPRESS_TO_R3 seq 10 permit 116.0.0.0/8 ip prefix-list UNSUPPRESS_TO_R3 seq 15 permit 117.0.0.0/8 ip prefix-list UNSUPPRESS_TO_R3 seq 20 permit 118.0.0.0/8 ip prefix-list UNSUPPRESS_TO_R3 seq 25 permit 119.0.0.0/8 ! ip prefix-list UNSUPPRESS_TO_SW2 seq 5 permit 28.119.16.0/24 ip prefix-list UNSUPPRESS_TO_SW2 seq 10 permit 112.0.0.0/8 ip prefix-list UNSUPPRESS_TO_SW2 seq 15 permit 113.0.0.0/8 ip prefix-list UNSUPPRESS_TO_SW2 seq 20 permit 114.0.0.0/8 ip prefix-list UNSUPPRESS_TO_SW2 seq 25 permit 115.0.0.0/8 ! route-map UNSUPPRESS_TO_SW2 permit 10 match ip address prefix-list UNSUPPRESS_TO_SW2 set community no-export ! route-map UNSUPPRESS_TO_R3 permit 10 match ip address prefix-list UNSUPPRESS_TO_R3 set community no-export Task 5.7 Breakdown The above task uses a combination of selective prefix unsuppressing and community manipulation in order to accomplish complex traffic engineering. When a router does a lookup in the IP routing table, it always chooses the route with the longest match to the destination. For example, suppose a packet is received with a destination IP address of 1.2.3.4, and the following routes are in the IP routing table:

0.0.0.0/0 1.0.0.0/8 1.2.0.0/16 1.2.3.0/24

Regardless of metric, administrative distance, or protocol, packets destined for 1.2.3.4 will always use the route 1.2.3.0/24. This is due to the fact that this is the longest match for the prefix in the routing table. By leaking specific longer matches to AS 300, AS 100 is able to affect the return traffic flow. This is due to the fact that routers in AS 300 have to choice but to use the longest match in the IP routing table.



As aggregation with the summary-only keyword has already been configured on R1, AS 300 only has the summary route regarding the prefixes learned from AS 54. Therefore, in order to force AS 300 to make routing decisions based on longer matches in the routing table, the prefixes mentioned in the task must be selectively unsuppressed on a per neighbor basis. Next, the task states that devices beyond AS should not have this specific reachability information. This has been accomplished by setting the community value to no-export as the prefixes are unsuppressed. In this manner AS 100 is able to force AS 300 to route a specific way, while at the same time ensuring upstream neighbors have the minimum amount of reachability information necessary.

Pitfall The above task can lead to problems with the order of operations of the BGP engine. For example, if the community no-export was set using a separate route-map than the unsuppress-map, it would not have been applied. This is due to the fact that the route-map is processed before the unsuppress-map. In that case, the route-map would be setting the community on prefixes that do not exist in the output engine. The subnets do not exist in the output engine until they are unsuppressed in the unsuppress-map. For this reason it is best always to consolidate all attribute setting in a single route-map. Do not mix and match the application of route-maps, unsuppress-maps, attribute-maps, distribute-lists, prefix-lists, or filter-lists to the same neighbor in the same direction.



6. IP Multicast Task 6.1 R4: ip multicast-routing ! interface Ethernet0/1 ip pim dense-mode ! interface Serial0/1 ip pim dense-mode ! ip mroute 0.0.0.0 0.0.0.0 Serial0/1 R5: ip multicast-routing ! interface Ethernet0/0 ip pim dense-mode ! interface Serial0/1 ip pim dense-mode Task 6.1 Breakdown Another option to using a static mroute would be to manipulate the IGP routing protocols so that R4 prefers to route across the Serial over the Frame Relay to reach R5. This will ensure that the RPF check is successful when a static mroute isn’t used.

Further Learning In depth coverage of RPF verification and troubleshooting is covered in the IEATC-RS Class on Demand.



7. IPv6 Task 7.1 R3: ipv6 unicast-routing ! interface Ethernet0/0 ipv6 address FEC0:CC1E:1:38::/64 eui-64 ! interface Serial1/0 ipv6 address FEC0:CC1E:1:35::/64 eui-64 frame-relay map ipv6 FEC0:CC1E:1:35:207:EBFF:FEDE:5621 305 broadcast R4: ipv6 unicast-routing ! interface Ethernet0/0 ipv6 address FEC0:CC1E:1:4::/64 eui-64 ! interface Ethernet0/1 ipv6 address 2001:192:10:1::/64 eui-64 ! interface Serial0/0 ipv6 address FEC0:CC1E:1:54::/64 eui-64 frame-relay map ipv6 FEC0:CC1E:1:54:207:EBFF:FEDE:5621 405 broadcast ! interface Serial0/1 ipv6 address FEC0:CC1E:1:45::/64 eui-64 R5: ipv6 unicast-routing ! interface Serial0/1 ipv6 address FEC0:CC1E:1:45::/64 eui-64 ! interface Serial0/0.54 point-to-point ipv6 address FEC0:CC1E:1:54::/64 eui-64 ipv6 address FEC0:CC1E:1:35::/64 eui-64 Task 7.2 R3: interface Ethernet0/0 ipv6 rip RIPng enable ! interface Serial1/0 ipv6 rip RIPng enable frame-relay map ipv6 FE80::207:EBFF:FEDE:5621 305 ! ipv6 router rip RIPng



R4: interface Ethernet0/0 ipv6 rip RIPng enable ! interface Serial0/0 ipv6 rip RIPng enable frame-relay map ipv6 FE80::207:EBFF:FEDE:5621 405 ! interface Ethernet0/1 ipv6 rip RIPng enable ! interface Serial0/1 ipv6 rip RIPng enable ! ipv6 router rip RIPng R5: interface Serial0/0.35 point-to-point ipv6 rip RIPng enable ! interface Serial0/0.54 point-to-point ipv6 rip RIPng enable ipv6 rip RIPng metric-offset 2 ! interface Serial0/1 ipv6 rip RIPng enable Task 7.3 R4: interface Serial0/0 ipv6 traffic-filter DENY_FROM_VLAN38 in ! interface Serial0/1 ipv6 traffic-filter DENY_FROM_VLAN38 in ! ipv6 access-list DENY_FROM_VLAN38 deny ipv6 FEC0:CC1E:1:38::/64 any permit ipv6 any any

Task 7.3 Breakdown Access-list filtering in IPv6 is configured with the ipv6 access-list [name] command, where name is the access-list identifier. Note that there is no separation between standard access-lists and extended access-lists in IPv6. To apply the access-list to the interface the more intuitive ipv6 traffic-filter command is used. Keep in mind that just like IPv4 access-lists, IPv6 access-lists end in implicit deny.



8. QoS Task 8.1 R4: interface Ethernet0/1 service-policy input MARK_VOIP ! interface Ethernet0/0 service-policy input SET_DSCP_CS1 ! ip access-list extended VOIP permit tcp any any eq 1720 permit udp any any range 16384 32767 ! class-map match-all VOIP match access-group name VOIP ! policy-map MARK_VOIP class VOIP set dscp cs5 class class-default set dscp cs1 policy-map SET_DSCP_CS1 class class-default set dscp cs1 ! R5: interface Ethernet0/0 service-policy input MARK_VOIP ! interface Ethernet0/1 service-policy input SET_DSCP_CS1 ! interface Serial0/0.35 point-to-point service-policy input SET_DSCP_CS1 ! ip access-list extended VOIP permit tcp any any eq 1720 permit udp any any range 16384 32767 ! class-map match-all VOIP match access-group name VOIP ! policy-map MARK_VOIP class VOIP set dscp cs5 class class-default set dscp cs1 policy-map SET_DSCP_CS1 class class-default set dscp cs1



Task 8.2 R3: interface Serial1/0 frame-relay traffic-shaping frame-relay interface-dlci 305 class DLCI_305 ! map-class frame-relay DLCI_305 frame-relay cir 768000 R4: interface Serial0/0 frame-relay traffic-shaping frame-relay interface-dlci 405 class DLCI_405 ! map-class frame-relay DLCI_405 frame-relay cir 768000 frame-relay bc 7680 frame-relay fragment 960 R5: interface Serial0/0 frame-relay traffic-shaping ! interface Serial0/0.35 point-to-point frame-relay interface-dlci 503 class DLCI_503 ! interface Serial0/0.54 point-to-point frame-relay interface-dlci 504 class DLCI_504 ! map-class frame-relay DLCI_504 frame-relay cir 768000 frame-relay bc 7680 frame-relay fragment 960 ! map-class frame-relay DLCI_503 frame-relay cir 768000 Task 8.2 Breakdown Frame Relay fragmentation allows for minimal delay when sending small real time packets across a Frame Relay circuit, such as VoIP. As previously discussed, a router always sends traffic out an interface at the serialization, or clocking, of that interface. Typically this results in periods of traffic bursts, followed by periods of no activity. Traffic shaping attempts to smooth these peaks and valleys out by pacing the output of packets on the interface. However, as the transmit ring (hardware queue) of an interface is always first in first out (FIFO), small real time packets can experience unacceptable delay when they are stuck behind large data packets, even when priority queueing is enabled.



By reducing the maximum packet size that can be sent out the Frame Relay circuit, fragmentation reduces the worst case delay that a real time packet must endure. Typically the fragmentation size is set to match the Bc. This guarantees that the worst case delay a packet will endure is a single Tc interval.

Further Reading Frame Relay Fragmentation for Voice


http://www.cisco.com/warp/public/788/vofr/fr_frag.html


Task 8.3 R4: class-map match-all DSCP_CS5 match dscp cs5 ! policy-map FR_QOS class DSCP_CS5 class class-default set fr-de ! map-class frame-relay DLCI_405 service-policy output FR_QOS R5: class-map match-all DSCP_CS5 match dscp cs5 ! policy-map FR_QOS class DSCP_CS5 class class-default set fr-de ! map-class frame-relay DLCI_504 service-policy output FR_QOS Task 8.3 Breakdown The Frame Relay discard-eligible bit tells the Frame Relay switches in the provider cloud which frames to drop first when congestion occurs. By manually setting the DE bit on non essential traffic, real time traffic such as VoIP is less likely to be dropped in the event of congestion.



Task 8.4 R4: policy-map ETHERNET_QOS class DSCP_CS5 priority 256 policy-map FR_QOS class DSCP_CS5 priority 256 ! interface Ethernet0/1 service-policy output ETHERNET_QOS R5:

policy-map ETHERNET_QOS class DSCP_CS5 priority 256 policy-map FR_QOS class DSCP_CS5 priority 256 ! interface Ethernet0/0 service-policy output ETHERNET_QOS Task 8.4 Breakdown The priority 256 command ensures that all VoIP traffic up to 256Kbps in the output queue is dequeued first. This prioritization ensures the minimum amount of delay for priority packets as they sit in the output queue.

Previous Reference Low Latency Queueing: Lab 6 Task 8.1



9. Security Task 9.1 R4: interface Ethernet0/1 ip access-group NO_FRAGMENTS out ! ip access-list extended NO_FRAGMENTS deny ip any any fragments permit ip any any Task 9.1 Breakdown

Standard RFC 1858: Security Considerations for IP Fragment Filtering

Further Reading Access Control Lists and IP Fragments


http://www.cisco.com/warp/public/105/acl_wp.html



Task 9.2 R4: ip cef ! class-map match-all ROOT_EXPLOIT match protocol http url "*root.exe*" ! policy-map SET_DSCP_CS1 class ROOT_EXPLOIT drop Task 9.2 Breakdown As of IOS 12.2(13)T, the drop command is a new option in the policy-map. As the command implies, any matching traffic is simply dropped. Prior to this option, traffic could be unconditionally dropped using the police keyword with both the conform and exceed actions set to drop.

Further Reading Using Network-Based Application Recognition and ACLs for Blocking the "Code Red" Worm


http://www.cisco.com/warp/public/63/nbar_acl_codered.shtml

http://www.cisco.com/warp/public/63/nbar_acl_codered.shtml


10. System Management Task 10.1 R1 - SW2: logging 163.1.5.100 logging 163.1.6.100 service timestamps log datetime msec R2, R4, and R6: logging facility local3 R1, R3, and R5: logging facility local4 SW1 and SW2: logging facility local5 Task 10.2 R1 - SW2: ntp source Loopback0 ntp server 204.12.1.254



11. IP Services Task 11.1 R6: ip dhcp excluded-address 163.1.6.0 163.1.6.127 ip dhcp excluded-address 163.1.6.130 ip dhcp excluded-address 163.1.6.251 163.1.6.255 ! ip dhcp pool VLAN6_POOL network 163.1.6.0 255.255.255.0 default-router 163.1.6.6 domain-name InternetworkExpert.com Task 11.1 Breakdown In SOHO environments, the DHCP server functionality of IOS can significantly reduce the administrative overhead of maintaining static IP addressing or dedicating another machine to run DHCP. To enable the DHCP server process, first create a DHCP pool by issuing the ip dhcp pool [name] global configuration command. This will bring you to the DHCP server mode. Once inside the DHCP server mode, specify the address pool by issuing the network command. The default gateway is then specified with the default-router option, DNS servers with the dns-server command, and domain-name with the domain-name command. In order to control which portion of the specified network is assigned, exclude address space that should not be leased out by issuing the ip dhcp excluded-address [start] [end] global configuration command.

Further Reading Configuring DHCP


http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c/ipcprt1/1cddhcp.htm


Task 11.2 R3: interface Ethernet0/0 ip address 163.1.38.254 255.255.255.0 secondary Task 11.3 R6: interface GigabitEthernet0/0 ip mobile arp access-group 2 ! router rip redistribute mobile metric 1 ! access-list 2 permit 163.1.5.25 Task 11.3 Breakdown Not to be confused with Mobile IP, Local Area Mobility (LAM) offers a simple way for mobile hosts to roam around the network. When the ip mobile arp command is issued on the interface, the LAM process starts listening for ARP requests received on the interface that are from hosts which are not in the IP subnet of that interface. When these requests are received, the LAM processes knows that the ARP came from a mobile host. This hosts IP address is then installed in the IP routing table as a mobile host route. Additionally, ARP requests are sent to the host at a more frequent interval (minutes instead of hours) in order to ensure that they are still on the segment. The access-group option tells the router which hosts to listen for ARP requests from. By default any host on the segment can be mobile. Note that LAM is not very scalable, as each mobile host requires a host route entry in the IP routing table.

Further Reading Local Area Mobility


http://www.cisco.com/warp/public/cc/pd/iosw/ioft/lam/tech/lamso_wp.htm


1. Catalyst 3550 Task 1.1 SW1: vtp domain CISCOVTP vtp password CISCO vlan 3,4,7,26,45,52,53,67,1001 ! interface FastEthernet0/1 switchport access vlan 1001 ! interface FastEthernet0/2 switchport access vlan 26 ! interface FastEthernet0/3 switchport access vlan 3 ! interface FastEthernet0/4 switchport access vlan 4 ! interface FastEthernet0/5 switchport access vlan 52 ! interface FastEthernet0/6 switchport access vlan 67 ! interface FastEthernet0/9 switchport access vlan 3 ! interface FastEthernet0/10 switchport access vlan 3 ! interface FastEthernet0/11 switchport access vlan 3 ! interface FastEthernet0/24 switchport access vlan 53 ! interface Vlan7 ip address 174.1.7.7 255.255.255.0 ! interface Vlan67 ip address 174.1.67.7 255.255.255.0



SW2: vtp mode client vtp password CISCO ! interface FastEthernet0/3 no switchport ip address 174.1.38.8 255.255.255.0 ! interface FastEthernet0/4 switchport access vlan 45 ! interface FastEthernet0/6 switchport access vlan 26 ! interface FastEthernet0/24 switchport access vlan 52 Task 1.2 R5: interface Ethernet0/1 full-duplex ! interface Ethernet0/1.52 encapsulation dot1Q 52 ip address 192.10.1.5 255.255.255.0 ! interface Ethernet0/1.53 encapsulation dot1Q 53 ip address 204.12.1.5 255.255.255.0 SW1 and SW2: interface FastEthernet0/13 switchport trunk encapsulation isl switchport mode trunk switchport nonegotiate ! interface FastEthernet0/14 switchport trunk encapsulation isl switchport mode trunk switchport nonegotiate ! interface FastEthernet0/15 switchport trunk encapsulation isl switchport mode trunk switchport nonegotiate SW2: interface FastEthernet0/5 switchport trunk encapsulation dot1q switchport mode trunk switchport nonegotiate duplex full



Further Reading

Configuring and Troubleshooting Ethernet 10/100/1000Mb Half/Full Duplex Auto-Negotiation Troubleshooting Cisco Catalyst Switches to NIC Compatibility Issues

Task 1.3 Root Bridge: interface FastEthernet0/14 spanning-tree port-priority 16


http://www.cisco.com/en/US/tech/tk389/tk214/technologies_tech_note09186a0080094781.shtml

http://www.cisco.com/en/US/tech/tk389/tk214/technologies_tech_note09186a0080094781.shtml

http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00800a7af0.shtml

http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00800a7af0.shtml


Task 1.4 SW1: interface FastEthernet0/9 duplex full speed 100 ! interface FastEthernet0/10 duplex full speed 100 ! interface FastEthernet0/11 duplex full speed 100 Task 1.4 Breakdown Errors in speed and duplex negotiation typically result in one side of the link appearing up while the other side appears down, or very low performance on the line. In order to avoid errors in auto negotiation of speed and duplex these values may be hard coded with the interface level commands speed and duplex respectively.



2. Frame-Relay Task 2.1 R1: interface Serial0/0 ip address 174.1.145.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 174.1.145.4 104 broadcast frame-relay map ip 174.1.145.5 105 broadcast no frame-relay inverse-arp R4: interface Serial0/0 ip address 174.1.145.4 255.255.255.0 encapsulation frame-relay frame-relay map ip 174.1.145.1 401 broadcast frame-relay map ip 174.1.145.5 401 no frame-relay inverse-arp R5: interface Serial0/0 ip address 174.1.145.5 255.255.255.0 encapsulation frame-relay frame-relay map ip 174.1.145.1 501 broadcast frame-relay map ip 174.1.145.4 501 no frame-relay inverse-arp



Task 2.2 R2: username Rack1R3 password CISCO ! interface Multilink1 ip address 174.1.23.2 255.255.255.0 ppp multilink multilink-group 1 ! interface Serial0/0 encapsulation frame-relay no frame-relay inverse-arp ! interface Serial0/0.203 point-to-point frame-relay interface-dlci 203 ppp Virtual-Template1 ! interface Serial0/0.213 point-to-point frame-relay interface-dlci 213 ppp Virtual-Template1 ! interface Virtual-Template1 ppp multilink multilink-group 1 ppp authentication chap R3: username Rack1R2 password CISCO ! interface Multilink1 ip address 174.1.23.3 255.255.255.0 ppp multilink multilink-group 1 ! interface Serial1/0 encapsulation frame-relay no frame-relay inverse-arp frame-relay interface-dlci 302 ppp Virtual-Template1 ! interface Serial1/1 encapsulation frame-relay no frame-relay inverse-arp frame-relay interface-dlci 312 ppp Virtual-Template1 ! interface Virtual-Template1 ppp multilink multilink-group 1 ppp authentication chap



Task 2.2 Breakdown Since Frame Relay does not natively support features such as authentication, link quality monitoring, and reliable transmission, it is sometimes advantageous to run PPP over Frame Relay in order to enable these features. A useful feature of PPP that can be used over Frame Relay as well is PPP multilink. This configuration is aptly named Multilink PPP over Frame Relay (MLPoFR).

Note As of IOS release 12.2(8)T Multilink over Frame Relay (FRF.16) is supported on platforms as low as the 2600. Previously this feature was reserved for high end platforms such as the 12000. For more information see Multilink Frame Relay (FRF.16)


http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/ft_mfr.htm


The first step in configuring MLPoFR is to define the multilink interface. This is the interface where all logical configuration such as IP addressing will be placed. Create this interface by issuing the interface multilink [num] global configuration command. Next, multilink should be enabled an a group number defined. This is accomplished by issuing the ppp multilink and multilink-group [num] interface commands. Next, create a virtual-template interface using the interface virtual-template [num] global command. This interface is where the Frame Relay VCs will be bound. This interface should be part of the previously created multilink group, as well as have any authentication options desired.

Lastly, configure Frame Relay on the physical interfaces in question, and bind the respective VCs to the virtual-template interface. This is accomplished by issuing the frame-relay interface-dlci [num] virtual-template [num].

Note PPP over Frame Relay can be configured in the same manner by leaving out the multilink interface and the multilink-group.

Verification Rack1R3#show ppp multilink Multilink1, bundle name is Rack1R2 Bundle up for 00:08:28, 1/255 load Receive buffer limit 24384 bytes, frag timeout 1000 ms 0/0 fragments/bytes in reassembly list 0 lost fragments, 3 reordered 0/0 discarded fragments/bytes, 0 lost received 0x1C received sequence, 0x1A sent sequence Member links: 2 active, 1 inactive (max not set, min not set) Vi3, since 00:08:28 Virtual-Access spawned from Virtual-Template Vi2, since 00:08:27 Virtual-Access spawned from Virtual-Template Vt1 (inactive) Virtual-Template not used, Virtual-Access is

the individual instance of the template



Task 2.3 R6: interface Serial0/0/0 encapsulation frame-relay no frame-relay inverse-arp ip 51 no frame-relay inverse-arp ip 101 no frame-relay inverse-arp ip 201 no frame-relay inverse-arp ip 301 no frame-relay inverse-arp ip 401 Task 2.3 Breakdown For this task we will need to discover all of the DLCIs that are being learned through LMI from the Frame Relay switch. To do this shutdown the interface, enable Frame Relay encapsulation, disable inverse-ARP, and finally bring the interface back up by doing a no shutdown. Finally issue the show frame-relay pvc command and include only the “DLCI” keyword. This will simplify the output. Rack1R6#show run int s0/0/0 Building configuration... Current configuration : 147 bytes ! interface Serial0/0/0 ip address 54.1.2.6 255.255.255.0 encapsulation frame-relay no frame-relay inverse-arp frame-relay lmi-type cisco end Rack1R6#sho fram pvc | include DLCI DLCI = 51, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0 DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0 DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0 DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0 DLCI = 301, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0 DLCI = 401, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0 Rack1R6# Now that the DLCIs have been discovered we can disable inverse-ARP for the unused DLCIs and re-enable it for the whole interface by using the frame-relay inverse-arp command.



3. Interior Gateway Routing Task 3.1 R2: interface Ethernet0/0 ip ospf authentication ip ospf authentication-key CISCO ! router ospf 1 router-id 150.1.2.2 network 150.1.2.2 0.0.0.0 area 0 network 174.1.23.2 0.0.0.0 area 0 network 174.1.26.2 0.0.0.0 area 0 R3: router ospf 1 router-id 150.1.3.3 network 150.1.3.3 0.0.0.0 area 0 network 174.1.23.3 0.0.0.0 area 0 R6: interface FastEthernet1/0/0.26 ip ospf authentication ip ospf authentication-key CISCO ! router ospf 1 router-id 150.1.6.6 network 174.1.26.6 0.0.0.0 area 0 Task 3.1 Breakdown The above task states to authenticate the OSPF adjacency between R2 and R6. Although this task can be accomplished by authenticating all area 0 adjacencies by issuing the area 0 authentication command under the OSPF process, the wording of the question implies that interface authentication between R2 and R6 should be used. To enable interface authentication issue the ip ospf authentication [message-digest] interface level command. To define the authentication key issue the interface level command ip ospf authentication-key [key].



Task 3.2 R3: router ospf 1 area 38 stub network 174.1.38.3 0.0.0.0 area 38 SW2: router ospf 1 router-id 150.1.8.8 area 38 stub network 174.1.38.8 0.0.0.0 area 38 Task 3.2 Breakdown The above task requires that external routing information not be injected into OSPF area 38. However, inter area routing information should be preserved. This task can be accomplished by defining area 38 as either a stub area or a not-so-stubby area (NSSA). Both stub and NSSA areas will block external (LSA 5) OSPF information, but will preserve inter-area (LSA 3 and 4) OSPF information. If an NSSA is used to meet this task ensure to add the default-information statement in order to ensure that SW2 has full reachability to all networks external to the routing domain.



Task 3.3 R6: router ospf 1 network 150.1.6.6 0.0.0.0 area 67 network 174.1.67.6 0.0.0.0 area 67 area 67 range 150.1.6.0 255.255.254.0 SW1: ip routing ! router ospf 1 router-id 150.1.7.7 network 150.1.7.7 0.0.0.0 area 67 network 174.1.67.7 0.0.0.0 area 67 Task 3.3 Breakdown The above task requires networks 150.1.6.0/24 and 150.1.7.0/24 to be summarized without overlapping address space. As previously shown, the first step in summarizing address space is to write the address out in binary. As it is evident that the first 16 bits of the above addresses are the same (150.1), the summary will start in the second octet.

128 64 32 16 8 4 2 1 6 0 0 0 0 0 1 1 0 7 0 0 0 0 0 1 1 1

From the above table it can be seen that the first seven bits of the third octet are also the same. Therefore, the summary for these two networks is 150.1.0.0/(16 + 7) = 150.1.0.0/23, or 150.1.0.0 255.255.254.0. Since the above summary is created as internal OSPF prefixes are moving between areas, the area range syntax is used. The summary-address keyword is only used when external address space (redistributed prefixes) are summarized.

Further Reading OSPF Design Guide: OSPF and Route Summarization




Task 3.4 R1: interface Serial0/0 no ip split-horizon eigrp 1024 ! router eigrp 1024 network 150.1.1.1 0.0.0.0 network 174.1.13.1 0.0.0.0 network 174.1.145.1 0.0.0.0 no auto-summary eigrp router-id 150.1.1.1 R3: router eigrp 1024 network 150.1.3.3 0.0.0.0 network 174.1.13.3 0.0.0.0 no auto-summary eigrp router-id 150.1.3.3 R4: router eigrp 1024 network 150.1.4.4 0.0.0.0 network 174.1.45.4 0.0.0.0 network 174.1.145.4 0.0.0.0 no auto-summary eigrp router-id 150.1.4.4 R5: router eigrp 1024 network 150.1.5.5 0.0.0.0 network 174.1.45.5 0.0.0.0 network 174.1.145.5 0.0.0.0 no auto-summary eigrp router-id 150.1.5.5 Task 3.4 Breakdown The above section illustrates a basic EIGRP configuration. Note that EIGRP split horizon must be disabled on R1’s Serial interface, as this interface connects to both R4 and R5. Therefore when R1 learns a route in this Serial interface from R4, it can be advertised back out the same interface to reach R5. By default EIGRP split-horizon is on, and would result in partial reachability by R4 and R5 to the routing domain.

Further Reading EIGRP: Split Horizon and Poison Reverse


http://www.cisco.com/warp/public/103/eigrp-toc.html


Task 3.5 R5: key chain RIP key 1 key-string CISCO ! interface Ethernet0/0 ip rip authentication mode md5 ip rip authentication key-chain RIP ! router rip version 2 network 192.10.1.0 Task 3.5 Breakdown The above task illustrates a simple RIPv2 configuration with MD5 authentication. First a key chain is defined. Next, the key number 1 is defined with the key-string CISCO. Authentication is enabled on the interface with the ip rip authentication mode md5 command. Lastly, the key chain is applied to the interface with the ip rip authentication key-chain [name] command.

Further Reading Sample Configuration for Authentication in RIPv2


http://www.cisco.com/en/US/tech/tk365/tk554/technologies_configuration_example09186a0080093f1c.shtml


Task 3.6 R3: router eigrp 1024 redistribute ospf 1 metric 10000 10 255 1 1500 ! router ospf 1 redistribute eigrp 1024 subnets R5: router eigrp 1024 redistribute rip metric 10000 10 255 1 1500 ! router rip redistribute eigrp 1024 metric 1



Task 3.7 R1: interface Serial0/0 delay 1 R4: interface Serial0/0 delay 21500 ! interface Ethernet0/1 delay 6000 ! router eigrp 1024 variance 4 R5: interface Serial0/0 delay 1 Task 3.7 Breakdown This task can be easily verified by using the show ip route <any prefix from BB2> command to view the “traffic share count”. Any metric manipulation that achieves the traffic share count of 4 for the Ethernet link and 1 for the Frame Relay link is acceptable. In this solution delay was used. Remember that all tasks are not graded by viewing the router’s configuration and this task would be graded by using the show ip route command.

Further Learning Detailed coverage of how various tasks are graded is covered in the IEW-RS workshop and Mock Lab Class-on-Demand series

Further Reading How Does Unequal Cost Path Load Balancing (Variance) Work in IGRP and EIGRP?


http://www.internetworkexpert.com/


http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009437d.shtml

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009437d.shtml


4. Exterior Gateway Routing Task 4.1 R1: router bgp 65145 bgp router-id 150.1.1.1 no synchronization bgp confederation identifier 100 bgp confederation peers 65038 neighbor 150.1.4.4 remote-as 65145 neighbor 150.1.4.4 update-source Loopback0 neighbor 150.1.5.5 remote-as 65145 neighbor 150.1.5.5 update-source Loopback0 neighbor 174.1.13.3 remote-as 65038 R2: router bgp 65267 no synchronization bgp router-id 150.1.2.2 bgp confederation peers 65038 bgp confederation identifier 100 bgp confederation peers 65038 neighbor 174.1.23.3 remote-as 65038 neighbor 174.1.26.7 remote-as 65267 R3: router bgp 65038 no synchronization bgp router-id 150.1.3.3 bgp confederation identifier 100 bgp confederation peers 65145 65267 neighbor 174.1.13.1 remote-as 65145 neighbor 174.1.23.2 remote-as 65267 neighbor 174.1.38.8 remote-as 65038 R4: router bgp 65145 no synchronization bgp router-id 150.1.4.4 bgp confederation identifier 100 neighbor 150.1.1.1 remote-as 65145 neighbor 150.1.1.1 update-source Loopback0 neighbor 150.1.5.5 remote-as 65145 neighbor 150.1.5.5 update-source Loopback0 R5: router bgp 65145 no synchronization bgp router-id 150.1.5.5 bgp confederation identifier 100 neighbor 150.1.1.1 remote-as 65145 neighbor 150.1.1.1 update-source Loopback0 neighbor 150.1.4.4 remote-as 65145 neighbor 150.1.4.4 update-source Loopback0



R6: router bgp 65267 no synchronization bgp router-id 150.1.6.6 bgp confederation identifier 100 neighbor 54.1.2.254 remote-as 54 neighbor 174.1.26.2 remote-as 65267 neighbor 174.1.26.2 route-reflector-client neighbor 174.1.67.7 remote-as 65267 neighbor 174.1.67.7 route-reflector-client no auto-summary SW1: router bgp 65267 no synchronization bgp router-id 150.1.7.7 bgp confederation identifier 100 neighbor 174.1.67.6 remote-as 65267 SW2: router bgp 65038 no synchronization bgp router-id 150.1.8.8 lobgp confederation identifier 100 neighbor 174.1.38.3 remote-as 65038



Task 4.1 Breakdown The above BGP setup centers on the confederated AS 100. AS 100 has been divided into three sub-autonomous systems, AS 65038, AS 65145, and AS 65267. Recall from Lab 7 Task 4.1 that BGP confederation still requires either full mesh or route reflection between iBGP peers within the sub-AS. Inside sub-AS 65145, full iBGP mesh is maintained. However, within AS 65267, only a partial iBGP mesh is maintained. For this reason R6 has been designated a route-reflector for this sub-AS.

Previous Reference BGP Confederation: Lab 7 Task 4.1



Task 4.2 R5: router bgp 65145 redistribute static neighbor 150.1.4.4 route-map TO_R4 out neighbor 150.1.1.1 route-map TO_R1 out ! ip route 174.1.0.0 255.255.0.0 Null0 ! ip prefix-list AGGREGATE seq 5 permit 174.1.0.0/16 ! route-map TO_R4 deny 10 match ip address prefix-list AGGREGATE ! route-map TO_R4 permit 1000 ! route-map TO_R1 deny 10 match ip address prefix-list AGGREGATE ! route-map TO_R1 permit 1000 R6: router bgp 65267 redistribute static neighbor 174.1.26.2 route-map TO_R2 out neighbor 174.1.67.7 route-map TO_SW1 out ! ip route 174.1.0.0 255.255.0.0 Null0 ! ip prefix-list AGGREGATE seq 5 permit 174.1.0.0/16 ! route-map TO_R2 deny 10 match ip address prefix-list AGGREGATE ! route-map TO_R2 permit 1000 ! route-map TO_SW1 deny 10 match ip address prefix-list AGGREGATE ! route-map TO_SW1 permit 1000

Previous Reference BGP Aggregate Address: Lab 2



Task 4.3 R5: route-map TO_R4 permit 1000 set ip next-hop peer-address ! route-map TO_R1 permit 1000 set ip next-hop peer-address R6: route-map TO_R2 permit 1000 set ip next-hop peer-address ! route-map TO_SW1 permit 1000 set ip next-hop peer-address

Pitfall

When altering the next hop with eBGP ensure that eBGP multihop is enabled when altering the next hop to an IP address that is not directly connected.



Task 4.4 R3: router bgp 65038 network 174.1.3.0 mask 255.255.255.0 R4: router bgp 65145 network 174.1.4.0 mask 255.255.255.0 R5: router bgp 65145 neighbor 204.12.1.254 route-map MED out neighbor 204.12.1.254 send-community ! ip prefix VLAN_4 permit 174.1.4.0/24 ip prefix VLANS_3_&_7 permit 174.1.3.0/24 ip prefix VLANS_3_&_7 permit 174.1.7.0/24 ! route-map MED permit 10 match ip address prefix-list VLAN_4 set metric 20 set community no-export ! route-map MED permit 20 match ip address prefix-list VLANS_3_&_7 set metric 10 set community no-export ! route-map MED permit 30 R6: router bgp 65267 neighbor 54.1.2.254 route-map MED out neighbor 54.1.2.254 send-community ! ip prefix VLAN_4 permit 174.1.4.0/24 ip prefix VLANS_3_&_7 permit 174.1.3.0/24 ip prefix VLANS_3_&_7 permit 174.1.7.0/24 ! route-map MED permit 10 match ip address prefix-list VLAN_4 set metric 10 set community no-export ! route-map MED permit 20 match ip address prefix-list VLANS_3_&_7 set metric 20 set community no-export ! route-map MED permit 30 SW1: router bgp 65267 network 174.1.7.0 mask 255.255.255.0



Task 4.4 Breakdown In order to affect inbound traffic flow, either AS-Path of MED should be modified. MED is only compared (by default) between prefixes learned from the same autonomous system. As AS 100 is dual homed to AS 54, this is an appropriate case to modify the multi-exit discriminator value.

Previous Reference BGP MED: Lab 1



Task 4.5 R1: router bgp 65145 network 174.1.1.0 mask 255.255.255.0 route-map LOCAL_AS neighbor 150.1.5.5 send-community ! route-map LOCAL_AS permit 10 set community local-AS Task 4.5 Breakdown The well known community local-AS is a special case of the community no-export. This community is used to ensure that a prefix is not advertised outside of a sub-AS in a confederation. If this prefix were to have been set to the community no-export, it would have been advertised between AS 65038, AS 65145, and AS 65267.

Previous Reference BGP Communities: Lab 3



5. IP Multicast Task 5.1 R1: ip multicast-routing ! interface FastEthernet0/0 ip pim sparse-dense-mode ! interface Serial0/0 ip pim sparse-dense-mode ! interface Serial0/1 ip pim sparse-dense-mode R2: ip multicast-routing ! interface FastEthernet0/0 ip pim sparse-dense-mode ! interface Multilink1 ip pim sparse-dense-mode R3: ip multicast-routing ! interface Ethernet0/0 ip pim sparse-dense-mode ! interface Multilink1 ip pim sparse-dense-mode ! interface Serial1/2 ip pim sparse-dense-mode R4: ip multicast-routing ! interface Ethernet0/0 ip pim sparse-dense-mode ! interface Ethernet0/1 ip pim sparse-dense-mode ! interface Serial1/0 ip pim sparse-dense-mode



Task 5.2 R1: interface Loopback0 ip pim sparse-dense-mode ! ip pim send-rp-announce Loopback0 scope 16 group-list EVEN interval 5 ! ip access-list standard EVEN permit 224.0.0.0 0.0.0.255 permit 226.0.0.0 0.0.0.255 permit 228.0.0.0 0.0.0.255 permit 230.0.0.0 0.0.0.255 permit 232.0.0.0 0.0.0.255 permit 234.0.0.0 0.0.0.255 permit 236.0.0.0 0.0.0.255 permit 238.0.0.0 0.0.0.255 R2: interface Loopback0 ip pim sparse-dense-mode ! ip pim send-rp-announce Loopback0 scope 16 group-list ODD interval 5 ! ip access-list standard ODD permit 225.0.0.0 0.0.0.255 permit 227.0.0.0 0.0.0.255 permit 229.0.0.0 0.0.0.255 permit 231.0.0.0 0.0.0.255 permit 233.0.0.0 0.0.0.255 permit 235.0.0.0 0.0.0.255 permit 237.0.0.0 0.0.0.255 permit 239.0.0.0 0.0.0.255 R3: interface Loopback0 ip pim sparse-dense-mode ! ip pim send-rp-discovery Loopback0 scope 16 ! ip pim rp-announce-filter rp-list R2_RP group-list R2_GROUPS ip pim rp-announce-filter rp-list R1_RP group-list R1_GROUPS ! ip access-list standard R1_GROUPS permit 224.0.0.0 0.0.0.255 permit 226.0.0.0 0.0.0.255 permit 228.0.0.0 0.0.0.255 permit 230.0.0.0 0.0.0.255 permit 232.0.0.0 0.0.0.255 permit 234.0.0.0 0.0.0.255 permit 236.0.0.0 0.0.0.255 permit 238.0.0.0 0.0.0.255 ! ip access-list standard R1_RP permit 150.1.1.1 !



ip access-list standard R2_GROUPS permit 225.0.0.0 0.0.0.255 permit 227.0.0.0 0.0.0.255 permit 229.0.0.0 0.0.0.255 permit 231.0.0.0 0.0.0.255 permit 233.0.0.0 0.0.0.255 permit 235.0.0.0 0.0.0.255 permit 237.0.0.0 0.0.0.255 permit 239.0.0.0 0.0.0.255 ! ip access-list standard R2_RP permit 150.1.2.2 Task 5.3 R1,R2,R3,R4 and R5: ip pim spt-threshold 128 Task 5.4 R1: interface Serial0/0 ip pim nbma-mode

Previous Reference PIM NMBA Mode: Lab 2

Further Learning PIM NBMA Mode is covered in detail in the IEATC-RS Class-on-Demand




Task 5.5 R1: interface FastEthernet0/0 ip directed-broadcast ! interface Serial0/1 ip multicast helper-map 239.39.39.39 174.1.1.255 100 ! access-list 100 permit udp any any eq 3434 ! ip forward-protocol udp 3434 R2: interface FastEthernet0/0 ip multicast helper-map broadcast 239.39.39.39 100 ! access-list 100 permit udp any any eq 3434 ! ip forward-protocol udp 3434 Task 5.5 Breakdown The ip multicast helper-map is used to translate UDP broadcast packets into multicast packets, or translate UDP multicast packets into broadcast packets. This type of configuration is usually required when legacy applications (typically stock ticker applications) only send out traffic to the local IP broadcast address 255.255.255.255. In order to transport this traffic from one portion of the network to the other, the only other options would be to translate the broadcast packets to unicast packets using the ip helper-address command, or to bridge IP traffic between various network segments. Neither of these two solutions scale. Therefore broadcast to multicast conversion can take advantage of an already in place multicast transit network (typical of trading environment), and drop the packets off at the desination as either a multicast, or reconvert the traffic back to broadcast. In order to convert a UDP broadcast to a multicast for transit, and then back to a broadcast for final delivery, as in this scenario, the helper-map must be configured on both the ingress device and egress device for the traffic flow.

Note Although the first hop device is the ingress (entry) point and the last hop device is the egress (exit) point, the helper map is configured on the incoming interface of both devices.



The above scenario describes the case where the legacy application is located on VLAN 26 attached to R2. This application is sending broadcast traffic (255.255.255.255) to UDP port 3434. The destination of this traffic is on VLAN 1001 attached to R1. Therefore the ingress point will be R2, while the egress point is R1. The incoming interfaces of both of these devices are E0/0 on R2 and S0/1 on R1 (R2 incoming from the source and R1 incoming from the IP cloud). The syntax for broadcast to multicast conversion is: ip multicast helper-map broadcast [group] [acl] The syntax for multicast to broadcast conversion is: ip multicast helper-map [group] [directed_broadcast] [acl] Where group is the multicast group address to translate to, acl is the access list which matches the udp port or ports to listen for, and directed_broadcast is the IP directed broadcast address of the final destination interface.

Note In order for incoming traffic to hit the multicast helper-map it must be processed switched. In order to process switch traffic on a per port basis use the ip forward-protocol udp [port] command. In this specific scenario port 3434 must be matched on both R1 and R2.

Finally, in order to transmit the multicast to broadcast conversion, the target interface must support directed broadcast transmissions. To enable the transmission of these directed broadcast packets issue the ip directed-broadcast interface level command.



6. IPv6 Task 6.1 R1 and R5: ipv6 unicast-routing R1: interface FastEthernet0/0 ipv6 address FEC0:CC1E:1:1::/64 eui-64 ! interface Serial0/0 ipv6 address 2001:CC1E:1:1515::/64 eui-64 frame-relay map ipv6 2001:CC1E:1:1515:207:EBFF:FEDE:5621 105 broadcast R5: interface Ethernet0/1.52 ipv6 address 2001:192:10:1::/64 eui-64 ipv6 rip RIPng enable ! interface Serial0/0 ipv6 address 2001:CC1E:1:1515::/64 eui-64 frame-relay map ipv6 2001:CC1E:1:1515:204:27FF:FEB5:2F60 501 broadcast ! ipv6 router rip RIPng Task 6.2 R1: interface FastEthernet0/0 ipv6 ospf 1 area 0 ! interface Serial0/0 ipv6 ospf neighbor 2001:CC1E:1:1515:207:EBFF:FEDE:5621 ipv6 ospf 1 area 0 frame-relay map ipv6 FE80::207:EBFF:FEDE:5621 105 ! ipv6 router ospf 1 R5: interface Serial0/0 ipv6 ospf priority 0 ipv6 ospf 1 area 0 frame-relay map ipv6 FE80::204:27FF:FEB5:2F60 501 ! ipv6 router ospf 1



Task 6.3 R5: ipv6 route ::/0 Null0 ! ipv6 router ospf 1 default-information originate Task 6.4 R5: ipv6 router rip RIPng redistribute ospf 1 metric 1



7. QoS Task 7.1 R1, R4, and R5: interface Serial0/0 frame-relay traffic-shaping frame-relay class FRTS ! map-class frame-relay FRTS frame-relay cir 128000 frame-relay bc 16000

Previous Reference Frame Relay Traffic Shaping: Lab 1

Task 7.2 R4: map-class frame-relay FRTS frame-relay holdq 400 Task 7.2 Breakdown The Frame Relay hold queue is the amount of buffers that are dedicated to the traffic shaping queue. When the hold queue is full, all other packets attempting to enter the output queue are dropped.



Task 7.3 R1: class-map match-all AUDIO match access-group name AUDIO ! policy-map LLQ class AUDIO priority 128 8000 ! interface Serial0/1 bandwidth 1536 service-policy output LLQ ! ip access-list extended AUDIO permit udp any any eq 7070 R3: class-map match-all AUDIO match access-group name AUDIO ! policy-map LLQ class AUDIO priority 128 8000 ! interface Serial1/2 bandwidth 1536 service-policy output LLQ ! ip access-list extended AUDIO permit udp any any eq 7070

Previous Reference Low Latency Queueing: Lab 6 Task 7.1



Task 7.4 R4: policy-map WRED class class-default fair-queue random-detect random-detect precedence 5 60 90 5 ! map-class frame-relay FRTS service-policy output WRED Task 7.4 Breakdown The above task dictates how to configure Weighted Random Early Detection (WRED) inside the Modular QoS CLI. In order to configure WRED inside the MQC, the class in question must either have a bandwidth reservation configured, or be the default class with fair-queue enabled.

Previous Reference Weighted Random Early Detection: Lab 4



8. Security Task 8.1 R5: no ip source-route ! interface Ethernet0/1.52 ip access-group APPEASE_MANAGER in no ip proxy-arp no cdp enable ! interface Ethernet0/1.53 ip access-group APPEASE_MANAGER in no ip proxy-arp no cdp enable ! ip access-list extended APPEASE_MANAGER deny tcp any 174.1.0.0 0.0.255.255 eq www deny tcp any 174.1.0.0 0.0.255.255 eq telnet deny tcp any 150.1.0.0 0.0.255.255 eq www deny tcp any 150.1.0.0 0.0.255.255 eq telnet deny icmp any any echo permit ip any any



Task 8.2 R5: class-map match-all FROM_BB3 match input-interface Ethernet0/1 class-map match-all FROM_BB2 match input-interface Ethernet0/0 ! policy-map TO_BB2 class FROM_BB3 drop policy-map TO_BB3 class FROM_BB2 drop ! interface Ethernet0/0 service-policy output TO_BB2 ! interface Ethernet0/1 service-policy output TO_BB3 Task 8.2 Breakdown The above configuration stops traffic from transiting between two interfaces. By matching the input interface for traffic and dropping it, traffic cannot come in Ethernet 0/1.52 and go out Ethernet 0/1.53, or vice versa.



Task 8.3 R5: class-map match-all FROM_BB3 match not access-group name TO_SMTP_SERVER class-map match-all FROM_BB2 match not access-group name FROM_SMTP_SERVER ! ip access-list extended FROM_SMTP_SERVER permit tcp host 192.10.1.100 eq smtp 204.12.1.0 0.0.0.255 ip access-list extended TO_SMTP_SERVER permit tcp 204.12.1.0 0.0.0.255 host 192.10.1.100 eq smtp Task 8.3 Breakdown The above configuration adds an exception to the previous task. Traffic is only dropped when it is moving between Ethernet0/1.52 and Ethernet0/1.53 if it is not a traffic flow from the above referenced SMTP server and its clients in VLAN 53.



9. System Management Task 9.1 R2: interface FastEthernet0/0 no ip proxy-arp R6: interface GigabitEthernet0/1 no ip proxy-arp Task 9.1 Breakdown When a router received an ARP request on an interface that is for a client not on that network, the router will respond with its own MAC address if it has a route for the destination in the IP routing table. This behavior is known as proxy arp. Proxy arp is on by default on all Ethernet interfaces. To disable this behavior, issue the no ip proxy-arp interface level command.

Further Reading Proxy ARP


http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094adb.shtml


Task 9.2 R4: interface Serial0/0 ip wccp web-cache redirect out Task 9.2 Breakdown Web Cache Communication Protocol (WCCP) allows the transparent redirection of client web requests to one or more web cache engine, which can significantly improve browsing performance over low speed links. The only command needed to enable WCCP is the interface level command ip wccp web-cache redirect [in | out] command. This command instructs the router in which direction to listen for HTTP requests. In the above example R4 listens for HTTP requests leaving the Serial0/0 interface. These requests will be redirected to one or more web cache engines that have been configured to communicate with the router via WCCP.



Task 9.3 R6: rtr 1 type echo protocol ipIcmpEcho 115.0.0.1 request-data-size 1250 timeout 25 threshold 25 frequency 30 rtr schedule 1 start-time now Task 9.3 Breakdown Cisco Service Assurance Agent (SAA), also known as the Response Time Reporter (RTR), is a monitoring application built into IOS that can track service levels through UDP echo, ICMP, DNS lookups, packet loss, etc. To configure SAA, first issue the rtr [number] global configuration command. This creates an instance of SAA. Once inside the rtr mode, specify the type of traffic to generate by issuing the type command. In the above example ICMP echo packets will be sent to the IP address 115.0.0.1. The frequency and timeout have also been specified in the above configuration. To initiate an SAA instance, issue the rtr schedule [number] start-time [time].

Further Reading Cisco Service Assurance Agent User Guide Measuring Delay, Jitter, and Packet Loss with Cisco IOS SAA and RTTMON


http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/saaug_ai.htm

http://www.cisco.com/en/US/tech/tk869/tk769/technologies_white_paper09186a00801b1a1e.shtml

http://www.cisco.com/en/US/tech/tk869/tk769/technologies_white_paper09186a00801b1a1e.shtml


Task 9.4 R2: interface FastEthernet0/0 standby 1 ip 174.1.26.254 standby 1 preempt R6: track 1 rtr 1 ! interface GigabitEthernet0/1 standby 1 ip 174.1.26.254 standby 1 priority 110 standby 1 preempt standby 1 track 1 decrement 20

Previous Reference HSRP: Lab 1



1. Catalyst 3550 Task 1.1 SW1: vtp domain CISCO vtp password CISCO ! vlan 3,4,5,6,7,8,10,18,68,73,77,232 ! interface FastEthernet0/1 switchport access vlan 18 ! interface FastEthernet0/2 switchport access vlan 232 ! interface FastEthernet0/3 switchport access vlan 3 ! interface FastEthernet0/4 switchport access vlan 4 ! interface FastEthernet0/5 no switchport ip address 148.1.57.7 255.255.255.0 ! interface FastEthernet0/6 switchport access vlan 6 ! interface FastEthernet0/10 switchport access vlan 10 ! interface FastEthernet0/20 switchport access vlan 4 ! interface FastEthernet0/21 switchport access vlan 4 ! interface FastEthernet0/22 switchport access vlan 4 ! interface FastEthernet0/24 switchport access vlan 73 ! interface Vlan7 ip address 148.1.7.7 255.255.255.0 ! interface Vlan73 ip address 204.12.1.7 255.255.255.0 ! interface Vlan77 ip address 148.1.77.7 255.255.255.0



SW2: vtp domain CISCO vtp password CISCO ! interface FastEthernet0/3 switchport access vlan 232 ! interface FastEthernet0/5 switchport access vlan 5 ! interface FastEthernet0/6 switchport access vlan 68 ! interface FastEthernet0/24 switchport access vlan 232 ! interface Vlan8 ip address 148.1.8.8 255.255.255.0 ! interface Vlan18 ip address 148.1.18.8 255.255.255.0 ! interface Vlan68 ip address 148.1.68.8 255.255.255.0



Task 1.2 SW1 and SW2: define interface-range DOT-ONE-Q FastEthernet0/13 - 15 ! interface FastEthernet0/13 switchport trunk encapsulation dot1q switchport mode trunk ! interface FastEthernet0/14 switchport trunk encapsulation dot1q switchport mode trunk ! interface FastEthernet0/15 switchport trunk encapsulation dot1q switchport mode trunk Task 1.2 Breakdown In order to ease in management of ports that have similar configuration the 3550 supports interface-range macros. These macros are user defined identifiers that represent a range of ports. To define an interface-range macro, use the global configuration command define interface-range [name] [range]. After the macro is defined these ports can be referenced by issuing the interface range macro [name] command.

Further Reading Configuring Interface Characteristics




Task 1.3 SW1: interface FastEthernet0/10 spanning-tree guard root Task 1.3 Breakdown Spanning-tree root guard is typically used when a provider is leasing an Ethernet line out to a customer. In the case that a switch in the customer’s network is elected root, all traffic from the provider and its other customers must follow sub-optimal forwarding. Root guard can be used to prevent this case by disabling the port connected to the customer if a superior BPDU is received. The term superior BPDU implies that the cost to the root out that port is better than the current root port. To enable root guard use the interface level command spanning-tree guard root.

Further Reading Spanning-Tree Protocol Root Guard Enhancement


http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00800ae96b.shtml


2. Frame-Relay Task 2.1 R1: interface Serial0/0 ip address 148.1.0.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 148.1.0.2 102 broadcast frame-relay map ip 148.1.0.3 102 frame-relay map ip 148.1.0.4 104 broadcast no frame-relay inverse-arp R2: interface Serial0/0 ip address 148.1.0.2 255.255.255.0 encapsulation frame-relay frame-relay map ip 148.1.0.1 201 broadcast frame-relay map ip 148.1.0.3 203 broadcast frame-relay map ip 148.1.0.4 201 no frame-relay inverse-arp R3: interface Serial1/0 encapsulation frame-relay ! interface Serial1/0.302 point-to-point ip address 148.1.0.3 255.255.255.0 frame-relay interface-dlci 302 R4: interface Serial0/0 encapsulation frame-relay ! interface Serial0/0.401 point-to-point ip address 148.1.0.4 255.255.255.0 frame-relay interface-dlci 401



Task 2.2 R3: interface Serial1/1 ip address 148.1.35.3 255.255.255.0 encapsulation frame-relay no frame-relay inverse-arp ip 311 no frame-relay inverse-arp ip 312 no frame-relay inverse-arp ip 314 R5: interface Serial0/0 ip address 148.1.35.5 255.255.255.0 encapsulation frame-relay no frame-relay inverse-arp ip 501 no frame-relay inverse-arp ip 502 no frame-relay inverse-arp ip 503 no frame-relay inverse-arp ip 504 Task 2.3 R6: interface Serial0/0/0 frame-relay map ip 54.1.3.254 51 broadcast no frame-relay inverse-arp

3. HDLC/PPP Task 3.1 R4: interface Serial0/0.401 point-to-point backup delay 0 300 backup interface Serial0/1 R5: interface Serial0/1 clockrate 64000



4. Interior Gateway Routing Task 4.1 R1: router ospf 1 router-id 150.1.1.1 network 148.1.18.1 0.0.0.0 area 168 network 150.1.1.1 0.0.0.0 area 168 R6: router ospf 1 router-id 150.1.6.6 network 148.1.6.6 0.0.0.0 area 168 network 148.1.68.6 0.0.0.0 area 168 network 150.1.6.6 0.0.0.0 area 168 SW2: ip routing ! router ospf 1 router-id 150.1.8.8 network 148.1.8.8 0.0.0.0 area 168 network 148.1.18.8 0.0.0.0 area 168 network 148.1.68.8 0.0.0.0 area 168 network 150.1.8.8 0.0.0.0 area 168 Task 4.1 Breakdown

Note Single area OSPF implementations do not require area 0.



Task 4.2 R1 and SW2: router ospf 1 ignore lsa mospf Task 4.2 Breakdown Cisco’s OSPF implementation does not support LSA 6 (multicast OSPF). By default, every time one of these LSAs is received, a syslog message is generated. To disable this behavior issue the OSPF routing process subcommand ignore lsa mospf.

Standard RFC 1584: Multicast Extensions to OSPF

Task 4.3 R1: service password-encryption ! interface FastEthernet0/0 ip ospf message-digest-key 7 md5 CISCO ! router ospf 1 area 168 authentication message-digest SW2: service password-encryption ! interface Vlan18 ip ospf message-digest-key 7 md5 CISCO ! interface Vlan68 ip ospf authentication null ! router ospf 1 area 168 authentication message-digest




Task 4.3 Breakdown As previously covered, there are two ways to enable OSPF authentication, on a per area basis and on a per interface basis. As the above task states that the ip ospf authentication message-digest command cannot be used, area authentication must be. However, this task also states that the adjacency between R6 and SW2 must not be authenticated. Since R1, R6, and SW2 are all in the same area, this presents a problem. This task illustrates that there are actually three types of OSPF authentication, MD5, clear text, and NULL. By setting the OSPF authentication type to NULL on VLAN 68, SW2 has effectively disabled OSPF authentication on that interface.

Next, this task states that R1 and SW2 should use a pre-encrypted key with the number 7. This task is designed to illustrate the difference between key number and encryption type. The key number of an MD5 key is used as a seed or salt value in the MD5 hash algorithm. This seed is a number used to randomize the output of the hash algorithm, and decrease the effectiveness of a brute force attack on the MD5 algorithm. Key numbers must match on all devices authenticating on the segment.

The encryption type determines whether or not the password is stored in a clear-text or pre-encrypted form in the router’s configuration file. By issuing the service password-encryption global configuration command, all clear text passwords in the routers configuration are pre-encrypted with type 7 encryption. Type 7 encryption uses a Cisco proprietary insecure reversible encryption algorithm. This encryption is simply used to shield a password from an over the shoulder user seeing the password in show commands or backups or configuration files.

Further Reading Passwords and Privileges Commands Cisco IOS Password Encryption Facts


http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/cs/csprts/csprts5/cspasswd.htm



Task 4.4 R3: router eigrp 100 eigrp router-id 150.1.3.3 passive-interface default no passive-interface Serial1/1 network 148.1.3.3 0.0.0.0 network 148.1.35.3 0.0.0.0 no auto-summary R4: router eigrp 100 eigrp router-id 150.1.4.4 network 148.1.45.4 0.0.0.0 no auto-summary R5: router eigrp 100 eigrp router-id 150.1.5.5 network 150.1.5.5 0.0.0.0 network 148.1.5.5 0.0.0.0 network 148.1.35.5 0.0.0.0 network 148.1.45.5 0.0.0.0 network 148.1.57.5 0.0.0.0 no auto-summary SW1: ip routing ! router eigrp 100 eigrp router-id 150.1.7.7 network 150.1.7.7 0.0.0.0 network 148.1.7.7 0.0.0.0 network 148.1.57.7 0.0.0.0 network 148.1.77.7 0.0.0.0 no auto-summary



Task 4.5 R3: interface Serial1/1 ip hello-interval eigrp 100 4 ip hold-time eigrp 100 12 R5: interface Serial0/0 ip hello-interval eigrp 100 4 ip hold-time eigrp 100 12 Task 4.5 Breakdown To adjust neighbor hello and dead intervals in EIGRP use the interface level commands ip hello-interval eigrp [AS] [hello_interval] and ip hold-time eigrp [AS] [hold_time]. By default the EIGRP hello interval is 60 seconds for low speed NBMA interfaces and 5 seconds for all other media. The hold-time defaults to three times these values.



Task 4.6 R5 and SW1: key chain EIGRP key 1 key-string CISCO2003 accept-lifetime 00:00:00 Jan 1 1993 00:15:00 Jan 1 2006 send-lifetime 00:00:00 Jan 1 1993 23:45:00 Dec 31 2005 key 2 key-string CISCO2004 accept-lifetime 23:15:00 Dec 31 2005 infinite send-lifetime 23:45:00 Dec 31 2005 infinite R5: interface Ethernet0/0 ip authentication mode eigrp 100 md5 ip authentication key-chain eigrp 100 EIGRP SW1: interface FastEthernet0/5 ip authentication mode eigrp 100 md5 ip authentication key-chain eigrp 100 EIGRP Task 4.6 Breakdown Key chain authentication allows for key lifetime and rotation based on time. This option allows for smooth transition between authentication keys throughout the entire network at the same time. The two options that dictate a key’s timing are the accept-lifetime and the send-lifetime. As their names imply, the accept lifetime is the time period for which the specified key will be accepted from a neighbor as valid for authentication. The send-lifetime specifies during which time interval the key will be valid for transmission to a neighbor. The infinite option dictates that the specified key is valid from the start time on.

Note To ensure smooth key transition in the real world, NTP should be used in any practical time based key chain authentication implementations. In a lab situation unless the task specifically asks for NTP just applying the configurations without NTP should be adequate. Ask the proctor if in doubt about the need for NTP.

Further Reading IP Routing Protocol Independent Commands: accept-lifetime and send-lifetime


http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_r/iprprt2/1rdindep.htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_r/iprprt2/1rdindep.htm


Task 4.7 SW1: interface Vlan73 ip rip send version 1 2 ! router rip version 2 network 204.12.1.0 no auto-summary Task 4.7 Breakdown When the RIP routing process is enabled, all interfaces configured for RIP send RIP version 1 updates, and listed for version 2 updates. This can be modified by the routing process subcommand rip version [1 | 2] or the interface level commands ip rip send version and ip rip receive version commands. The interface level commands always override the process level version command.

Verification Router#show ip protocols Routing Protocol is "rip" Sending updates every 30 seconds, next due in 23 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Redistributing: rip Default version control: send version 1, receive any version Interface Send Recv Triggered RIP Key-chain Ethernet0/0 1 1 2 Serial0/0 1 1 2 Loopback0 1 1 2 Automatic network summarization is in effect Maximum path: 4 Routing for Networks: 10.0.0.0 Routing Information Sources: Gateway Distance Last Update Distance: (default is 120)



Task 4.8 R1: router rip version 2 passive-interface default no passive-interface Serial0/0 network 148.1.0.0 no auto-summary R2: router rip version 2 passive-interface default no passive-interface FastEthernet0/0 no passive-interface Serial0/0 network 150.1.0.0 network 148.1.0.0 network 192.10.1.0 no auto-summary R3: router rip version 2 passive-interface default no passive-interface Ethernet0/1 no passive-interface Serial1/0.302 network 150.1.0.0 network 148.1.0.0 network 192.10.1.0 no auto-summary R4: router rip version 2 passive-interface default network 150.1.0.0 network 148.1.0.0 no auto-summary



Task 4.9 SW2: vlan access-map RIP_FILTER 10 action drop match ip address 100 vlan access-map RIP_FILTER 20 action forward vlan filter RIP_FILTER vlan-list 232 ! access-list 100 permit udp host 192.10.1.254 any eq rip Task 4.9 Breakdown Although SW2 is only switching at layer two for the above network segment, it can still filter traffic above layer 3 by using VLAN Access-Lists (VACLs). The above VACL matches all RIP traffic coming from BB2 and discards it. Ensure to add the explicit permit sequence to ensure that all other traffic is forwarded unmodified.

Further Reading Configuring Network Security with ACLs




Task 4.10 R1: router ospf 1 redistribute rip subnets ! router rip redistribute ospf 1 metric 1 R3: router eigrp 100 redistribute rip metric 10000 1000 255 1 1500 ! router rip redistribute eigrp 100 metric 1 R5: interface Serial0/1 ip summary-address eigrp 100 0.0.0.0 0.0.0.0 ! router eigrp 100 redistribute static metric 64 10 255 1 1500 ! ip route 150.1.4.0 255.255.255.0 148.1.45.4 5 Task 4.10 Breakdown The default-information [in | out] statement in EIGRP does not generate a default route advertisement like other IGPs. Instead, it simply allows a default route which already exists to be received or propagated. EIGRP, like IGRP, uses the ip default-network statement to propagate default information. A default network must be a classful network dynamically learned that is not directly connected. However, a default-network propagates in all directions. In the above scenario it is specified that R5 should generate a default route specifically to R4. Since a default-network advertisement cannot be filtered out without filtering the actual network, ip default-network cannot be used in this case. A default route is the most generic IPv4 summary address there is, having a subnet mask of zero. Therefore, a default route can be generated by using an interface summary-address of 0.0.0.0. The above configuration example dictates so.



Task 4.11 SW1: router eigrp 100 redistribute rip metric 10000 1000 255 1 1500 ! router rip redistribute eigrp 100 metric 15 Task 4.11 Breakdown RIP defines an infinite (unreachable) metric as 16. Metric is incremented as a route advertisement exits an interface. The above task states that the devices on VLAN 73 should not be able to pass on RIP updates learned from SW1. By redistributing prefixes from the EIGRP domain into the RIP domain with a metric of 15, their metric will be infinite when BB3 or any other device tries to pass them on.



5. Exterior Gateway Routing Task 5.1 R1: router bgp 100 no synchronization bgp router-id 150.1.1.1 neighbor 148.1.0.2 remote-as 200 neighbor 148.1.0.4 remote-as 400 neighbor 150.1.8.8 remote-as 100 neighbor 150.1.8.8 update-source Loopback0 R2: router bgp 200 no synchronization bgp router-id 150.1.2.2 neighbor 148.1.0.1 remote-as 100 neighbor 150.1.3.3 remote-as 200 neighbor 192.10.1.254 remote-as 254 neighbor 192.10.1.254 password CISCO neighbor 150.1.3.3 update-source Loopback0 neighbor 150.1.3.3 password CISCO R3: router bgp 200 no synchronization bgp router-id 150.1.3.3 neighbor 148.1.35.5 remote-as 65057 neighbor 150.1.2.2 remote-as 200 neighbor 192.10.1.254 remote-as 254 neighbor 192.10.1.254 password CISCO neighbor 150.1.2.2 update-source Loopback0 neighbor 150.1.2.2 password CISCO R4: router bgp 400 bgp router-id 150.1.4.4 neighbor 148.1.0.1 remote-as 100 R5: router bgp 65057 no synchronization bgp router-id 150.1.5.5 neighbor 148.1.35.3 remote-as 200 neighbor 148.1.57.7 remote-as 65057 R6: router bgp 100 no synchronization bgp router-id 150.1.6.6 neighbor 150.1.8.8 remote-as 100 neighbor 150.1.8.8 update-source Loopback0 neighbor 54.1.3.254 remote-as 54



SW1: router bgp 65057 no synchronization bgp router-id 150.1.7.7 neighbor 148.1.57.5 remote-as 65057 SW2: router bgp 100 no synchronization bgp router-id 150.1.8.8 neighbor 150.1.1.1 remote-as 100 neighbor 150.1.1.1 route-reflector-client neighbor 150.1.1.1 update-source Loopback0 neighbor 150.1.6.6 remote-as 100 neighbor 150.1.6.6 route-reflector-client neighbor 150.1.6.6 update-source Loopback0



Task 5.2 R6: router bgp 100 neighbor 54.1.3.254 filter-list 25 in ! ip as-path access-list 25 permit ^54(_[0-9]+)?$ Task 5.2 Breakdown A common view to take of the BGP table is the directly connected AS’s customer routes. Taking this type of view conserves memory since the router does not have to store the entire BGP table. Recall that the characters used in regular expressions: Character Meaning

^ Start of string

$ End of string

[] Range of characters

- Used to specify range ( i.e. [0-9] )

( ) Logical grouping

. Any single character

* Zero or more instances

+ One or more instance

? Zero or one instance

_ (underscore) Comma, open or close brace, open or close parentheses, start or end of string, or space



The goal of the regular expression used in the above task is to match routes originated in AS 54, or routes originated in AS 54’s customer’s networks. Therefore the possible AS paths to match are either “54” or “54 X”, where “X” is any single AS. First let us match just routes originated in AS 54:

ip as-path access-list 25 permit ^54$ This means:

Character(s) Meaning

^ Start of line

54 Exactly AS 54

$ End of line

Now we need to check for the case “54 X” where X is any single AS:

ip as-path access-list 25 permit ^54_[0-9]+$ This means:

Character(s) Meaning

^ Start of line

54 Exactly AS 54

_ Space

[0-9] Any number 0 through 9

+ One or more instance of 0 to 9

$ End of line

Comparing the above two expressions, it is evident that the difference between them is the sequence “_[0-9]+” Therefore, these expressions can be combined by checking for zero or one instance (true or false) of this sequence. Zero or one instance is the character ? Remember that to match the question mark in the line the escape sequence CTRL-V must be issued first.




Verification C:\>telnet route-server.net ############## route-server.xx.net ############### ######### xx Route Monitor ########### This router maintains peerings with customer-facing routers throughout the xx Backbone: <output deleted> This router has the global routing table view from each of the above routers, providing a glimpse to the Internet routing table from the xx network's perspective. route-server>show ip bgp regexp ^701(_[0-9]+)?$ Network Next Hop Metric LocPrf Weight Path * i 208.172.146.30 100 0 701 10912 i * i24.206.128.0/20 208.172.146.30 100 0 701 21615 i *>i 208.172.146.29 100 0 701 21615 i * i24.206.128.0/18 208.172.146.30 100 0 701 21615 i *>i 208.172.146.29 100 0 701 21615 i * i24.206.144.0/20 208.172.146.30 100 0 701 21615 i *>i 208.172.146.29 100 0 701 21615 i *>i24.204.42.0/24 208.172.146.29 100 0 701 i * i 208.172.146.30 100 0 701 i *>i24.204.43.0/24 208.172.146.29 100 0 701 i * i 208.172.146.30 100 0 701 i * i24.204.80.0/22 208.172.146.30 100 0 701 i *>i 208.172.146.29 100 0 701 i * i24.204.84.0/22 208.172.146.30 100 0 701 i *>i 208.172.146.29 100 0 701 i * i24.204.88.0/22 208.172.146.30 100 0 701 i *>i 208.172.146.29 100 0 701 i *>i24.204.136.0/22 208.172.146.29 100 0 701 10912 i * i 208.172.146.30 100 0 701 10912 i *>i24.204.139.0/24 208.172.146.29 100 0 701 10912 i * i24.206.160.0/19 208.172.146.30 100 0 701 21615 i *>i 208.172.146.29 100 0 701 21615 i *>i24.214.128.0/18 208.172.146.29 100 0 701 12083 ? * i 208.172.146.30 100 0 701 12083 ? *>i24.214.192.0/18 208.172.146.29 100 0 701 12083 ? * i 208.172.146.30 100 0 701 12083 ? * i24.215.64.0/18 208.172.146.30 100 0 701 11260 i *>i 208.172.146.29 100 0 701 11260 i *>i24.216.0.0/16 208.172.146.29 100 0 701 i


Task 5.3 R4: router bgp 400 redistribute connected route-map CONNECTED2BGP auto-summary ! route-map CONNECTED2BGP permit 10 match interface Ethernet0/0 Task 5.3 Breakdown The auto-summary keyword in BGP only affects prefixes that were redistributed into BGP. When it is on, routes redistributed into the BGP domain are automatically summarized to the classful boundary. When off, subnets will retain their subnet mask information.



Task 5.4 R6: router bgp 100 network 54.1.3.0 mask 255.255.255.0 network 148.1.6.0 mask 255.255.255.0 aggregate-address 148.1.0.0 255.255.128.0 suppress-map SUPPRESS_MAP ! route-map SUPPRESS_MAP permit 10 Task 5.4 Breakdown The summary-only keyword suppresses all subnets of an aggregate in order to prevent them from being advertised. The suppress-map is a route-map that can selectively suppress one or more subnets of the aggregate. Typically this configuration is used when the amount of prefixes that should be suppressed is outweighed by the amount that should not be suppressed. Unlike an unsuppress-map, the suppress-map is configured on the aggregate itself, and affects the local BGP table. The unsuppress-map is applied on a per neighbor basis.

In the above configuration uses an unsuppress-map that does not match anything. This is effectively an explicit permit statement for the route-map, and will suppress all subnets of the aggregate.

Another way to solve this task would have been to simply filter the subnets from being advertised to BB1 by using an access-list or prefix-list.



Task 5.5 SW1: interface Loopback1 ip address 148.1.177.7 255.255.255.0 ! router bgp 65057 neighbor 148.1.57.5 send-community network 148.1.177.0 mask 255.255.255.0 route-map SET_COMM ! route-map SET_COMM permit 10 set community no-export Task 5.5 Breakdown The above task illustrates the usage of the route-map keyword on the network statement. This route-map can be used to modify attributes of the prefix as it is originated into the BGP domain. These attributes may include weight, local-preference, MED, and community.

Previous Reference BGP Communities: Lab 3



6. IP Multicast Task 6.1 R1 and R2: ip multicast-routing ! interface FastEthernet0/0 ip pim dense-mode ! interface Serial0/0 ip pim dense-mode R3: ip multicast-routing ! interface Ethernet0/0 ip pim dense-mode ! interface Serial1/0.302 ip pim dense-mode R6: ip multicast-routing ! interface GigabitEthernet0/0 ip pim dense-mode ! interface GigabitEthernet0/1 ip pim dense-mode SW2: ip multicast-routing ! interface Vlan 18 ip pim dense-mode ! interface Vlan 68 ip pim dense-mode



Task 6.2 R1: interface Tunnel0 ip address 148.1.13.1 255.255.255.0 ip pim dense-mode tunnel source Loopback0 tunnel destination 150.1.3.3 ! ip mroute 0.0.0.0 0.0.0.0 Tunnel0 R3: interface Tunnel0 ip address 148.1.13.3 255.255.255.0 ip pim dense-mode tunnel source Loopback0 tunnel destination 150.1.1.1 R6: interface GigabitEthernet0/0 ip igmp join-group 224.6.6.6 Task 6.3 R2: ip multicast rpf backoff 300 5000



7. IPv6 Task 7.1 R3: ipv6 unicast-routing ! interface Loopback0 ipv6 address 2002:9601:303::3/64 ! interface Ethernet0/0 ipv6 address 2002:9601:303:1::3/64 R4: ipv6 unicast-routing ! interface Loopback0 ipv6 address 2002:9601:404::4/64 ! interface Ethernet0/0 ipv6 address 2002:9601:404:1::4/64 R5: ipv6 unicast-routing ! interface Loopback0 ipv6 address 2002:9601:505::5/64 ! interface Ethernet0/1 ipv6 address 2002:9601:505:1::5/64 R6: ipv6 unicast-routing ! interface Loopback0 ipv6 address 2002:9601:606::6/64 ! interface GigabitEthernet0/0 ipv6 address 2002:9601:606:1::6/64



Task 7.2 R3: interface Tunnel3456 ipv6 address 2002:9601:303:3456::3/64 tunnel source Loopback0 tunnel mode ipv6ip 6to4 ! ipv6 route 2002::/16 Tunnel3456 R4: interface Tunnel3456 ipv6 address 2002:9601:404:3456::4/64 tunnel source Loopback0 tunnel mode ipv6ip 6to4 ! ipv6 route 2002::/16 Tunnel3456 R5: interface Tunnel3456 ipv6 address 2002:9601:505:3456::5/64 tunnel source Loopback0 tunnel mode ipv6ip 6to4 ! ipv6 route 2002::/16 Tunnel3456 R6: interface Tunnel3456 ipv6 address 2002:9601:606:3456::6/64 tunnel source Loopback0 tunnel mode ipv6ip 6to4 ! ipv6 route 2002::/16 Tunnel3456 Task 7.3 R6: ipv6 access-list PC_IN_VLAN6 permit ipv6 host 2002:9601:606:1:: any ! line vty 0 4 ipv6 access-class PC_IN_VLAN6 in



8. QoS Task 8.1 R6: policy-map SHAPE class class-default shape average 5000000 160000 80000 ! interface Serial0/0/0 bandwidth 45000 service-policy output SHAPE

Previous Reference MQC Generic Traffic Shaping: Lab 5

Task 8.2 R6: ip cef ! class-map match-any PEER-TO-PEER match protocol fasttrack match protocol gnutella match protocol kazaa2 ! policy-map QOS_POLICY class PEER-TO-PEER police cir 8000 ! policy-map SHAPE class class-default service-policy QOS_POLICY

Previous Reference MQC Traffic Policing: Lab 1

Further Reading Network Based Application Recognition (NBAR)


http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_guide09186a0080134add.html


Task 8.3 R6: class-map match-all HTTP match protocol http class-map match-all SMTP match protocol smtp ! policy-map QOS_POLICY class HTTP bandwidth 2000 class SMTP bandwidth 1000 Task 8.3 Breakdown

Previous Reference MQC Bandwidth Reservation: Lab 2

Task 8.4 R6: class-map match-all #CISCO_UNDERNET_IRC match access-group name CISCO_UNDERNET_IRC ! policy-map QOS_POLICY class #CISCO_UNDERNET_IRC priority 32 ! ip access-list extended CISCO_UNDERNET_IRC permit tcp host 148.1.6.10 any eq 6667 Task 8.6 Breakdown

Previous Reference MQC Low Latency Queueing: Lab 6



9. Security Task 9.1 R6: interface Serial0/0/0 ip access-group RFC1918 in ! ip access-list extended RFC1918 deny ip 10.0.0.0 0.255.255.255 any deny ip 172.16.0.0 0.15.255.255 any deny ip 192.168.0.0 0.0.255.255 any permit ip any any Task 9.1 Breakdown RFC 1918 specifies that the address ranges 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 are reserved for private usage. As these addresses are not publicly routable on the Internet, there is no valid reason for traffic to be received on an outside interface which is sourced from a host in this range. Therefore best security practice dictates that these addresses should be denied from entering the network.

Standard RFC 1918: Address Allocation for Private Internets

Task 9.2 R5: interface Ethernet0/1 ip access-group DENY_INTERNET_SURFING in ! ip access-list extended DENY_INTERNET_SURFING permit tcp any any eq www time-range NON_WORK_HOURS permit tcp any host 148.1.3.100 eq www ! time-range NON_WORK_HOURS periodic weekend 0:00 to 23:59 periodic weekdays 0:00 to 8:59 periodic weekdays 17:01 to 23:59




10. System Management Task 10.1 R6: ip ftp username R6CORE ip ftp password CISCO exception dump 148.1.3.100 exception protocol ftp exception core-file R6DUMP.txt Task 10.1 When a router crashes it can be possible to create a core dump of what is currently in RAM. This output can be useful for TAC to troubleshoot a hardware or software problem. Core dumps can be created through TFTP, FTP, RCP, or direct to flash.

Further Reading Creating Core Dumps

Task 10.2 R5: ntp server 204.12.1.254 ntp peer 148.1.57.7 SW1: ntp server 204.12.1.254 Task 10.3 R5: ntp authentication-key 1 md5 CISCO ntp authenticate ntp trusted-key 1 ntp server 204.12.1.254 key 1 prefer SW1: ntp authentication-key 1 md5 CISCO ntp authenticate ntp trusted-key 1 ntp server 204.12.1.254 key 1 prefer


http://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1/tr19aa.htm


11. IP Services Task 11.1 R1: ip tcp synwait-time 5 Task 11.1 Breakdown The TCP SYN wait time is the time the router will wait after sending a TCP SYN packet for a SYN/ACK to come back. If the SYN/ACK response has not been received before the timer expires, the connection is reset. Task 11.2 R6: interface Serial0/0/0 ip accounting output-packets ! ip accounting-threshold 1000 Task 11.3 R3: interface Ethernet0/0 ip nat inside ! interface Ethernet0/1 ip nat outside ! interface Serial1/0.302 point-to-point ip nat outside ! interface Serial1/1 ip nat outside ! ip nat pool REAL_SERVERS 148.1.3.110 148.1.3.112 prefix-length 24 type rotary ip nat inside destination list OLD_WEB_SERVER pool REAL_SERVERS ! ip access-list extended OLD_WEB_SERVER permit tcp any host 148.1.3.100 eq www permit tcp any host 148.1.3.100 eq 8080 permit tcp any host 148.1.3.100 eq 443

Further Reading Providing TCP Load Distribution




1. Catalyst 3550 Task 1.1 - 1.3 SW1: vtp domain CCIE vtp mode transparent vlan 5,7,18,26,43,62 ! interface FastEthernet0/1 switchport access vlan 18 ! interface FastEthernet0/2 switchport access vlan 26 ! interface FastEthernet0/4 no switchport ip address 164.1.47.7 255.255.255.0 ! interface FastEthernet0/5 switchport access vlan 5 ! interface FastEthernet0/6 switchport access vlan 62 ! interface FastEthernet0/10 switchport access vlan 5 ! interface FastEthernet0/11 switchport access vlan 5 ! interface FastEthernet0/15 switchport access vlan 18 ! interface FastEthernet0/24 switchport access vlan 43 ! interface Vlan7 ip address 164.1.7.7 255.255.255.0



SW2: vtp domain CCIE vtp mode transparent vlan 3,26,43,55,62 ! interface FastEthernet0/3 switchport access vlan 3 ! interface FastEthernet0/4 switchport access vlan 43 ! interface FastEthernet0/5 switchport access vlan 55 ! interface FastEthernet0/6 switchport access vlan 26 ! interface FastEthernet0/15 no switchport ip address 164.1.18.8 255.255.255.0 ! interface FastEthernet0/24 switchport access vlan 62 Task 1.1 Breakdown This task states that “SW1 and SW2 should keep independent VTP databases”. To accomplish this they should both be set to transparent mode by issuing the vlan database or global configuration command vtp mode transparent. Note that if transparent mode is configured first before the VLANs are defined you must configure redundant VLAN statements on both switches (i.e. issue the vlan 62 command on both SW1 and SW2). One way to avoid this is to configure the VTP domain and the VLANs, allow them to propagate through VTP advertisements ,and then after VTP has converged issue the vtp mode transparent command on both switches.



Task 1.2 SW1: interface Port-channel1 switchport trunk encapsulation dot1q ! interface FastEthernet0/13 switchport trunk encapsulation dot1q channel-group 1 mode desirable ! interface FastEthernet0/14 switchport trunk encapsulation dot1q channel-group 1 mode desirable ! vlan dot1q tag native SW2: interface Port-channel1 switchport trunk encapsulation dot1q ! interface FastEthernet0/13 switchport trunk encapsulation dot1q channel-group 1 mode desirable ! interface FastEthernet0/14 switchport trunk encapsulation dot1q channel-group 1 mode desirable ! vlan dot1q tag native Task 1.2 Breakdown By default all traffic except the native VLAN is encapsulated with a dot1q header when it is sent across an 802.1q trunk link. The vlan dot1q tag native command instructs the switch to encapsulate even the native VLAN with an 802.1q header.


Task 1.3 SW1: mls qos ! interface FastEthernet0/10 switchport voice vlan dot1p switchport priority extend cos 3 mls qos trust cos ! interface FastEthernet0/11 switchport voice vlan dot1p switchport priority extend cos 3 mls qos trust cos Task 1.9 - 1.12 Breakdown Much like the scenario covered before, this task describes a setup where Cisco IP phones are connected to the 3550. In the above case the 802.1p priority tag value is used to indicate whether or not a packet is voice destined for the phone. Additionally the CoS value that the PCs are generating is overwritten with a value of 3 as it enters the switch block. The default behavior of the phone is to override the CoS of all traffic received from the extension with a CoS of zero. By adding the switchport priority extend cos command the switch will overwrite the CoS of packets received from the device attached to its extension.

Further Reading Configuring Voice VLAN


http://www.cisco.com/en/US/products/hw/switches/ps646/products_configuration_guide_chapter09186a0080115951.html



2. Frame-Relay Task 2.1 R3: interface Serial1/0 encapsulation frame-relay ! interface Serial1/0.34 point-to-point ip address 164.1.34.3 255.255.255.0 frame-relay interface-dlci 304 ! interface Serial1/0.35 point-to-point ip address 164.1.35.3 255.255.255.0 frame-relay interface-dlci 305 R4: interface Serial0/0 encapsulation frame-relay frame-relay map ip 164.1.34.3 403 broadcast no frame-relay inverse-arp R5: interface Serial0/0 encapsulation frame-relay frame-relay map ip 164.1.35.3 503 broadcast no frame-relay inverse-arp



Task 2.2 R1: interface Serial0/0 encapsulation frame-relay frame-relay map ip 164.1.12.2 102 broadcast no frame-relay inverse-arp R2: interface Serial0/0 encapsulation frame-relay ! interface Serial0/0.12 point-to-point ip address 164.1.12.2 255.255.255.0 frame-relay interface-dlci 201 ! interface Serial0/0.23 point-to-point ip address 164.1.23.2 255.255.255.0 frame-relay interface-dlci 213 R3: interface Serial1/1 encapsulation frame-relay ! interface Serial1/1.23 point-to-point ip address 164.1.23.3 255.255.255.0 frame-relay interface-dlci 312



3. HDLC/PPP Task 3.1 R1: username ROUTER3_T1 password 0 CISCO ! interface Serial0/1 encapsulation ppp ppp authentication chap ppp chap hostname ROUTER1_T1 R3: username ROUTER1_T1 password 0 CISCO ! interface Serial1/2 encapsulation ppp ppp authentication chap ppp chap hostname ROUTER3_T1 R4: username Rack1R5 password 0 CISCO ! interface Serial0/1 encapsulation ppp ppp authentication chap R5: username Rack1R4 password 0 CISCO ! interface Serial0/1 encapsulation ppp ppp authentication chap Task 3.1 The “MD5” keyword in this task indicates that CHAP authentication is required. CHAP authentication has been discussed in various previous labs.



4. Interior Gateway Routing Task 4.1 R1: router eigrp 100 network 150.1.1.1 0.0.0.0 network 164.1.12.1 0.0.0.0 network 164.1.13.1 0.0.0.0 network 164.1.18.1 0.0.0.0 no auto-summary eigrp router-id 150.1.1.1 R2: router eigrp 100 network 150.1.2.2 0.0.0.0 network 164.1.12.2 0.0.0.0 network 164.1.23.2 0.0.0.0 network 164.1.26.2 0.0.0.0 no auto-summary eigrp router-id 150.1.2.2 R3: router eigrp 100 network 150.1.3.3 0.0.0.0 network 164.1.13.3 0.0.0.0 network 164.1.23.3 0.0.0.0 no auto-summary eigrp router-id 150.1.3.3 R6: router eigrp 100 network 150.1.6.6 0.0.0.0 network 164.1.26.6 0.0.0.0 no auto-summary eigrp router-id 150.1.6.6 SW2: ip routing ! router eigrp 100 network 150.1.8.8 0.0.0.0 network 164.1.18.8 0.0.0.0 no auto-summary eigrp router-id 150.1.8.8



Task 4.2 R1: interface Serial0/0 bandwidth 256 delay 20038 ! interface Serial0/1 bandwidth 1536 ! router eigrp 100 variance 5 R3: interface Serial1/1.23 point-to-point bandwidth 1280 Task 4.2 Breakdown EIGRP is the only IGP that supports unequal cost load balancing. In order to enable this load balancing issue the variance command under the EIGRP process. In order for a path to be considered for unequal cost load balancing it must be a feasible successor with a metric less than or equal to the successor’s metric times the variance. To choose the best path through the network and prevent looping EIGRP’s route selection uses the feasibility condition. In order to understand this calculation it is important to understand the difference between advertised distance and local distance. Advertised distance is the metric reported by the upstream neighbor as their cost to the destination. Local distance is the metric from the local device to the upstream neighbor. First the local router looks through all advertised paths and chooses the path with the lowest advertised distance plus local distance. Like other protocols this is simply the lowest end to end metric for the path. The metric for this path is called the feasible distance. The path itself called the successor. The successor is the best route to the destination.


Once the successor has been found EIGRP does an additional check to see if there may be alternate paths throughout the network. These alternate paths are known as feasible successors. These are paths that could be (are feasible to be) the successor if the successor is lost. A path whose advertised distance is lower than the feasible distance of the successor is deemed a feasible successor. In the case that a router is advertising a lower distance than the local device is using as its successor it can be guaranteed that there is not a loop in the topology.

Note Only routes that are feasible successors can be used for unequal cost load balancing.

Now that the successor and all feasible successors have been chosen the router does a final check based on the input variance value to determine which feasible successors can be installed in the IP routing table along with the successor. If the end to end metric of a feasible successor is less than or equal to the metric of the successor times the variance it is valid to be installed as an additional path. EIGRP unequal cost load balancing also does efficient traffic sharing. For example if the successor has a metric of one and the feasible successor has a metric of two, two packets will be sent out the successor’s path and one packet will be sent out the feasible successor’s path. This ensures that higher bandwidth paths are more utilized than lower bandwidth paths. In the above task R1 is to be configured to send traffic out to the destination 164.X.26.0/24 to both R3 and R2 in a ratio of 5:1 respectively. In addition to this the question specifies what the underlying bandwidths of the network circuits are. The first step in accomplishing this goal is to set the appropriate bandwidth statement on the interface. In the above configuration this is done on the outgoing interfaces to reach the destination. Typically the bandwidth value is configured on both ends of the link to be the same value, but in this case it is not required to accomplish the goal.




After the bandwidth values are set the following output is seen on R1: Rack1R1#show ip eigrp topology 164.1.26.0 255.255.255.0 IP-EIGRP (AS 100): Topology entry for 164.1.26.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3026432 Routing Descriptor Blocks: 164.1.13.3 (Serial0/1), from 164.1.13.3, Send flag is 0x0 Composite metric is (3026432/2514432), Route is Internal Vector metric: Minimum bandwidth is 1280 Kbit Total delay is 40100 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 2 164.1.12.2 (Serial0/0), from 164.1.12.2, Send flag is 0x0 Composite metric is (10514432/28160), Route is Internal Vector metric: Minimum bandwidth is 256 Kbit Total delay is 20100 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1 From this output we can see that R1 has two paths, one through R3 and one through R2. The path through R3 has a metric of 3026432, while the path through R2 has a metric of 10514432. Since the metric through R3 is less it is the successor. Next the feasibility check is run, and R2’s advertised distance of 28160 is compared against the feasible distance of 3026432. Since R2’s advertised distance is less than the feasible distance the route through R2 is a feasible successor. At this point if the variance command was configured traffic would be load balanced between R3 and R2 in a ratio of 10514432:3026432, or approximately 80:23. This can be seen in the show ip route 164.1.26.0 output on R1: Rack1R1#show ip route 164.1.26.0 Routing entry for 164.1.26.0/24 Known via "eigrp 100", distance 90, metric 3026432, type internal Redistributing via eigrp 101 Last update from 164.1.13.3 on Serial0/1, 00:04:00 ago Routing Descriptor Blocks: * 164.1.12.2, from 164.1.12.2, 00:04:00 ago, via Serial0/0 Route metric is 10514432, traffic share count is 23 Total delay is 20100 microseconds, minimum bandwidth is 256 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1 164.1.13.3, from 164.1.13.3, 00:04:00 ago, via Serial0/1 Route metric is 3026432, traffic share count is 80 Total delay is 40100 microseconds, minimum bandwidth is 1280 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 2



In order to achieve the desired ratio of 5:1 we must now modify the metric through R2 to be 5 times that of R3’s metric, while still keeping the route through R2 a feasible successor. The easiest way to do this is to change the delay on R1’s connection to R2 over the Frame Relay cloud. To determine the correct delay value we must first determine how the current composite metric value is derived. EIGRP metric calculation uses the formula: Metric = [k1 * bandwidth + (k2 * bandwidth)/(256 - load) + k3 * delay] * [k5/(reliability + k4)] The “k” values are derived from the metric weights command, where K1 and K3 are 1 by default and all other values are 0. This essentially means that only bandwidth and delay are taken into account. “Bandwidth” is the inverse bandwidth in Kbps times 107 (107/BWKbps). “Delay” is delay in tens of microseconds (DLYusec/10). These values are added together and then scaled by a factor of 256. The composite metric is therefore represented by default as: Metric = (107/BWKbps + DLYusec/10) * 256 Using the output from the show ip eigrp topology 164.1.26.0 255.255.255.0 we can see that the metric through R3 has a minimum bandwidth value of 1280Kbps and a total delay of 40100 microseconds. The metric to R3 is then calculated as: Metric_through_R3 = (107/1280 + 40100/10) * 256 Metric_through_R3 = (7812.5 + 4010) * 256 Metric_through_R3 = (11822.5) * 256 Metric_through_R3 ~ (11822) * 256 Metric_through_R3 ~ 3026432 In order to get our ratio of 5:1 we now need to modify our calculation as follows: Metric_through_R3 * 5 = Metric_through_R2 Or more specifically: (107/1280 + 40100/10) * 256 * 5 = (107/BWKbps-R2 + DLYusec-R2/10) * 256



The value that we will modify through R2 is the delay, so we can use our current BW value to R2 of 256Kbps (as seen from the show ip eigrp topology output) (107/1280 + 40100/10) * 256 * 5 = (107/BWKbps-R2 + DLYusec-R2/10) * 256 (107/1280 + 40100/10) * 256 * 5 = (107/256 + DLYusec-R2/10) * 256 (107/1280 + 40100/10) * 5 = (107/256 + DLYusec-R2/10) (7812.5 + 4010) * 5 = (39062.5 + DLYusec-R2/10) (7812 + 4010) * 5 ~ (39062 + DLYusec-R2/10) 59110 ~ (39062 + DLYusec-R2/10) 20048 ~ DLYusec-R2/10 200480 ~ DLYusec-R2 Based on this calculation we can see that if the end to end delay through R2 is 200480 the resulting composite metric through R2 will be five times that of through R3. Looking at the show ip eigrp topology 164.1.26.0 255.255.255.0 output on R2 we can see that R2 already has a delay of 100 microseconds to reach this destination: Rack1R2#show ip eigrp topology 164.1.26.0 255.255.255.0 IP-EIGRP (AS 101): Topology entry for 164.1.26.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 28160 Routing Descriptor Blocks: 0.0.0.0 (FastEthernet0/0), from Connected, Send flag is 0x0 Composite metric is (28160/0), Route is Internal Vector metric: Minimum bandwidth is 100000 Kbit Total delay is 100 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 0


This means that R1 should have a local delay to R2 of (200480 – 100), or 20038 tens of microseconds. Once the delay 20038 command is configured on R1’s Serial0/0 interface the traffic share is in a ratio of 5 to 1: Rack1R1#show ip route 164.1.26.0 Routing entry for 164.1.26.0/24 Known via "eigrp 101", distance 90, metric 3026432, type internal Redistributing via eigrp 101 Last update from 164.1.13.3 on Serial0/1, 00:00:00 ago Routing Descriptor Blocks: * 164.1.12.2, from 164.1.12.2, 00:00:00 ago, via Serial0/0 Route metric is 15132160, traffic share count is 1 Total delay is 200480 microseconds, minimum bandwidth is 256 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1 164.1.13.3, from 164.1.13.3, 00:00:00 ago, via Serial0/1 Route metric is 3026432, traffic share count is 5 Total delay is 40100 microseconds, minimum bandwidth is 1280 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 2

Further Reading How Does Unequal Cost Path Load Balancing (Variance) Work in IGRP and EIGRP?


http://www.cisco.com/en/US/tech/tk365/tk207/technologies_tech_note09186a008009437d.shtml

http://www.cisco.com/en/US/tech/tk365/tk207/technologies_tech_note09186a008009437d.shtml



Task 4.3 R3: router ospf 1 network 164.1.34.3 0.0.0.0 area 0 network 164.1.35.3 0.0.0.0 area 0 R4: interface Serial0/0 ip ospf network point-to-point ! router ospf 1 router-id 150.1.4.4 network 164.1.34.4 0.0.0.0 area 0 R5: interface Serial0/0 ip ospf network point-to-point ! router ospf 1 router-id 150.1.5.5 network 164.1.5.5 0.0.0.0 area 0 network 164.1.35.5 0.0.0.0 area 0 network 164.1.55.5 0.0.0.0 area 0 Task 4.4 R4: interface Loopback0 ip ospf network point-to-point ! router ospf 1 network 150.1.4.4 0.0.0.0 area 1 network 164.1.45.4 0.0.0.0 area 1 R5: interface Loopback0 ip ospf network point-to-point ! router ospf 1 network 150.1.5.5 0.0.0.0 area 1 network 164.1.45.5 0.0.0.0 area 1



Task 4.5 R4: interface Serial0/1 ip ospf cost 1 ! router ospf 1 network 164.1.47.4 0.0.0.0 area 38 area 1 virtual-link 150.1.5.5 R5: router ospf 1 area 1 virtual-link 150.1.4.4 SW1: ip routing ! router ospf 1 network 150.1.7.7 0.0.0.0 area 38 network 164.1.47.7 0.0.0.0 area 38 Task 4.5 Breakdown OSPF path selection will always choose an Intra-Area route over an Inter-Area route. Therefore when R4 goes to forward traffic to VLAN 5, which is advertised into area 0, it will choose the area 0 interface to R3 as opposed to the area 1 interface to R5. By configuring a virtual-link between R4 and R5 VLAN 5 will be advertised as an area 0 Intra-Area route directly from R5 to R4 over the PPP link. Since the PPP link has a lower cost to reach this destination than the Frame Relay link this will be the preferred path. Task 4.6 R3: interface Serial1/0.34 ip ospf authentication ip ospf authentication-key CISCO ! interface Serial1/0.35 ip ospf authentication ip ospf authentication-key CISCO R4: interface Serial0/0 ip ospf authentication ip ospf authentication-key CISCO ! router ospf 1 area 1 virtual-link 150.1.5.5 authentication area 1 virtual-link 150.1.5.5 authentication-key CISCO



R5: interface Serial0/0 ip ospf authentication ip ospf authentication-key CISCO ! router ospf 1 area 1 virtual-link 150.1.4.4 authentication area 1 virtual-link 150.1.4.4 authentication-key CISCO Task 4.7 R3: interface Serial1/1.23 ip summary-address eigrp 100 150.1.4.0 255.255.254.0 ! interface Serial1/2 ip summary-address eigrp 100 150.1.4.0 255.255.254.0 ! router eigrp 100 redistribute ospf 1 metric 10000 1000 1 255 1500 Task 4.8 R3: router ospf 1 default-information originate route-map CONDITIONAL_DEFAULT ! ip prefix-list R1_or_R2 seq 5 permit 164.1.13.0/24 ip prefix-list R1_or_R2 seq 10 permit 164.1.23.0/24 ! route-map CONDITIONAL_DEFAULT permit 10 match ip address prefix-list R1_or_R2 Task 4.9 R6: router rip version 2 no auto-summary network 54.0.0.0 ! router eigrp 100 redistribute rip metric 10000 1000 1 255 1500



5. Exterior Gateway Routing Task 5.1 R1: router bgp 300 no synchronization neighbor 164.1.12.2 remote-as 200 neighbor 164.1.13.3 remote-as 200 neighbor 164.1.18.8 remote-as 300 R2: router bgp 200 no synchronization neighbor 164.1.12.1 remote-as 300 neighbor 164.1.23.3 remote-as 200 neighbor 164.1.23.3 route-reflector-client neighbor 164.1.26.6 remote-as 200 neighbor 164.1.26.6 route-reflector-client R3: router bgp 200 no synchronization network 164.1.3.0 mask 255.255.255.0 neighbor 150.1.4.4 remote-as 100 neighbor 150.1.4.4 ebgp-multihop 255 neighbor 150.1.4.4 update-source Loopback0 neighbor 164.1.13.1 remote-as 300 neighbor 164.1.23.2 remote-as 200 R4: router bgp 100 no synchronization neighbor 150.1.3.3 remote-as 200 neighbor 150.1.3.3 ebgp-multihop 255 neighbor 150.1.3.3 update-source Loopback0 neighbor 163.1.13.1 remote-as 300 neighbor 204.12.1.254 remote-as 54 R6: router bgp 200 no synchronization neighbor 192.10.1.254 remote-as 254 neighbor 192.10.1.254 password CISCO neighbor 164.1.26.2 remote-as 200 neighbor 164.1.26.2 next-hop-self SW2: router bgp 300 neighbor 164.1.18.1 remote-as 300


Task 5.2 R3: router bgp 200 network 164.1.3.0 mask 255.255.255.0 R4: router bgp 100 aggregate-address 164.1.0.0 255.255.0.0 summary-only R6: router bgp 200 aggregate-address 164.1.0.0 255.255.0.0 summary-only Task 5.2 Breakdown

Previous Reference BGP Route Aggregation: Lab 2

Task 5.3 R1: router bgp 300 neighbor 164.1.18.8 default-originate neighbor 164.1.18.8 prefix-list DEFAULT out ! ip prefix-list DEFAULT seq 5 permit 0.0.0.0/0

Previous Reference IP Prefix-List: Lab 6

Task 5.4 R2: ip as-path access-list 1 permit ^$ ! router bgp 200 neighbor 164.1.12.1 filter-list 1 out R3: ip as-path access-list 1 permit ^$ ! router bgp 200 neighbor 164.1.13.1 filter-list 1 out



Task 5.4 Breakdown The above task states that AS 200 cannot be used as transit for users in AS 200. Therefore by only advertising prefixes that were originated inside AS 200, AS 300 cannot use AS 200 to reach any other ASs. In the above solution this is accomplished through the usage of filtering based on AS-Path information. Since the AS-Path of a prefix is not added until the prefix leaves the AS, prefixes which have been originated within the AS will have an empty AS-Path. This can be easily matched with a regular expression which specifies that the end of the line comes immediately after the end of the line, and is denoted as ^$

Verification C:\>telnet route-server.net ############## route-server.xx.net ############### ######### xx Route Monitor ########### This router maintains peerings with customer-facing routers throughout the xx Backbone: <output deleted> This router has the global routing table view from each of the above routers, providing a glimpse to the Internet routing table from the xx network's perspective. route-server>show ip bgp regexp ^$ BGP table version is 28963851, local router ID is 209.1.220.234 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i24.241.191.0/24 208.172.146.29 100 0 i * i 208.172.146.30 100 0 i *>i62.208.90.0/24 208.172.146.29 100 0 i * i 208.172.146.30 100 0 i *>i62.208.125.0/24 208.172.146.29 100 0 i * i 208.172.146.30 100 0 i *>i62.221.5.144/28 208.172.146.29 100 0 i * i 208.172.146.30 100 0 i *>i62.221.5.208/28 208.172.146.29 100 0 i * i 208.172.146.30 100 0 i *>i62.221.5.224/28 208.172.146.29 100 0 i * i 208.172.146.30 100 0 i *>i63.128.32.0/20 208.172.146.29 100 0 i * i 208.172.146.30 100 0 i *>i63.128.32.68/32 208.172.146.29 100 0 i * i 208 172 146 30 100 0 i



Task 5.5 R3: router ospf 1 redistribute bgp 200 route-map BGP2OSPF ! router bgp 200 bgp redistribute-internal ! ip as-path access-list 2 permit _54_ ! route-map BGP2OSPF deny 10 match as-path 2 ! route-map BGP2OSPF permit 20 R4: router ospf 1 redistribute bgp 100 route-map BGP2OSPF ! ip as-path access-list 1 permit ^54_ ! route-map BGP2ISIS permit 10 match as-path 1 Task 5.5 Breakdown The above task describes a case when reachability is lost to certain BGP networks when the primary Frame Relay connection of R4 is down. When the Frame Relay connection is down, all of R4’s traffic destined to R3 must transit R5. The problem, however, is that R5 does not participate in BGP routing. Therefore although BGP network layer reachability information is successfully transmitted throughout the network, traffic is black holed when it reaches R5. In order to resolve this issueBGP has been redistributed into IGP. R4 has been configured to redistribute all BGP information learned from AS 54 into OSPF, while R3 has been configured to redistribute all BGP information except that which has been learned from AS 54. Note that the bgp redistribute-internal command must be used on R3, as by default only EBGP learned information is candidate to be redistributed into IGP by default.

Previous Reference BGP Traffic Transiting Non-BGP Speaking Router: Lab 4




6. IP Multicast Task 6.1 R2: ip multicast-routing ! interface FastEthernet0/0 ip pim sparse-dense-mode ! interface Serial0/0.23 ip pim sparse-dense-mode R3: ip multicast-routing ! interface Ethernet0/1 ip pim sparse-dense-mode ! interface Serial1/1.23 ip pim sparse-dense-mode ! interface Serial1/0.34 ip pim sparse-dense-mode R4: ip multicast-routing ! interface Serial0/0 ip pim sparse-dense-mode ! interface Ethernet0/0 ip pim sparse-dense-mode SW1: ip multicast-routing ! interface FastEthernet0/4 ip pim sparse-dense-mode ! interface Vlan7 ip pim sparse-dense-mode



Task 6.2 R2, R3, R4, and SW1: ip pim rp-address 150.1.3.3 3 ! access-list 3 permit 225.10.0.0 0.16.255.255 access-list 3 permit 225.42.0.0 0.16.255.255 Task 6.2 Breakdown To find the minimum amount of statements to match these groups first examine the groups:

225.10.0.0 - 225.10.255.255 225.26.0.0 - 225.26.255.255 225.42.0.0 - 225.42.255.255 225.58.0.0 - 255.58.255.255

From this output it is evident that the first octet will always be 225, and the third and fourth octets can be anything. Next write out the second octet in binary for comparison:

10 = 00001010 26 = 00011010 42 = 00101010 58 = 00111010

These four networks differ in only the 3rd and 4th most significant bits, and can be matched with a wildcard mask as follows:

10 = 00001010 26 = 00011010 42 = 00101010 58 = 00111010

Wildcard = 00110000 Resulting in: access-list 3 permit 225.10.0.0 0.48.255.255



Task 6.3 R2, R3, R4, and SW1: ip pim rp-address 150.1.4.4 4 ! access-list 4 permit 226.37.0.0 1.8.255.255 Task 6.3 Breakdown To find the minimum amount of statements to match these groups first examine the groups:

226.37.0.0 - 226.37.255.255 226.45.0.0 - 226.45.255.255 227.37.0.0 - 227.37.255.255 227.45.0.0 - 227.45.255.255

From this output it is evident that the third and fourth octets can be anything. Next write out the first and second octets in binary for comparison:

226 = 11100010 227 = 11100011

37 = 00100101

45 = 00101101 These bit patterns result in four combinations which can be matched as follows:

226 = 11100010 227 = 11100011 Wildcard = 00000001

37 = 00100101 45 = 00101101

Wildcard = 00001000

226.37 = 11100010.00100101 226.45 = 11100011.00101101 227.37 = 11100010.00100101 227.45 = 11100011.00101101

Wildcard = 00000001.00001000 Resulting in: access-list 4 permit 226.37.0.0 1.8.255.255



Task 6.4 R3: interface Ethernet0/1 ip multicast boundary 1 ip igmp query-max-response-time 3 ip igmp query-interval 5 ! access-list 1 deny 226.37.1.1 access-list 1 permit any

7. IPv6 Task 7.1 R1: ipv6 unicast-routing ! interface Serial0/1 ipv6 address 2001:164:1:13::1/64 R2: ipv6 unicast-routing ! interface FastEthernet0/0 ipv6 address 2001:164:1:26::2/64 R3: ipv6 unicast-routing ! interface Serial1/2 ipv6 address 2001:164:1:13::3/64 R6: ipv6 unicast-routing ! interface GigabitEthernet0/0 ipv6 address 2001:192:10:1::100/64 ! interface GigabitEthernet0/1 ipv6 address 2001:164:1:26::6/64



Task 7.2 R1: interface Serial0/0 ipv6 address 2001:164:1:12::1/64 frame-relay map ipv6 2001:164:1:12::2 102 broadcast R2: interface Serial0/0.12 point-to-point ipv6 address 2001:164:1:12::2/64 ! interface Serial0/0.23 point-to-point ipv6 address 2001:164:1:23::2/64 R3: interface Serial1/1.23 point-to-point ipv6 address 2001:164:1:23::3/64 Task 7.3 R1: interface Serial0/0 ipv6 rip 1 enable frame-relay map ipv6 FE80::2 102 ! interface Serial0/1 ipv6 rip 1 enable R2: interface FastEthernet0/0 ipv6 rip 1 enable ! interface Serial0/0.12 point-to-point ipv6 address FE80::2 link-local ipv6 rip 1 enable ! interface Serial0/0.23 point-to-point ipv6 rip 1 enable R3: interface Serial1/1.23 point-to-point ipv6 rip 1 enable ! interface Serial1/2 ipv6 rip 1 enable R6: interface GigabitEthernet0/1 ipv6 rip 1 enable



Task 7.4 R1: router bgp 300 neighbor 2001:164:1:12::2 remote-as 200 neighbor 2001:164:1:13::3 remote-as 200 ! address-family ipv6 neighbor 2001:164:1:12::2 activate neighbor 2001:164:1:13::3 activate R2: router bgp 200 neighbor 2001:164:1:12::1 remote-as 300 neighbor 2001:164:1:23::3 remote-as 200 neighbor 2001:164:1:26::6 remote-as 200 ! address-family ipv6 neighbor 2001:164:1:12::1 activate neighbor 2001:164:1:23::3 activate neighbor 2001:164:1:26::6 activate neighbor 2001:164:1:23::3 route-reflector-client neighbor 2001:164:1:26::6 route-reflector-client R3: router bgp 200 neighbor 2001:164:1:13::1 remote-as 300 neighbor 2001:164:1:23::2 remote-as 200 ! address-family ipv6 neighbor 2001:164:1:13::1 activate neighbor 2001:164:1:23::2 activate R6: router bgp 200 neighbor 2001:164:1:26::2 remote-as 200 ! address-family ipv6 neighbor 2001:164:1:26::2 activate



Task 7.5 R6: router bgp 200 neighbor 2001:192:1:10::254 remote-as 254 ! address-family ipv6 neighbor 2001:192:1:10::254 activate network 2001:164:1:26::/64 aggregate-address 2001:164:1::/58 summary-only Task 7.5 Breakdown In order to aggregate the IPv6 prefixes first write them out for comparison: 2001:0164:0001:0012::/64 2001:0164:0001:0013::/64 2001:0164:0001:0023::/64 2001:0164:0001:0026::/64 Based on this it is evident that the first 14 digits are contiguous. Since IPv6 addresses are in hex these 14 digits = 14 * 4 bits = 56 bits. Now to summarize beyond this write the fourth most significant grouping out in binary: 2001:0164:0001:0012 = 2001:0164:0001:00000000.00010010 2001:0164:0001:0013 = 2001:0164:0001:00000000.00010011 2001:0164:0001:0023 = 2001:0164:0001:00000000.00100011 2001:0164:0001:0026 = 2001:0164:0001:00000000.00100110 FFFF:FFFF:FFFF.11111111.11000000 Based on this we can see that 58 bits are contiguous, so the resulting prefix is 2001:164:1::/58



8. QoS Task 8.1 R3: interface Serial1/0 frame-relay traffic-shaping ! interface Serial1/0.34 frame-relay interface-dlci 304 class DLCI_304 ! interface Serial1/0.35 frame-relay interface-dlci 305 class DLCI_305 ! map-class frame-relay DLCI_304 frame-relay cir 256000 frame-relay bc 2560 frame-relay fragment 320 ! map-class frame-relay DLCI_305 frame-relay cir 256000 frame-relay bc 2560 frame-relay fragment 320 R4: interface Serial0/0 frame-relay traffic-shaping frame-relay interface-dlci 403 class DLCI_403 ! map-class frame-relay DLCI_403 frame-relay cir 256000 frame-relay bc 2560 frame-relay fragment 320 R5: interface Serial0/0 frame-relay traffic-shaping frame-relay interface-dlci 503 class DLCI_503 ! map-class frame-relay DLCI_503 frame-relay cir 256000 frame-relay bc 2560 frame-relay fragment 320


Task 8.1 Breakdown

Previous Reference Frame Relay Traffic Shaping: Lab 1 Frame Relay Fragmentation: Lab 7

Task 8.2 R3: class-map match-all VoIP match access-group name VoIP ! policy-map LLQ class VoIP priority 200 ! ip access-list extended VoIP permit udp any any range 16384 32767 ! map-class frame-relay DLCI_304 frame-relay mincir 256000 service-policy output LLQ R4: class-map match-all VoIP match access-group name VoIP ! policy-map LLQ class VoIP priority 200 ! ip access-list extended VoIP permit udp any any range 16384 32767 ! map-class frame-relay DLCI_403 frame-relay mincir 256000 service-policy output LLQ



Task 8.2 Breakdown

Note The MQC uses the mincir value in the Frame Relay map-class to determine the available bandwidth on a VC. Since MINCIR defaults to half of the configured CIR, it may be required to adjust the MINCIR value higher if the reserved bandwidth exceeds half of the configured CIR, regardless of whether adaptive shaping is enabled.

Previous Reference MQC Low Latency Queueing: Lab 6




9. Security Task 9.1 SW1: username RDP password 0 CISCO ! interface FastEthernet0/4 ip access-group REMOTE_DESKTOP in ! ip access-list extended REMOTE_DESKTOP dynamic RDP permit tcp any host 164.1.7.100 eq 3389 deny tcp any host 164.1.7.100 eq 3389 permit ip any any ! line vty 0 4 login local autocommand access-enable host timeout 10 Task 9.1 This type of access-list configuration is known as a lock-and-key, or dynamic access-list. When the access-list is applied, the dynamic entry does not exist in the list. This is similar to how an entry can be inactive when referencing a time range. When the command access-enable is executed, all dynamic entries are inserted into the access-list. The command autocommand access-enable means that when a user logs in via the VTY line, the command access-enable will automatically execute. This is simply a way to automate the running of the command. The autocommand access-enable command can also be placed in the local user database on a per user basis. In the above case the autocommand applies The host option of the access-enable statement dictates that only the host that authenticated will be allowed access through the dynamic statement. This is accomplished by dynamically creating a copy of the configured dynamic entry or entries with the source IP address as the authenticated address.


Verification SW1#show access-lists Extended IP access list REMOTE_DESKTOP Dynamic RDP permit tcp any host 164.1.7.100 eq 3389 deny tcp any host 164.1.7.100 eq 3389 permit ip any any dynamic entry closed SW1#telnet 150.1.7.7 Trying 150.1.7.7 ... Open User Access Verification Username: RDP Password: [Connection to 150.1.7.7 closed by foreign host] authentication successful SW1#show access-lists Extended IP access list REMOTE_DESKTOP Dynamic RDP permit tcp any host 164.1.7.100 eq 3389 permit tcp host 150.1.7.7 host 164.1.7.100 eq 3389 deny tcp any host 164.1.7.100 eq 3389 permit ip any any (59 matches) dynamic entry open

Further Reading Configuring Lock-and-Key Security (Dynamic Access Lists)


http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_c/ftrafwl/scflock.htm


Task 9.2 SW1: username NOC password 0 CISCO ! access-list 100 permit tcp any any eq telnet access-list 100 permit tcp any any eq 3023 ! line vty 0 login local autocommand access-enable host timeout 10 ! line vty 1 4 no autocommand access-enable access-class 100 in rotary 23 Task 9.2 Breakdown Since the command autocommand access-enable applies to all users starting an exec process through the VTY line, regular telnet access at port 23 is no longer available for the management on the CLI. In order to still allow users to be able to telnet into the router to manage it, the properties applied to the VTY lines have been split into two. The first VTY line (VTY 0) is left with the autocommand access-enable command. All users that telnet to the router at port 23 will hit this line. The rotary command under the VTY line allows the router to listen for telnet sessions at higher port ranges (30xx, 50xx, 70xx, 100xx, where x is the configured rotary option), so users can still telnet in to access the CLI.

Verification SW1#telnet 150.1.7.7 Trying 150.1.7.7 ... Open User Access Verification Username: RDP telneting at port 23 hits the access-enable command Password: [Connection to 150.1.7.7 closed by foreign host] SW1#telnet 150.1.7.7 3023 Trying 150.1.7.7, 3023 ... Open User Access Verification Username: RDP Password: SW1> telneting at port 3023 accesses the CLI



10. System Management Task 10.1 R1 - SW2: banner exec " *****************************WARNING***************************** * * * All connections to this device are logged * * Unauthorized use of this system is strictly prohibited * * Violators will be prosecuted to the fullest extent of the law * * * *****************************WARNING***************************** " Task 10.1 Breakdown The exec banner will be displayed every time the exec process is initiated. Therefore no matter which line a user comes in on (console, AUX, VTY), the banner will be displayed.

Verification SW1 con0 is now available Press RETURN to get started. *****************************WARNING***************************** * * * All connections to this device are logged * * Unauthorized use of this system is strictly prohibited * * Violators will be prosecuted to the fullest extent of the law * * * *****************************WARNING***************************** SW1>en SW1#telnet 150.1.7.7 3023 Trying 150.1.7.7, 3023 ... Open User Access Verification Username: RDP Password: *****************************WARNING***************************** * * * All connections to this device are logged * * Unauthorized use of this system is strictly prohibited * * Violators will be prosecuted to the fullest extent of the law * * * *****************************WARNING*****************************



11. IP Services Task 11.1 R6: key chain DRP key 1 key-string CISCO ! ip drp access-group 10 ip drp authentication key-chain DRP ip drp server ! access-list 10 permit 185.28.8.143 access-list 10 permit 104.12.8.215 Task 11.1 Breakdown Director Response Protocol (DRP) server agent is used to communicate with the Cisco DistributedDirector platform. This configuration is used when there are multiple mirrored resources located in different geographic locations. The DistributedDirector can instruct the router where to forward client requests based on server utilization, response time from the server, etc. The only configuration that is required to enable DRP is the global configuration command ip drp server. The DistributedDirector platform will then be configured to specify the router’s IP address. In the above example the directors that can communicate with the router have been limited to those listed in access-list 10. Additionally these directors must authenticate with MD5.

Further Reading Configuring Cisco Routers as DRP Server Agents


http://www.cisco.com/en/US/products/hw/contnetw/ps813/products_installation_guide_chapter09186a008007d794.html

Solution.

Documents

Transcript of Solution.