IEWB-RS Version 4.0 Solutions Guide Lab 2
1. Bridging & Switching
Task 1.1
SW1:
vtp domain IE
vtp password CISCO
vlan 3,5,6,8,10,26,33,52,255,783
!
interface FastEthernet0/3
switchport access vlan 3
!
interface FastEthernet0/5
switchport access vlan 5
!
interface FastEthernet0/9
switchport access vlan 10
!
interface FastEthernet0/10
switchport access vlan 10
SW2:
vtp domain IE
vtp mode client
vtp password CISCO
!
interface FastEthernet0/2
switchport access vlan 26
!
interface FastEthernet0/24
switchport access vlan 52
SW3:
vtp domain IE
vtp mode client
vtp password CISCO
!
interface FastEthernet0/3
switchport access vlan 33
!
interface FastEthernet0/5
switchport access vlan 52
!
interface FastEthernet0/24
switchport access vlan 783
SW4:
vtp domain IE
vtp mode client
vtp password CISCO
!
interface FastEthernet0/4
switchport access vlan 255
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 1
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 1.1 Breakdown
In VTP there are three modes of operation. These modes are server, client, and
transparent. A bridge in server mode can add, remove, or change parameters of
the VTP domain. VTP clients listen for updates from servers, install parameters
advertised, and pass these advertisements on. A bridge running in VTP
transparent mode, as the name implies, passes VTP updates on transparently
without installing them. A bridge running in transparent mode effectively does
not participate in VTP with the rest of the domain, and keeps a separate local
copy of the vtp database.
The Catalyst 3550 and 3560 series switches default to VTP server mode. To
change the VTP operational mode, issue the vtp [server | client | transparent]
vlan database or global configuration command.
In the above task, SW1 is left as server, as it  should be responsible for creating
and modifying all VLAN parameters , while the other switches are set to client
mode so there are  not& able to create or modify any VLAN parameters but are
still able to  install VLANs created or modified on SW1.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 2
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 1.1 Verification
Verify the VTP status and VLAN assignments:
Rack1SW1#show vtp status
VTP Version : 2
Configuration Revision : 4
Maximum VLANs supported locally : 1005
Number of existing VLANs : 17
VTP Operating Mode : Server
VTP Domain Name : IE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x83 0x17 0xEE 0x43 0x84 0x3A 0x9A
0x01
Configuration last modified by 132.1.17.7 at 3-3-93 04:36:53
Local updater ID is 204.12.1.7 on interface Vl783 (lowest numbered VLAN
interface found)
Rack1SW1#
Rack1SW1#show vlan brief | exclude unsup
VLAN Name Status Ports
---- ---------------------------------- -------------------------------
1 default active Fa0/2, Fa0/4, Fa0/6, Fa0/7
Fa0/8, Fa0/11, Fa0/12, Fa0/14
Fa0/15, Fa0/23, Fa0/24, Gi0/1
Gi0/2
3 VLAN0003 active Fa0/3
5 VLAN0005 active Fa0/5
6 VLAN0006 active
8 VLAN0008 active
10 VLAN0010 active Fa0/9, Fa0/10
12 VLAN0012 active
13 VLAN0013 active
26 VLAN0026 active
33 VLAN0033 active
52 VLAN0052 active
255 VLAN0255 active
783 VLAN0783 active
Rack1SW2#show vtp status
VTP Version : 2
Configuration Revision : 4
Maximum VLANs supported locally : 1005
Number of existing VLANs : 17
VTP Operating Mode : Client
VTP Domain Name : IE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x83 0x17 0xEE 0x43 0x84 0x3A 0x9A
0x01
Configuration last modified by 132.1.17.7 at 3-3-93 04:36:53
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 3
IEWB-RS Version 4.0 Solutions Guide Lab 2
Rack1SW2#show vlan brief | exclude unsup
VLAN Name Status Ports
---- ---------------------------------- -------------------------------
1 default active Fa0/1, Fa0/3, Fa0/4, Fa0/5
Fa0/6, Fa0/7, Fa0/8, Fa0/9
Fa0/10, Fa0/11, Fa0/12, Fa0/14
Fa0/15, Fa0/20, Fa0/22, Fa0/23
Gi0/1, Gi0/2
3 VLAN0003 active
5 VLAN0005 active
6 VLAN0006 active
8 VLAN0008 active
10 VLAN0010 active
12 VLAN0012 active
13 VLAN0013 active
26 VLAN0026 active Fa0/2
33 VLAN0033 active
52 VLAN0052 active Fa0/24
255 VLAN0255 active
783 VLAN0783 active
Rack1SW3#show vtp status
VTP Version : 2
Configuration Revision : 4
Maximum VLANs supported locally : 1005
Number of existing VLANs : 17
VTP Operating Mode : Client
VTP Domain Name : IE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x83 0x17 0xEE 0x43 0x84 0x3A 0x9A
0x01
Configuration last modified by 132.1.17.7 at 3-3-93 04:36:53
Rack1SW3#show vlan brief | exclude unsup
VLAN Name Status Ports
---- ---------------------------------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/4, Fa0/6
Fa0/7, Fa0/8, Fa0/9, Fa0/10
Fa0/11, Fa0/12, Fa0/22, Fa0/23
Gi0/1, Gi0/2
3 VLAN0003 active
5 VLAN0005 active
6 VLAN0006 active
8 VLAN0008 active
10 VLAN0010 active
12 VLAN0012 active
13 VLAN0013 active
26 VLAN0026 active
33 VLAN0033 active Fa0/3
52 VLAN0052 active Fa0/5
255 VLAN0255 active
783 VLAN0783 active Fa0/24
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 4
IEWB-RS Version 4.0 Solutions Guide Lab 2
Rack1SW4#show vtp status
VTP Version : 2
Configuration Revision : 4
Maximum VLANs supported locally : 1005
Number of existing VLANs : 17
VTP Operating Mode : Client
VTP Domain Name : IE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x83 0x17 0xEE 0x43 0x84 0x3A 0x9A
0x01
Configuration last modified by 132.1.17.7 at 3-3-93 04:36:53
Rack1SW4#show vlan brief | exclude unsup
VLAN Name Status Ports
---- --------------------------------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/5
Fa0/6, Fa0/7, Fa0/8, Fa0/9
Fa0/10, Fa0/11, Fa0/12, Fa0/22
Fa0/23, Fa0/24, Gi0/1, Gi0/2
3 VLAN0003 active
5 VLAN0005 active
6 VLAN0006 active
8 VLAN0008 active
10 VLAN0010 active
12 VLAN0012 active
13 VLAN0013 active
26 VLAN0026 active
33 VLAN0033 active
52 VLAN0052 active
255 VLAN0255 active Fa0/4
783 VLAN0783 active
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 5
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 1.2
SW1 and SW2:
interface FastEthernet0/13
no shutdown
switchport trunk encapsulation isl
switchport mode trunk
channel-group 1 mode on
!
interface FastEthernet0/14
no shutdown
switchport trunk encapsulation isl
switchport mode trunk
channel-group 1 mode on
!
interface FastEthernet0/15
no shutdown
switchport trunk encapsulation isl
switchport mode trunk
channel-group 1 mode on
!
interface Port-channel1
switchport trunk encapsulation isl
switchport mode trunk
Task 1.2 Breakdown
In order to increase bandwidth capacity between switches and high end servers,
Cisco offers a feature known as EtherChannel. EtherChannel allows multiple
Ethernet interfaces to be bound together as if they were one logical link, and be
seen as a single interface from the spanning-tree process.
To create an EtherChannel, issue the interface command channel-group [num]
mode [on | desirable | auto | active | passive]. The channel  mode determines
which, if any, protocol is used to automatically negotiate the channel.
The Cisco proprietary negotiation for EtherChannel is known as Port Aggregation
Protocol (PAgP). PAgP is enabled by enabling a channel in either the  auto or
 desirable mode. When an interface runs PAgP in auto mode it will listen for
PAgP packets received on the interface and agree to negotiate once these
packets are received. An interface in auto mode will not initiate negotiation
through PAgP. When an interface runs in desirable mode it will initiation PAgP
negotiation.
The open standard for EtherChannel negotiation is Link Aggregation Control
Protocol (LACP), and is defined in IEEE 802.3ad.
To disable both PAgP and LACP, set the channel mode to  on
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 6
IEWB-RS Version 4.0 Solutions Guide Lab 2
The channel modes are as follows:
Mode Result
On PAgP and LACP disabled (no negotiation)
Desirable Actively negotiate PAgP
Auto Passively listen for PAgP
Active Actively negotiate LACP
Passive Passively listen for LACP
The following mode combinations will result in a successful channel:
Device A Device B
On On
Desirable Desirable
Desirable Auto
Active Active
Active Passive
Pitfall
Typical problems with EtherChannel configurations involve the mismatch in
compatible channel modes as well as a mismatch in the configuration of the
member interfaces. To ensure that all member interfaces maintain the exact
same configuration put them in the channel with the channel-group interface
command, then apply all subsequent configuration to the port-channel
interface. Note that for layer 3 EtherChannel configurations, member
interfaces must first be designated as routed interfaces before being put them
in the channel-group.
Further Reading
Configuring EtherChannels
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 7
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 1.2 Verification
Check the port-channel status:
Rack1SW1#show etherchannel 1 summary

Group Port-channel Protocol Ports
------+-------------+-----------+----------------------------------
1 Po1(SU) Fa0/13(P) Fa0/14(P) Fa0/15(P)
Rack1SW2#show etherchannel 1 summary

Group Port-channel Protocol Ports
------+-------------+-----------+----------------------------------
1 Po1(SU) Fa0/13(P) Fa0/14(P) Fa0/15(P)
Check for detailed EtherChannel information on both switches:
Rack1SW1#show etherchannel 1 port-channel

Port-channel: Po1
------------
Age of the Port-channel = 00d:00h:04m:58s
Logical slot/port = 2/1 Number of ports = 3
GC = 0x00000000 HotStandBy port = null
Port state = Port-channel Ag-Inuse
Protocol = -
Ports in the Port-channel:
Index Load Port EC state No of bits
------+------+------+------------------+-----------
0 00 Fa0/13 On/FEC 0
0 00 Fa0/14 On/FEC 0
0 00 Fa0/15 On/FEC 0
Rack1SW2#show etherchannel 1 port-channel

Port-channel: Po1
------------
Age of the Port-channel = 00d:00h:04m:58s
Logical slot/port = 2/1 Number of ports = 3
GC = 0x00000000 HotStandBy port = null
Port state = Port-channel Ag-Inuse
Protocol = -
Ports in the Port-channel:
Index Load Port EC state No of bits
------+------+------+------------------+-----------
0 00 Fa0/13 On/FEC 0
0 00 Fa0/14 On/FEC 0
0 00 Fa0/15 On/FEC 0
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 8
IEWB-RS Version 4.0 Solutions Guide Lab 2
Finally verify the ISL trunk:
Rack1SW1#show interface po1 trunk
Port Mode Encapsulation Status Native vlan
Po1 on isl trunking 1
Port Vlans allowed on trunk
Po1 1-4094
Port Vlans allowed and active in management domain
Po1 1,3,5-6,8,10,12-13,26,33,52,255,783
Port Vlans in spanning tree forwarding state and not pruned
Po1 1,3,5-6,8,10,12-13,26,33,52,255,783
Rack1SW1#
Rack1SW2#show interface po1 trunk
Port Mode Encapsulation Status Native vlan
Po1 on isl trunking 1
Port Vlans allowed on trunk
Po1 1-4094
Port Vlans allowed and active in management domain
Po1 1,3,5-6,8,10,12-13,26,33,52,255,783
Port Vlans in spanning tree forwarding state and not pruned
Po1 1,3,5-6,8,10,12-13,26,33,52,255,783
Rack1SW2#
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 9
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 1.3
SW1:
interface FastEthernet0/16
no shutdown
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 2 mode active
!
interface FastEthernet0/17
no shutdown
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 2 mode active
!
interface FastEthernet0/18
no shutdown
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 2 mode active
!
interface Port-channel2
switchport trunk encapsulation dot1q
switchport trunk native vlan 783
switchport mode trunk
SW3:
interface FastEthernet0/13
no shutdown
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 2 mode active
!
interface FastEthernet0/14
no shutdown
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 2 mode active
!
interface FastEthernet0/15
no shutdown
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 2 mode active
!
interface Port-channel2
switchport trunk encapsulation dot1q
switchport trunk native vlan 783
switchport mode trunk
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 10
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 1.3 Verification
Check the port-channel status:
Rack1SW1#show etherchannel 2 summary

Group Port-channel Protocol Ports
------+-------------+-----------+----------------------------------
2 Po2(SU) LACP Fa0/16(P) Fa0/17(P) Fa0/18(P)
Rack1SW3#show etherchannel 2 summary

Group Port-channel Protocol Ports
------+-------------+-----------+----------------------------------
2 Po2(SU) LACP Fa0/13(P) Fa0/14(P) Fa0/15(P)
Verify the dot1q trunk and native VLAN:
Rack1SW1#show interface po2 trunk
Port Mode Encapsulation Status Native vlan
Po2 on 802.1q trunking 783
Port Vlans allowed on trunk
Po2 1-4094
Port Vlans allowed and active in management domain
Po2 1,3,5-6,8,10,12-13,26,33,52,255,783
Port Vlans in spanning tree forwarding state and not pruned
Po2 1,3,5-6,8,10,12-13,26,33,52,255,783
Rack1SW3#show interface po2 trunk
Port Mode Encapsulation Status Native vlan
Po2 on 802.1q trunking 783
Port Vlans allowed on trunk
Po2 1-4094
Port Vlans allowed and active in management domain
Po2 1,3,5-6,8,10,12-13,26,33,52,255,783
Port Vlans in spanning tree forwarding state and not pruned
Po2 1,3,5-6,8,10,12-13,26,33,52,255,783
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 11
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 1.4
SW1:
lacp system-priority 1
!
interface FastEthernet0/19
no shutdown
switchport mode dynamic desirable
channel-group 3 mode active
!
interface FastEthernet0/20
no shutdown
switchport mode dynamic desirable
channel-group 3 mode active
!
interface FastEthernet0/21
no shutdown
switchport mode dynamic desirable
channel-group 3 mode active
!
interface Port-channel3
switchport mode dynamic desirable
SW4:
interface FastEthernet0/13
no shutdown
switchport mode dynamic desirable
channel-group 3 mode passive
!
interface FastEthernet0/14
no shutdown
switchport mode dynamic desirable
channel-group 3 mode passive
!
interface FastEthernet0/15
no shutdown
switchport mode dynamic desirable
channel-group 3 mode passive
!
interface Port-channel3
switchport mode dynamic desirable
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 12
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 1.4 Verification
Check the port-channel status:
Rack1SW1#show etherchannel 3 summary

Group Port-channel Protocol Ports
------+-------------+-----------+----------------------------------
3 Po3(SU) LACP Fa0/19(P) Fa0/20(P) Fa0/21(P)
Rack1SW4#show etherchannel 3 summary

Group Port-channel Protocol Ports
------+-------------+-----------+----------------------------------
3 Po3(SU) LACP Fa0/13(P) Fa0/14(P) Fa0/15(P)
Verify the trunk:
Rack1SW1#show interface po3 trunk
Port Mode Encapsulation Status Native vlan
Po3 desirable n-isl trunking 1
Port Vlans allowed on trunk
Po3 1-4094
Port Vlans allowed and active in management domain
Po3 1,3,5-6,8,10,12-13,26,33,52,255,783
Port Vlans in spanning tree forwarding state and not pruned
Po3 1,3,5-6,8,10,12-13,26,33,52,255,783
Rack1SW4#show interface po3 trunk
Port Mode Encapsulation Status Native vlan
Po3 desirable n-isl trunking 1
Port Vlans allowed on trunk
Po3 1-4094
Port Vlans allowed and active in management domain
Po3 1,3,5-6,8,10,12-13,26,33,52,255,783
Port Vlans in spanning tree forwarding state and not pruned
Po3 1,3,5-6,8,10,12-13,26,33,52,255,783
Rack1SW4#
Verify the dot1q LACP priority:
Rack1SW1#show lacp sys-id
1, 0019.55e6.6580
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 13
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 1.5
R6:
interface GigabitEthernet0/0.6
Troubleshooting
encapsulation dot1Q 6 native
The initial configuration for
ip address 132.1.6.6 255.255.255.0
R6 has the IP addresses
!
swapped on G0/0.6 and
interface GigabitEthernet0/0.26
G0/0.26
encapsulation dot1Q 26
ip address 132.1.26.6 255.255.255.0
SW2:
interface FastEthernet0/6
switchport trunk encapsulation dot1q
switchport trunk native vlan 6
switchport mode trunk
switchport nonegotiate
Task 1.5 Breakdown
Since the Catalyst switches are layer 3 capable devices they can be used to
route traffic between VLANs. However, for layer 2 only platforms an external
router must be used to route traffic between VLANs. In the latter setup traffic is
sent over a trunk link to a router where is it de-encapsulated, routed, then re-
encapsulated with the new VLAN header and sent back to the switch. Since only
one physical interface is involved in this routing process this setup is typically
referred to as  router-on-a-stick .
To configure router-on-a-stick, create a subinterface on the router and issue the
encapsulation [isl | dot1q] [vlan] [native] command. When ISL is used, the
native keyword is not required.
Further Reading
Routing Between VLANs Overview
Configuring Routing Between VLANs with ISL Encapsulation
Configuring Routing Between VLANs with 802.1Q Encapsulation
As previously mentioned, the native vlan on an 802.1q trunk link is not tagged
with a VLAN header. To change the native vlan, issue the switchport trunk
native vlan [num] interface level command. Dot1q trunking is supported on
10Mb Ethernet interfaces but the native VLAN must be 1.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 14
IEWB-RS Version 4.0 Solutions Guide Lab 2
Pitfall
When configuring router-on-a-stick with 802.1q encapsulation be sure to
add the native keyword on to the appropriate VLAN. Otherwise the router
will not recognize the traffic since it is not encapsulated with a VLAN
header as expected.
Dynamic Trunking Protocol (DTP), as the name implies, is the protocol used to
automatically negotiate a trunk link. DTP supports the auto negotiation of both
ISL and 802.1q. By default all ports on the Catalyst 3550 are dynamic desirable
ports which will aggressively attempt to negotiate trunking through DTP. The
Catalyst 3650 ports do not default to dynamic desirable. When an interface is
statically set to  mode trunk or  mode access , there is no advantage of
continuing to run DTP. To disable DTP and the auto negotiation of trunking,
issue the interface level command switchport nonegotiate.
Pitfall
Although Dot1q trunking is supported on 2600 and 3600 10MB Ethernet
interfaces, only VLAN 1 can be the native VLAN. The native VLAN can be
applied to VLANs other than 1 but the router s interface will not accept the
traffic for that VLAN.
Task 1.5 Verification
Check interface Fa0/6 s trunking mode and native VLAN:
Rack1SW2#show interfaces fa0/6 trunk
Port Mode Encapsulation Status Native vlan
Fa0/6 on 802.1q trunking 6
Check if DTP is disabled, and double-check native-VLAN:
Rack1SW2#show interfaces fa0/6 switchport
Name: Fa0/6
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 6 (VLAN0006)

Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 15
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 1.6
SW1:
vtp pruning
Task 1.6 Breakdown
VTP pruning allows a switch to communicate with its directly connected
neighbors about what VLANs they have locally assigned and/or are in the transit
path for. Therefore VLANs that are unnecessary can be  pruned off of the
interface.
The task states that traffic  VLANs not locally assigned should not be received
over any trunk links throughout the VTP domain. By default, all VLANs are
allowed to be sent over any trunk link in the VTP domain. Therefore, broadcast
frames and frames destined for unknown unicast addresses will be sent over all
trunks throughout the domain. This behavior is undesirable when one or more
switches throughout the VTP domain receive traffic for VLANs that they do not
have locally assigned and are not in the transit path for. In order to reduce this
unnecessary traffic VTP pruning should be enabled.
Task 1.6 Verification
Verify that pruning has been enabled within the VTP domain:
Rack1SW1#show vtp status | include Pruning
VTP Pruning Mode : Enabled
Rack1SW2#show vtp status | include Pruning
VTP Pruning Mode : Enabled
Rack1SW3#show vtp status | include Pruning
VTP Pruning Mode : Enabled
Rack1SW4#show vtp status | include Pruning
VTP Pruning Mode : Enabled
Verify that the unused VLANs are actually being pruned:
Rack1SW1#show interface po1 trunk
Port Mode Encapsulation Status Native vlan
Po1 on isl trunking 1
Port Vlans allowed on trunk
Po1 1-4094
Port Vlans allowed and active in management domain
Po1 1,3,5-6,8,10,12-13,26,33,52,255,783
Port Vlans in spanning tree forwarding state and not pruned
Po1 1,8,26,52,783
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 16
IEWB-RS Version 4.0 Solutions Guide Lab 2
Rack1SW1#show interface po2 trunk
Port Mode Encapsulation Status Native vlan
Po2 on 802.1q trunking 783
Port Vlans allowed on trunk
Po2 1-4094
Port Vlans allowed and active in management domain
Po2 1,3,5-6,8,10,12-13,26,33,52,255,783
Port Vlans in spanning tree forwarding state and not pruned
Po2 1,33,52,255,783
Rack1SW1#show interface po3 trunk
Port Mode Encapsulation Status Native vlan
Po3 desirable n-isl trunking 1
Port Vlans allowed on trunk
Po3 1-4094
Port Vlans allowed and active in management domain
Po3 1,3,5-6,8,10,12-13,26,33,52,255,783
Port Vlans in spanning tree forwarding state and not pruned
Po3 1,255
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 17
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 1.7
SW1:
aaa new-model
aaa authentication login default none
aaa authentication dot1x default group radius
!
dot1x system-auth-control
!
interface FastEthernet0/9
switchport mode access
dot1x port-control auto
!
interface FastEthernet0/10
switchport mode access
dot1x port-control auto
!
ip radius source-interface Loopback0
!
radius-server host 204.12.1.100
radius-server key CISCO
Task 1.7 Breakdown
In order to provide added security at the access layer of the network, 802.1x
defines username and password based authentication for Ethernet switches. To
enable 802.1x authentication, first issue the global configuration command dot1x
system-auth-control (prior to 12.1(14)EA1 this command is not required). Next,
enable dot1x must be enabled on a per interface basis by issuing the interface
level command dot1x port-control [mode], where mode is either auto, forced-
authorized, or forced-unauthorized. Forced-authorized is the default mode, and
indicated that authorization is not required for access into the network. Forced-
unauthorized is the opposite, and dictates that clients can never access the
network through this port. When the state is set to auto, dot1x is enabled for
username and password authentication.
In order to centrally manage users, dot1x integrates with Authentication
Authorization and Accounting (AAA) to offload username and password
databases to either TACACS or RADIUS. Therefore, to enable dot1x
authentication, AAA must be enabled. The first step in enabling AAA is to issue
the global command aaa new-model. This command starts the AAA process.
Next, either the TACACS or RADIUS server should be defined, along with its
corresponding key value. This is accomplished with the radius-server or
tacacs-server global configuration command. Additionally, since network
devices typically have multiple interfaces running IP, it is common practice to
force the router/switch to generate radius or tacacs packets from a single
interface instead of relying on what the routing table dictates the outgoing
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 18
IEWB-RS Version 4.0 Solutions Guide Lab 2
interface to be. This is accomplished with the ip [tacacs | radius] source-
interface command.
After AAA is enabled, the authentication policy must be defined. This is
accomplished by issuing the aaa authentication dot1x command. In the above
case, the default group is used. The default group applies to all interfaces and
lines of the device in question.
Further Reading
Configuring 802.1X Port-Based Authentication
Doc CD: AAA
Pitfall
Once AAA is enabled for dot1x it is automatically enabled for all lines and
interfaces. This means that unless some other line authentication is
defined for the console, aux, or vty, the username and password
combination for dot1x must be used. In the above task, no authentication
is used for login by issuing the aaa authentication login default none
command. Unless you have a username/password combination locally
defined or some other type of login authentication enabled you will be
locked out of the console if you exit. For this reason be sure to give
yourself an out when configuring AAA for any application. Best practices
usually dictates that this last resort method be the local user database.
Strategy Tip
The IP addresses used for servers (radius, syslog, etc) in the lab tasks
may not actually be reachable. If you are unsure if the IP address of the
server or PC in the task should be reachable or not ask the proctor.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 19
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 1.7 Verification
Verify dot1x port control:
Rack1SW1#show dot1x
Sysauthcontrol = Enabled
Supplicant Allowed In Guest Vlan = Disabled
Dot1x Protocol Version = 1
Rack1SW1#show dot1x all
Dot1x Info for interface FastEthernet0/9

HostMode = Single
PortControl = Auto
ControlDirection = Both
QuietPeriod = 60 Seconds
Re-authentication = Disabled

Dot1x Info for interface FastEthernet0/10
----------------------------------------------------

HostMode = Single
PortControl = Auto
ControlDirection = Both
QuietPeriod = 60 Seconds
Re-authentication = Disabled

Check to see if RADIUS is configured:
Rack1SW1#show aaa servers
RADIUS: id 1, priority 1, host 204.12.1.100, auth-port 1645, acct-port
1646
State: current UP, duration 3634s, previous duration 0s
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 20
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 1.8
Note
SW1 and SW2:
After altering the Switch
sdm prefer routing
Database Template (SDM) a
reload is required before the
new template will take effect.
Task 1.8 Breakdown
The Switch Database Template (SDM) is used to alter the default allocation of
resources (unicast routes, MAC addresses, etc) for the 3550 and 3560 series
switches. By default the 3560 will support 8,000 unicast routes. Since the new
company s network already has 8,000 routes the SDM will need to be altered to
prefer routing to allow SW1 and SW2 to contain over 8,000 routes in their routing
tables.
Further Reading
Understanding the SDM Templates
Task 1.8 Verification
Default SDM:
Rack1SW1#show sdm prefer | begin unicast routes
number of IPv4 unicast routes: 8K
number of directly-connected IPv4 hosts: 6K
number of indirect IPv4 routes: 2K
number of IPv4 policy based routing aces: 0
number of IPv4/MAC qos aces: 512
number of IPv4/MAC security aces: 1K
After the SDM has been changed to prefer routing and reloaded:
Rack1SW1#show sdm prefer | begin unicast routes
number of IPv4 unicast routes: 11K
number of directly-connected IPv4 hosts: 3K
number of indirect IPv4 routes: 8K
number of IPv4 policy based routing aces: 512
number of IPv4/MAC qos aces: 512
number of IPv4/MAC security aces: 1K
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 21
IEWB-RS Version 4.0 Solutions Guide Lab 2
2. Frame-Relay
Task 2.1
R1:
interface Serial0/0
ip address 132.1.0.1 255.255.255.0
encapsulation frame-relay
no frame-relay inverse-arp IP 105
no frame-relay inverse-arp IP 113
R2:
interface Serial0/0
ip address 132.1.0.2 255.255.255.0
encapsulation frame-relay
no frame-relay inverse-arp IP 205
no frame-relay inverse-arp IP 213
R3:
interface Serial1/0
ip address 132.1.0.3 255.255.255.0
encapsulation frame-relay
no frame-relay inverse-arp IP 305
R4:
interface Serial0/0
ip address 132.1.0.4 255.255.255.0
encapsulation frame-relay
no frame-relay inverse-arp IP 405
no frame-relay inverse-arp IP 413
Task 2.1 Breakdown
By default Frame Relay Inverse-ARP is enabled for all supported protocols on all
VCs on an interface. Therefore to enable Frame Relay on a circuit utilizing
Inverse-ARP, the only configuration command required is encapsulation frame-
relay. To ensure that this dynamic mapping was successful use the show
frame-relay map command.
Pitfall
The initial configurations have these interfaces configured with Frame Relay
and the IP addresses assigned. The interface will also be in the UP/UP
state which means they may have dynamic Frame Relay mappings learned
through inverse-ARP that will need to be removed prior to starting this
section.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 22
IEWB-RS Version 4.0 Solutions Guide Lab 2
Verification
R1#show frame-relay map
Broadcast support by default

Serial0/0 (up): ip 132.1.0.2 dlci 102(0x66,0x1860), dynamic,
broadcast,, status defined, active
Serial0/0 (up): ip 132.1.0.3 dlci 103(0x67,0x1870), dynamic, InARP
broadcast,, status defined, active
Serial0/0 (up): ip 132.1.0.4 dlci 104(0x68,0x1880), dynamic,
broadcast,, status defined, active
Pitfall
Frame Relay Inverse-ARP only works between devices that have a direct
VC between them. This means that spokes of a partial meshed topology
can not use Inverse-ARP to resolve each others layer 3 addresses. Instead,
they must use some other method such as static frame-relay map
statements, point-to-point subinterfaces (which don t need layer 3 to layer 2
resolution), layer 3 routing, etc.
Task 2.2
R3:
interface Serial1/1
encapsulation frame-relay
!
interface Serial1/1.1 point-to-point
ip address 132.1.35.3 255.255.255.0
frame-relay interface-dlci 315
R5:
interface Serial0/0
encapsulation frame-relay
!
interface Serial0/0.1 point-to-point
ip address 132.1.35.5 255.255.255.0
frame-relay interface-dlci 513
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 23
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 2.2 Breakdown
The reason that NBMA media requires explicit layer 3 to layer 2 resolution is that
the network is in reality a collection of point-to-point links. When a packet is sent
to an NBMA media the router must know which VC to send the packet out.
However, when there is only one VC on the interface (point-to-point), this is not
an issue. Therefore, when using a point-to-point subinterface, NBMA media
does not require any explicit protocol mapping. This applies to Frame Relay,
ISDN (dialer interface), and ATM.
To configure a point-to-point Frame-Relay interface first issue the encapsulation
frame-relay command on the main interface. If there additional unused VCs it is
recommended that you disable Frame Relay Inverse-ARP on the main interface.
Next, create a point-to-point subinterface by issuing the interface serial
[slot/port] point-to-point. Next, assign the virtual circuit to the interface by
issuing the frame-relay interface-dlci [dlci] command. All additional logical
configuration (IP addressing, etc) should be performed on this interface.
Note
The frame-relay interface-dlci command simply applies the VC to the
interface. By default all VCs are assigned to the main interface. This
command can be used to assign a VC to either a multipoint or point-to-point
subinterface, or to apply specific parameters to a VC such as traffic-shaping.
A common misconception is that this command relates to Frame Relay
Inverse-ARP. This is not true.
Verification
R3#show frame-relay map
point-to-point circuit
No protocol resolution required

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

Broadcast support by default
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 24
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 2.3
R6:
interface Serial0/0/0
ip address 54.1.2.6 255.255.255.0
encapsulation frame-relay
frame-relay map ip 54.1.2.254 100 broadcast
no frame-relay inverse-arp
Task 2.3 Verification
Verify the layer 3 to layer 2 mapping and IP reachability:
Rack1R6#show frame-relay map
Serial0/0/0 (up): ip 54.1.2.254 dlci 100(0x64,0x1840), static,
broadcast,
CISCO, status defined, active
Rack1R6#ping 54.1.2.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 54.1.2.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/61/68 ms
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 25
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 2.4
R2:
interface Serial0/0
frame-relay traffic-shaping
frame-relay class REMAINING_BW
frame-relay interface-dlci 204
class DLCI_204
!
map-class frame-relay DLCI_204
frame-relay cir 128000
frame-relay bc 1280
!
map-class frame-relay REMAINING_BW
frame-relay cir 192000
frame-relay bc 24000
R4:
interface Serial0/0
frame-relay class REMAINING_BW
frame-relay traffic-shaping
frame-relay interface-dlci 402
class DLCI_402
!
map-class frame-relay DLCI_402
frame-relay cir 128000
frame-relay bc 1280
!
map-class frame-relay REMAINING_BW
frame-relay cir 192000
frame-relay bc 24000
Task 2.4 Breakdown
Although the port speed is given in the task, it is not normally needed unless
there is a requirement to allow for bursts above CIR. In this section there is a
requirement to limit the other DLCIs to only use the remaining bandwidth. This
means that we need to subtract the CIR from the port speed to determine what
value to shape the remaining traffic to.
The task states that R2 and R4 are not to exceed the provisioned CIR. This
means that the value entered in the frame-relay cir map-class command will
need to equal the provisioned CIR. This will ensure that R2 and R4 do not
exceed the CIR as the default  Be value for FRTS is always zero.
The lowest Tc value supported by FRTS is 10ms or 1/100ths of a second. To
alter the Tc we need to manipulate the Bc value. A Tc of 10ms means that we
will have 100 intervals per second. By taking the CIR and dividing it by 100, it
will give us the Bc value needed to indirectly set the Tc to 10ms. One of the
benefits of have 100 intervals per second, is that the router has more chances to
prioritize certain traffic if needed.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 26
IEWB-RS Version 4.0 Solutions Guide Lab 2
Note
The FRTS values are mathematically related.
Burst size = Bc Bc = CIR * Tc
Average rate = CIR CIR = Bc / Tc
Time interval = Tc Tc = Bc / CIR
Pitfall
Do not use the frame-relay tc command when trying to configure a non-
default Tc value. The frame-relay tc command is used for Frame Relay
SVCs when configured with 0 CIR.
Task 2.4 Verification
Verify the FRTS parameters:
Rack1R4#show traffic-shape
Interface Se0/0
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
413 192000 3000 24000 0 125 3000 -
401 192000 3000 24000 0 125 3000 -
402 128000 160 1280 0 10 160 -
403 192000 3000 24000 0 125 3000 -
405 192000 3000 24000 0 125 3000 -
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 27
IEWB-RS Version 4.0 Solutions Guide Lab 2
3. HDLC/PPP
Task 3.1
R2:
interface Serial0/1
compress stac
R3:
interface Serial1/3
compress stac
clockrate 64000
Task 3.1 Verification
Verify that compression is working:
Rack1R3#debug compress
COMPRESS debugging is on
Serial1/3: COMPRESS: (expansion) status: 6, size in: 20, size out: 15
Serial1/3: COMPRESS: (expansion) status: 6, size in: 20, size out: 15
Verify L3 reachability:
Rack1R3#ping 132.1.23.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 132.1.23.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/16/16 ms
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 28
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 3.2
R4:
username ROUTER5 password 0 CISCO
!
interface Serial0/1
encapsulation ppp
ppp authentication chap
ppp chap hostname ROUTER4
R5:
username ROUTER4 password 0 CISCO
!
interface Serial0/1
encapsulation ppp
ppp chap hostname ROUTER5
Task 3.2 Verification
Verify the PPP authentication (note that ROUTER4 authenticates
ROUTER5):
Rack1R5#debug ppp negotiation
Rack1R5#conf t
Rack1R5(config)#interface s0/1
Rack1R5(config-if)#shutdown
Rack1R5(config-if)#no shutdown

Se0/1 LCP: State is Open
Se0/1 PPP: No authorization without authentication
Se0/1 PPP: Phase is AUTHENTICATING, by the peer
Se0/1 CHAP: I CHALLENGE id 2 len 28 from "ROUTER4"
Se0/1 CHAP: Using hostname from interface CHAP
Se0/1 CHAP: Using password from AAA
Se0/1 CHAP: O RESPONSE id 2 len 28 from "ROUTER5"
Se0/1 CHAP: I SUCCESS id 2 len 4
Se0/1 PPP: Phase is FORWARDING, Attempting Forward
Se0/1 PPP: Queue IPCP code[1] id[1]
Se0/1 PPP: Phase is ESTABLISHING, Finish LCP
Se0/1 PPP: Phase is UP

Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 29
IEWB-RS Version 4.0 Solutions Guide Lab 2
4. Interior Gateway Routing
Task 4.1
R1:
interface Serial0/0
ip ospf network point-to-multipoint
!
router ospf 1
router-id 150.1.1.1
network 132.1.0.1 0.0.0.0 area 0
network 150.1.1.1 0.0.0.0 area 0
R2:
interface Serial0/0
ip ospf network point-to-multipoint
!
router ospf 1
router-id 150.1.2.2
network 132.1.0.2 0.0.0.0 area 0
R3:
interface Serial1/0
ip ospf network point-to-multipoint
!
router ospf 1
router-id 150.1.3.3
network 132.1.0.3 0.0.0.0 area 0
R4:
interface Serial0/0
ip ospf network point-to-multipoint
!
router ospf 1
router-id 150.1.4.4
network 132.1.0.4 0.0.0.0 area 0
network 150.1.4.4 0.0.0.0 area 0
Task 4.1 Breakdown
As previously discussed the OSPF network types that support a DR/BDR
election are broadcast and non-broadcast. Since the Frame Relay segment
between R1, R2, R3, and R4 is a multipoint segment the OSPF network type
point-to-point cannot be used. The two configurable network types that are left
are therefore point-to-multipoint and point-to-multipoint non-broadcast. Point-to-
multipoint non-broadcast is used in NBMA environments with virtual circuits of
differing speeds, and is not appropriate in this case. Therefore the OSPF
network choice for the segment between R1, R2, R3, and R4 should be point-to-
multipoint.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 30
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 4.1 Verification
Verify the OSPF neighbors. For instance on R1:
Rack1R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
150.1.4.4 0 FULL/ - 00:01:58 132.1.0.4 Serial0/0
150.1.3.3 0 FULL/ - 00:01:58 132.1.0.3 Serial0/0
150.1.2.2 0 FULL/ - 00:01:58 132.1.0.2 Serial0/0
Verify the area and network type of the interface:
Rack1R1#show ip ospf interface Serial0/0
Serial0/0 is up, line protocol is up
Internet Address 132.1.0.1/24, Area 0
Process ID 1, Router ID 150.1.1.1, Network Type POINT_TO_MULTIPOINT,
Cost: 64

Task 4.2
R1:
interface FastEthernet0/0
ip ospf authentication-key CISCO
!
router ospf 1
area 17 authentication
network 132.1.17.1 0.0.0.0 area 17
SW1:
ip routing
!
interface FastEthernet0/1
ip ospf authentication-key CISCO
!
router ospf 1
router-id 150.1.7.7
area 17 authentication
network 132.1.17.7 0.0.0.0 area 17
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 31
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 4.2 Verification
Verify that the OSPF adjacencies in area 17 are being authenticated:
Rack1R1#show ip ospf | begin Area 17
Area 17
Number of interfaces in this area is 1
Area has simple password authentication
Check in the interface is configured for authentication:
Rack1R1#show ip ospf interface fa0/0 | inc auth
Simple password authentication enabled
Verify that the adjacency is up:
Rack1R1#show ip ospf neighbor | inc 132.1.17.7
150.1.7.7 1 FULL/DR 00:00:32 132.1.17.7 FastEthernet0/0
Task 4.3
R3:
router ospf 1
passive-interface Ethernet0/0
passive-interface Ethernet0/1
network 132.1.3.3 0.0.0.0 area 3
network 132.1.33.3 0.0.0.0 area 33
Task 4.3 Breakdown
In order to prevent hello packets from exiting an interface that is running OSPF
use the passive-interface command under the OSPF process. Unlike distance
vector protocols such as RIP configuring an interface as passive in OSPF will
prevent the device from learning any network reachability information out the
interface in question. This is due to the fact that OSPF like IS-IS and EIGRP
uses periodic hello packets to establish and maintain active neighbor
adjacencies.
Note
To get the effect of the distance vector passive interface (i.e. receive routes
but not send routes) in OSPF use the interface level command ip ospf
database-filter all out. This command will allow adjacency to be
established, but will not allow LSA advertisements to be sent out the
interface.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 32
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 4.3 Verification
Verify that Ethernet0/0 is in area 3 and has OSPF hellos disabled:
Rack1R3#show ip ospf interface e0/0
Ethernet0/0 is up, line protocol is up
Internet Address 132.1.3.3/24, Area 3
Process ID 1, Router ID 150.1.3.3, Network Type BROADCAST, Cost: 10

No Hellos (Passive interface)

Finally verify OSPF routes in the routing table:
Rack1R1#show ip route ospf
132.1.0.0/16 is variably subnetted, 7 subnets, 2 masks
O 132.1.0.4/32 [110/64] via 132.1.0.4, 00:02:16, Serial0/0
O IA 132.1.3.0/24 [110/74] via 132.1.0.3, 00:02:16, Serial0/0
O 132.1.0.3/32 [110/64] via 132.1.0.3, 00:02:16, Serial0/0
O 132.1.0.2/32 [110/64] via 132.1.0.2, 00:02:16, Serial0/0
O IA 132.1.33.0/24 [110/74] via 132.1.0.3, 00:02:16, Serial0/0
150.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
O 150.1.4.4/32 [110/65] via 132.1.0.4, 00:02:16, Serial0/0
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 33
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 4.4
R2:
router eigrp 10
network 132.1.23.2 0.0.0.0
network 150.1.2.2 0.0.0.0
no auto-summary
eigrp router-id 150.1.2.2
R3:
router eigrp 10
network 132.1.23.3 0.0.0.0
network 132.1.35.3 0.0.0.0
network 150.1.3.3 0.0.0.0
no auto-summary
eigrp router-id 150.1.3.3
R4:
router eigrp 10
network 132.1.45.4 0.0.0.0
no auto-summary
eigrp router-id 150.1.4.4
R5:
router eigrp 10
network 132.1.35.5 0.0.0.0
network 132.1.45.5 0.0.0.0
network 150.1.5.5 0.0.0.0
no auto-summary
eigrp router-id 150.1.5.5
R6:
router eigrp 10
network 54.1.2.6 0.0.0.0
network 150.1.6.6 0.0.0.0
no auto-summary
eigrp router-id 150.1.6.6
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 34
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 4.4 Verification
Verify that the interfaces are enabled for EIGRP:
Rack1R6#show ip eigrp interfaces
IP-EIGRP interfaces for process 10
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Se0/0/0 1 0/0 516 0/15 3119 0
Lo0 0 0/0 0 0/10 0 0
Check to see if we have neighbors:
Rack1R6#show ip eigrp neighbors
IP-EIGRP neighbors for process 10
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 54.1.2.254 Se0/0/0 14 00:03:26 516 3096 0 549
Verify that we are receiving EIGRP routes:
Rack1R6#show ip route eigrp
D 200.0.0.0/24 [90/2297856] via 54.1.2.254, 00:03:28, Serial0/0/0
D 200.0.1.0/24 [90/2297856] via 54.1.2.254, 00:03:28, Serial0/0/0
D 200.0.2.0/24 [90/2297856] via 54.1.2.254, 00:03:28, Serial0/0/0
D 200.0.3.0/24 [90/2297856] via 54.1.2.254, 00:03:28, Serial0/0/0
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 35
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 4.5
R2:
router eigrp 10
network 132.1.26.2 0.0.0.0
neighbor 132.1.26.6 FastEthernet0/0
R6:
router eigrp 10
network 132.1.26.6 0.0.0.0
neighbor 132.1.26.2 GigabitEthernet0/0.26
Task 4.5 Verification
Verify that the EIGRP packets are being sent to the unicast address
(protocol 88 is EIGRP):
Rack1R2#debug interface fa0/0
Rack1R2#debug ip packet detail
IP: s=132.1.26.6 (FastEthernet0/0), d=132.1.26.2 (FastEthernet0/0), len
60, rcvd 3, proto=88
IP: s=132.1.26.2 (local), d=132.1.26.6 (FastEthernet0/0), len 60,
sending, proto=88
Rack1R2#undebug all
Rack1R2#no debug interface fa0/0
Verify that we have formed the appropriate EIGRP adjacencies:
Rack1R2#show ip eigrp neighbors
IP-EIGRP neighbors for process 10
H Address Interface Hold Uptime SRTT RTO Q Seq Type
(sec) (ms) Cnt Num
1 132.1.26.6 Fa0/0 14 13:42:44 1 200 0 25 S
0 132.1.23.3 Se0/1 14 13:43:08 43 258 0 61
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 36
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 4.6
R6:
interface GigabitEthernet0/0.26
encapsulation dot1Q 26
ip address 132.1.26.6 255.255.255.0
ip summary-address eigrp 10 200.0.0.0 255.255.252.0 5
Task 4.6 Verification
Verify that the EIGRP summary is generated on R6:
Rack1R6#show ip route | inc Null0
D 200.0.0.0/22 is a summary, 00:00:30, Null0
Check that the other EIGRP enabled routers see the summary:
Rack1R2#show ip route eigrp | inc 200.0
D 200.0.0.0/22 [90/2300416] via 132.1.26.6,00:01:38, FastEthernet0/0
Task 4.7
R5:
router eigrp 10
redistribute connected metric 1 1 1 1 1 route-map CONNECTED_TO_EIGRP
!
route-map CONNECTED_TO_EIGRP permit 10
Note
match interface Ethernet0/0 Ethernet0/1
The metric values used for
redistribution are arbitrary.
R6:
router eigrp 10
redistribute connected metric 1 1 1 1 1 route-map CONNECTED_TO_EIGRP
!
route-map CONNECTED_TO_EIGRP permit 10
match interface GigabitEthernet0/0.6
Task 4.7 Verification
Verify that VLANs 5, 6, and 52 appear as EIGRP external routes:
Rack1R3#show ip route eigrp | inc (132.1.5.0|132.1.6.0|192.10.1.0)
D EX 132.1.5.0/24 [170/2560512256] via 132.1.35.5,00:02:11, Serial1/1.1
D EX 132.1.6.0/24 [170/2560514816] via 132.1.23.2,00:01:54, Serial1/3
D EX 192.10.1.0/24[170/2560512256] via 132.1.35.5,00:02:11, Serial1/1.1
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 37
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 4.8
R5:
interface Serial0/0.1 point-to-point
backup delay 60 300
backup interface Serial0/1
Task 4.8 Verification
Verify that backup is configured:
Rack1R5#show backup
Primary Interface Secondary Interface Status
----------------- ------------------- ------
Serial0/0.1 Serial0/1 normal operation
Rack1R5#show interface Serial 0/1
Serial0/1 is standby mode, line protocol is down
Check to see that the backup configuration is actually working (note,
shutting down the interface on the router with the backup configuration
will not trigger the backup):
Rack1R5#debug backup
Rack1R5#conf t
Rack1R5(config)#interface s0/0.1
Rack1R5(config-subif)#no frame-relay interface-dlci 513
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 132.1.35.3 (Serial0/0.1) is
down: interface down
BACKUP(Serial0/0.1): event = primary interface went down
BACKUP(Serial0/0.1): changed state to "waiting to backup"
60 seconds later:
BACKUP(Serial0/0.1): event = timer expired on primary
BACKUP(Serial0/0.1): secondary interface (Serial0/1) made active
BACKUP(Serial0/0.1): changed state to "backup mode"
%LINK-3-UPDOWN: Interface Serial0/1, changed state to up
BACKUP(Serial0/1): event = secondary interface came up
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 132.1.45.4 (Serial0/1) is
up: new adjacency
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed
state to up
BACKUP(Serial0/1): event = secondary interface came up
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 38
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 4.9
SW1:
router rip
version 2
network 150.1.0.0
network 204.12.1.0
no auto-summary
SW2:
ip routing
!
router rip
version 2
network 132.1.0.0
network 150.1.0.0
network 204.12.1.0
no auto-summary
Task 4.9 Verification
Verify that RIP is configured and working:
Rack1SW1#show ip protocols | begin rip

Interface Send Recv Triggered RIP Key-chain
Vlan783 2 2
Loopback0 2 2

Routing for Networks:
150.1.0.0
204.12.1.0
Routing Information Sources:
Gateway Distance Last Update
204.12.1.254 120 00:00:05
204.12.1.8 120 00:00:06
Distance: (default is 120)
Verify that RIP routes are being received from the backbone router:
Rack1SW1#show ip route rip
132.1.0.0/16 is variably subnetted, 8 subnets, 2 masks
R 132.1.8.0/24 [120/1] via 204.12.1.8, 00:00:18, Vlan783
31.0.0.0/16 is subnetted, 4 subnets
R 31.3.0.0 [120/1] via 204.12.1.254, 00:00:14, Vlan783
R 31.2.0.0 [120/1] via 204.12.1.254, 00:00:14, Vlan783
R 31.1.0.0 [120/1] via 204.12.1.254, 00:00:14, Vlan783
R 31.0.0.0 [120/1] via 204.12.1.254, 00:00:14, Vlan783
150.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
R 150.1.8.0/24 [120/1] via 204.12.1.8, 00:00:18, Vlan783
30.0.0.0/16 is subnetted, 4 subnets
R 30.2.0.0 [120/1] via 204.12.1.254, 00:00:14, Vlan783
R 30.3.0.0 [120/1] via 204.12.1.254, 00:00:14, Vlan783
R 30.0.0.0 [120/1] via 204.12.1.254, 00:00:14, Vlan783
R 30.1.0.0 [120/1] via 204.12.1.254, 00:00:14, Vlan783
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 39
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 4.10
SW1:
router rip
offset-list EVEN_SECOND_OCTET in 16 Vlan783
!
ip access-list standard EVEN_SECOND_OCTET
permit 0.0.0.0 255.254.255.255
Task 4.10 Breakdown
The least significant bit of a binary number determines whether the number is
even or odd. If the least significant bit is not set the number must be even. If the
least significant bit is set the number must be odd. This always holds true since
all other places in the binary table are even numbers, and any combination of
even numbers plus an odd number results in an odd number. Likewise any
combination of even numbers results in an even number.
Place 128 64 32 16 8 4 2 1
Even X X X X X X X 0
Odd X X X X X X X 1
Where  X is either 0 or 1.
Since only the least significant bit determines whether a number is even or odd it
is the only bit that needs to be checked. Therefore the resulting wildcard mask is
254, or in binary as follows:
Place 128 64 32 16 8 4 2 1
Wildcard 1 1 1 1 1 1 1 0
Where  0 is check and  1 is ignore.
The most common way to filter off a routing prefix in a distance vector protocol is
to use the distribute-list command. A distribute-list is a way to apply an access-
list to routing protocol updates. A routing prefix may also be filtered out by
poisoning the metric or distance of the route.
To change the metric of a distance vector prefix use the routing process level
command offset-list. In RIP a metric of 16 is  infinite . When a prefix has a
metric of 16 it is considered unreachable, and cannot be installed in the routing
table. The first solution to this task adds a metric of 16 to the incoming prefixes,
hence invalidating them.
The second solution is to use the distance command. A distance of 255 is
infinite. Any prefix with a distance of 255 is considered unreachable, and cannot
be installed in the routing table. To change the distance of a prefix use the
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 40
IEWB-RS Version 4.0 Solutions Guide Lab 2
distance [distance] [neighbor] [wildcard] [access-list] where distance is the
desired distance, neighbor is the originating address of the prefix, wildcard is a
wildcard mask used to check the neighbor field, and access-list is a standard
access-list number.
Note
The distance of external EIGRP cannot be changed on a per prefix basis.
Caution
The neighbor field in the distance command may not always be the
interface address of the directly connected neighbor. In the case of OSPF
this address is the router-id of the originating router into the area. In the
case of BGP it is the address used to establish the peering relationship. It is
not necessary to remember which address is used in which protocol, but
instead you must only know where this value is located. The address used
in the neighbor field is the from w.x.y.z address in the show ip route output:
R3#show ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "isis", distance 115, metric 10, type level-2
Redistributing via isis
Last update from 13.0.0.1 on Ethernet0/0, 01:17:11 ago
Routing Descriptor Blocks:
* 13.0.0.1, from 1.1.1.1, via Ethernet0/0
Route metric is 10, traffic share count is 1
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 41
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 4.10 Verification
Verify that the RIP networks with an even second octet are being
filtered:
Rack1SW1#debug ip rip

RIP: received v2 update from 204.12.1.254 on Vlan783
30.0.0.0/16 via 0.0.0.0 in 17 hops (inaccessible)
30.1.0.0/16 via 0.0.0.0 in 1 hops
30.2.0.0/16 via 0.0.0.0 in 17 hops (inaccessible)
30.3.0.0/16 via 0.0.0.0 in 1 hops
31.0.0.0/16 via 0.0.0.0 in 17 hops (inaccessible)
31.1.0.0/16 via 0.0.0.0 in 1 hops
31.2.0.0/16 via 0.0.0.0 in 17 hops (inaccessible)
31.3.0.0/16
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 42
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 4.11
SW1:
router ospf 1
redistribute rip subnets
network 132.1.17.7 0.0.0.0 area 17
!
router rip
Note
redistribute ospf 1 metric 1
The metric values used for
distance 109
redistribution are arbitrary. If
the lab doesn t specify or imply
R2:
a certain value should be
router eigrp 10
used, then any value can be
redistribute ospf 1 metric 1 1 1 1 1
used.
!
router ospf 1
redistribute eigrp 10 subnets metric 20
distance ospf external 171
distance 110 0.0.0.0 255.255.255.255 EXTERNAL_VIA_OSPF
!
ip access-list standard EXTERNAL_VIA_OSPF
remark == External prefixes that should be reachable via OSPF
permit 132.1.7.0
permit 132.1.8.0
permit 150.1.7.0
permit 150.1.8.0
permit 204.12.1.0
permit 31.0.0.0 0.255.255.255
permit 30.0.0.0 0.255.255.255
R3:
router eigrp 10
redistribute ospf 1 metric 1 1 1 1 1
!
router ospf 1
redistribute eigrp 10 subnets metric 30
distance ospf external 171
distance 110 0.0.0.0 255.255.255.255 EXTERNAL_VIA_OSPF
!
ip access-list standard EXTERNAL_VIA_OSPF
remark == External prefixes that should be reachable via OSPF
permit 132.1.7.0
permit 132.1.8.0
permit 150.1.7.0
permit 150.1.8.0
remark == VLAN6 is here for multicast & PBR sections
permit 132.1.6.0
permit 204.12.1.0
permit 31.0.0.0 0.255.255.255
permit 30.0.0.0 0.255.255.255
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 43
IEWB-RS Version 4.0 Solutions Guide Lab 2
R4:
router eigrp 10
redistribute ospf 1 metric 1 1 1 1 1
!
router ospf 1
redistribute eigrp 10 subnets metric 40
distance ospf external 171
distance 110 0.0.0.0 255.255.255.255 EXTERNAL_VIA_OSPF
!
ip access-list standard EXTERNAL_VIA_OSPF
remark == External prefixes that should be reachable via OSPF
permit 132.1.7.0
permit 132.1.8.0
permit 150.1.7.0
permit 150.1.8.0
permit 204.12.1.0
permit 31.0.0.0 0.255.255.255
permit 30.0.0.0 0.255.255.255
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 44
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 4.11 Verification
Verify that redistribution is active:
Rack1SW1#show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "ospf 1"

It is an autonomous system boundary router
Redistributing External Routes from,
rip, includes subnets in redistribution

Routing Protocol is "rip"

Redistributing: ospf 1, rip

Verify full IGP reachability with TCL script:
tclsh
foreach i {
132.1.0.1
132.1.17.1
150.1.1.1
132.1.0.2
132.1.23.2
150.1.2.2
132.1.26.2
132.1.3.3
132.1.0.3
132.1.23.3
150.1.3.3
132.1.35.3
132.1.33.3
132.1.0.4
150.1.4.4
132.1.255.4
132.1.45.4
132.1.5.5
150.1.5.5
132.1.35.5
132.1.45.5
192.10.1.5
54.1.2.6
132.1.6.6
150.1.6.6
132.1.26.6
132.1.17.7
150.1.7.7
204.12.1.7
132.1.8.8
150.1.8.8
204.12.1.8
132.1.255.9
132.1.255.10
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 45
IEWB-RS Version 4.0 Solutions Guide Lab 2
} { puts [ exec "ping $i" ] }
Do not worry if you can not ping local unmapped IP addresses on Frame
Relay multipoint and physical interfaces. If you are uncertain as to
the requirement for your particular lab ask the proctor for
clarification. Also for now ignore the 132.1.45.0/24 subnet as it s
the backup link between R4 and R5.
As additional verification bring down the Frame Relay link between R3
and R5 by removing the DLCI from either side s subinterface. Once the
backup interface is out of the standby state, rerun the ping script.
Although the 3550 s and 3560 s do not support the TCL shell they do
support macros. The macro below can be used for testing from the
switches.
conf t
macro name ping_internal
do ping 132.1.0.1
do ping 132.1.17.1
do ping 150.1.1.1
do ping 132.1.0.2
do ping 132.1.23.2
do ping 150.1.2.2
do ping 132.1.26.2
do ping 132.1.3.3
do ping 132.1.0.3
do ping 132.1.23.3
do ping 150.1.3.3
do ping 132.1.35.3
do ping 132.1.33.3
do ping 132.1.0.4
do ping 132.1.255.4
do ping 150.1.4.4
do ping 132.1.5.5
do ping 150.1.5.5
do ping 132.1.35.5
do ping 192.10.1.5
do ping 54.1.2.6
do ping 132.1.6.6
do ping 150.1.6.6
do ping 132.1.26.6
do ping 132.1.17.7
do ping 150.1.7.7
do ping 204.12.1.7
do ping 132.1.8.8
do ping 150.1.8.8
do ping 204.12.1.8
do ping 132.1.255.9
do ping 132.1.255.10
@
macro global apply ping_internal
Although points are not taken away for additional configuration it is
advisable to remove the macros from the configuration prior to leaving
the lab.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 46
IEWB-RS Version 4.0 Solutions Guide Lab 2
Lastly, verify reachability to the backbone IGP networks with following
TCL script and macro:
tclsh
foreach i {
200.0.0.1
200.0.1.1
200.0.2.1
200.0.3.1
31.3.0.1
31.1.0.1
30.3.0.1
30.1.0.1
} { puts [ exec "ping $i" ] }
SW1 and SW2:
conf t
macro name ping_external
do ping 200.0.0.1
do ping 200.0.1.1
do ping 200.0.2.1
do ping 200.0.3.1
do ping 31.3.0.1
do ping 31.1.0.1
do ping 30.3.0.1
do ping 30.1.0.1
@
macro global apply ping_external
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 47
IEWB-RS Version 4.0 Solutions Guide Lab 2
5. Exterior Gateway Routing
Task 5.1
R1:
router bgp 300
bgp router-id 150.1.1.1
no synchronization
neighbor 132.1.0.4 remote-as 300
neighbor 132.1.17.7 remote-as 400
R2:
router bgp 300
bgp router-id 150.1.2.2
no synchronization
neighbor 132.1.0.4 remote-as 300
neighbor 132.1.26.6 remote-as 100
R3:
router bgp 300
bgp router-id 150.1.3.3
no synchronization
neighbor 132.1.0.4 remote-as 300
neighbor 132.1.35.5 remote-as 200
R4:
router bgp 300
bgp router-id 150.1.4.4
no synchronization
neighbor 132.1.0.1 remote-as 300
neighbor 132.1.0.1 route-reflector-client
neighbor 132.1.0.2 remote-as 300
neighbor 132.1.0.2 route-reflector-client
neighbor 132.1.0.3 remote-as 300
neighbor 132.1.0.3 route-reflector-client
neighbor 132.1.45.5 remote-as 200
R5:
router bgp 200
bgp router-id 150.1.5.5
neighbor 132.1.35.3 remote-as 300
neighbor 132.1.45.4 remote-as 300
R6:
router bgp 100
bgp router-id 150.1.6.6
neighbor 54.1.2.254 remote-as 54
neighbor 132.1.26.2 remote-as 300
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 48
IEWB-RS Version 4.0 Solutions Guide Lab 2
SW1:
router bgp 400
bgp router-id 150.1.7.7
no synchronization
neighbor 132.1.17.1 remote-as 300
neighbor 204.12.1.8 remote-as 400
neighbor 204.12.1.254 remote-as 54
SW2:
router bgp 400
bgp router-id 150.1.8.8
no synchronization
neighbor 204.12.1.7 remote-as 400
Task 5.1 Breakdown
The initial BGP setup of this task is relatively straightforward. Since R4 is the
only device that establishes a peering relationship with all devices in AS 300, it is
implied that R4 is performing route-reflection for these devices.
Task 5.1 Verification
Verify that BGP peering is up, for instance on R4:
Rack1R4#show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
132.1.0.1 4 300 3 2 0 0 0 00:00:29 0
132.1.0.2 4 300 6 3 0 0 0 00:00:35 10
132.1.0.3 4 300 3 3 0 0 0 00:00:48 0
132.1.45.5 4 200 0 0 0 0 0 never Idle
Note that the peering session to 132.1.45.5 is via the backup interface
and should be idle unless the backup is active.
Strategy Tip
Do not move beyond this point in the lab without first verifying the BGP
peering.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 49
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 5.2
R5:
router bgp 200
neighbor 192.10.1.254 remote-as 254
neighbor 192.10.1.254 password CISCO
Task 5.2 Verification
Try setting wrong password and see results:
Rack1R5#conf t
Rack1R5(config)#router bgp 200
Rack1R5(config-router)#no neighbor 192.10.1.254 password CISCO
Rack1R5(config-router)#neighbor 192.10.1.254 password CISCO1
Rack1R5(config-router)#do clear ip bgp 192.10.1.254
%BGP-5-ADJCHANGE: neighbor 192.10.1.254 Down User reset
%TCP-6-BADAUTH: Invalid MD5 digest from 192.10.1.254(179) to
192.10.1.5(49258)
%TCP-6-BADAUTH: Invalid MD5 digest from 192.10.1.254(179) to
192.10.1.5(49258)
Task 5.3
SW1:
router bgp 400
neighbor 204.12.1.254 remote-as 54
neighbor 204.12.1.254 local-as 100 no-prepend
Task 5.3 Breakdown
This task states that SW1 has recently been acquired from AS 100, but AS 54
has not updated its configuration yet. This is where the BGP local-AS feature
comes into play.
The BGP local-AS feature is typically used in a case similar to what is described
here, when one of more devices are acquired from a different autonomous
system. In order to keep traffic flowing while changes are made to various
providers and customers, the newly configured device can be configured to make
its peers believe it is in a different AS. By adding the neighbor 204.12.1.254
local-as 100 no-prepend statement on to SW1, BB2 will continue to see SW1
as being in AS 100.
Further Reading
Configuring the BGP Local-AS Feature
BGP Hide Local-Autonomous System
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 50
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 5.3 Verification
Verify that local-AS is configured:
Rack1SW1#show ip bgp neighbors 204.12.1.254 | inc local
BGP neighbor is 204.12.1.254, remote AS 54, local AS 100 no-prepend,
external link
Verify that the local-AS is not prepended on iBGP peering session:
Rack1SW1#show ip bgp neighbors 204.12.1.8 advertised-routes

Network Next Hop Metric LocPrf Weight Path
*> 28.119.16.0/24 204.12.1.254 0 0 54 i
*> 28.119.17.0/24 204.12.1.254 0 0 54 i
*> 112.0.0.0 204.12.1.254 0 54 50 60 i
*> 113.0.0.0 204.12.1.254 0 54 50 60 i
Remove the  no-prepend keyword to see the difference:
Rack1SW1#conf t
Rack1SW1(config)#router bgp 400
Rack1SW1(config-router)#no neighbor 204.12.1.254 local-as 100 no-
prepend
Rack1SW1(config-router)#neighbor 204.12.1.254 local-as 100 no-prepend
%BGP-5-ADJCHANGE: neighbor 204.12.1.254 Down Local AS change
Rack1SW1(config-router)#neighbor 204.12.1.254 local-as 100
Rack1SW1#show ip bgp neighbors 204.12.1.8 advertised-routes

Network Next Hop Metric LocPrf Weight Path
*> 28.119.16.0/24 204.12.1.254 0 0 100 54 i
*> 28.119.17.0/24 204.12.1.254 0 0 100 54 i
*> 112.0.0.0 204.12.1.254 0 100 54 50 60 i
*> 113.0.0.0 204.12.1.254 0 100 54 50 60 i
*> 114.0.0.0 204.12.1.254 0 100 54 i

Task 5.4
SW1:
router bgp 400
neighbor 204.12.1.254 route-map STOP_TRANSIT_TO_AS_254 out
!
ip as-path access-list 1 permit _254$
!
route-map STOP_TRANSIT_TO_AS_254 deny 10
match as-path 1
!
route-map STOP_TRANSIT_TO_AS_254 permit 20
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 51
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 5.4 Breakdown
The above task states that AS 400 does not want to provide transit for AS 54 to
get to 254. Assuming that AS 54 has not configured static routes to get to AS
254 through AS 400, the simplest way to accomplish this task is to stop
advertising prefixes from AS 254 to AS 54. These prefixes can be matched in a
single statement using a regular expression. Regular expressions are stings of
special characters that can be used to search and find patterns in an AS path.
The regular expression characters are as follows:
Character Meaning
^ Start of string
$ End of string
[] Range of characters
- Used to specify range ( i.e. [0-9] )
( ) Logical grouping
. Any single character
* Zero or more instances
+ One or more instance
? Zero or one instance
_ Comma, open or close brace, open or close parentheses, start
(underscore) or end of string, or space
In order to match one of these characters within the string the escape sequence \
may be used.
Some commonly used regular expressions include:
Expression Meaning
.* Anything
^$ Locally originated routes
^100_ Learned from AS 100
_100$ Originated in AS 100
_100_ Any instance of AS 100
^[0-9]+$ Directly connected ASs
^[0-9]+(_[0-9])?$ Directly connected ASs and/or their customers
^\(.*\)$ Routes originated in confederation peers
^(\(.*\))?$ Locally originated and/or routes originated in confederation
peers
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 52
IEWB-RS Version 4.0 Solutions Guide Lab 2
Note
Since the question mark indicated context sensitive help in the IOS, the IOS
escape sequence of CTRL-V or ESC-Q must be entered before specifying a
question mark in a regular expression.
Task 5.4 Verification
Check if we have AS 254 originated routes in BGP table:
Rack1SW1#show ip bgp regexp _254$

Network Next Hop Metric LocPrf Weight Path
*> 205.90.31.0 132.1.17.1 0 300 200 254 ?
*> 220.20.3.0 132.1.17.1 0 300 200 254 ?
*> 222.22.2.0 132.1.17.1 0 300 200 254 ?
Make sure they are not advertised to AS 54
Rack1SW1#show ip bgp neighbor 204.12.1.254 advertised-routes
Rack1SW1#
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 53
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 5.5
R5:
router bgp 200
network 132.1.5.0 mask 255.255.255.0
aggregate-address 132.1.0.0 255.255.0.0 summary-only
neighbor 132.1.35.3 route-map DENY_AGGREGATE out
neighbor 132.1.45.4 route-map DENY_AGGREGATE out
!
ip prefix-list DENY_AGGREGATE seq 5 permit 132.1.0.0/16
!
route-map DENY_AGGREGATE deny 10
match ip address prefix-list DENY_AGGREGATE
!
route-map DENY_AGGREGATE permit 20
Task 5.5 Breakdown
When a prefix is aggregated in BGP, the default behavior is to advertise the all
subnets of the aggregate, plus the aggregate to all BGP speaking neighbors.
Since the main goal of BGP aggregation is to reduce the amount of routing
prefixes required in the global BGP table, this default behavior may not be
desired. To prevent the advertisement of subnets that make up the aggregate
add the summary-only keyword on to the aggregate-address statement.
Once the summary-only keyword has been configured, subnets of the aggregate
are suppressed. This means that these subnets are not candidate to be
advertised to other BGP speaking neighbors. In order to have complete control
over which devices receive which prefixes, the unsuppress-map can be used to
selectively advertise previously suppressed routes on a per-neighbor basis.
To accomplish the given task, the above configuration first aggregates the
prefixes in question with the summary-only keyword. Next, the aggregate is
denied from being advertised to all other BGP neighbors. This is accomplished
by creating a prefix-list which is an exact match for the aggregate route. Finally,
an unsuppress-map is applied to the other BGP neighbors.
Further Reading
Understanding Route Aggregation in BGP
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 54
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 5.5 Verification
Verify that the aggregate is being generated:
Rack1R5#show ip bgp

*> 132.1.0.0 0.0.0.0 32768 i
s> 132.1.5.0/24 0.0.0.0 0 32768 i
Check if we send only the summary route to BB2:
Rack1R5#show ip bgp neig 192.10.1.254 advertised-routes | inc 0.0.0.0
*> 132.1.0.0 0.0.0.0 32768 i
Check if we don t send the summary to R3 and R4:
Rack1R5#show ip bgp neighbors 132.1.35.3 advertised-routes | inc
132.1.0.0
Rack1R5#
Finally verify that AS 254 is reachable from AS 100, AS 300, and AS 400
using the TCL script below:
tclsh
foreach i {
205.90.31.1
220.20.3.1
222.22.2.1
} { puts [ exec "ping $i" ] }
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 55
IEWB-RS Version 4.0 Solutions Guide Lab 2
6. IP Multicast
Task 6.1
R1:
ip multicast-routing
!
interface FastEthernet0/0
ip pim sparse-mode
!
interface Serial0/0
ip pim sparse-mode
!
ip pim rp-address 150.1.2.2
R2:
ip multicast-routing
!
interface FastEthernet0/0
ip pim sparse-mode
!
interface Serial0/0
ip pim sparse-mode
!
ip pim rp-address 150.1.2.2
R3:
ip multicast-routing
!
interface Ethernet0/0
ip pim sparse-mode
!
interface Ethernet0/1
ip pim sparse-mode
!
interface Serial1/0
ip pim sparse-mode
!
ip pim rp-address 150.1.2.2
R6:
ip multicast-routing
!
interface GigabitEthernet0/0.6
ip pim sparse-mode
!
interface GigabitEthernet0/0.26
ip pim sparse-mode
!
ip pim rp-address 150.1.2.2
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 56
IEWB-RS Version 4.0 Solutions Guide Lab 2
SW1:
ip multicast-routing distributed
!
interface FastEthernet0/1
ip pim sparse-mode
!
interface Vlan783
ip pim sparse-mode
!
ip pim rp-address 150.1.2.2
Task 6.1 Breakdown
This above section states to configure IP multicast routing utilizing PIM sparse
mode. Since sparse mode requires the definition of a rendezvous point (RP),
static RP assignments were defined on each router pointing to R2 s Loopback 0
interface. This included using the ip pim rp-address command on the RP itself.
As various documentation sources contradict themselves as to whether or not
the router that will be the RP needs the ip pim rp-address command, it is
recommended that the ip pim rp-address command be configured on the RP
itself.
Since R2 will be the RP it is important to ensure that all routers can reach the
R2 s Loopback 0 address. If any router can not reach R2 s Loopback 0 address
that particular router will not be able to participate in the multicast routing
process. If PIM dense or spare-dense mode was used and the RP is
unreachable the router will treat a multicast stream received on an interface as
dense. The determining factor as to if a multicast group will be treated as sparse
or dense is not based on how the interface is configure but on if the router knows
of an RP for that particular multicast group. To view the multicast group-to-RP
mappings on a router use the ip pim rp mapping exec mode command.
Verification
Rack1R1#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 150.1.2.2 (?)
Rack1R1#
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 57
IEWB-RS Version 4.0 Solutions Guide Lab 2
Another important consideration in any multicast network is the possibility of a
reverse-path forwarding (RPF) failure. When there is more than one possible
route through the network to reach the RP, or more than one possible route
between the source and destinations of the multicast streams there is the
possibility of an RPF failure. Since R1, R6, and SW1 only have one path to
reach R2 s Loopback 0 there should not be an issue with an RPF failure. R3 on
the other hand has two possible routes to reach R2 s Loopback 0. One route is
over its Frame-Relay connection to R2 learned when EIGRP (technically
connected) was redistributed into OSPF. The other route is learned from EIGRP
directly from R2 via the HDLC link.
Note
Understanding Reverse Path Forwarding
PIM uses the unicast routing table by default to determine the route to the
source of the multicast stream. This behavior is called Reverse Path
Forwarding (RPF). When a multicast stream is received inbound on an
interface, the router will look at the source IP address of the multicast stream
and determine if the interface the multicast stream was received on is the
interface the router would use to reach that particular IP address. If it is the
interface the multicast stream will have passed the RPF check. If it is not
the interface the unicast routing table would use to reach the source IP
address, the multicast stream would have failed the RPF check. If the
unicast routing table does not have a route to the source of the multicast
stream, the stream would then fail the RPF check. Multicast streams that fail
the RPF check will not be forwarded.
By default PIM can use any unicast route in the routing table for this RPF
check, hence the term Protocol Independent Multicast. If it is needed to
accept a multicast stream that is not received on an interface that the unicast
routing table would use to reach the source IP address of the stream, a
static multicast route can be configured. The ip mroute command is
different than the ip route command in that the ip mroute command
references the source of the multicast packet and not the destination. A
multicast static route will be preferred over any unicast route.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 58
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 6.2
SW1:
interface Vlan783
ip igmp join-group 228.28.28.28
Task 6.2 Breakdown
To enable a multicast enabled router to respond to an ICMP echo sent to a
particular multicast IP address, use the ip igmp join-group interface command.
This command is commonly used when troubleshooting a multicast routing issue
or testing a new multicast deployment. This command is not needed to enable
hosts on a segment to receive multicast traffic. If a host on a segment wants to
receive traffic for a particular multicast group the host will respond to the router s
IGMP query messages or send an unsolicited IGMP report message.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 59
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 6.2 Verification
Verify the joined groups and multicast routes:
Rack1SW1#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
228.28.28.28 Vlan783 00:00:32 00:02:27 204.12.1.7
224.0.1.40 FastEthernet0/1 00:04:35 00:02:04 132.1.17.7
Rack1SW1#show ip mroute

(*, 228.28.28.28), 00:00:41/00:02:18, RP 150.1.2.2, flags: SJCL
Incoming interface: FastEthernet0/1, RPF nbr 132.1.17.1
Outgoing interface list:
Vlan783, Forward/Sparse, 00:00:41/00:02:18, H
Use mtrace to see how the packets should flow through the network:
Rack1SW1#mtrace 132.1.6.6 228.28.28.28
Type escape sequence to abort.
Mtrace from 132.1.6.6 to 132.1.17.7 via group 228.28.28.28
From source (?) to destination (?)
Querying full reverse path...
0 132.1.17.7
-1 132.1.17.7 PIM [132.1.6.0/24]
-2 132.1.17.1 PIM [132.1.6.0/24]
-3 132.1.0.2 PIM Reached RP/Core [132.1.6.0/24]
-4 132.1.26.6 PIM [132.1.6.0/24]
Use ping to verify the configuration:
Rack1R6#debug ip mpacket
Rack1R6#ping 228.28.28.28
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 228.28.28.28, timeout is 2 seconds:
IP(0): s=132.1.6.6 (GigabitEthernet0/0.6) d=228.28.28.28 id=498,
ttl=254, prot=1, len=114(100), mroute olist null
IP(0): s=132.1.26.6 (GigabitEthernet0/0.26) d=228.28.28.28 id=498,
ttl=254, prot=1, len=114(100), mroute olist null
Reply to request 0 from 132.1.17.7, 8 ms
Reply to request 0 from 132.1.17.7, 12 ms
Finally look at the output of the multicast routing table:
Rack1R6#show ip mroute

(132.1.6.6, 228.28.28.28), 00:01:09/00:02:24, flags: FT
Incoming interface: GigabitEthernet0/0.6, RPF nbr 0.0.0.0,
Registering
Outgoing interface list:
GigabitEthernet0/0.26, Forward/Sparse, 00:01:09/00:03:17
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 60
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 6.3
R2:
interface Serial0/0
ip pim nbma-mode
Task 6.3 Breakdown
When a multicast feed is sent out an interface PIM is not concerned if there is
one client that would like to receive the multicast stream or thousand clients. The
multicast routing table associates which interface to forward the multicast stream
out, and not which particular IP address or addresses would like to receive the
feed. This being the case when a multicast stream is sent out a NBMA interface
it is replicated out all VCs that have broadcast support. In the case that not all
endpoints of the NBMA network require a particular multicast feed(s) this default
behavior is undesirable. For this reason PIM can run in NBMA mode.
Verification
Rack1R2#show ip mroute 226.26.26.26
IP Multicast Routing Table

(150.1.2.2, 226.26.26.26), 00:00:15/00:03:17, flags: FT
Incoming interface: Loopback0, RPF nbr 0.0.0.0, Registering
Outgoing interface list:
Serial0/0, Forward/Sparse, 00:00:14/00:03:17
By enabling PIM NBMA the default behavior of associating interfaces in the
Outgoing Interface List (OIL) will be changed to unicast IP addresses. This
enables the multicast stream to be sent only to the particular neighbor or
neighbors that have requested the multicast stream.
Verification
Rack1R2#show ip mroute 226.26.26.26
IP Multicast Routing Table

(150.1.2.2, 226.26.26.26), 00:00:12/00:03:20, flags: FT
Incoming interface: Loopback0, RPF nbr 0.0.0.0, Registering
Outgoing interface list:
Serial0/0, 132.1.0.3, Forward/Sparse, 00:00:12/00:03:18
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 61
IEWB-RS Version 4.0 Solutions Guide Lab 2
7. IPv6
Task 7.1
R2:
ipv6 unicast-routing
!
interface Loopback0
ipv6 address 2001:CC1E:1::2/128
!
interface Serial0/0
ipv6 address 2001:CC1E:1:2323::2/64
frame-relay map ipv6 2001:CC1E:1:2323::3 203 broadcast
!
ipv6 route 2001:CC1E:1::3/128 Serial0/0 2001:CC1E:1:2323::3
R3:
ipv6 unicast-routing
!
interface Loopback0
ipv6 address 2001:CC1E:1::3/128
!
interface Serial1/0
ipv6 address 2001:CC1E:1:2323::3/64
frame-relay map ipv6 2001:CC1E:1:2323::2 302 broadcast
!
ipv6 route 2001:CC1E:1::2/128 Serial1/0 2001:CC1E:1:2323::2
Task 7.1 Breakdown
Frame Relay is a non-broadcast multi-access (NBMA) media. This implies that
for multipoint configurations layer 3 to layer 2 resolution must be obtained. Since
only static routing is used, a mapping is not required to the remote link-local
address. If dynamic IPv6 routing were configured a mapping for the remote link-
local address would be required.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 62
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 7.1 Verification
Verify the Frame Relay IPv6 layer 3 to layer 2 mappings:
Rack1R3#show frame-relay map

Serial1/0 (up): ipv6 2001:CC1E:1:2323::2 dlci 302(0x12E,0x48E0),
static,
broadcast,
CISCO, status defined, active
Verify L3 reachability:
Rack1R3#ping 2001:CC1E:1::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:1::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/31/32 ms
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 63
IEWB-RS Version 4.0 Solutions Guide Lab 2
8. QoS
Task 8.1
R3:
class-map match-all SMTP_FROM_SERVER
match access-group name SMTP_FROM_SERVER
!
policy-map CBWFQ
class SMTP_FROM_SERVER
bandwidth 256
!
interface Serial1/1
bandwidth 512
service-policy output CBWFQ
!
ip access-list extended SMTP_FROM_SERVER
permit tcp host 132.1.3.100 eq smtp any
R5:
class-map match-all SMTP_TO_SERVER
match access-group name SMTP_TO_SERVER
!
policy-map CBWFQ
class SMTP_TO_SERVER
bandwidth 256
!
interface Serial0/0
bandwidth 512
service-policy output CBWFQ
!
ip access-list extended SMTP_TO_SERVER
permit tcp any host 132.1.3.100 eq smtp
Task 8.1 Breakdown
To meet the requirements of this section the best solution will be to use the
MQC. Technically custom queuing could be used to meet the requirements but
using the MQC is a more appropriate and simpler solution. Both custom queuing
and priority queuing have fallen out of favor in the more recent IOS versions.
Cisco s preferred solution for QoS is to use the MQC.
The bandwidth guarantee is only active during times of congestion. When
congestion occurs, R3 and R5 will ensure packets matching the class-maps are
allotted the configured bandwidth.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 64
IEWB-RS Version 4.0 Solutions Guide Lab 2
Caution
Output queue calculations for the MQC are based on the configured
bandwidth value of the interface and not the speed the interface is clocked
at. Be sure to set the appropriate bandwidth value when configuring the
MQC on an interface.
Task 8.2 Verification
Verify that the policy-map is configured, applied, and working.
Simulate SMTP traffic from R5:
Rack1R5#telnet 132.1.3.100 25 /source-interface e0/1
Trying 132.1.3.100, 25 ...
Check out policy-map status:
Rack1R5#show policy-map interface s0/0
Serial0/0
Service-policy output: CBWFQ
Class-map: SMTP_TO_SERVER (match-all)
4 packets, 192 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name SMTP_TO_SERVER
Queueing
Output Queue: Conversation 137
Bandwidth 256 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 4/192
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
51 packets, 3292 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 65
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 8.2
R2:
interface FastEthernet0/0
ip policy route-map POLICY-ROUTE
!
ip access-list extended FTP_FROM_VLAN6
permit tcp 132.1.6.0 0.0.0.255 host 132.1.33.3 eq ftp
permit tcp 132.1.6.0 0.0.0.255 host 132.1.33.3 eq ftp-data
!
route-map POLICY-ROUTE permit 10
match ip address FTP_FROM_VLAN6
set ip next-hop 132.1.23.3
R3:
interface Ethernet0/1
ip policy route-map POLICY-ROUTE
!
ip access-list extended FTP_FROM_SERVER
permit tcp host 132.1.33.3 eq ftp 132.1.6.0 0.0.0.255
permit tcp host 132.1.33.3 eq ftp-data 132.1.6.0 0.0.0.255
!
route-map POLICY-ROUTE permit 10
match ip address FTP_FROM_SERVER
set ip next-hop 132.1.23.2
Task 8.2 Breakdown
This section will require the use of policy routing. The first step is to configure
the policy routing to ensure that FTP traffic transverses the HDLC link. Policy
routing is enabled by creating a route-map to define match and set criteria. In
the above task an access-list is used to match the traffic that will be policy
routed. The set ip next-hop 132.1.23.2 will force packets that match the
access-list to the next hop 132.1.23.2 regardless of what the IP routing table
says. The policy is then bound to the interface using the ip policy route-map
command. Policy routing applied to an interface only affects incoming traffic on
the interface.
Note
Policy routing can be used to affect packets sourced by the router itself by
binding a route-map globally using the ip local policy route-map command.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 66
IEWB-RS Version 4.0 Solutions Guide Lab 2
Since policy routing occurs before normal routing it can be used to route packets
based on more than just the normal destination IP address. In this task policy
routing is used to route packets based on an extended access-list. Other criteria
such as the length of the packet can also be used. Due to this flexibility that
policy routing adds it is commonly referred to as the duct tape of routing.
Task 8.2 Verification
Verify that the policy-map is configured:
Rack1R2#show ip policy
Interface Route map
Fa0/0 POLICY-ROUTE
Verify that the packets are actually being policy routed:
Rack1R2#debug ip policy
Rack1R2#conf t
Rack1R2(config)#interface fa0/0
Rack1R2(config-if)#no ip route-cache
Rack1R6#telnet 132.1.33.3 21 /source-interface g0/0.6
Rack1R2#
IP: s=132.1.6.6 (FastEthernet0/0), d=132.1.33.3 (Serial0/1), len 44,
policy routed
IP: FastEthernet0/0 to Serial0/1 132.1.23.3
Task 8.3
R2:
class-map match-all FTP_FROM_VLAN6
match access-group name FTP_FROM_VLAN6
!
policy-map RESERVE_FTP
class FTP_FROM_VLAN6
bandwidth 256
!
interface Serial0/1
bandwidth 1536
service-policy output RESERVE_FTP
R3:
class-map match-all FTP_FROM_SERVER
match access-group name FTP_FROM_SERVER
!
policy-map RESERVE_FTP
class FTP_FROM_SERVER
bandwidth 256
!
interface Serial1/3
bandwidth 1536
service-policy output RESERVE_FTP
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 67
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 8.3 Breakdown
Once the packets have been policy routed across the HDLC link, a QoS policy
can be configured using the MQC that will guarantee 256Kbps for the FTP traffic.
Since this FTP traffic will not be using PASV FTP we only need to match TCP
ports 20 and 21 in the access-list.
Further Reading
Internet Protocol Journal: Is Your FTP Active or Passive?
Task 8.3 Verification
Verify the policy-map configuration:
Rack1R3#show policy-map interface s1/3
Serial1/3
Service-policy output: RESERVE_FTP
Class-map: FTP_FROM_SERVER (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name FTP_FROM_SERVER
Queueing
Output Queue: Conversation 265
Bandwidth 256 (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)
2 packets, 88 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 68
IEWB-RS Version 4.0 Solutions Guide Lab 2
9. Security
Task 9.1
R5:
no ip source-route
no ip bootp server
!
interface Ethernet0/1
no ip proxy-arp
no cdp enable
!
banner login "Access to this device or the attached networks is
prohibited without express written permission. Violators will be shot
on sight."
Task 9.1 Breakdown
Source routing is enabled by default in the IOS. Source routing, as the name
implies, allows the source to determine the route the packet will take through the
network to reach the destination.
There are two types of source routing defined by RFC 791 (Internet Protocol).
The first type is called loose source routing. This is where the complete route is
not included in the packet. The packet can take any path through the network to
reach the destination as long as the packet is passed through the routers whose
IP addresses are included in the header of the packet. The second type is called
strict source routing. In strict source routing the packet must pass through the
routers, and only the routers defined in the header of the packet to reach the
destination.
Further Reading
RFC 791 - Internet Protocol
Source routing can be a security risk, but can also be a useful tool in
troubleshooting routing problems. The IOS supports source routing packets
using telnet, ping, and traceroute.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 69
IEWB-RS Version 4.0 Solutions Guide Lab 2
Rack1R5#telnet 10.1.1.1 ?
/debug Enable telnet debugging mode
/ipv4 Force use of IP version 4
/ipv6 Force use of IP version 6
/line Enable telnet line mode
/noecho Disable local echo
/quiet Suppress login/logout messages
/route: Enable telnet source route mode
Rack1R5#ping
Protocol [ip]:
Target IP address: 10.1.1.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Rack1R5#traceroute
Protocol [ip]:
Target IP address: 10.1.1.1
Source address:
Numeric display [n]: y
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
By default, a Cisco router will act as a bootstrap server (BOOTP). BOOTP was
around before DHCP and was originally used to allow diskless workstations to
determine their IP address, the address of the server from which a bootfile can
be downloaded, and the name of the bootfile itself. BOOTP is outlined in RFC
951.
Even after disabling the BOOTP server in the global configuration, the output of
the show ip socket command will still show that the router is listening to UDP
port 67 if DHCP is still enabled. Disabling DHCP can be done by using the no
service dhcp command.
Rack1R5#show ip socket
Proto Remote Port Local Port In Out Stat TTY OutputIF
17 0.0.0.0 0 150.1.5.5 67 0 0 2211 0
IP Protocol 17 (UDP) UDP Port 67 (BOOTP)
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 70
IEWB-RS Version 4.0 Solutions Guide Lab 2
Proxy ARP is a technique in which a router will answer for an ARP request if the
ARP request is for an IP address that is not on the local segment and the router
has a route for the IP address. Proxy ARP is enabled by default.
Rack1R5#show ip interface e0/0 | include Proxy ARP
Proxy ARP is enabled
Local Proxy ARP is disabled
Further Reading
Proxy ARP
Local Proxy ARP
Managing Connections, Menus, and System Banners
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 71
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 9.1 Verification
Verify that CDP is disabled on interface Ethernet0/1  compare the
outputs for the two interfaces:
Rack1R5#show cdp interface ethernet 0/0
Ethernet0/0 is up, line protocol is up
Encapsulation ARPA
Sending CDP packets every 60 seconds
Holdtime is 180 seconds
Rack1R5#show cdp interface ethernet 0/1
Rack1R5#
Verify that the commands are in the configuration:
Rack1R5#show run | inc (source-route|bootp)
no ip source-route
no ip bootp server
If you really want to see how source-routing works, try the following
command from R4:
Rack1R4#traceroute
Protocol [ip]:
Target IP address: 222.22.2.1
Source address:
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]: L
Source route: 132.1.0.1 132.1.0.2 132.1.23.3 132.1.35.5 192.10.1.254
Loose, Strict, Record, Timestamp, Verbose[LV]:
Now try it with source-routing enabled on R5.
Rack1R5#show running-config interface e0/1
interface Ethernet0/1
ip address 192.10.1.5 255.255.255.0
no ip proxy-arp
half-duplex
no cdp enable
end
To be sure that Proxy-ARP is disabled, issue the following command:
Rack1R5#sh ip interface e0/1 | include Proxy
Proxy ARP is disabled
Local Proxy ARP is disabled
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 72
IEWB-RS Version 4.0 Solutions Guide Lab 2
Verify the login banner:
Rack1R3#telnet 150.1.5.5
Trying 150.1.5.5 ... Open
Access to this device or the attached networks is
prohibited without express written permission. Violators will be shot
on sight.
User Access Verification
Password:
Task 9.2
R5:
interface Ethernet0/1
ip access-group DENY_SNMP in
!
ip access-list extended DENY_SNMP
deny udp any any eq snmp
permit ip any any
R6:
interface Serial0/0/0
ip access-group DENY_SNMP in
!
ip access-list extended DENY_SNMP
deny udp any any eq snmp
permit ip any any
Task 9.2 Breakdown
The two UDP ports used by SNMP are 161 and 162. UDP port 161 is used by
network management devices to poll managed devices. UDP port 162 is used
by managed devices to send SNMP traps. Since this section stated R2 and R4
were being polled via SNMP, only port UDP port 161 needs to be denied.
If a rogue device was sending SNMP traps to the network management server,
than an access-list denying UDP port 162 can be used.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 73
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 9.3
R2 and R4:
snmp-server community public RO 1
access-list 1 deny any log
logging 132.1.33.100
Task 9.3 Breakdown
The key to this section is to create an access-list that denies all IP address and
includes the log keyword. The access-list is then bound to the RO community
string of public. This is a useful technique to track down the source of a host
attempting to poll a device.
Task 9.4
R5:
interface Ethernet0/1
ip access-group DENY_SNMP in
ip access-group EVALUATE_ICMP out
!
ip access-list extended DENY_SNMP
deny udp any any eq snmp
permit icmp any any time-exceeded
permit icmp any any port-unreachable
evaluate ICMP
deny icmp any any
permit ip any any
!
ip access-list extended EVALUATE_ICMP
permit icmp any any reflect ICMP
permit ip any any
Task 9.4 Breakdown
Reflexive access-lists and content based access-control (CBAC) can be used to
turn the router into a stateful firewall. A stateful firewall means that when traffic
leaves the network it is noted in a state table. When traffic tries to come back
into the network it is only allowed in if there is a previously created entry in the
state table. A reflexive access-list uses the same principle.
When traffic is leaving the network it is reflected to the state table. When traffic
tries to come back in it is evaluated to see if there is a previous entry in the state
table. If there is no entry (and no explicit permit statement) the traffic is denied.
Without the reflect statement nothing would show up in the state table and
everything would be effectively denied.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 74
IEWB-RS Version 4.0 Solutions Guide Lab 2
An important point to note about reflexive access-lists and CBAC is that an
outbound access-list does not affect traffic locally generated by the router. This
means that traffic the router originates (routing protocol traffic, telnet, ping, etc)
will not get evaluated. There are two choices to deal with this problem. You can
either explicitly permit this traffic to return, or you can policy route all locally
generated traffic to another local interface first. The first method is easier, and
the second is potentially more secure. Take the following example:
R1 and R2 are directly connected over an Ethernet segment with the IP network
12.0.0.0/8. R1 is applying a reflexive access-list outbound towards R2. Its
configuration is as follows:
Rack1R1:
interface Ethernet0/0
ip address 12.0.0.1 255.0.0.0
ip access-group INBOUND in
ip access-group OUTBOUND out
!
ip access-list extended INBOUND
evaluate REFLEXIVE
deny ip any any
ip access-list extended OUTBOUND
permit tcp any any reflect REFLEXIVE
permit udp any any reflect REFLEXIVE
permit icmp any any reflect REFLEXIVE
Rack1R1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Traffic is denied as it tries to
Rack1R1#show access-list INBOUND
re-enter the Ethernet interface
Extended IP access list INBOUND
connecting to R2
10 evaluate REFLEXIVE
20 deny ip any any (10 matches)
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 75
IEWB-RS Version 4.0 Solutions Guide Lab 2
1st solution: Manually allow traffic back in.
Rack1R1(config)#ip access-list extended INBOUND
Rack1R1(config-ext-nacl)#1 permit icmp host 12.0.0.2 host 12.0.0.1
echo-reply
Rack1R1#show access-list INBOUND
Extended IP access list INBOUND
1 permit icmp host 12.0.0.2 host 12.0.0.1 echo-reply
10 evaluate REFLEXIVE
20 deny ip any any (10 matches)
Rack1R1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
!!!!!
Rack1R1#
Now ICMP echo-replies are allowed to come back in from R2.
2nd solution: Policy route the locally generated traffic.
Telnet traffic denied
from returning from R2.
Rack1R1#telnet 12.0.0.2
Trying 12.0.0.2 ...
% Connection timed out; remote host not responding
Rack1R1(config)#interface loopback 0
Rack1R1(config-if)#ip address 1.1.1.1 255.255.255.255
Rack1R1(config-if)#exit
Rack1R1(config)#route-map LOCAL_POLICY
Rack1R1(config-route-map)#set interface loopback 0
Rack1R1(config-route-map)#exit
Rack1R1(config)#ip local policy route-map LOCAL_POLICY
Rack1R1(config)#end
Rack1R1#telnet 12.0.0.2
Trying 12.0.0.2 ... Open
Password required, but none set
[Connection to 12.0.0.2 closed by foreign host]
Rack1R1#show access-list REFLEXIVE
Reflexive IP access list REFLEXIVE
permit tcp host 12.0.0.2 eq telnet host 12.0.0.1 eq 11468 (22
matches) (time left 3)
Now all locally generated traffic is treated as transit traffic. Be careful of using
this method in production as it can have a negative impact on CPU utilization.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 76
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 9.4 Verification
To verify our reflective ACL ping from R3 to BB2:
Rack1R3#ping 192.10.1.254 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 192.10.1.254, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!
Rack1R5#show ip access-lists ICMP
Reflexive IP access list ICMP
permit icmp host 192.10.1.254 host 132.1.35.3 (400 matches) (time
left 297)
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 77
IEWB-RS Version 4.0 Solutions Guide Lab 2
10. System Management
Task 10.1
R5 and R6:
rmon event 1 trap IETRAP description "Five Minute CPU Average Above
75%"
rmon event 2 trap IETRAP description "Five Minute CPU Average Below
40%"
rmon alarm 1 lsystem.58.0 60 absolute rising-threshold 75 1 falling-
threshold 40 2
!
snmp-server host 132.1.33.100 IETRAP
Task 10.1
Breakdown
In this section we have configured R5 and R6 to generate an SNMP trap
whenever their 5 minute CPU utilization average crosses the defined thresholds.
Although RMON is not commonly used in most networks, this particular type of
configuration is very useful to helping in detecting certain network related
problems when they first start to appear.
Another real network usage would be to configure the router to generate an
SNMP trap or log message whenever an interface s utilization increases above
the normal rate for an extended period. For example, if a company s Internet
connection normally has a 25% utilization rate but starts to run at a 75%
utilization rate, there might be an issue that needs attention.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 78
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 10.1 Verification
Verify RMON configuration:
Rack1R6#show rmon alarms
Alarm 1 is active, owned by config
Monitors lsystem.58.0 every 60 second(s)
Taking absolute samples, last value was 0
Rising threshold is 75, assigned to event 1
Falling threshold is 40, assigned to event 2
On startup enable rising or falling alarm
Rack1R6#show rmon events
Event 1 is active, owned by config
Description is Five Minute CPU Average Above 75%
Event firing causes trap to community IETRAP,
last event fired at 0y0w0d,00:00:00,
Current uptime 0y0w0d,18:12:47
Event 2 is active, owned by config
Description is Five Minute CPU Average Below 40%
Event firing causes trap to community IETRAP,
last event fired at 0y0w0d,18:12:04,
Current uptime 0y0w0d,18:12:47
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 79
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 10.2
R4:
username NOC password 0 CISCO
!
line vty 0 4
exec-timeout 5 0
logout-warning 60
absolute-timeout 15
login local
Task 10.2 Breakdown
The exec-timeout [minutes] [seconds] command is used to end an idle exec
process. To disable the exec-timeout either set the timeout to 0 minutes and 0
seconds or issue the command no exec-timeout.
Caution
If using the no exec-timeout command be careful not to issue the no exec
command. If the no exec command is entered no one will be able to create
an exec process and in turn will not be able to login.
The logout-warning command is self explanatory. A warning is issued 60
seconds prior to the user being logged out.
The absolute-timeout command will end an exec process and in turn log a user
off after the configured time expires even if the process is not idle. This
command is useful to limit the length a time a user can be logged in. Normally
this command would be used to limit the amount of time a user can be dialed into
a router as it is not common in a real network to limit the amount of time a user
can be telneted into a router.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 80
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 10.3
R4:
no username NOC password CISCO
username NOC secret CISCO
Task 10.3 Breakdown
In IOS 12.2(8)T Cisco added the ability to store a password associated with a
username as an MD5 hash. The standard encryption used by the service
password-encryption command uses a weak reversible algorithm and was
mainly designed to stop someone from being able to view the configurations and
see the passwords.
Storing a password as an MD5 hash is far more secure but this method can not
be used with PPP PAP or CHAP authentication. With PAP and CHAP the
password needs to be known by the authentication process, but if the password
is stored as a MD5 hash, the actual password is discarded after the hash has
been generated. This makes the password stored in the username command
unusable by PAP or CHAP.
Further Reading
Enhanced Password Security
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 81
IEWB-RS Version 4.0 Solutions Guide Lab 2
Task 10.4
R3:
interface Serial1/0
no logging event link-status
logging event dlci-status-change
!
logging 132.1.33.100
logging trap debugging
Task 10.4 Breakdown
By default only severity 6 (informational) and below messages are sent to a
remote syslog server. To include debugging messages, use the logging trap
debugging command. This command could be also entered as logging trap 7.
The logging trap command can either take the level in its numerical value or by
entering the common name for the level.
Rack1R3(config)#logging trap ?
<0-7> Logging severity level
alerts Immediate action needed (severity=1)
critical Critical conditions (severity=2)
debugging Debugging messages (severity=7)
emergencies System is unusable (severity=0)
errors Error conditions (severity=3)
informational Informational messages (severity=6)
notifications Normal but significant conditions (severity=5)
warnings Warning conditions (severity=4)

Rack1R3(config)#logging trap 7
Rack1R3(config)#logging trap informational
To verify the logging configuration, use the show logging exec command.
Rack1R3#show logging
Syslog logging: enabled (0 messages dropped, 1 messages rate-limited, 0
flushes, 0 overruns, xml disabled)
Console logging: level debugging, 26 messages logged, xml disabled
Monitor logging: level debugging, 0 messages logged, xml disabled
Buffer logging: disabled, xml disabled
Logging Exception size (4096 bytes)
Count and timestamp logging messages: disabled
Trap logging: level debugging, 31 message lines logged
Logging to 132.1.33.100, 2 message lines logged, xml disabled
Note
The logging level specifies that a particular level and all levels below are logged.
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 82
IEWB-RS Version 4.0 Solutions Guide Lab 2
11. IP Services
Task 11.1
R5:
interface Ethernet0/1
ip accounting access-violations
!
ip accounting-threshold 2500
R6:
interface Serial0/0/0
ip accounting access-violations
!
ip accounting-threshold 2500
Task 11.1 Breakdown
Although IP accounting is normally used to track how many packets are received
or sent out an interface in this section it is used to account for the number of
access-list violations. This will account for packets that were denied by the
access-list applied to the interface. To view the accounting records for access-
list violations use the show ip accounting access-violations exec mode
command.
To control the amount of memory that the IP account process uses, the number
of accounting records stored is limited to 2500.
Task 11.1 Verification
Access-violation accounting appears to only work with numbered ACLs in
the IOS versions used:
Rack1R5#show ip access-lists 100
Extended IP access list 100
10 deny udp any any eq snmp
20 permit icmp any any time-exceeded
30 permit icmp any any port-unreachable
40 deny icmp any any (30 matches)
50 permit ip any any (8 matches)
Rack1R5#show run interface ethernet 0/1
!
interface Ethernet0/1
ip address 192.10.1.5 255.255.255.0
ip access-group 100 in

Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 83
IEWB-RS Version 4.0 Solutions Guide Lab 2
Note
You will not have access to the
FRS-BB2>ping 132.1.0.4
backbone routers in the real.
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 132.1.0.4, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
FRS-BB2>ping 132.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 132.1.3.3, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
FRS-BB2>ping 132.1.33.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 132.1.33.3, timeout is 2 seconds:
U.U.U
Rack1R5#show ip accounting access-violations
Source Destination Packets Bytes ACL
192.10.1.254 132.1.33.3 5 500 100
192.10.1.254 132.1.3.3 5 500 100
192.10.1.254 132.1.0.4 5 500 100
Copyright © 2007 Internetwork Expert www.InternetworkExpert.com
2 - 84