1. Bridging and Switching

Transcription

1 1. Bridging and Switching Task 1.1 SW1: Rack1SW1#vlan database Rack1SW1(vlan)#vtp domain IE Changing VTP domain name from NULL to IE Rack1SW1(vlan)#vtp password CISCO Setting device VLAN database password to CISCO. Rack1SW1(vlan)#vtp pruning Pruning switched ON Rack1SW1(vlan)#vlan 6 name VLAN_F VLAN 6 added: Name: VLAN_F Rack1SW1(vlan)#vlan 7 name VLAN_G VLAN 7 added: Name: VLAN_G Rack1SW1(vlan)#vlan 8 name VLAN_H VLAN 8 added: Name: VLAN_H Rack1SW1(vlan)#vlan 12 name VLAN_AB VLAN 12 added: Name: VLAN_AB Rack1SW1(vlan)#vlan 36 name VLAN_CF VLAN 36 added: Name: VLAN_CF Rack1SW1(vlan)#vlan 43 name VLAN_DC VLAN 43 added: Name: VLAN_DC Rack1SW1(vlan)#vlan 45 name VLAN_DE VLAN 45 added: Name: VLAN_DE Rack1SW1(vlan)#vlan 77 name VLAN_GG VLAN 77 added: Name: VLAN_GG Rack1SW1(vlan)#vlan 88 name VLAN_HH VLAN 88 added: Name: VLAN_HH Rack1SW1(vlan)#vlan 255 name VLAN_BEE VLAN 255 added: Name: VLAN_BEE Rack1SW1(vlan)#vlan 258 name VLAN_BEH VLAN 258 added: Name: VLAN_BEH Rack1SW1(vlan)#exit APPLY completed. Exiting... Quick Note The VLAN and VTP pruning commands only need to be applied to one switch within the VTP domain interface FastEthernet1/1 switchport access vlan 12 interface FastEthernet1/5 switchport access vlan

2 SW2: Rack1SW2#vlan database Rack1SW2(vlan)#vtp domain IE Changing VTP domain name from NULL to IE Rack1SW2(vlan)#vtp password CISCO Setting device VLAN database password to CISCO interface FastEthernet1/2 switchport access vlan 258 interface FastEthernet1/4 switchport access vlan 45 interface FastEthernet1/6 switchport access vlan 36 interface FastEthernet1/0 switchport access vlan 12 SW3: Rack1SW3#vlan database Rack1SW3(vlan)#vtp domain IE Changing VTP domain name from NULL to IE Rack1SW3(vlan)#vtp password CISCO Setting device VLAN database password to CISCO interface FastEthernet1/3 switchport access vlan 36 interface FastEthernet1/5 switchport access vlan 258 interface FastEthernet1/0 switchport access vlan 43 SW4: Rack1SW4#vlan database Rack1SW4(vlan)#vtp domain IE Changing VTP domain name from NULL to IE Rack1SW4(vlan)#vtp password CISCO Setting device VLAN database password to CISCO interface FastEthernet1/4 switchport access vlan 43 interface FastEthernet1/6 switchport access vlan 6 Task 1.1 Verification Rack1SW1#show vtp status VTP Version : 2 Configuration Revision : 9 Maximum VLANs supported locally : 256 Number of existing VLANs : 16 VTP Operating Mode : Server - 2 -

3 VTP Domain Name : IE VTP Pruning Mode : Enabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled MD5 digest : 0x51 0x0E 0x69 0xEC 0x9A 0x24 0xE3 0xD0 Configuration last modified by at :04:28 Local updater ID is on interface Vl7 (lowest numbered VLAN interface found) Verify the VTP status and VLAN assignments: Rack1SW1#show vtp status include Domain Pruning VTP Domain Name : IE VTP Pruning Mode : Enabled Rack1SW2#show vtp status include Domain Pruning VTP Domain Name : IE VTP Pruning Mode : Enabled Rack1SW3#show vtp status include Domain Pruning VTP Domain Name : IE VTP Pruning Mode : Enabled Rack1SW4#show vtp status include Domain Pruning VTP Domain Name : IE VTP Pruning Mode : Enabled Rack1SW1#show vlan-switch brief VLAN Name Status Ports default active Fa1/0, Fa1/2, Fa1/4, Fa1/6 Fa1/10, Fa1/11, Fa1/12 6 VLAN_F active 7 VLAN_G active 8 VLAN_H active 12 VLAN_AB active Fa1/1 36 VLAN_CF active 43 VLAN_DC active 45 VLAN_DE active Fa1/5 77 VLAN_GG active 88 VLAN_HH active 255 VLAN_BEE active 258 VLAN_BEH active 1002 fddi-default active 1003 token-ring-default active 1004 fddinet-default active 1005 trnet-default active - 3 -

4 Rack1SW2#show vlan-switch brief VLAN Name Status Ports default active Fa1/1, Fa1/3, Fa1/5, Fa1/13 Fa1/14, Fa1/15 6 VLAN_F active 7 VLAN_G active 8 VLAN_H active 12 VLAN_AB active Fa1/0 36 VLAN_CF active Fa1/6 43 VLAN_DC active 45 VLAN_DE active Fa1/4 77 VLAN_GG active 88 VLAN_HH active 255 VLAN_BEE active 258 VLAN_BEH active Fa1/ fddi-default active 1003 token-ring-default active 1004 fddinet-default active 1005 trnet-default active Rack1SW3#show vlan-switch brief VLAN Name Status Ports default active Fa1/1, Fa1/2, Fa1/4, Fa1/6 Fa1/7, Fa1/8, Fa1/9 6 VLAN_F active 7 VLAN_G active 8 VLAN_H active 12 VLAN_AB active 36 VLAN_CF active Fa1/3 43 VLAN_DC active Fa1/0 45 VLAN_DE active 77 VLAN_GG active 88 VLAN_HH active 255 VLAN_BEE active 258 VLAN_BEH active Fa1/ fddi-default active 1003 token-ring-default active 1004 fddinet-default active 1005 trnet-default active - 4 -

5 Rack1SW4#show vlan-switch brief VLAN Name Status Ports default active Fa1/0, Fa1/1, Fa1/2, Fa1/3 Fa1/5, Fa1/10, Fa1/11, Fa1/12 6 VLAN_F active Fa1/6 7 VLAN_G active 8 VLAN_H active 12 VLAN_AB active 36 VLAN_CF active 43 VLAN_DC active Fa1/4 45 VLAN_DE active 77 VLAN_GG active 88 VLAN_HH active 255 VLAN_BEE active 258 VLAN_BEH active 1002 fddi-default active 1003 token-ring-default active 1004 fddinet-default active 1005 trnet-default active Task 1.2 SW1: interface FastEthernet1/7 description To SW2 F1/7 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/8 description To SW2 F1/8 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/9 description To SW2 F1/9 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/13 description To SW4 F1/7 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/14 description To SW4 F1/8 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/15-5 -

6 description To SW4 F1/9 switchport trunk native vlan 255 switchport mode trunk no shutdown SW2: interface FastEthernet1/7 description To SW1 F1/7 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/8 description To SW1 F1/8 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/9 description To SW1 F1/9 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/10 description To SW3 F1/10 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/11 description To SW3 F1/11 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/12 description To SW3 F1/12 switchport trunk native vlan 255 switchport mode trunk no shutdown SW3: interface FastEthernet1/10 description To SW2 F1/10 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/11 description To SW2 F1/11 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/12 description To SW2 F1/12-6 -

7 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/13 description To SW4 F1/13 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/14 description To SW4 F1/14 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/15 description To SW4 F1/15 switchport trunk native vlan 255 switchport mode trunk no shutdown SW4: interface FastEthernet1/7 description To SW1 F1/13 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/8 description To SW1 F1/14 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/9 description To SW1 F1/15 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/13 description To SW3 F1/13 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/14 description To SW3 F1/14 switchport trunk native vlan 255 switchport mode trunk no shutdown interface FastEthernet1/15 description To SW3 F1/15 switchport trunk native vlan 255 switchport mode trunk - 7 -

8 no shutdown Task 1.2 Verification Rack1SW1#show interfaces trunk Port Mode Encapsulation Status Native vlan Fa1/7 on 802.1q trunking 255 Fa1/8 on 802.1q trunking 255 Fa1/9 on 802.1q trunking 255 Fa1/13 on 802.1q trunking 255 Fa1/14 on 802.1q trunking 255 Fa1/15 on 802.1q trunking 255 <output omitted> Rack1SW2#show interfaces trunk Port Mode Encapsulation Status Native vlan Fa1/7 on 802.1q trunking 255 Fa1/8 on 802.1q trunking 255 Fa1/9 on 802.1q trunking 255 Fa1/10 on 802.1q trunking 255 Fa1/11 on 802.1q trunking 255 Fa1/12 on 802.1q trunking 255 <output omitted> Rack1SW3#show interfaces trunk Port Mode Encapsulation Status Native vlan Fa1/10 on 802.1q trunking 255 Fa1/11 on 802.1q trunking 255 Fa1/12 on 802.1q trunking 255 Fa1/13 on 802.1q trunking 255 Fa1/14 on 802.1q trunking 255 Fa1/15 on 802.1q trunking 255 Rack1SW4#show interfaces trunk Port Mode Encapsulation Status Native vlan Fa1/7 on 802.1q trunking 255 Fa1/8 on 802.1q trunking 255 Fa1/9 on 802.1q trunking 255 Fa1/13 on 802.1q trunking 255 Fa1/14 on 802.1q trunking 255 Fa1/15 on 802.1q trunking

9 Task 1.3 SW1: spanning-tree vlan 258 root primary SW3: spanning-tree vlan 258 root secondary SW2: interface range Fa1/7-9 spanning-tree vlan 258 cost 100 Task 1.3 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 to use the fewest number of commands to accomplish this task and do not alter SW1 s port-priority. Since SW1 is the root of the spanningtree, the appropriate value to change is the spanning tree cost for VLAN 258 on SW2. 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 spanningtree port-priority. Port-priority is only locally significant between two directly connected bridges

10 Task 1.3 Verification Rack1SW2#show spanning-tree vlan 258 brief VLAN258 Spanning tree enabled protocol ieee Root ID Priority 8192 Address cc06.030f.000b Cost 57 Port 51 (FastEthernet1/10) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority Address cc b Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 Interface Designated Name Port ID Prio Cost Sts Cost Bridge ID Port ID FastEthernet1/ FWD cc b FastEthernet1/ BLK cc06.030f.000b FastEthernet1/ BLK cc06.030f.000b FastEthernet1/ BLK cc06.030f.000b FastEthernet1/ FWD cc b FastEthernet1/ BLK cc b Interface Designated Name Port ID Prio Cost Sts Cost Bridge ID Port ID FastEthernet1/ BLK cc b Task 1.4 SW4: interface FastEthernet1/15 spanning-tree vlan 258 port-priority 16 Task 1.4 Breakdown As mentioned earlier the two common methods to affect the spanning-tree path to the root are cost and port-priority. The key to remembering which to use where is to understand the direction these two options affect in regards to spanning tree. When going away from the root of the tree use port-priority. When going towards the root of the tree use cost. Task 1.4 Verification Rack1SW3#show spanning-tree vlan 258 in Fa1/15 Port 56 (FastEthernet1/15) FastEthernet1/ FWD cc b

11 Task 1.5 SW1: interface FastEthernet1/1 storm-control unicast level Task 1.5 Breakdown Storm control limits the amount of unicast, multicast, or broadcast traffic that is received on a layer 2 switchport. When the threshold of unicast or broadcast traffic is exceeded, traffic in excess of the threshold is dropped. When the multicast threshold is exceeded, all unicast, multicast, or broadcast traffic is dropped until the level falls below the threshold. To configure storm-control issue the storm-control [unicast broadcast multicast] level [level] interface level command. The 3550 and 3560 both support using the PPS (Packets Per Second) option with the storm-control command but the 3550 does not support the BPS (Bits Per Second) option. Pitfall Do not assume that the task title will directly indicate the solution. In this case the title of the task is Rate-Limiting but the solution used is stormcontrol. Task 1.5 Verification Rack1SW1#show storm-control f1/1 unicast Interface Filter State Upper Lower Current Fa1/1 Forwarding 80.00% 80.00% 0.00% Task 1.6 SW2: mls qos map cos-dscp Task 1.6 Verification Rack1SW2#show mls qos maps cos-dscp Cos-dscp map: ipprec: dscp:

12 Task 1.7 SW2: interface FastEthernet0/2 mls qos trust cos Task 1.7 Verification Rack1SW2#show mls qos interface f1/2 FastEthernet1/2 trust state: trust cos trust mode: trust cos COS override: dis default COS: 0 pass-through: none Further Reading Configuring Classification Using Port Trust States

13 2. Frame-Relay Task 2.1 R1: interface Serial1/0 encapsulation frame-relay no frame-relay inverse-arp interface Serial1/0.1 point-to-point ip address frame-relay interface-dlci 102 R2: interface Serial1/0 ip address encapsulation frame-relay frame-relay map ip broadcast frame-relay map ip 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 frame-relay interface-dlci 302 Task 2.1 Verification Rack1R2#show frame-relay map Serial1/0 (up): ip dlci 201(0xC9,0x3090), static, broadcast, CISCO, status defined, active Serial1/0 (up): ip dlci 203(0xCB,0x30B0), static, broadcast, CISCO, status defined, active Rack1R1#ping Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds: Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms Rack1R1#ping Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds: Success rate is 100 percent (5/5), round-trip min/avg/max = 32/36/40 ms

14 Task 2.2 R4: interface Serial1/0 ip address encapsulation frame-relay frame-relay map ip broadcast no frame-relay inverse-arp R5: interface Serial1/0 ip address encapsulation frame-relay frame-relay map ip broadcast no frame-relay inverse-arp Task 2.2 Verification Verify reachability: Rack1R4#ping Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds: Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms Task 2.3 R6: interface Serial1/0 ip address encapsulation frame-relay frame-relay map ip broadcast no frame-relay inverse-arp Task 2.3 Verification Rack1R6#show frame-relay map Serial1/0 (up): ip dlci 101(0x65,0x1850), static, broadcast, CISCO, status defined, active Rack1R6#ping Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds: Success rate is 100 percent (5/5), round-trip min/avg/max = 60/60/64 ms

15 3. HDLC/PPP Task 3.1 R4: username Rack1R5 password 0 CISCO interface Serial1/1 encapsulation ppp ppp authentication pap R5: username Rack1R4 password 0 CISCO interface Serial1/1 encapsulation ppp clockrate ppp authentication chap ppp pap sent-username Rack1R5 password 0 CISCO Task 3.1 Verification Verify that the correct authentication protocols are being used. R4 should request to authenticate R5 via PAP and R5 should request to authenticate R4 via CHAP. Rack1R5#debug ppp authentication Rack1R5#conf t Rack1R5(config)#interface s1/1 Rack1R5(config-if)#shutdown Rack1R5(config-if)#no shutdown Se0/1 PPP: Using default call direction Se0/1 PPP: Treating connection as a dedicated line Se0/1 PPP: Session handle[ ] Session id[2] Se0/1 PPP: Authorization required Se0/1 PAP: Using hostname from interface PAP Se0/1 PAP: Using password from interface PAP Se0/1 PAP: O AUTH-REQ id 2 len 18 from "Rack1R5" Se0/1 CHAP: O CHALLENGE id 1 len 28 from "Rack1R5" Se0/1 PAP: I AUTH-ACK id 2 len 5 Se0/1 CHAP: I RESPONSE id 1 len 28 from "Rack1R4" Se0/1 PPP: Sent CHAP LOGIN Request Se0/1 PPP: Received LOGIN Response PASS Se0/1 PPP: Sent LCP AUTHOR Request Se0/1 PPP: Sent IPCP AUTHOR Request Se0/1 LCP: Received AAA AUTHOR Response PASS Se0/1 IPCP: Received AAA AUTHOR Response PASS Se0/1 CHAP: O SUCCESS id 1 len 4 Se0/1 PPP: Sent CDPCP AUTHOR Request Se0/1 CDPCP: Received AAA AUTHOR Response PASS Se0/1 PPP: Sent IPCP AUTHOR Request

16 Task 3.2 R4 and R5: interface Serial1/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. Task 3.2 Verification Rack1R4#show compress Serial1/1 Software compression enabled uncompressed bytes xmt/rcv 327/332 compressed bytes xmt/rcv 0/0 Compressed bytes sent: 0 bytes 0 Kbits/sec Compressed bytes recv: 0 bytes 0 Kbits/sec 1 min avg ratio xmt/rcv 0.709/ min avg ratio xmt/rcv 0.709/ min avg ratio xmt/rcv 0.709/0.922 no bufs xmt 0 no bufs rcv 0 resyncs 0 Rack1R4#ping Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds: Success rate is 100 percent (5/5), round-trip min/avg/max = 16/16/16 ms Rack1R4#show compress Serial1/1 Software compression enabled uncompressed bytes xmt/rcv 837/842 compressed bytes xmt/rcv 170/168 Compressed bytes sent: 170 bytes 0 Kbits/sec ratio: Compressed bytes recv: 168 bytes 0 Kbits/sec ratio: min avg ratio xmt/rcv 1.190/ min avg ratio xmt/rcv 1.190/ min avg ratio xmt/rcv 1.190/1.482 no bufs xmt 0 no bufs rcv 0 resyncs

17 4. Interior Gateway Routing Task 4.1 R1: interface Serial1/0.1 point-to-point ip ospf network non-broadcast ip ospf priority 0 router ospf 1 router-id network area 0 R2: router ospf 1 router-id network area 0 neighbor neighbor R3: interface Serial1/0.1 point-to-point ip ospf network non-broadcast ip ospf priority 0 router ospf 1 router-id network 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

18 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.1 Verification Verify OSPF neighbors for instance on R2: Rack1R2#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface FULL/DROTHER 00:01: Serial1/ FULL/DROTHER 00:01: Serial1/0 Verify OSPF interface on R1 to see network type and priority: Rack1R1#show ip ospf interface s1/0.1 Serial1/0.1 is up, line protocol is up Internet Address /24, Area 0 Process ID 1,Router ID ,Network Type NON_BROADCAST, Cost: 64 Transmit Delay is 1 sec, State DROTHER, Priority 0 Caution If you receive a log message similar to the one below check to ensure the router does not have any Frame Relay mappings to the IP address. %OSPF-5-ADJCHG: Process 1, Nbr on Serial0/0 from ATTEMPT to DOWN, Neighbor Down: Dead timer expired

19 Task 4.2 R1: interface FastEthernet0/0 ip ospf network non-broadcast ip ospf hello-interval 10 router ospf 1 network area 51 neighbor 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

20 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 nonbroadcast. 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

21 Task 4.2 Verification Rack1R1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface FULL/DR 00:01: Serial1/ FULL/DR 00:00: FastEthernet0/0 Rack1R1#show ip ospf interface fa0/0 FastEthernet0/0 is up, line protocol is up Internet Address /24, Area 51 Process ID 1, Router ID , Network Type NON_BROADCAST,Cost: 1 Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) , Interface address Backup Designated router (ID) , Interface address Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 <output omitted> Check to see if we are receiving multicast hello packets and sending unicast hellos: Rack1R1#debug ip packet IP: s= (local), d= (FastEthernet0/0), len 80, sending IP: s= (FastEthernet0/0), d= , len 80, rcvd

22 Task 4.3 R1: router ospf 1 network area 0 R2: router ospf 1 network area 0 network area 1 R3: router ospf 1 network area 0 R5: router ospf 1 router-id network area 1 SW2: ip routing router ospf 1 router-id redistribute connected subnets route-map CONNECTED->OSPF network area 1 network area 1 network area 1 network area 1 route-map CONNECTED->OSPF permit 10 match interface Loopback0 SW3 and SW4: no ip routing ip default-gateway Task 4.3 Verification Verify interface s area (e.g. on R3): Rack1R3#show ip ospf interface lo0 Loopback0 is up, line protocol is up Internet Address /24, Area 0 Process ID 1, Router ID , Network Type LOOPBACK, Cost: 1 Loopback interface is treated as a stub Host Verify OSPF routes and specifically verify SW2 s Loopback0 prefix: Rack1R3#show ip route ospf <output omitted> O /32 [110/782] via , 00:04:03, Serial1/0.1 O /32 [110/782] via , 00:04:03, Serial1/0.1 O E /24 [110/20] via , 00:03:02, Serial1/

23 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.4 Verification Verify the area configuration and the translated prefixes: Rack1R2#show ip ospf begin Area 1 Area 1 Number of interfaces in this area is 1 It is a NSSA area Perform type-7/type-5 LSA translation <output omitted> Rack1R2#show ip route ospf include O N /24 [110/20] via , 00:23:07, FastEthernet0/0 Rack1R1#show ip route ospf include O E /24 [110/20] via , 00:27:24, Serial1/

24 Task 4.5 R2: interface Tunnel0 ip address tunnel source FastEthernet0/0 tunnel destination router ospf 1 network area 0 Quick Note Virtual-Link cannot be created over a stub area R4: interface Serial1/0 ip ospf network point-to-point router ospf 1 router-id network area 2 network area 2 network area 2 network area 2 R5: interface Serial1/0 ip ospf network point-to-point interface Tunnel0 ip address tunnel source Ethernet0/1 tunnel destination router ospf 1 router-id network area 0 network area 2 network area 2 network area 2 network area 2 Quick Note Virtual-Link cannot be created over a stub area Task 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

25 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 nonbroadcast 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. 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 7 NSSA External it leaves the NSSA area. These routes appear as LSA 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

26 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-totallystubby 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

27 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.5 Verification Verify that tunnel is up and running in OSPF area 0: Rack1R5#show interfaces tu0 Tunnel0 is up, line protocol is up Hardware is Tunnel Internet address is /24 <output omitted> Rack1R5#show ip ospf interface tu0 Tunnel0 is up, line protocol is up Internet Address /24, Area 0 Process ID 1, Router ID , Network Type POINT_TO_POINT, Cost: Transmit Delay is 1 sec, State POINT_TO_POINT, <output omitted> Rack1R5#ping Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds: Success rate is 100 percent (5/5), round-trip min/avg/max = 4/10/36 ms Next verify OSPF neighbors on the tunnel:

28 Rack1R5#show ip ospf neighbor tu0 Neighbor ID Pri State Dead Time Address Interface FULL/ - 00:00: Tunnel0 Finally verify that we are seeing R5 and R2 Loopback0 prefixes as inter-area summary prefixes on R1: Rack1R1#show ip route ospf include ( ) O IA /32 [110/11176] via , 01:44:25, Serial1/0.1 O IA /32 [110/11186] via , 01:44:19, Serial1/0.1 Task 4.6 R4 and R5: interface Serial1/0 bandwidth 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

29 Task 4.6 Verification Verify that equal-cost load balancing is actually occurring: Rack1R4#show ip route Routing entry for /32 Known via "ospf 1", distance 110, metric 11, type intra area Last update from on Ethernet0/0, 00:00:05 ago Routing Descriptor Blocks: * , from , 00:00:05 ago, via Ethernet0/0 Route metric is 11, traffic share count is , from , 00:00:05 ago, via Serial1/0 Route metric is 11, traffic share count is 1 Rack1R5#show ip route Routing entry for /32 Known via "ospf 1", distance 110, metric 11, type intra area Last update from on Ethernet0/0, 00:01:29 ago Routing Descriptor Blocks: * , from , 00:01:29 ago, via Ethernet0/0 Route metric is 11, traffic share count is , from , 00:01:29 ago, via Serial1/0 Route metric is 11, traffic share count is 1 Task 4.7 R4: interface Ethernet0/0 ip ospf hello-interval 2 interface Serial1/0 ip ospf hello-interval 2 R5: interface Ethernet0/0 ip ospf hello-interval 2 interface Serial1/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

30 Task 4.7 Verification Verify the hello and dead timers: Rack1R5#show ip ospf interface e0/0 Ethernet0/0 is up, line protocol is up Internet Address /24, Area 2 Process ID 1, Router ID , Network Type BROADCAST, Cost: 10 Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) , Interface address Backup Designated router (ID) , Interface address Timer intervals configured, Hello 2, Dead 8, Wait 8, Retransmit 5 <output omitted> Task 4.8 R3: router rip version 2 passive-interface default no passive-interface Ethernet0/0 no passive-interface Ethernet0/1 network no auto-summary R4: router rip version 2 network no auto-summary R6: router rip version 2 passive-interface default no passive-interface Ethernet0/0 network no auto-summary SW1: ip routing router rip version 2 network network no auto-summary

31 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.8 Verification Verify that RIP is configured and verify the passive interfaces: Rack1R3#show ip protocols begin rip Routing Protocol is "rip" Sending updates every 30 seconds, next due in 22 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 2, receive version 2 Interface Send Recv Triggered RIP Key-chain Ethernet0/0 2 2 Ethernet0/1 2 2 Automatic network summarization is not in effect Maximum path: 4 Routing for Networks: Passive Interface(s): Serial1/0 Serial1/0.1 Serial1/1 Serial1/2 Serial1/3 Loopback0 VoIP-Null0 Routing Information Sources: Gateway Distance Last Update :00: :00:18 Distance: (default is 120)

32 Task 4.9 R6: router rip network no passive-interface Serial1/0 offset-list 1 in 9 Serial1/0 network access-list 1 permit 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. Strategy Tip 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.9 Verification Verify that the prefixes with even 3rd octet have a RIP metric of 10: Rack1R6#show ip route rip include R /24 [120/1] via , 00:00:05, Serial1/0 R /24 [120/10] via , 00:00:05, Serial1/0 R /24 [120/1] via , 00:00:05, Serial1/0 R /24 [120/10] via , 00:00:05, Serial1/0-32 -

33 Task 4.10 R3: router ospf 1 redistribute rip subnets router rip redistribute ospf 1 metric 1 R4: router ospf 1 summary-address summary-address redistribute rip subnets route-map RIP->OSPF router rip version 2 redistribute ospf 1 metric 1 ip prefix-list VLAN43 seq 5 permit /24 route-map RIP->OSPF permit 10 match ip address prefix-list VLAN43 set metric 100 route-map RIP->OSPF permit 20 set metric-type type-1 Task 4.10 Breakdown The following networks are learned from BB3 via RIP: / / / / / / / /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

34 Binary Decimal 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 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 /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 /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

35 Task 4.10 Verification Verify that we see only the summary prefixes in the OSPF domain for routes learned from BB3 (note the metric type): Rack1R1#show ip route include (31 30) /14 is subnetted, 1 subnets O E [110/11205] via , 00:03:19, Serial1/ /14 is subnetted, 1 subnets O E [110/11205] via , 00:03:19, Serial1/0.1 Verify route for VLAN43 (note the metric): Rack1R1#show ip route include O E /24 [110/100] via , 00:06:46, Serial1/0.1 Next verify full connectivity between internal routers using the following TCL script: foreach i {

36 } {puts [ exec "ping $i" ] } Finally verify that backbone IGP prefixes are reachable from every internal router using the TCL script below: foreach i { } {puts [ exec "ping $i" ] }

37 5. IP Multicast Task 5.1 R1: ip multicast-routing interface FastEthernet0/0 ip pim sparse-mode interface Serial1/0.1 point-to-point ip pim sparse-mode R2: ip multicast-routing interface FastEthernet0/0 ip pim sparse-mode interface Serial1/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 Serial1/0 ip pim sparse-mode R5: ip multicast-routing interface Ethernet0/0 ip pim sparse-mode interface Ethernet0/1 ip pim sparse-mode interface Serial1/0 ip pim sparse-mode

38 SW1: ip multicast-routing interface FastEthernet1/3 ip pim sparse-mode interface Vlan7 ip pim sparse-mode SW2: ip multicast-routing interface Vlan258 ip pim sparse-mode Task 5.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 R5: ip pim send-rp-announce Loopback0 scope 16 group-list 50 access-list 50 permit SW2: ip pim send-rp-discovery Loopback0 scope 16 Task 5.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 and 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

39 Task 5.2 Verification Verify the group to RP mappings on each multicast enabled router. For example on SW2: Rack1SW2#show ip pim rp mapping PIM Group-to-RP Mappings This system is an RP-mapping agent (Loopback0) Group(s) /8 RP (?), v2v1 Info source: (?), elected via Auto-RP Uptime: 00:00:58, expires: 00:01:57 Group(s) /8 RP (?), v2v1 Info source: (?), elected via Auto-RP Uptime: 00:00:11, expires: 00:02:49 Task 5.3 R2: interface Serial1/0 ip pim nbma-mode interface Tunnel0 ip pim sparse-mode R3: interface Ethernet0/0 ip igmp join-group interface Ethernet0/1 ip igmp join-group R5: interface Tunnel0 ip pim sparse-mode Task 5.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