IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
1. Bridging and Switching
Task 1.1
Quick Note
SW1:
The VLAN and VTP pruning
vtp domain IE
commands only need to be
vtp password CISCO
applied to one switch within
vtp pruning
the VTP domain
!
vlan 6
name VLAN_F
vlan 7
name VLAN_G
vlan 8
name VLAN_H
vlan 12
name VLAN_AB
vlan 36
name VLAN_CF
vlan 43
name VLAN_DC
vlan 45
name VLAN_DE
vlan 77
name VLAN_GG
vlan 88
name VLAN_HH
vlan 255
name VLAN_BEE
vlan 258
name VLAN_BEH
!
interface FastEthernet0/1
switchport access vlan 12
!
interface FastEthernet0/5
switchport access vlan 45
SW2:
vtp domain IE
vtp password CISCO
!
interface FastEthernet0/2
switchport access vlan 258
!
interface FastEthernet0/4
switchport access vlan 45
!
interface FastEthernet0/6
switchport access vlan 36
!
interface FastEthernet0/24
switchport access vlan 12
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 1
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
SW3:
vtp domain IE
vtp password CISCO
!
interface FastEthernet0/3
switchport access vlan 36
!
interface FastEthernet0/5
switchport access vlan 258
!
interface FastEthernet0/24
switchport access vlan 43
SW4:
vtp domain IE
vtp password CISCO
!
interface FastEthernet0/4
switchport access vlan 43
!
interface FastEthernet0/6
switchport access vlan 6
Task 1.1 Verification
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 brief | exclude unsup|^ |^1|active[ \t]+$
VLAN Name Status Ports
---- ------------------------ --------- ------------------------------
43 VLAN_DC active Fa0/24
45 VLAN_DE active Fa0/5
12 VLAN_AB active Fa0/1
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 2
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Rack1SW2#show vlan brief | exclude unsup|^ |^1|active[ \t]+$
VLAN Name Status Ports
---- ------------------------ --------- ------------------------------
12 VLAN_AB active Fa0/24
36 VLAN_CF active Fa0/6
45 VLAN_DE active Fa0/4
258 VLAN_BEH active Fa0/2
Rack1SW3#show vlan brief | exclude unsup|^ |^1|active[ \t]+$
VLAN Name Status Ports
---- ------------------------ --------- ------------------------------
36 VLAN_CF active Fa0/3
43 VLAN_DC active Fa0/24
258 VLAN_BEH active Fa0/5
Rack1SW4#show vlan brief | exclude unsup|^ |^1|active[ \t]+$
VLAN Name Status Ports
---- ------------------------ --------- ------------------------------
6 VLAN_F active Fa0/6
43 VLAN_DC active Fa0/4
Task 1.2
SW1:
interface range Fa0/13 - 15, Fa0/19 - 21
switchport trunk encapsulation dot1q
switchport trunk native vlan 255
switchport mode trunk
no shutdown
SW2:
interface range Fa0/13 - 18
switchport trunk encapsulation dot1q
switchport trunk native vlan 255
switchport mode trunk
no shutdown
SW3:
interface range Fa0/16 - 21
switchport trunk encapsulation dot1q
switchport trunk native vlan 255
switchport mode trunk
no shutdown
SW4:
interface range Fa0/13 - 15, Fa0/19 - 21
switchport trunk encapsulation dot1q
switchport trunk native vlan 255
switchport mode trunk
no shutdown
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 3
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 1.2 Verification
Rack1SW1#show interfaces trunk
Port Mode Encapsulation Status Native vlan
Fa0/13 on 802.1q trunking 255
Fa0/14 on 802.1q trunking 255
Fa0/15 on 802.1q trunking 255
Fa0/19 on 802.1q trunking 255
Fa0/20 on 802.1q trunking 255
Fa0/21 on 802.1q trunking 255

Rack1SW2#show interfaces trunk
Port Mode Encapsulation Status Native vlan
Fa0/13 on 802.1q trunking 255
Fa0/14 on 802.1q trunking 255
Fa0/15 on 802.1q trunking 255
Fa0/16 on 802.1q trunking 255
Fa0/17 on 802.1q trunking 255
Fa0/18 on 802.1q trunking 255

Rack1SW3#show interfaces trunk
Port Mode Encapsulation Status Native vlan
Fa0/16 on 802.1q trunking 255
Fa0/17 on 802.1q trunking 255
Fa0/18 on 802.1q trunking 255
Fa0/19 on 802.1q trunking 255
Fa0/20 on 802.1q trunking 255
Fa0/21 on 802.1q trunking 255
Rack1SW4#show interfaces trunk
Port Mode Encapsulation Status Native vlan
Fa0/13 on 802.1q trunking 255
Fa0/14 on 802.1q trunking 255
Fa0/15 on 802.1q trunking 255
Fa0/19 on 802.1q trunking 255
Fa0/20 on 802.1q trunking 255
Fa0/21 on 802.1q trunking 255
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 4
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 1.3
SW1:
interface FastEthernet 0/13
switchport trunk pruning vlan 2-7,9-1001
SW3:
interface FastEthernet 0/16
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.
Task 1.3 Verification
Rack1SW1#show interface fa0/13 switchport | include Pruning
Pruning VLANs Enabled: 2-1001 Prune eligible list
Rack1SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Rack1SW1(config)#interface fa0/13
Rack1SW1(config-if)#switchport trunk pruning vlan 2-7,9-1001

Delete vlan 8 from the prune eligible list
Rack1SW1(config)#^Z
Rack1SW1#show interface fa0/13 switchport | include Pruning
Pruning VLANs Enabled: 2-7,9-1001 VLAN 8 can no longer be pruned
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 5
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 1.4
SW1:
spanning-tree vlan 258 root primary
SW3:
spanning-tree vlan 258 root secondary
SW2:
interface range Fa0/13 - 15
spanning-tree vlan 258 cost 100
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 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 spanning-
tree, 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 spanning-
tree port-priority. Port-priority is only locally significant between two directly
connected bridges.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 6
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 1.4 Verification
Rack1SW2#show spanning-tree vlan 258
VLAN0258
Spanning tree enabled protocol ieee
Root ID Priority 24834
Address 000a.f4f3.e780
Cost 10
Port 18 (FastEthernet0/16) Root port
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- -----------------
Fa0/2 Desg FWD 19 128.4 P2p
Fa0/13 Altn BLK 100 128.15 P2p
Fa0/14 Altn BLK 100 128.16 P2p
Fa0/15 Altn BLK 100 128.17 P2p
Fa0/16 Root FWD 19 128.18 P2p
Fa0/17 Altn BLK 19 128.19 P2p
Fa0/18 Altn BLK 19 128.20 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.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 7
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 8
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 1.5 Verification
Verify the UDLD configuration:
Rack1SW2#show udld fa0/15
Interface Fa0/15
---
Port enable administrative configuration setting: Enabled / in
aggressive mode
Port enable operational state: Enabled / in aggressive mode
Current bidirectional state: Bidirectional
Current operational state: Advertisement - Single neighbor detected
Message interval: 7
Time out interval: 5

Verify loop guard on SW1 Fa0/15:
Rack1SW1#show spanning-tree interface fa0/15 detail

Link type is point-to-point by default
Loop guard is enabled on the port
BPDU: sent 1234, received 21

Task 1.6
SW4:
interface FastEthernet0/21
spanning-tree vlan 258 port-priority 16
Task 1.6 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.6 Verification
Rack1SW3#show spanning-tree vlan 258 | in Fa0/21
Fa0/21 Root FWD 19 128.21 P2p
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 9
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 1.7
SW1, SW2, SW3, and SW4:
spanning-tree pathcost method long
Task 1.7 Breakdown
By default spanning-tree uses a 16-bit based number for path cost. This allows
for costs up to 65535. By setting the method to long a 32-bit value is used which
allows for path costs of up to 200,000,000.
Note
It is uncommon in a real network to need spanning-tree costs above 65535.
Task 1.8
SW1:
interface FastEthernet0/1
storm-control unicast level pps 250
Task 1.8 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 BPS (Bits Per Second) option with the
storm-control command but the 3550 does not support the PPS (Packets 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 storm-
control.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 10
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 1.8 Verification
Rack1SW1#show storm-control unicast
Interface Filter State Upper Lower Current
--------- ------------- ----------- ----------- ----------
Fa0/1 Forwarding 250 pps 250 pps 0 pps
Task 1.9
SW2:
mls qos map ip-prec-dscp 0 0 0 0 32 40 0 0
Task 1.9 Breakdown
The switches use internal DSCP mappings for classification and marking of
frames as they transverse the switch. Mappings are used to help determine how
the switch will handle the frame. To alter the default mappings between the
internal DSCP and the IP precedence the mls qos map ip-prec-dscp <8 DSCP
values> command is used.
Task 1.9 Verification
Rack1SW2#show mls qos maps ip-prec-dscp
IpPrecedence-dscp map:
ipprec: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 0 0 0 32 40 0 0
Further Reading
Configuring DSCP Maps
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 11
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 1.10
SW2:
interface FastEthernet0/2
mls qos trust ip-precedence
Task 1.10 Breakdown
By configuring the interface to trust IP precedence the IP precedence to DCSP
map created in the previous task will be used to map ingress packet s IP
precedence values to the internal DSCP values.
Task 1.10 Verification
Rack1SW2#show mls qos interface fa0/2 | include ip-precedence
trust state: trust ip-precedence
trust mode: trust ip-precedence
Further Reading
Configuring Classification Using Port Trust States
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 12
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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.1 Verification
Rack1R2#show frame-relay map
Serial0/0 (up): ip 141.1.123.1 dlci 201(0xC9,0x3090), static,
broadcast,
CISCO, status defined, active
Serial0/0 (up): ip 141.1.123.3 dlci 203(0xCB,0x30B0), static,
broadcast,
CISCO, status defined, active
Rack1R1#ping 141.1.123.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 141.1.123.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Rack1R1#ping 141.1.123.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 141.1.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/36/40 ms
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 13
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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.2 Verification
Verify reachability:
Rack1R4#ping 141.1.54.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 141.1.54.5, 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 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
Task 2.3 Verification
Rack1R6#show frame-relay map
Serial0/0/0 (up): ip 54.1.1.254 dlci 101(0x65,0x1850), static,
broadcast,
CISCO, status defined, active
Rack1R6#ping 54.1.1.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 54.1.1.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/60/64 ms
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 14
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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.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 s0/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[20000002] 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
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 15
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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.
Task 3.2 Verification
Rack1R4#show compress
Serial0/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/0.922
5 min avg ratio xmt/rcv 0.709/0.922
10 min avg ratio xmt/rcv 0.709/0.922
no bufs xmt 0 no bufs rcv 0
resyncs 0
Rack1R4#ping 141.1.45.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 141.1.45.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/16/16
ms
Rack1R4#show compress
Serial0/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: 4.923
Compressed bytes recv: 168 bytes 0 Kbits/sec ratio: 5.011
1 min avg ratio xmt/rcv 1.190/1.482
5 min avg ratio xmt/rcv 1.190/1.482
10 min avg ratio xmt/rcv 1.190/1.482
no bufs xmt 0 no bufs rcv 0
resyncs 0
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 16
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 17
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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
150.1.3.3 0 FULL/DROTHER 00:01:58 141.1.123.3 Serial0/0
150.1.1.1 0 FULL/DROTHER 00:01:58 141.1.123.1 Serial0/0
Verify OSPF interface on R1 to see network type and priority:
Rack1R1#show ip ospf interface s0/0.1
Serial0/0.1 is up, line protocol is up
Internet Address 141.1.123.1/24, Area 0
Process ID 1,Router ID 150.1.1.1,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 0.0.0.0 IP address.
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.0 on Serial0/0 from ATTEMPT to
DOWN, Neighbor Down: Dead timer expired
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 18
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 4.2
R1:
interface FastEthernet0/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.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 19
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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:
DR/BDR
Network Type 1 Network Type 2
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.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 20
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 4.2 Verification
Rack1R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
150.1.2.2 1 FULL/DR 00:01:54 141.1.123.2 Serial0/0.1
192.10.1.254 1 FULL/DR 00:00:37 192.10.1.254 FastEthernet0/0
Rack1R1#show ip ospf interface fa0/0
FastEthernet0/0 is up, line protocol is up
Internet Address 192.10.1.1/24, Area 51
Process ID 1, Router ID 150.1.1.1, Network Type NON_BROADCAST,Cost: 1
Transmit Delay is 1 sec, State BDR, Priority 1
Designated Router (ID) 192.10.1.254, Interface address 192.10.1.254
Backup Designated router (ID) 150.1.1.1, Interface address 192.10.1.1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

Check to see if we are receiving multicast hello packets and sending
unicast hellos:
Rack1R1#debug ip packet
IP: s=192.10.1.1 (local), d=192.10.1.254 (FastEthernet0/0), len 80,
sending
IP: s=192.10.1.254 (FastEthernet0/0), d=224.0.0.5, len 80, rcvd 0
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 21
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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
network 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:
ip routing
!
router ospf 1
router-id 150.1.8.8
redistribute connected subnets route-map CONNECTED->OSPF
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
network 141.1.255.8 0.0.0.0 area 1
!
route-map CONNECTED->OSPF permit 10
match interface Loopback0
SW3 and SW4:
ip default-gateway 141.1.255.8
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 150.1.3.3/24, Area 0
Process ID 1, Router ID 150.1.3.3, 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

O 150.1.2.2/32 [110/782] via 141.1.123.2, 00:04:03, Serial1/0.1
O 150.1.1.1/32 [110/782] via 141.1.123.1, 00:04:03, Serial1/0.1
O E2 150.1.8.0/24 [110/20] via 141.1.123.2, 00:03:02, Serial1/0.1
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 22
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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

Rack1R2#show ip route ospf | include 150.1.8.0
O N2 150.1.8.0/24 [110/20] via 141.1.0.8, 00:23:07, FastEthernet0/0
Rack1R1#show ip route ospf | include 150.1.8.0
O E2 150.1.8.0/24 [110/20] via 141.1.123.2, 00:27:24, Serial0/0.1
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 23
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 4.5
R2:
Quick Note
interface Tunnel0
Virtual-Link cannot be
ip address 141.1.25.2 255.255.255.0
created over a stub area
tunnel source FastEthernet0/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
!
interface Tunnel0
Quick Note
ip address 141.1.25.5 255.255.255.0
Virtual-Link cannot be
tunnel source Ethernet0/1
created over a stub area
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.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.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 24
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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
Generated by all routers in an area to describe
1 Router LSA their directly attached links (intra-area routes).
Does not leave the area.
Generated by the DR of a broadcast or non-
broadcast segment to describe the neighbors
2 Network LSA
connected to that segment. Does not leave the
area.
Generated by the area border router (ABR) to
3 Summary LSA describe a route to neighbors outside the area
(inter-area route).
Generated by the ABR to describe a route to an
4 Summary LSA autonomous system border router (ASBR) to
neighbors outside the area.
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,
5 External LSA
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
NSSA External it leaves the NSSA area. These routes appear as
7
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.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 25
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 26
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
The stub area types can be summarized as follows:
Default
Stub Type Keyword LSAs
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- area x nssa no-summary 1,2, default of 3, 7 YES
Stubby
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 141.1.25.5/24

Rack1R5#show ip ospf interface tu0
Tunnel0 is up, line protocol is up
Internet Address 141.1.25.5/24, Area 0
Process ID 1, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost:
11111
Transmit Delay is 1 sec, State POINT_TO_POINT,

Rack1R5#ping 141.1.25.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 141.1.25.2, 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:
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 27
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Rack1R5#show ip ospf neighbor tu0
Neighbor ID Pri State Dead Time Address Interface
150.1.2.2 0 FULL/ - 00:00:38 141.1.25.2 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 (150.1.4.4|150.1.5.5)
O IA 150.1.5.5/32 [110/11176] via 141.1.123.2, 01:44:25, Serial0/0.1
O IA 150.1.4.4/32 [110/11186] via 141.1.123.2, 01:44:19, Serial0/0.1
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
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 28
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 4.6 Verification
Verify that equal-cost load balancing is actually occurring:
Rack1R4#show ip route 150.1.5.5
Routing entry for 150.1.5.5/32
Known via "ospf 1", distance 110, metric 11, type intra area
Last update from 141.1.145.5 on Ethernet0/0, 00:00:05 ago
Routing Descriptor Blocks:
* 141.1.145.5, from 150.1.5.5, 00:00:05 ago, via Ethernet0/0
Route metric is 11, traffic share count is 1
141.1.54.5, from 150.1.5.5, 00:00:05 ago, via Serial0/0
Route metric is 11, traffic share count is 1
Rack1R5#show ip route 150.1.4.4
Routing entry for 150.1.4.4/32
Known via "ospf 1", distance 110, metric 11, type intra area
Last update from 141.1.145.4 on Ethernet0/0, 00:01:29 ago
Routing Descriptor Blocks:
* 141.1.145.4, from 150.1.4.4, 00:01:29 ago, via Ethernet0/0
Route metric is 11, traffic share count is 1
141.1.54.4, from 150.1.4.4, 00:01:29 ago, via Serial0/0
Route metric is 11, traffic share count is 1
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.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 29
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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 141.1.145.5/24, Area 2
Process ID 1, Router ID 150.1.5.5, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State BDR, Priority 1
Designated Router (ID) 150.1.4.4, Interface address 141.1.145.4
Backup Designated router (ID) 150.1.5.5, Interface address
141.1.145.5
Timer intervals configured, Hello 2, Dead 8, Wait 8, Retransmit 5

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:
ip routing
!
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
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 30
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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:
141.1.0.0
Passive Interface(s):
Serial1/0
Serial1/0.1
Serial1/1
Serial1/2
Serial1/3
Loopback0
VoIP-Null0
Routing Information Sources:
Gateway Distance Last Update
141.1.37.7 120 00:00:23
141.1.36.6 120 00:00:18
Distance: (default is 120)
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 31
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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.
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 54.1.1.254
R 212.18.1.0/24 [120/1] via 54.1.1.254, 00:00:05, Serial0/0/0
R 212.18.0.0/24 [120/10] via 54.1.1.254, 00:00:05, Serial0/0/0
R 212.18.3.0/24 [120/1] via 54.1.1.254, 00:00:05, Serial0/0/0
R 212.18.2.0/24 [120/10] via 54.1.1.254, 00:00:05, Serial0/0/0
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 32
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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 RIP->OSPF
!
router rip
version 2
redistribute ospf 1 metric 1
!
ip prefix-list VLAN43 seq 5 permit 204.12.1.0/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:
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.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 33
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 34
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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)
31.0.0.0/14 is subnetted, 1 subnets
O E1 31.0.0.0 [110/11205] via 141.1.123.2, 00:03:19, Serial0/0.1
30.0.0.0/14 is subnetted, 1 subnets
O E1 30.0.0.0 [110/11205] via 141.1.123.2, 00:03:19, Serial0/0.1
Verify route for VLAN43 (note the metric):
Rack1R1#show ip route | include 204.12
O E2 204.12.1.0/24 [110/100] via 141.1.123.2, 00:06:46, Serial0/0.1
Next verify full connectivity between internal routers using the
following TCL script:
foreach i {
150.1.1.1
192.10.1.1
141.1.123.1
141.1.0.2
141.1.25.2
150.1.2.2
141.1.123.2
150.1.3.3
141.1.37.3
141.1.36.3
141.1.123.3
141.1.145.4
150.1.4.4
141.1.45.4
141.1.54.4
204.12.1.4
141.1.145.5
141.1.0.5
141.1.25.5
150.1.5.5
141.1.45.5
141.1.54.5
54.1.1.6
141.1.6.6
150.1.6.6
141.1.36.6
141.1.7.7
150.1.7.7
141.1.37.7
141.1.77.7
141.1.0.8
141.1.8.8
150.1.8.8
141.1.88.8
141.1.255.8
141.1.255.9
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 35
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
141.1.255.10
} {puts [ exec "ping $i" ] }
Finally verify that backbone IGP prefixes are reachable from every
internal router using the TCL script below:
foreach i {
54.1.1.254
212.18.1.1
212.18.0.1
212.18.3.1
212.18.2.1
204.12.1.254
31.3.0.1
31.2.0.1
31.1.0.1
31.0.0.1
30.2.0.1
30.3.0.1
30.0.0.1
} {puts [ exec "ping $i" ] }
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 36
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
5. IP Multicast
Task 5.1
R1:
ip multicast-routing
!
interface FastEthernet0/0
ip pim sparse-mode
!
interface Serial0/0.1 point-to-point
ip pim sparse-mode
R2:
ip multicast-routing
!
interface FastEthernet0/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
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 37
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
SW1:
ip multicast-routing distributed
!
interface FastEthernet0/3
ip pim sparse-mode
!
interface Vlan7
ip pim sparse-mode
SW2:
ip multicast-routing distributed
!
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 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 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 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.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 38
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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) 225.0.0.0/8
RP 150.1.2.2 (?), v2v1
Info source: 150.1.2.2 (?), elected via Auto-RP
Uptime: 00:00:58, expires: 00:01:57
Group(s) 239.0.0.0/8
RP 150.1.5.5 (?), v2v1
Info source: 150.1.5.5 (?), elected via Auto-RP
Uptime: 00:00:11, expires: 00:02:49
Task 5.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 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.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 39
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Note
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 5.3 Verification
Simulate multicast packets from R1 to group 225.25.25.25:
Rack1R1#ping
Protocol [ip]:
Target IP address: 225.25.25.25
Repeat count [1]: 100
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Interface [All]: Serial0/0.1
Time to live [255]:
Source address: 192.10.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 40
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 225.25.25.25, timeout is 2 seconds:
Packet sent with a source address of 192.10.1.1
Reply to request 0 from 141.1.123.3, 92 ms
Reply to request 1 from 141.1.123.3, 92 ms
Reply to request 2 from 141.1.123.3, 92 ms
Verify the multicast routing table on R2:
Rack1R2#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C -
Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast
Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 225.25.25.25), 00:10:49/stopped, RP 150.1.2.2, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/0, 141.1.123.3, Forward/Sparse, 00:10:49/00:02:35

(192.10.1.1, 225.25.25.25), 00:01:43/00:03:22, flags: T
Incoming interface: Serial0/0, RPF nbr 141.1.123.1
Outgoing interface list:
Serial0/0, 141.1.123.3, Forward/Sparse, 00:01:43/00:02:46
Finally, simulate multicast packets from R4 to group 239.39.39.39:
Rack1R4#ping
Protocol [ip]:
Target IP address: 239.39.39.39
Repeat count [1]: 100
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Interface [All]: Ethernet0/0
Time to live [255]:
Source address: 204.12.1.4
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 41
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 239.39.39.39, timeout is 2 seconds:
Packet sent with a source address of 204.12.1.4
Reply to request 0 from 141.1.123.3, 40 ms
Reply to request 1 from 141.1.123.3, 36 ms
Reply to request 2 from 141.1.123.3, 32 ms
Verify the multicast table on R2 again (note Tunnel0 is used as RPF
interface):
Rack1R2#show ip mroute 239.39.39.39
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C -
Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast
Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.39.39.39), 01:52:21/stopped, RP 150.1.5.5, flags: S
Incoming interface: Tunnel0, RPF nbr 141.1.25.5
Outgoing interface list:
Serial0/0, 141.1.123.3, Forward/Sparse, 01:52:21/00:03:00
(204.12.1.4, 239.39.39.39), 00:00:06/00:03:23, flags: T
Incoming interface: Tunnel0, RPF nbr 141.1.25.5
Outgoing interface list:
Serial0/0, 141.1.123.3, Forward/Sparse, 00:00:06/00:03:23
Task 5.4
SW1:
interface FastEthernet0/3
ip multicast rate-limit out 1000
Task 5.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.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 42
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
6. IPv6
Task 6.1
R1:
ipv6 unicast-routing
!
interface FastEthernet0/0
ipv6 address 2001:192:10:1::/64 eui-64
ipv6 ospf 1 area 0
Task 6.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
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 43
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 44
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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 6.1 Verification
Verify the IPv6 addressing:
Rack1R1#show ipv6 interface brief | beg FastE
FastEthernet0/0 [up/up]
FE80::204:27FF:FEB5:2F60
2001:192:10:1:204:27FF:FEB5:2F60

Rack1R1#show ipv6 neighbors
IPv6 Address Age Link-layer Addr State
Interface
FE80::210:7BFF:FE3A:14CC 2 0010.7b3a.14cc STALE
Fa0/0
Verify IPv6 OSPF configuration:
Rack1R1#show ipv6 ospf interface fastEthernet 0/0
FastEthernet0/0 is up, line protocol is up
Link Local Address FE80::204:27FF:FEB5:2F60, Interface ID 3
Area 0, Process ID 1, Instance ID 0, Router ID 150.1.1.1
Network Type BROADCAST, Cost: 1

Adjacent with neighbor 192.10.1.254 (Designated Router)
Suppress hello for 0 neighbor(s)
Rack1R1#show ipv6 ospf neighbor
Neighbor ID Pri State Dead Time Interface ID Interface
192.10.1.254 1 FULL/DR 00:00:37 2 FastEthernet0/0
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 45
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 6.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
SW2:
sdm prefer dual-ipv4-and-ipv6 default
Quick Note
!
A reload is required for
ipv6 unicast-routing
the new SDM template to
!
take effect. Until then IPv6
interface VLAN258
routing is not supported on
ipv6 address 2001:141:1:25::A/64
the 3560s
ipv6 ospf 1 area 1
Task 6.2 Verification
Rack1R2#show ipv6 ospf neighbor
Neighbor ID Pri State Dead Time Interface ID Interface
150.1.1.1 1 FULL/ - 00:00:38 8 Serial0/0
150.1.8.8 1 FULL/DROTHER 00:00:39 2326 FastEthernet0/0
150.1.5.5 1 FULL/DR 00:00:38 6 FastEthernet0/0
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 46
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Rack1R2#show ipv6 route ospf
IPv6 Routing Table - 8 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::204:27FF:FEB5:2F60, Serial0/0
OI 2001:192:10:1::/64 [110/65]
via FE80::204:27FF:FEB5:2F60, Serial0/0
Task 6.3
R1:
ipv6 router ospf 1
area 1 range 2001:141:1::/58
Task 6.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.
Task 6.3 Verification
Verify that the summary is generated:
Rack1R1#show ipv6 route
IPv6 Routing Table - 9 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::210:7BFF:FE3A:14CC, FastEthernet0/0
O 2001:141:1::/58 [110/0]
via ::, Null0

Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 47
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Additionally verify the OSPFv3 database:
Rack1R1#show ipv6 ospf database inter-area prefix
OSPFv3 Router with ID (150.1.1.1) (Process ID 1)
Inter Area Prefix Link States (Area 0)
LS age: 17
LS Type: Inter Area Prefix Links
Link State ID: 2
Advertising Router: 150.1.1.1
LS Seq Number: 80000001
Checksum: 0x7844
Length: 36
Metric: 64
Prefix Address: 2001:141:1::
Prefix Length: 58, Options: None

7. QoS
Task 7.1
R1:
interface FastEthernet0/0
random-detect
random-detect precedence 0 15 40 10
Task 7.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.
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
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 48
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
random-detect precedence [precedence] [minimum threshold] [maximum
threshold] [mark probability demonitator].
Note
Weighted RED is the process of using different queues and thresholds for
packets with different IP precedence values.
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.
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.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 49
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 7.1 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
Task 7.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 7.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
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 50
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 7.2 Verification
Verify that the policy-map is attached and the class-map is configured:
Rack1R5#show policy-map interface e0/1
Ethernet0/1
Service-policy output: QoS
Class-map: SMTP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol smtp
Queueing
Output Queue: Conversation 265
Bandwidth 1500 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
23 packets, 2310 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Task 7.3
R5:
class-map match-all ABOVE_1250_BYTES
match packet length min 1251
!
policy-map QoS
class ABOVE_1250_BYTES
police cir 2500000
Task 7.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 CCIE lab, use the  ? along with the command to view how the
parameter is accepted by the IOS for that particular command. Do not expect
the values given in the lab itself to be the same as what will need to be
entered in the configuration. Entering a value in as bytes when the command
takes bits will cause you to lose points for that section.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 51
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 7.3 Verification
Verify that the policy-map is configured and applied:
Rack1R5#show policy-map interface e0/1
Ethernet0/1
Service-policy output: QoS

Class-map: ABOVE_1250_BYTES (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: packet length min 1250
police:
cir 2500000 bps, bc 78125 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)
220 packets, 21377 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Simulate a packet stream from R4 and verify the statistics:
Rack1R4#ping 141.1.0.8 size 1250 repeat 10000 timeout 1
Type escape sequence to abort.
Sending 10000, 1250-byte ICMP Echos to 141.1.0.8, timeout is 1 seconds:
!!!!!!!!!!!!!
Rack1R5#show policy-map interface e0/1
Ethernet0/1
Service-policy output: QoS

Class-map: ABOVE_1250_BYTES (match-all)
27 packets, 34128 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: packet length min 1250
police:
cir 2500000 bps, bc 78125 bytes
conformed 27 packets, 34128 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps

Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 52
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
8. Security
Task 8.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 8.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
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 53
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
" Permit DNS lookups and zone transfers
ip access-list extended TRAFFIC_FILTER
permit tcp any any eq domain
permit udp any any eq domain
Note
Zone 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 8.1 Verification
Verify the ACL counters:
Rack1R6#show ip access-lists TRAFFIC_FILTER
Extended IP access list TRAFFIC_FILTER
10 permit icmp any any echo
20 permit tcp any 141.1.7.0 0.0.0.255 eq telnet
30 permit tcp any 141.1.77.0 0.0.0.255 eq telnet
40 permit tcp any host 141.1.88.100 eq www
50 permit tcp any host 141.1.88.100 eq 443
60 permit tcp any any eq domain
70 permit udp any any eq domain
80 permit tcp any any eq bgp (88 matches)
90 permit tcp any eq bgp any (47 matches)
100 permit udp any any eq rip (342 matches)
110 evaluate REFLEXIVE
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 54
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Verify the ACLs by telneting from BB1:
BB1>telnet 141.1.7.7
Trying 141.1.7.7 ... Open
User Access Verification
Password:
Next try pinging from an internal router to BB1:
Rack1R3#ping 54.1.1.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 54.1.1.254, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
At the same time, telnet does work:
Rack1R3#telnet 54.1.1.254
Trying 54.1.1.254 ... Open
BB1>
And finally verify that BB1 could ping the internal routers:
BB1>ping 141.1.36.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 141.1.36.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/61/64 ms
Strategy Tip
As mentioned in previous labs access to any backbone routers is prohibited
in the real CCIE lab but at this stage of your preparation it is useful to fully
verify your configuration by accessing the backbone routers. By the time
you are ready for the real CCIE lab you will need to rely on your
configuration and verification without accessing the backbone routers.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 55
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 8.2
R4:
Legacy command
ip cef
!
interface Ethernet0/1
ip verify unicast reverse-path
OR
ip cef
!
interface Ethernet0/1
ip verify unicast source reachable-via rx
Task 8.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.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 56
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Note
Unicast RPF requires CEF to be enabled globally.
Task 8.2 Verification
Verify that uRPF is configured on the interface:
Rack1R4#show ip interface e0/1 | include verification
IP verify source reachable-via RX, allow default
0 verification drops
0 suppressed verification drops
9. System Management
Task 9.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 9.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 9.1 Verification
Verify the ACL and basic SNMP configuration:
Rack1R3#show access-lists 2
Standard IP access list 2
10 permit 141.1.77.100
20 permit 141.1.7.100
Rack1R3#show snmp
Chassis: 10578766

SNMP logging: enabled
Logging to 141.1.7.100.162, 0/10, 0 sent, 0 dropped.
Logging to 141.1.77.100.162, 0/10, 0 sent, 0 dropped.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 57
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
And finally verify that the configuration commands were accepted:
Rack1R3#show running-config | include snmp
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
Task 9.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 9.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.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 58
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Further Reading
Creating Menus
Task 9.2 Verification
Telnet to R2 to verify the menu:
Rack1R3#telnet 150.1.2.2
Trying 150.1.2.2 ... Open
User Access Verification
Username: NOC
Password:
Menu for NOC users
1. Ping R5
2. Ping R6
3. Traceroute to R5
4. Traceroute to R6
5. Exit
10. IP Services
Task 10.1
R2:
ip alias 141.1.0.22 23
Task 10.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#
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 59
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Rack1AS#show sessions
Conn Host Address Byte Idle Conn Name
* 8 AS-Line8 172.16.2.122 0 0 AS-Line8
Rack1AS#
Task 10.1 Verification
Verify that the alias is configured:
Rack1R2#show ip aliases
Address Type IP Address Port
Interface 141.1.0.2
Interface 141.1.25.2
Interface 150.1.2.2
Alias 141.1.0.22 23
Interface 141.1.123.2
Verify the ARP entry for the aliased IP:
Rack1R2#show ip arp 141.1.0.2
Protocol Address Age (min) Hardware Addr Type Interface
Internet 141.1.0.2 - 0004.27b5.2fa0 ARPA
FastEthernet0/0
Finally telnet from R5 to 141.1.0.2:
Rack1R5#telnet 141.1.0.2
Trying 141.1.0.2 ... Open
User Access Verification
Username: NOC
Password:
Menu for NOC users

Task 10.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 GigabitEthernet0/0
standby 1 ip 141.1.36.1
standby 2 ip 141.1.36.2
standby 2 priority 150
standby 2 preempt
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 60
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 10.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 10.2 Verification
Verify the HSRP configuration:
Rack1R6#show standby
GigabitEthernet0/0 - Group 1
State is Standby
1 state change, last state change 00:00:13
Virtual IP address is 141.1.36.1
Active virtual MAC address is 0000.0c07.ac01
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.368 secs
Preemption disabled
Active router is 141.1.36.3, priority 150 (expires in 9.108 sec)
Standby router is local
Priority 100 (default 100)
IP redundancy name is "hsrp-Gi0/0-1" (default)
GigabitEthernet0/0 - Group 2
State is Active
1 state change, last state change 00:00:30
Virtual IP address is 141.1.36.2
Active virtual MAC address is 0000.0c07.ac02
Local virtual MAC address is 0000.0c07.ac02 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 2.112 secs
Preemption enabled
Active router is local
Standby router is 141.1.36.3, priority 100 (expires in 7.112 sec)
Priority 150 (configured 150)
IP redundancy name is "hsrp-Gi0/0-2" (default)
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 61
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 10.3
R3:
ip host R4 150.1.4.4
!
busy-message R4  Connection Unsuccessful
Task 10.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
Task 10.3 Verification
Shutdown Serial 1/0 on R3, and try connecting to R4 by name:
Rack1R3(config)#interface s1/0
Rack1R3(config-if)#shutdown
Rack1R3#R4
Translating "R4"
Connection Unsuccessful
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 62
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
11. Exterior Gateway Routing
Task 11.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.1.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
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 63
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Task 11.1 Verification
On all BGP enabled routers verify the BGP peering sessions:
Rack1R1#show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
141.1.123.2 4 200 5 6 4 0 0 00:01:06 0
192.10.1.254 4 254 5 4 4 0 0 00:00:49 3
Task 11.2
R6:
router bgp 100
neighbor 141.1.123.2 filter-list 1 out
!
ip as-path access-list 1 permit _54$
Task 11.2 Breakdown
The above task basically is showing 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 11.2 Verification
Verify that R6 receives AS54 originated prefixes as well as AS54
customer s prefixes:
Rack1R6#show ip bgp
BGP table version is 14, local router ID is 150.1.6.6
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
*> 28.119.16.0/24 54.1.1.254 0 54 i
*> 28.119.17.0/24 54.1.1.254 0 54 i
*> 112.0.0.0 54.1.1.254 0 0 54 50 60 i
*> 113.0.0.0 54.1.1.254 0 0 54 50 60 i
*> 114.0.0.0 54.1.1.254 0 0 54 i

Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 64
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Make sure only AS54 originated prefixes are announced to R2:
Rack1R6#show ip bgp neighbors 141.1.123.2 advertised-routes | begin Net
Network Next Hop Metric LocPrf Weight Path
*> 28.119.16.0/24 54.1.1.254 0 54 i
*> 28.119.17.0/24 54.1.1.254 0 54 i
*> 114.0.0.0 54.1.1.254 0 0 54 i
*> 115.0.0.0 54.1.1.254 0 0 54 i
*> 116.0.0.0 54.1.1.254 0 0 54 i
*> 117.0.0.0 54.1.1.254 0 0 54 i
*> 118.0.0.0 54.1.1.254 0 0 54 i
*> 119.0.0.0 54.1.1.254 0 0 54 i
Total number of prefixes 8
Task 11.3
R1:
router ospf 1
redistribute bgp 200 subnets route-map BGP->OSPF
!
ip prefix-list BGP->OSPF seq 5 permit 205.90.31.0/24
ip prefix-list BGP->OSPF seq 10 permit 220.20.3.0/24
ip prefix-list BGP->OSPF seq 15 permit 222.22.2.0/24
!
route-map BGP->OSPF permit 10
match ip address prefix-list BGP->OSPF
R6:
router rip
redistribute bgp 100 metric 1 route-map BGP->RIP
!
ip prefix-list BGP->RIP seq 5 permit 28.119.16.0/24
ip prefix-list BGP->RIP seq 10 permit 28.119.17.0/24
ip prefix-list BGP->RIP seq 15 permit 114.0.0.0/8
ip prefix-list BGP->RIP seq 20 permit 115.0.0.0/8
ip prefix-list BGP->RIP seq 25 permit 116.0.0.0/8
ip prefix-list BGP->RIP seq 30 permit 117.0.0.0/8
ip prefix-list BGG->RIP seq 35 permit 118.0.0.0/8
ip prefix-list BGP->RIP seq 40 permit 119.0.0.0/8
!
route-map BGP->RIP permit 10
match ip address prefix-list BGP->RIP
Task 11.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).
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 65
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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).
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 66
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
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.
Task 11.3 Verification
Verify that the BGP prefixes from BB1 are being redistributed into RIP:
Rack1R3#show ip route | include (212\.|11[4-9]\.0)
R 119.0.0.0/8 [120/1] via 141.1.36.6, 00:00:05, Ethernet0/1
R 118.0.0.0/8 [120/1] via 141.1.36.6, 00:00:05, Ethernet0/1
R 117.0.0.0/8 [120/1] via 141.1.36.6, 00:00:05, Ethernet0/1
R 116.0.0.0/8 [120/1] via 141.1.36.6, 00:00:05, Ethernet0/1
R 115.0.0.0/8 [120/1] via 141.1.36.6, 00:00:05, Ethernet0/1
R 114.0.0.0/8 [120/1] via 141.1.36.6, 00:00:05, Ethernet0/1
R 212.18.1.0/24 [120/2] via 141.1.36.6, 00:00:05, Ethernet0/1
R 212.18.0.0/24 [120/11] via 141.1.36.6, 00:00:05, Ethernet0/1
R 212.18.3.0/24 [120/2] via 141.1.36.6, 00:00:05, Ethernet0/1
R 212.18.2.0/24 [120/11] via 141.1.36.6, 00:00:05, Ethernet0/1
Verify that the BGP prefixes from BB2 are being redistributed into
OSPF:
Rack1R3#show ip route | include 205\.|220\.|222\.
O E2 222.22.2.0/24 [110/1] via 141.1.123.1, 00:27:13, Serial1/0.1
O E2 220.20.3.0/24 [110/1] via 141.1.123.1, 00:27:13, Serial1/0.1
O E2 205.90.31.0/24 [110/1] via 141.1.123.1, 00:27:13, Serial1/0.1
Finally verify reachability using the TCL script below:
foreach i {
28.119.16.1
28.119.17.1
114.0.0.1
115.0.0.1
116.0.0.1
117.0.0.1
118.0.0.1
119.0.0.1
205.90.31.1
220.20.3.1
222.22.2.1
} { puts [ exec "ping $i" ] }
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 67
IEWB-RS Volume I Version 4.0 Solutions Guide Lab 4
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
4 - 68