Microsoft Word - iewb-rs.v4.vol1.lab02.solutions.guide.doc

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
s

witchport 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

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.”

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

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

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

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’

www.InternetworkExpert.com

2 - 6

IEWB-RS Version 4.0 Solutions Guide Lab 2

The channel modes are as follows:

Mode

Result

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

Desirable Desirable
Desirable Auto
Active

Active

Passive

Further Reading

Configuring EtherChannels

Pitfall

Typical problems with EtherChannel configurations involve the mismatch in
compatible channel modes as well as a mismatch in the configuration of the
member interfaces. To ensure that all member interfaces maintain the exact
same configuration put them in the channel with the channel-group interface
command, 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.

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
<output omitted>
Group Port-channel Protocol Ports
------+-------------+-----------+----------------------------------
1 Po1(SU) Fa0/13(P) Fa0/14(P) Fa0/15(P)

Rack1SW2#show etherchannel 1 summary
<output omitted>
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
<output omitted>
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
<output omitted>
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

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#

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

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
<output omitted>
Group Port-channel Protocol Ports
------+-------------+-----------+----------------------------------
2 Po2(SU) LACP Fa0/16(P) Fa0/17(P) Fa0/18(P)

Rack1SW3#show etherchannel 2 summary
<output omitted>
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

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

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
<output omitted>
Group Port-channel Protocol Ports
------+-------------+-----------+----------------------------------
3 Po3(SU) LACP Fa0/19(P) Fa0/20(P) Fa0/21(P)

Rack1SW4#show etherchannel 3 summary
<output omitted>
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

www.InternetworkExpert.com

2 - 13

IEWB-RS Version 4.0 Solutions Guide Lab 2

Task 1.5

R6:
interface GigabitEthernet0/0.6

encapsulation dot1Q 6 native
ip address 132.1.6.6 255.255.255.0

!
interface GigabitEthernet0/0.26

encapsulation dot1Q 26
ip address 132.1.26.6 255.255.255.0

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

) Troubleshooting

The initial configuration for
R6 has the IP addresses
swapped on G0/0.6 and
G0/0.26

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.

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)
<output omitted>

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

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

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

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.

Pitfall

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

Further Reading

Configuring 802.1X Port-Based Authentication

Doc CD: AAA

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.

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
<output omitted>
HostMode = Single
PortControl = Auto
ControlDirection = Both
QuietPeriod = 60 Seconds
Re-authentication = Disabled
<output omitted>

Dot1x Info for interface FastEthernet0/10
----------------------------------------------------
<output omitted>
HostMode = Single
PortControl = Auto
ControlDirection = Both
QuietPeriod = 60 Seconds
Re-authentication = Disabled
<output omitted>

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

www.InternetworkExpert.com

2 - 20

IEWB-RS Version 4.0 Solutions Guide Lab 2

Task 1.8

) Note

After altering the Switch
Database Template (SDM) a
reload is required before the
new template will take effect.

SW1 and SW2:
sdm prefer routing

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

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.

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

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

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

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/100

ths

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.

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 -

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

lockrate 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

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
<output omitted>
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
<output omitted>

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.

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

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.

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
<output omitted>
No Hellos (Passive interface)
<output omitted>

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

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

igrp router-id 150.1.3.3

R4:
router eigrp 10

network 132.1.45.4 0.0.0.0
no auto-summary

igrp router-id 150.1.4.4

R5:
router eigrp 10

network 132.1.35.5 0.0.0.0
network 132.1.45.5 0.0.0.0
network 150.1.5.5 0.0.0.0
no auto-summary
eigrp router-id 150.1.5.5

R6:
router eigrp 10

network 54.1.2.6 0.0.0.0
network 150.1.6.6 0.0.0.0
no auto-summary
eigrp router-id 150.1.6.6

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

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

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

match interface Ethernet0/0 Ethernet0/1

) Note

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

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

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
<output omitted>

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

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

Even

Odd

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

Wildcard

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

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.

0 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

Note

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

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
<output omitted>
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

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

redistribute ospf 1 metric 1
distance 109

R2:
router eigrp 10

redistribute ospf 1 metric 1 1 1 1 1

) Note

The metric values used for
redistribution are arbitrary. If
the lab doesn’t specify or imply
a certain value should be
used, then any value can be
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

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

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"

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

<output omitted>
Routing Protocol is "rip"

<output omitted>
Redistributing: ospf 1, rip
<output omitted>

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

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.

www.InternetworkExpert.com

2 - 46

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

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.

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

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
<output omitted>

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
<output omitted>

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
<output omitted>

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

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

_
(underscore)

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

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

Some commonly used regular expressions include:

Expression

Meaning

Anything

Locally originated routes

^100_

Learned from AS 100

_100$

Originated in AS 100

_100_

Any instance of AS 100

^[0-9]+$

Directly connected ASs

^[0-9]+(_[0-9])?$

Directly connected ASs and/or their customers

^$.*$$

Routes originated in confederation peers

^($.*$)?$

Locally originated and/or routes originated in confederation
peers

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$
<output omitted>

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#

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

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
<output omitted>
*> 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" ] }

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

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#

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.

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.

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
<output omitted>
(*, 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
<output omitted>

(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

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
<snip>

(150.1.2.2, 226.26.26.26), 00:00:15/00:03:17, flags: FT

Incoming interface: Loopback0, RPF nbr 0.0.0.0, Registering
Outgoing interface list:
Serial0/0, Forward/Sparse, 00:00:14/00:03:17

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

; Verification

Rack1R2#show ip mroute 226.26.26.26
IP Multicast Routing Table

<snip>

(150.1.2.2, 226.26.26.26), 00:00:12/00:03:20, flags: FT
Incoming interface: Loopback0, RPF nbr 0.0.0.0, Registering
Outgoing interface list:
Serial0/0, 132.1.0.3, Forward/Sparse, 00:00:12/00:03:18

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.

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
<output omitted>
Serial1/0 (up): ipv6 2001:CC1E:1:2323::2 dlci 302(0x12E,0x48E0),
static,

broadcast,
CISCO, status defined, active

Verify L3 reachability:

Ra

ck1R3#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

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.

www.InternetworkExpert.com

2 - 64

IEWB-RS Version 4.0 Solutions Guide Lab 2

0 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

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.

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

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

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.

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
Loose, Strict, Record, Timestamp, Verbose[none]:

[0xABCD]:

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

UDP Port 67 (BOOTP)

IP Protocol 17 (UDP)

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

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

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.

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.

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)

Rack1R1#show access-list INBOUND
Extended IP access list INBOUND

10 evaluate REFLEXIVE
20 deny ip any any (10 matches)

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

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(

end

config)#

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.

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)

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

!
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.

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

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.

0 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.

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

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)
<cr>

Rack1R3(config)#logging trap 7
Rack1R3(config)#logging trap informational

To verify the logging configuration, use the show logging exec command.

Rack1R3#show logging
Syslog logging: enabled (0 messages dropped, 1 messages rate-limited, 0
flushes, 0 overruns, xml disabled)

Console logging: level debugging, 26 messages logged, xml disabled
Monitor logging: level debugging, 0 messages logged, xml disabled
Buffer logging: disabled, xml disabled
Logging Exception size (4096 bytes)
Count and timestamp logging messages: disabled
Trap logging: level debugging, 31 message lines logged
Logging to 132.1.33.100, 2 message lines logged, xml disabled

Note

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

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

www.InternetworkExpert.com

2 - 83

IEWB-RS Version 4.0 Solutions Guide Lab 2

FRS-BB2>ping 132.1.0.4

Type escape sequence to abort.

) Note

You will not have access to the
backbone routers in the real.

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

www.InternetworkExpert.com

2 - 84