Sie sind auf Seite 1von 59

CIERSASSESS-5-AK

Cisco 360 CCIE R&S Advanced Workshop 2 Assessment Lab 1

The Cisco 360 CCIE ® Routing and Switching (R&S) Advanced Workshop 2 is a five-day course for CCIE candidates who are ready to attempt the Cisco CCIE lab. Advanced Workshop 2 is not an entry-level course. You should take this course only if you are close to passing the actual CCIE lab.

Advanced Workshop 2 further develops such high-level candidates by presenting learners with five multitopic labs that simulate the actual Cisco CCIE lab experience. Four of the labs are eight hours long; one is four hours long.

One lab is administered on each day of the course. On the first four days, you will perform an eight-hour lab. On the fifth day of the course, you will perform the four-hour lab. During each lab, you will be tested on your knowledge of complex internetworking subjects, your problem- solving skills, and your test-taking strategies.

After each of the labs, you will receive a detailed assessment score report combined with an answer key and Mentor Guide support. To supplement this feedback, Cisco CCIE instructors will provide review sessions after each lab and directed instruction during each lab, if necessary. These resources provide feedback that maximizes the learning experience of each lab.

Cisco 360 CCIE R&S Advanced Workshop 2 Assessment Lab 1 Answer Key

COPYRIGHT 2009, CISCO SYSTEMS, INC. ALL RIGHTS RESERVED. ALL CONTENT AND MATERIALS, INCLUDING WITHOUT LIMITATION, RECORDINGS, COURSE MATERIALS, HANDOUTS AND PRESENTATIONS AVAILABLE ON THIS PAGE, ARE PROTECTED BY COPYRIGHT LAWS. THESE MATERIALS ARE LICENSED EXCLUSIVELY TO REGISTERED STUDENTS FOR THEIR INDIVIDUAL PARTICIPATION IN THE SUBJECT COURSE. DOWNLOADING THESE MATERIALS SIGNIFIES YOUR AGREEMENT TO THE FOLLOWING: (1) YOU ARE PERMITTED TO PRINT THESE MATERIALS ONLY ONCE, AND OTHERWISE MAY NOT REPRODUCE THESE MATERIALS IN ANY FORM, OR BY ANY MEANS, WITHOUT PRIOR WRITTEN PERMISSION FROM CISCO; AND (2) YOU ARE NOT PERMITTED TO SAVE ON ANY SYSTEM, MODIFY, DISTRIBUTE, REBROADCAST, PUBLISH, TRANSMIT, SHARE OR CREATE DERIVATIVE WORKS ANY OF THESE MATERIALS. IF YOU ARE NOT A REGISTERED STUDENT THAT HAS ACCEPTED THESE AND OTHER TERMS OUTLINED IN THE STUDENT AGREEMENT OR OTHERWISE AUTHORIZED BY CISCO, YOU ARE NOT AUTHORIZED TO ACCESS THESE MATERIALS.

Table of Contents

Cisco 360 CCIE R&S Advanced Workshop 2 Assessment Lab 1

1

Cisco 360 CCIE R&S Advanced Workshop 2 Assessment Lab 1 Answer Key

2

Table of Contents

Answer Key Structure

3

4

Section

One

4

Section

Two

4

Cisco 360 CCIE R&S Advanced Workshop 2 Assessment Lab 1 Answer Key

5

Grading and Duration

5

Restrictions

and Goals

5

Explanation of Each of the Restrictions and Goals

7

1.

Frame Relay and Serial Communications Section

9

2.

Cisco Catalyst Switch Configuration Section

11

3.

IPv4 OSPF Section

22

4.

IPv4 EIGRP Section

24

5.

IPv4 RIP Section

27

6.

Cisco OER and NAT Section

28

7.

Border Gateway Protocol Section

37

8.

IPv6 Routing Section

41

9.

Security Section

46

10.

QoS Section

49

11.

Address Administration Section

50

12.

HSRP Gateway Redundancy Section

51

13.

NTP Configuration Section

52

14.

Multicast Configuration Section

54

15.

SNMP Section

57

Answer Key Structure

Section One

The answer key PDF document is downloadable from the web portal.

Section Two

To obtain a comprehensive view of the configuration, access the Mentor Guide engine in the web portal.

Cisco 360 CCIE R&S Advanced Workshop 2 Assessment Lab 1 Answer Key

Regardless of any configuration that you perform in this lab, you must conform to the general guidelines that are provided. If you do not conform to the guidelines, you can expect a significant deduction of points in your final exam score.

Grading and Duration

Lab duration:

8 hours

Maximum score:

100 points

Minimum passing score:

80 points

Restrictions and Goals

Note

Read this section carefully.

To receive any credit for a subsection, you must complete the subsection. You will not get partial credit for partially completed subsections.

IP subnets on the Lab IPv4 IGP diagram belong to network 172.16.0.0/16.

Use a minimum number of statements in all filters unless otherwise directed.

Use only the IP version 4 (IPv4) and IP version 6 (IPv6) addresses that are displayed on the IPv4 and IPv6 interior gateway protocol (IGP) diagrams. Do not introduce new addresses.

The Frame Relay switching router is configured for a full mesh of permanent virtual circuits (PVCs). Do not change the PVC configuration on the Frame Relay switching router.

Do not rely on Frame Relay Inverse Address Resolution Protocol (Inverse ARP).

Do not create any static routes on any routers and switches except for R6 and SW2. Do not use policy-based routing (PBR).

Advertise all loopback interfaces with their original masks, unless noted otherwise.

All IPv4 IP addresses involved in this scenario must be reachable, except for the prefixes from the 1.0.0.0/8 network that are involved in Cisco Optimized Edge Routing (OER), prefixes that are advertised from the backbone, and interfaces that are connected to the shared equipment.

N represents the group number; X represents the pod number. Check your online instructions for your number NX . Failure to assign the correct IP address could result in losing points in multiple sections.

Do not modify the hostname, console, or vty configuration unless you are specifically asked to do so.

Do not modify the initial interface or IP address numbering.

Explanation of Each of the Restrictions and Goals

IP subnets in the scenario diagrams belong to network 172.16.0.0/16.

The third and fourth octets of the IP addresses that are displayed on the diagrams belong to

172.16.0.0/16.

Use a minimum number of statements whenever possible.

If a task requires an access list, prefix list or, autonomous system (AS) path filter list, use as few statements as possible.

Use only the IPv4 and IPv6 addresses that are displayed on the IPv4 and IPv6 IGP diagrams. Do not introduce new ones.

Do not create any new IP addresses. Use the existing addresses to accomplish all tasks.

The Frame Relay switch router is configured for a full mesh of PVCs. Do not change the PVC configuration.

Find alternate methods of controlling the full mesh of PVCs.

Do not rely on dynamic Frame Relay Inverse ARP.

This requirement forces you to fulfill your Frame Relay Inverse ARP requirements with Frame Relay map statements. Think of a Frame Relay map statement as the equivalent of a static Inverse ARP entry.

Do not create any static routes manually.

Static routes can solve a range of reachability problems. However, you cannot use them. You must rely on skillful configuration of all your unicast routing protocols. The scenario is not concerned about static routes created by any Cisco IOS Software protocol or feature.

You can create only one tunnel link in this scenario.

Only one tunnel interface is allowed between R1 and R6 to encapsulate and exchange the Cisco Discovery Protocol packets.

Advertise all IPv4 and IPv6 loopback interfaces with their original mask, unless noted otherwise.

This requirement is primarily for the Open Shortest Path First (OSPF) advertised loopbacks. Use the ip ospf network point-to-point command under the loopback interface. Otherwise, the loopback will be advertised as a /32 host entry by default.

Do not change the configuration on the lines CON and AUX.

These lines are used for grading.

All IP interfaces in the diagram must be reachable within this internetwork.

This is a key goal and requires that all IGPs and routing policy tasks be configured properly. The key elements of your routing policy include route redistribution and the controlling of routing updates using distribute lists, route maps, and the distance command. Although the term “redistribution” might never be explicitly used in this exam, you must perform redistribution to ensure that all IP addresses are reachable without the use of static routes.

IP addresses from the networks that are connected to the backbone are excluded from the previous requirement.

You are not required to make backbone prefixes reachable from all routers in your pod.

N represents the group number; X represents the pod number. Check your online instructions for your number NX. Check your online instructions for your group and pod numbers.

Do not modify the hostname, console configuration, vty configuration, initial interface, or IP address numbering. Follow the numbering conventions carefully.

1.

Frame Relay and Serial Communications Section

Issue:

 

Configure the Frame Relay interface, and control the full mesh with static maps. Verify Layer 3 connectivity.

Solution:

 

The Frame Relay switch is preconfigured for a full mesh of PVCs. You are instructed to use “a minimum amount of data-link connection identifiers (DLCIs) to provide Layer 3 connectivity.” When examining the Lab IPv4 IGP diagram, you see that the Layer 3 connections over the nonbroadcast multiaccess (NBMA) network reflect a hub-and-spoke topology. To fulfill this requirement, perform the following tasks:

Disable Inverse ARP.

Provide static Frame Relay mappings on each of the Frame Relay attached routers. Make sure that one spoke of the Frame Relay topology can ping the other spoke. To fulfill this requirement, make sure that routers R2 and R3 not only possess a Frame Relay map statement to R1 but also possess map statements to one another.

Issue:

 

All Frame Relay interfaces must be capable of receiving pings, including local interfaces.

Solution:

 

A

local Frame Relay interface will not respond to a ping from a router unless you provide Layer

3-to-Layer 2 mapping for the destination address. To make the local address capable of receiving pings, there must be a mapping for the local address as well. Use the PVC associated with the interface where the local IP address is configured for the Frame Relay map. For example, use the frame-relay map IP 172.16.123.2 201 command on R2.

Issue:

 

R1 must be sending Internet Control Message Protocol (ICMP) packets to R2 when you ping 172.16.123.1 from R1.

Solution:

This requirement suggests using DLCI 102 in the map statement for the local Frame Relay mapping to the R1 IP address 172.16.123.1. Even if the router pings its own local interface, the ICMP packet will be encapsulated into a Frame Relay frame with the respective DLCI and will be transmitted to the other end of the PVC associated with the DLCI. The remote end will send it back, assuming that the other router possesses necessary Layer 3-to-Layer 2 mapping information.

Configuration and verification:

R1 and R2 are used as an example of configuration of hub and spoke. R3 is configured similarly

to R2.

R1#show run interface Serial0/0/0.123 | inc map ip + frame-relay map ip 172.16.123.1 102 frame-relay map ip 172.16.123.2 102 broadcast frame-relay map ip 172.16.123.3 103 broadcast

R1#

R2#show run int Serial0/0/0 | inc map ip + frame-relay map ip 172.16.123.1 201 frame-relay map ip 172.16.123.2 201 broadcast frame-relay map ip 172.16.123.3 201

R2#

Note

Only one map statement for a protocol and a DLCI is configured with the broadcast statement. It will satisfy the requirement to encapsulate the broadcast and multicast packets on this DLCI if necessary (IGP routing and multicast routing).

R1#ping 172.16.123.255 rep 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 172.16.123.255, timeout is 2 seconds:

Reply to request 0 from 172.16.123.2, 8 ms Reply to request 0 from 172.16.123.3, 20 ms

R1#

interface Serial0/0/0.62 point-to-point ip address 172.16.62.2 255.255.255.0 frame-relay interface-dlci 206

R6:

interface Serial0/0/0.62 point-to-point ip address 172.16.62.6 255.255.255.0 frame-relay interface-dlci 602

Verify connectivity on the Frame Relay subnet:

R2#ping 172.16.123.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.123.1, timeout is 2 seconds:

!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms

R2#ping 172.16.123.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.123.2, timeout is 2 seconds:

!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/27/88 ms

R2#ping 172.16.123.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.123.3, timeout is 2 seconds:

!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 24/24/28 ms

R2#

R6#ping 172.16.62.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.62.2, timeout is 2 seconds:

!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 100/104/120 ms

Verify that when R1 pings its own IP address 172.16.123.1, the ICMP packets travel to R2.

On R2, create an access list for the debugging purpose—for example, 199:

R2(config)#access-list 199 permit icmp any any

Disable fast switching on the serial interface so that the debugging process can pick up the ICMP packets, which are not destined to R2 but are rerouted to R1:

R2(config)#int Serial0/0/0 R2(config-if)#no ip route-cache

Run the debug ip packets detail 199 and debug ip icmp commands on R2:

R2#deb ip pack det 199 IP packet debugging is on (detailed) for access list 199 R2#debug ip icmp ICMP packet debugging is on

R2#

Go to R1 and ping 172.16.123.1:

R1#ping 172.16.123.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.123.1, timeout is 2 seconds:

!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 20/36/100 ms

R1#

On R2, you should see similar debugging traces:

R2#

*May 29 18:33:36.169: IP: tableid=0, s=172.16.123.1 (Serial0/0/0), d=172.16.123.1 (Serial0/0/0), routed via FIB

*May 29 18:33:36.169:

IP: s=172.16.123.1 (Serial0/0/0), d=172.16.123.1 (Serial0/0/0), len 100,

redirected
redirected

*May 29 18:33:36.169:

ICMP type=8, code=0

*May 29 18:33:36.169: ICMP: redirect sent to 172.16.123.1 for dest 172.16.123.1, use gw

*May 29 18:33:36.169: ICMP: redirect sent to 172.16.123.1 for dest 172.16.123.1, use gw

172.16.123.1

*May 29 18:33:36.169: ICMP: redirect sent to 172.16.123.1 for dest 172.16.123.1, use gw 172.16.123.1

R2 receives the Frame Relay packets on DLCI 102 and redirects the IPv4 packets back to R1 according to the destination IPv4 address 172.16.123.1 and Frame Relay map statement for 172.16.123.1 and DLCI 201.

Do not forget to remove the access list, apply fast switching, and use the undebug all command.

Note

To obtain a comprehensive view of the configuration tasks in this section, access the Mentor Guide engine. With the Mentor Guide engine, you can enter more than 1000 Cisco IOS Software commands as well as a collection of proprietary commands such as show all.

2. Cisco Catalyst Switch Configuration Section

Configure the VLANs and the VLAN names according to the scenario specifications, and assign the ports of the switches to these VLANs. Spell the VLAN names correctly, and match the letter case.

To ensure a thorough understanding of the Layer 2 topology, create a VLAN propagation diagram like the one that follows. Construct it by studying the VLAN table, Switch-to-Router Connections table, Switch-to-Switch Connections table, the IGP diagrams, and the other section requirements, and then carefully document each connection on a copy of the physical layer diagram. You will find that, with practice, you can create such a diagram quickly and find it to be a valuable tool.

VLAN Propagation

VLAN Propagation 12 Cisco 360 CCIE R&S Workshop 2 Assessment Lab 1 Answer Key © 2009

Issue:

 

Do not use any dynamic VLAN advertisement techniques.

Solution:

 

The Cisco Catalyst switch can be configured in one of three modes: server mode, client mode, or transparent mode. The client and server communicate VLANs dynamically to each other using the VLAN Trunking Protocol (VTP). This scenario requires no dynamic VLAN advertisements; therefore, configure VTP transparent mode. VTP transparent mode does not advertise any VLANs that are locally created.

Issue:

 

Allow only necessary VLANs on the trunk between switches SW1 and SW2.

Solution:

 

The preceding VLAN Propagation diagram will help you determine which VLANs stay within one switch and which VLANs span across the links between SW1, SW2, SW3, and SW4. The diagram also shows which VLANs must be allowed on the trunks. Only VLANs 12, 16, 88, and 150 will be allowed between SW1 and SW2 on the port channel.

Verification:

SW1#show int trunk

Port

Mode

Encapsulation Status

Native vlan

Fa0/5

on

802.1q

trunking

1

Fa0/19

desirable

isl

trunking

1

Po1

desirable

n-isl

trunking

1

Port

Vlans allowed on trunk

 

Fa0/5

25,150

Fa0/19

12,16

Po1

12,16,88,150

 

Port

Vlans allowed and active in management domain

Fa0/5

25,150

Fa0/19

12,16

Po1

12,16,88,150

Port

Vlans in spanning tree forwarding state and not pruned

Fa0/5

25,150

Fa0/19

12

Po1

12,16,88,150

SW1#

SW2#show interfaces trunk

Port

Mode

Encapsulation Status

Native vlan

Fa0/1

on

802.1q

trunking

1

Fa0/19

on

isl

trunking

1

Po1

on

isl

trunking

1

Port

Vlans allowed on trunk

 

Fa0/1

16-17,88,100

Fa0/19

12,17,34,100,150

 

Po1

12,16,88,150

 

Port

Vlans allowed and active in management domain

Fa0/1

16-17,88,100

Fa0/19

12,17,34,100,150

 

Po1

12,16,88,150

Port

Vlans in spanning tree forwarding state and not pruned

Fa0/1

16-17,88,100

Fa0/19

12,17,34,100,150

 

Po1

12,16,88,150

Issue:

 

Configure the following switch-to-router connections. Use the IEEE tagging method on these trunk links where necessary.

Solution:

 

Inter-Switch Link (ISL) is a proprietary Cisco protocol; the alternative trunking protocol, 802.1Q, is an IEEE standard.

Issue:

 

Automatically aggregate ports 0/23 and 0/24 between SW1 and SW2 using the protocol that is nonproprietary to Cisco.

Solution:

 

The ports 0/23 and 0/24 can be automatically aggregated using Link Aggregation Control Protocol (LACP). This protocol is defined in IEEE 802.3ad.

Issue:

 

Initiate this process from the SW1 switch only.

Solution:

 

The interface starts actively sending LACP negotiation protocol packets if it is configured with the keyword active. If the interface is configured as passive, it listens to the LACP packets and responds to them, but it does not initiate the packets itself. The solution is to configure the SW1 ports as active (SA below) and the SW2 ports as passive (SP below).

Verification:

SW1#show lacp internal

Flags: S - Device is requesting Slow LACPDUs

F - Device is requesting Fast LACPDUs

A - Device is in Active mode

Channel group 1

P - Device is in Passive mode

 

LACP port

Admin

Oper

Port

Port

Port

Flags

State

Priority

Key

Key

Number

State

Fa0/23

SA SA
SA
SA

bndl

32768

0x1

0x1

0x13

0x3D

Fa0/24

bndl

32768

0x1

0x1

0x14

0x3D

SW1#

SW1#show lacp neighbor

Flags: S - Device is requesting Slow LACPDUs

F - Device is requesting Fast LACPDUs

A - Device is in Active mode

Channel group 1 neighbors

Partner's information:

P - Device is in Passive mode

 

LACP port

 

Oper

Port

Port

Port

Flags

Priority Dev ID

Age

Key

Number

State

Fa0/23

SP SP
SP
SP

32768

000a.8afb.2680

4s

0x1

0x13

0x3C

Fa0/24

32768

000a.8afb.2680

4s

0x1

0x14

0x3C

SW1#

Issue:

Use a Cisco proprietary trunk protocol on the link between SW1 and SW2. Specify the trunk encapsulation on SW2 only. The SW2 end of the trunk should be set to permanent trunking.

Solution:

The Cisco proprietary protocol is ISL. The SW2 end will be set with the encapsulation ISL and mode trunk. SW1 will retain the default mode, dynamic desirable. A summary of the configuration is shown here. Note that the channel-protocol lacp command is optional here; it simply precludes the configuration of modes other than LACP.

SW1:

 

interface Port-channel1

 
 

switchport mode dynamic desirable

 

!

interface FastEthernet0/23 switchport mode dynamic desirable

 

channel-group 1 mode active

 

channel-protocol lacp

 

!

interface FastEthernet0/24 switchport mode dynamic desirable channel-group 1 mode active channel-protocol lacp

SW2:

interface Port-channel1

switchport trunk encapsulation isl

switchport trunk encapsulation isl

switchport mode trunk

switchport trunk encapsulation isl switchport mode trunk

!

interface FastEthernet0/23 switchport trunk encapsulation isl switchport mode trunk

channel-group 1 mode passive

channel-protocol lacp

!

interface FastEthernet0/24 switchport trunk encapsulation isl switchport mode trunk channel-group 1 mode passive channel-protocol lacp

Verification:

SW1#sh interfaces trunk | inc isl

Fa0/19

desirable

isl

trunking

1

Po1

desirable

n-isl

trunking

1

SW1#

SW2#sh interfaces trunk | inc isl

 

Fa0/19

on

isl

trunking

1

Po1

on

isl

trunking

1

SW2#

Issue:

Make SW4 the root bridge for VLAN 12 with priority 24576. Leave all path cost values on the links of VLAN 12 to the default values set by the Cisco IOS Software. If the link between SW1 and SW2 goes down, make sure that forwarding on the link between SW1 and SW3 resumes within 5 seconds maximum.

Solution:

Look at the following diagram. By default, you should find the interface 0/19 on SW1 blocking for VLAN 12:

If the link between SW1 and SW2 goes down, the Spanning Tree Protocol (STP) will
If the link between SW1 and SW2 goes down, the Spanning Tree Protocol (STP) will
If the link between SW1 and SW2 goes down, the Spanning Tree Protocol (STP) will
If the link between SW1 and SW2 goes down, the Spanning Tree Protocol (STP) will
If the link between SW1 and SW2 goes down, the Spanning Tree Protocol (STP) will
If the link between SW1 and SW2 goes down, the Spanning Tree Protocol (STP) will
If the link between SW1 and SW2 goes down, the Spanning Tree Protocol (STP) will
If the link between SW1 and SW2 goes down, the Spanning Tree Protocol (STP) will
If the link between SW1 and SW2 goes down, the Spanning Tree Protocol (STP) will
If the link between SW1 and SW2 goes down, the Spanning Tree Protocol (STP) will
If the link between SW1 and SW2 goes down, the Spanning Tree Protocol (STP) will
If the link between SW1 and SW2 goes down, the Spanning Tree Protocol (STP) will

If the link between SW1 and SW2 goes down, the Spanning Tree Protocol (STP) will recalculate a new forwarding path from SW1 to the root, and interface 0/23 will go through different states, namely listening and learning. This can take up to 50 seconds. The scenario specifies a maximum of only 5 seconds. The optional spanning-tree feature UplinkFast can help you to solve this task:

UplinkFast provides fast convergence after a direct link failure and achieves load balancing between redundant Layer 2 links using uplink groups. An uplink group is a set of Layer 2 interfaces (per VLAN), only one of which is forwarding at any given time. Specifically, an uplink group consists of the root port, which is forwarding, and a set of blocked ports, except for self-looping ports. The uplink group provides an alternate path in case the currently forwarding link fails.

As the preceding diagram shows, if SW1 detects a direct link failure on its root port—the port channel link—UplinkFast unblocks the blocked interface on SW1 and transitions it to the forwarding state without going through the listening and learning states. This change takes approximately 1 to 5 seconds. The following diagram illustrates this process:

5 seconds. The following diagram illustrates this process: Configuration and verification: Configure the root bridge on

Configuration and verification:

Configure the root bridge on SW4:

spanning-tree vlan 12 priority 24576

On SW1, verify the blocking interface:

SW1#sh spanning-tree vlan 12

VLAN0012

Spanning tree enabled protocol ieee

Root ID

Priority

24588

Address

0017.0e3f.4080

 

Cost

3031

Port

65 (Port-channel1)

 

Hello Time

2 sec

Max Age 20 sec

Forward Delay 15 sec

Bridge ID Priority

49164 (priority 49152 sys-id-ext 12)

Address 000a.b7f7.7900

Hello Time Aging Time 15 Uplinkfast enabled

2 sec

Max Age 20 sec

Forward Delay 15 sec

Interface

---------------- ---- --- --------- -------- --------------------------------

Role Sts Cost

Prio.Nbr Type

Fa0/6

Desg FWD 3019

128.8

P2p

Fa0/19

Altn BLK 19

128.19

P2p

 

Po1

Root FWD 12

128.65

P2p

SW1

As you can see, the blocking interface is on the link just as on the diagram.

Normally, a blocking port transitions from blocking to a forwarding state through listening and learning states. For example:

SW1#debug spanning-tree events Spanning Tree event debugging is on

SW1#conf t Enter configuration commands, one per line. End with CNTL/Z.

SW1(config)#int po1

SW1(config-if)#shut

SW1(config-if)#

20:51:37: STP: VLAN0012 new root port Fa0/19, cost 38

20:51:37: STP: VLAN0012 new root port Fa0/19, cost 38

20:51:37: STP: VLAN0012 Fa0/19 -> listening

20:51:37: STP: VLAN0012 new root port Fa0/19, cost 38 20:51:37: STP: VLAN0012 Fa0/19 -> listening

20:51:37: STP: VLAN0016 we are the spanning tree root 20:51:37: STP: VLAN0088 we are the spanning tree root 20:51:38: STP: VLAN0016 heard root 24592-000a.8afb.2680 on Fa0/19 20:51:38: supersedes 32784-000a.b7f7.7900 20:51:38: STP: VLAN0016 new root is 24592, 000a.8afb.2680 on port Fa0/19, cost 38 20:51:38: STP: VLAN0016 sent Topology C SW1(config-if)#hange Notice on Fa0/19 20:51:38: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changed state to down 20:51:39: %LINK-5-CHANGED: Interface FastEthernet0/23, changed state to administratively down 20:51:39: %LINK-5-CHANGED: Interface FastEthernet0/24, changed state to administratively down 20:51:39: STP: VLAN0012 sent Topology Change Notice on Fa0/19

SW1(config-if)#

20:51:39: %LINK-5-CHANGED: Interface Port-channel1, changed state to administratively down 20:51:40: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/23, changed state to down 20:51:40: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/24, changed state to down

SW1(config-if)#

20:51:52: STP: VLAN0012 Fa0/19 -> learning

SW1(config-if)#

20:52:07: STP: VLAN0012 sent Topology Change Notice on Fa0/19

20:52:07: STP: VLAN0012 Fa0/19 -> forwarding

SW1(config-if)#

It took about 30 seconds in this example to get from blocking to forwarding.

Bring the interface port channel back up, and configure UplinkFast. When you enable UplinkFast, it affects all VLANs on the switch. You cannot configure UplinkFast on an individual VLAN. When UplinkFast is enabled, the switch priority of all VLANs is set to 49152. If you change the path cost to a value less than 3000 and enable UplinkFast, or UplinkFast is already enabled, the path cost of all interfaces and VLAN trunks is increased by 3000. (If you change the path cost to 3000 or above, the path cost is not altered.) The changes to the switch priority reduce the chance that a switch will become the root switch.

SW1(config)#spanning-tree uplinkfast

SW1#show spanning-tree vlan 12

VLAN0012

Spanning tree enabled protocol ieee

Root ID

Priority

24588

Address

0017.0e3f.4080

 

Cost

3031

Port

65 (Port-channel1)

 

Hello Time

2 sec

Max Age 20 sec

Forward Delay 15 sec

Bridge ID Priority

(priority 49152 sys-id-ext 12)Max Age 20 sec Forward Delay 15 sec Bridge ID Priority Address 000a.b7f7.7900 Hello Time 2

Address 000a.b7f7.7900

Hello Time

2 sec

Max Age 20 sec

Forward Delay 15 sec

Aging Time 300 Uplinkfast enabled

Interface

---------------- ---- --- --------- -------- --------------------------------

Role Sts Cost

Prio.Nbr Type

Fa0/6

Desg FWD 3019

128.8

P2p

Fa0/19

Altn BLK

3019 3012
3019
3012

128.23

P2p

Po1

Root FWD

128.65

P2p

SW1#

Note

Path cost and bridge priority are changed.

Shut down the port channel interface, and observe the spanning-tree events:

SW1(config)#int po 1

SW1(config-if)#shut

SW1(config-if)#

21:02:09: STP: VLAN0012 new root port Fa0/19, cost 3038

 

21:02:09: %SPANTREE_FAST-7-PORT_FWD_UPLINK: VLAN0012 FastEthernet0/19 moved to Forwarding

(UplinkFast).

 

21:02:09: STP: VLAN0016 new root port Fa0/19, cost 3038 21:02:09: STP: VLAN0088 we are the spanning tree root 21:02:10: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changed state to down

SW1(config-if)#

21:02:11: %LINK-5-CHANGED: Interface FastEthernet0/23, changed state to administratively down 21:02:11: %LINK-5-CHANGED: Interface FastEthernet0/24, changed state to administratively down 21:02:11: STP: VLAN0012 sent Topology Change Notice on Fa0/19 21:02:11: STP: VLAN0016 sent Topology Change Notice on Fa0/19

SW1(config-if)#

21:02:11: %LINK-5-CHANGED: Interface Port-channel1, changed state to administratively down 21:02:12: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/23, changed state to down 21:02:12: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/24, changed state to down

SW1(config-if)#

Note

Port 0/19 immediately moved to the forwarding state.

Issue:

Place the access interfaces 0/21 of SW2 and SW3 on the STP. Make SW2 the root bridge for VLAN 16 with priority 24576. Leave all path cost values on the links of VLAN 16 to the default set by Cisco IOS Software. If the link between SW2 and SW3 goes down, make sure that forwarding on the link between SW1 and SW3 resumes without waiting for maximum aging time expiration.

Solution:

Look at the following diagram. By default, you should find that the blocking interface is 0/19 on SW1 for VLAN 16:

that the blocking interface is 0/19 on SW1 for VLAN 16: © 2009 Cisco Systems, Inc.

If the link between SW2 and SW3 fails, as shown in the following diagram, SW1 cannot detect this failure, because it is not connected directly to the failed link. However, because SW3 is directly connected to the root switch over this link, it detects the failure, elects itself the root, and begins sending bridge protocol data units (BPDUs) to SW1, identifying itself as the root. When SW1 receives the inferior BPDUs from SW3, SW1 assumes that an indirect failure has occurred.

At that point, BackboneFast allows the blocked interface on SW1 to move immediately to the listening state without waiting for the maximum aging time for the interface to expire. BackboneFast then transitions the Layer 2 interface on SW1 to the forwarding state, providing a path from SW3 to SW2. The root-switch election takes approximately 30 seconds, twice the forward delay time if the default forward delay time of 15 seconds is set.

The following diagram shows how BackboneFast reconfigures the topology to account for the failure between SW2 and SW3.

If you use BackboneFast, you must enable it on all switches in the network.

you must enable it on all switches in the network. Configuration and verification: Configure the root

Configuration and verification:

Configure the root bridge on SW2:

spanning-tree vlan 16 priority 24576

On SW2 and SW1, verify the blocking interface:

SW2#show spanning-tree vlan 16

VLAN0016

Spanning tree enabled protocol ieee

Root ID

Priority

24592

Address

000a.8afb.2680

This bridge is the root

Hello Time

2 sec

Max Age 20 sec

Forward Delay 15 sec

Bridge ID Priority

24592 (priority 24576 sys-id-ext 16)

Address 000a.8afb.2680

Hello Time

Aging Time 300

2 sec

Max Age 20 sec

Forward Delay 15 sec

Interface

---------------- ---- --- --------- -------- --------------------------------

Role Sts Cost

Prio.Nbr Type

Fa0/6

Desg FWD 19

128.8

P2p

Fa0/21

Desg FWD 19

128.21

P2p

Po1

Desg FWD 12

128.65

P2p

SW2#

SW1#show spanning-tree vlan 16

VLAN0016

Spanning tree enabled protocol ieee

Root ID

Priority

24592

Address

000a.8afb.2680

 

Cost

3012

Port

65 (Port-channel1)

 

Hello Time

2 sec

Max Age 20 sec

Forward Delay 15 sec

Bridge ID Priority

49168 (priority 49152 sys-id-ext 16)

Address 000a.b7f7.7900

Hello Time Aging Time 15 Uplinkfast enabled

2 sec

Max Age 20 sec

Forward Delay 15 sec

Interface

---------------- ---- --- --------- -------- --------------------------------

Role Sts Cost

Prio.Nbr Type

Fa0/1

Desg FWD 3019

128.8

P2p

Fa0/19

Altn BLK 3019

128.23

P2p

Po1

Root FWD 3012

128.65

P2p

SW1#

The blocking interface is on the link, just as on the diagram.

Path cost and bridge priority are changed by the previous UplinkFast configuration.

Shut down the interface 0/21 of SW2, and observe the spanning-tree events on SW1:

SW1#debug spanning-tree events Spanning Tree event debugging is on

SW1#

21:25:19: STP: VLAN0016 heard root 32784-0019.55af.7800 on Fa0/19 21:25:21: STP: VLAN0016 heard root 32784-0019.55af.7800

21:25:19: STP: VLAN0016 heard root 32784-0019.55af.7800 on Fa0/19 21:25:21: STP: VLAN0016 heard root 32784-0019.55af.7800 on Fa0/19 21:25:23: STP: VLAN0016 heard root 32784-0019.55af.7800 on Fa0/19 21:25:25: STP: VLAN0016 heard root 32784-0019.55af.7800 on Fa0/19 21:25:27: STP: VLAN0016 heard root 32784-0019.55af.7800 on Fa0/19 21:25:29: STP: VLAN0016 heard root 32784-0019.55af.7800 on Fa0/19 21:25:31: STP: VLAN0016 heard root 32784-0019.55af.7800 on Fa0/19 21:25:33: STP: VLAN0016 heard root 32784-0019.55af.7800 on Fa0/19 21:25:35: STP: VLAN0016 heard root 32784-0019.55af.7800 on Fa0/19 21:25:37: STP: VLAN0016 heard root 32784-0019.55af.7800 on Fa0/19

21:25:37: STP: VLAN0016 Fa0/19 -> listening

Fa0/19 21:25:37: STP: VLAN0016 heard root 32784-0019.55af.7800 on Fa0/19 21:25:37: STP: VLAN0016 Fa0/19 -> listening

21:25:38: STP: VLAN0016 Topology Change rcvd on Fa0/19 21:25:38: STP: VLAN0016 sent Topology Change Notice on Po1

21:25:52: STP: VLAN0016 Fa0/19 -> learning

21:26:07: STP: VLAN0016 sent Topology Change Notice on Po1

21:26:07: STP: VLAN0016 Fa0/19 -> forwarding

In this example, it took about 18 seconds to get to a listening state.

Bring the interface 0/21 of SW2 back up, and configure BackboneFast on all switches configured for VLAN 16:

SW1#show run | inc backbone spanning-tree backbonefast

SW1#

SW2#show run | inc backbone spanning-tree backbonefast

SW2#

SW3#show run | inc backbone spanning-tree backbonefast

SW3#

Shut down interface 0/21 of SW2, and observe the spanning-tree events:

21:40:47: STP: VLAN0016 heard root 32784-0019.55af.7800 on Fa0/19

21:40:47: STP: VLAN0016 heard root 32784-0019.55af.7800 on Fa0/19

21:40:47: STP: VLAN0016 Fa0/19 -> listening

21:40:47: STP: VLAN0016 heard root 32784-0019.55af.7800 on Fa0/19 21:40:47: STP: VLAN0016 Fa0/19 -> listening

21:40:48: STP: VLAN0016 Topology Change rcvd on Fa0/19 21:40:48: STP: VLAN0016 sent Topology Change Notice on Po1

21:41:02: STP: VLAN0016 Fa0/19 -> learning

21:41:17: STP: VLAN0016 sent Topology Change Notice on Po1

21:41:17: STP: VLAN0016 Fa0/19 -> forwarding

Port Fa0/19 moved to listening state right after it received the inferior BPDU from SW3.

Note

To obtain a comprehensive view of the configuration tasks in this section, access the Mentor Guide engine. With the Mentor Guide engine, you can enter more than 1000 Cisco IOS Software commands as well as a collection of proprietary commands such as show all.

3. IPv4 OSPF Section

Note

Configure all OSPF routers with only one OSPF process ID (PID). Use your IGP diagram to help guide configuration.

Issue:

 

Allow backbone OSPF speakers to automatically discover each other, and elect a designated router (DR).

Solution:

 

The OSPF network type “broadcast” is the correct answer here. OSPF speakers will “automatically” discover each other through the multicast address 224.0.0.5 during the initial hello exchange. The OSPF speakers will also elect at least a DR and possibly a backup designated router (BDR), fulfilling both tasks.

In a Frame Relay hub-and-spoke topology, the DR must be on the hub router. To ensure that the hub router is elected as the DR and that a spoke router is not elected as a BDR, use the ip ospf priority command on the spoke routers to set the priority to 0, which makes the spokes ineligible for DR or BDR election.

No BDR should be elected in this topology, because all DROTHERs—routers that are neither DRs nor DBRs—must form an adjacency with both the DR and the BDR. Any other spoke router cannot form an OSPF adjacency with another spoke router. Therefore, a BDR cannot be designated in a hub-and-spoke topology.

Issue:

 

Add loopback 2 on R2 into the OSPF as an external route. Configure OSPF Area 126 on the R2 Frame Relay interface configured with the IPv4 address 172.16.62.2.

Solution:

Add loopback 2 into OSPF using the redistribute connected command. Make sure that you filter the redistribution process so that only loopback 2 and no other connected network is injected into OSPF. Fulfill this filtering requirement by applying either a route map or a distribution list to the redistribution of the connected networks.

Configure OSPF Area 126 on the Frame Relay interface on R2. You can use the OSPF router network command or the ip ospf PID area 126 interface command to accomplish this task. The network command was used in this answer key.

router ospf 100

redistribute connected subnets route-map CONNECTED

redistribute connected subnets route-map CONNECTED

network 172.16.62.0 0.0.0.255 area 126

redistribute connected subnets route-map CONNECTED network 172.16.62.0 0.0.0.255 area 126

!

access-list 1 permit 172.16.2.0 0.0.0.255

!

route-map CONNECTED permit 10

match ip address 1

R2#show ip ospf int brie

Interface

PID

Area

IP Address/Mask

Cost State Nbrs F/C

Se0/0/0

100

0

172.16.123.2/24

64

DROTH 1/1

 

VL0

100

0

172.16.25.2/24

1

P2P

1/1

Lo20

100

20

172.16.20.5/30

1

P2P

0/0

Fa0/0

100

25

172.16.25.2/24

1

BDR

1/1

Se0/0/0.62

100

126

172.16.62.2/24

64

P2P

0/0

 

R2#

R2#show ip ospf database external 172.16.2.0

OSPF Router with ID (172.16.20.5) (Process ID 100)

Issue:

Type-5 AS External Link States

LS age: 267 Options: (No TOS-capability, DC) LS Type: AS External Link

Link State ID:

Advertising Router: 172.16.20.5 LS Seq Number: 8000027C Checksum: 0x127C Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0

172.16.2.0 (External Network Number )

R2#

Place loopback 30 and loopback 3 in OSPF Area 30 on R3.

Solution:

Configure OSPF Area 30 on R3 as requested in the scenario:

R3#show run | section router ospf router ospf 100 log-adjacency-changes redistribute eigrp 1 subnets redistribute eigrp 2 subnets

network 3.3.3.0 0.0.0.255 area 30

network 3.3.3.0 0.0.0.255 area 30 network 172.16.30.0 0.0.0.255 area 30
network 172.16.30.0 0.0.0.255 area 30

network 172.16.30.0 0.0.0.255 area 30

network 172.16.123.0 0.0.0.255 area 0

R3#

R3#show ip ospf int brie

Interface

PID

Area

IP Address/Mask

Cost State Nbrs F/C

Se0/0/0

100

0

172.16.123.3/24

64

DROTH 1/1

 

Lo30

100

30

172.16.30.3/22

1

P2P

0/0

Lo3

100

30

3.3.3.3/24

1

P2P

0/0

R3#

Issue:

Make sure that the network 2.0.0.0 and its subnets do not appear in the routing tables of any router except R2.

Solution:

The challenge in this task is to make the 2.2.2.0/24 network reachable throughout the pod without announcing it to any other router. The solution is provided by configuring default- information originate always on R2.

Whenever you must make an unadvertised network reachable, consider advertising a summary that includes the network. The 0.0.0.0/0 prefix is just an extreme summary:

R2#show ip ospf database external 0.0.0.0

OSPF Router with ID (172.16.20.5) (Process ID 100)

Issue:

Type-5 AS External Link States

LS age: 480 Options: (No TOS-capability, DC) LS Type: AS External Link

Link State ID:

Advertising Router: 172.16.20.5 LS Seq Number: 8000027C Checksum: 0xFDFD Length: 36 Network Mask: /0 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 1 Forward Address: 0.0.0.0 External Route Tag: 100

0.0.0.0 (External Network Number )

R2#

Configure Area 25 between R2 and R5. Add loopback 50 on R5 into OSPF as Area 50.

Solution:

R5 possesses a connection to R2 through Area 25. R5 has no direct connection to Area 0. However, R5 also has a loopback interface assigned to Area 50. Because R5 maintains a connection to an area that has no direct connection to Area 0, it requires a virtual link for Area

50.

Note

To obtain a comprehensive view of the configuration tasks in this section, access the Mentor Guide engine. With the Mentor Guide engine, you can enter more than 1000 Cisco IOS Software commands as well as a collection of proprietary commands such as show all.

4. IPv4 EIGRP Section

Issue:

Solving reachability issues on R4

Solution:

The only IGP configured on R4 is Enhanced Interior Gateway Routing Protocol (EIGRP). R4 will not be able to reach all addresses in the test pod unless a gateway of last resort is set to R3. An EIGRP speaker sets the gateway of last resort based on a 0.0.0.0/0 network or a prefix marked as a “candidate default.” The scenario allows only the 3.0.0.0/8 prefix to be advertised from R3 to R4. The scenario does not specify how the 3.0.0.0/8 prefix should be advertised from

R3 to R4; the EIGRP network statement is chosen in this answer key. So the solution to this issue is to configure ip default-network 3.0.0.0 on R4. This will provide a default route configuration for R4 referencing the next-hop router as R3.

You cannot use the ip default-network command on R3, because it already has a necessary 0.0.0.0/0 route learned from R2 through OSPF. The ip default-network command will take precedence over 0.0.0.0/0, making network 2.2.2.0 unreachable. To best understand this statement, consider the following progression of events:

1. R3 learns the 0.0.0.0/0 prefix from R2.

2. The 0.0.0.0/0 on R3 allows R3 to reach the 2.2.2.0/24 prefix on R2.

3. If R3 is configured to advertise a default route to the stub EIGRP R4, it must use the ip default-network command referencing a non-0.0.0.0/0 prefix; due to the constraints of this exam, EIGRP is not allowed to advertise the 0.0.0.0/0 prefix.

4. If R3 references the 3.0.0.0/8 prefix using the ip default-network command, this command will deactivate the use of the 0.0.0.0/0 prefix on R3, because any non-0.0.0.0/0 prefix that is specified by ip default-network takes precedence over the 0.0.0.0/0 route.

Add network 3.3.3.0 in EIGRP AS1 on R3:

router eigrp 1

network 3.3.3.0 0.0.0.255

network 172.16.34.0 0.0.0.127 no auto-summary no eigrp log-neighbor-changes

!

R4#show ip route summary IP routing table name is Default-IP-Routing-Table(0) IP routing table maximum-paths is 16

Route Source

Networks

Subnets

Overhead

Memory (bytes)

connected

0

2

144

272

static

0

0

0

0

eigrp 1

1

 

0

72

136

bgp 64600

3

0

216

408

External: 0 Internal: 3 Local: 0

 

internal

1

1156

Total

5

2

432

1972

Removing Queue Size 0

R4#

Note that R4 receives only an EIGRP prefix.

Configure the ip default-network command on R4:

R4#sh run | inc ip default-network

ip default-network 3.0.0.0

R4#

R4#sho ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area,

o - ODR, P - periodic downloaded static route

inter area, o - ODR, P - periodic downloaded static route * - candidate default, U

* - candidate default, U - per-user static route

Gateway of last resort is 172.16.34.3 to network 3.0.0.0

B 192.168.104.0/24 [200/0] via 172.16.123.1, 1d01h

D*

3.0.0.0/8

[90/156160] via 172.16.34.3, 2w0d, FastEthernet0/1

B

192.168.105.0/24 [200/0] via 172.16.123.1, 1d01h 172.16.0.0/25 is subnetted, 2 subnets

C

172.16.40.0 is directly connected, Loopback40

C

172.16.34.0 is directly connected, FastEthernet0/1

B

192.168.100.0/22 [200/0] via 172.16.123.1, 1d01h

R4#

Note that the prefix 3.0.0.0/8 is a candidate default prefix, and the gateway of last resort is set to

R3.

Issue:

Add loopback 40 on R4 into EIGRP as an “EX” prefix.

Solution:

Redistribute the loopback 40 network as a connected network into EIGRP AS1 on R4:

router eigrp 1

redistribute connected metric 1000 100 255 3 1500 route-map CONNECTED

network 172.16.34.0 0.0.0.127

!

access-list 1 permit 172.16.40.0 0.0.0.127

!

route-map CONNECTED permit 10

match ip address 1

!

R4#show

ip eigrp 1 topology 172.16.40.0/25

IP-EIGRP (AS 1): Topology entry for 172.16.40.0/25 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2585600 Routing Descriptor Blocks:

0.0.0.0, from Rconnected, Send flag is 0x0

Composite metric is (2585600/0),

Vector metric:

Minimum bandwidth is 1000 Kbit Total delay is 1000 microseconds Reliability is 255/255 Load is 3/255 Minimum MTU is 1500 Hop count is 0 External data:

Route is External

Originating router is 172.16.40.1 (this system) AS number of route is 0 External protocol is Connected, external metric is 0 Administrator tag is 0 (0x00000000)

R4#

R3#show

ip route eigrp

3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

D

3.0.0.0/8 is a summary, 2w0d, Null0 172.16.0.0/16 is variably subnetted, 16 subnets, 3 masks

D

172.16.140.0/24 [90/156160] via 172.16.34.40, 2w0d, FastEthernet0/1

D EX

172.16.40.0/25

[170/2588160] via 172.16.34.4, 2w0d, FastEthernet0/1

R3#

Issue:

Allow only one prefix—the one that represents the entire IPv4 address space—to be advertised from R3 to SW4; filter all other prefixes.

Solution:

Prefix 0.0.0.0/0 represents the entire IPv4 address space. It is a default route. R3 learns 0.0.0.0/0 through OSPF. On R3, redistribute OSPF into EIGRP AS2, and allow only 0.0.0.0/0 to be advertised from R3 to SW4, as shown:

router eigrp 2

redistribute ospf 100

network 172.16.34.0 0.0.0.127 default-metric 1000 100 3 255 1500

distribute-list 10 out FastEthernet0/0

auto-summary

!

access-list 10 permit 0.0.0.0

Verify the results of the configuration on SW4:

SW4#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is 172.16.34.3 to network 0.0.0.0

172.16.0.0/24 is subnetted, 2 subnets

C

172.16.140.0 is directly connected, Loopback140

C

172.16.34.0 is directly connected, Vlan34

D*EX 0.0.0.0/0 [170/2585856] via 172.16.34.3, 18:05:17, Vlan34

SW4#

On SW4, advertise loopback 140 with the EIGRP network statement:

router eigrp 2 network 172.16.34.0 0.0.0.255

network 172.16.140.0 0.0.0.255

auto-summary

Verify the results on R3. Make sure that EIGRP AS2 is redistributed into OSPF to propagate loopback 140 to other routers.

R3#show ip route eigrp 3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

D 3.0.0.0/8 is a summary, 1d19h, Null0 172.16.0.0/16 is variably subnetted, 18 subnets, 5 masks

D 172.16.140.0/24

[90/156160] via 172.16.34.40, 18:08:12, FastEthernet0/0

D EX

R3#

R3#sh run | beg router ospf router ospf 100 log-adjacency-changes redistribute eigrp 1 subnets

172.16.40.0/25 [170/2588160] via 172.16.34.4, 1d19h, FastEthernet0/0

redistribute eigrp 2 subnets

R3#

Note

To obtain a comprehensive view of the configuration tasks in this section, access the Mentor Guide engine. With the Mentor Guide engine, you can enter more than 1000 Cisco IOS Software commands as well as a collection of proprietary commands such as show all.

5. IPv4 RIP Section

Issue:

 

Configure SW1 to send only a summary 172.16.80.0/25 on VLAN 88.

Solution:

 

Configure this summary on SW1 with the command ip summary-address rip 172.16.80.0 255.255.255.128 under interface VLAN 88.

Issue:

Restrict the advertisement of Routing Information Protocol (RIP) updates to the VLAN 17 and VLAN 88 interfaces only.

Solution:

 

Configure R1, SW3, and SW1 with passive interface default. Then, disable passive interface on the VLAN 17 and VLAN and 88 interfaces with the no passive command.

Issue:

 

Solving reachability issues in the RIP domain

Solution:

You can redistribute OSPF into RIP on R1. You do not have to redistribute RIP into OSPF to provide reachability to RIP-originated networks. The 0.0.0.0/0 route will provide the reachability to these networks. The RIP domain will receive the 0.0.0.0/0 default generated on R2. This will provide full reachability from the RIP domain to the rest of the pod addresses, including 2.2.2.0/24 on R2. There are no fixed-length subnet mask (FLSM) or variable-length subnet mask (VLSM) issues, because RIP version 2 (RIPv2) is classless. One could filter the more specific prefixes using a distribution list or route map, but this is not required.

Note

To obtain a comprehensive view of the configuration tasks in this section, access the Mentor Guide engine. With the Mentor Guide engine, you can enter more than 1000 Cisco IOS Software commands as well as a collection of proprietary commands such as show all.

6. Cisco OER and NAT Section

Issue:

Statically configure two default routes to 172.16.16.1 and 172.16.62.2 on R6. Statically configure a default route to 1.1.1.6 on SW2.

Solution:

The lab general restrictions prohibit the use of static routes except for R6. Configure two default networks on R6:

ip route 0.0.0.0 0.0.0.0 172.16.16.1 ip route 0.0.0.0 0.0.0.0 172.16.62.2

Verify static routing entries in the show ip route table on R6:

R6#show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "static", distance 1, metric 0, candidate default path Routing Descriptor Blocks:

172.16.62.2

Route metric is 0, traffic share count is 1

* 172.16.16.1 Route metric is 0, traffic share count is 1

R6#

Configure a default networks on SW2:

ip route 0.0.0.0 0.0.0.0 1.1.1.6

Issue:

R6 should be configured as a master controller and a border Cisco OER router. R6 should measure a network delay to network 3.3.3.3/32 and, based on the lower delay, select R1 as a gateway for the network 3.3.3.3/32.

Solution:

Cisco OER provides automatic route optimization and load distribution for multiple connections between networks. Cisco OER is an integrated Cisco IOS Software solution that allows you to monitor IP traffic flows and then define policies and rules based on network delay, traffic class performance, link-load distribution, link bandwidth monetary cost, and traffic type.

Cisco OER deployment has two primary components: a master controller and one or more border routers. The master controller is a decision maker. Communication between the master controller and border router is protected by Message Digest 5 (MD5) authentication.

A Cisco OER-managed network must have at least two egress interfaces that can carry outbound traffic and can be configured as external interfaces. The router must also have one interface, reachable by the internal network, that can be configured as an internal interface. There are three interface configurations required to deploy Cisco OER:

External interfaces are configured as Cisco OER-managed exit links to forward traffic. Each border router must have at least one external interface, and a minimum of two external interfaces are required in a Cisco OER-managed network.

Internal interfaces are used only for passive performance monitoring with NetFlow. The internal interface is configured as a Cisco OER internal interface on the master controller. At least one internal interface must be configured on each border router.

Local interfaces are used only for master controller and border router MD5-protected communication.

The following diagram illustrates R6 configured as a single router that is configured to run a master controller and border router process:

to run a master controller and border router process: Note that a Cisco router that is

Note that a Cisco router that is configured to run both a master controller and border router process will use more memory than a router that is configured to run only a border router process. This memory impact should be considered when selecting a router for dual operation.

Configure the Cisco OER master controller and the border router on R6. MD5 authentication is required. You can use any string in this lab, because the lab does not explicitly specify it. The string “OER” is used in this answer key:

key chain OER key 1

key-string OER

!

oer master
oer master

policy-rules prfx

 

logging

!

border 1.1.1.6

key-chain

OER

 

interface

FastEthernet0/0 internal FastEthernet0/1 external

interface

interface

Serial0/0/0.62 external

 

!

learn delay periodic-interval 3 monitor-period 1

mode route control mode monitor active

!

active-probe echo 3.3.3.3

!

oer border logging local Loopback80 master 1.1.1.6 key-chain OER
oer border
logging
local Loopback80
master
1.1.1.6
key-chain
OER

!

Internal communication between the master controller and the border router is illustrated in the following diagram:

the border router is illustrated in the following diagram: Verification: R6#show oer master OER state: ENABLED
the border router is illustrated in the following diagram: Verification: R6#show oer master OER state: ENABLED
the border router is illustrated in the following diagram: Verification: R6#show oer master OER state: ENABLED

Verification:

R6#show oer master

OER state: ENABLED and ACTIVE

 

Conn Status: SUCCESS, PORT: 3949

Number of Border routers: 1

 

Number of Exits: 2

 

Number of monitored prefixes: 1 (max 5000) Max prefixes: total 5000 learn 2500 Prefix count: total 1, learn 0, cfg 1

Border

Status

UP/DOWN

AuthFail

1.1.1.6

ACTIVE

UP

2d22h

0

<skipped>

R6#show oer border

OER BR 1.1.1.6 ACTIVE, MC 1.1.1.6 UP/DOWN: UP

Auth Failures: 0

2d22h,

Conn Status: SUCCESS, PORT: 3949

Exits

Fa0/0

INTERNAL

Fa0/1

EXTERNAL

Se0/0/0.62

EXTERNAL

R6#

Issue:

 

R6 should actively monitor a network delay to the network 3.3.3.3/32 by sending ICMP probes and, based on the lower delay, select R1 as a gateway for 3.3.3.3/32. If the ICMP probe fails between the R6 interface on VLAN 16 and the network 3.3.3.3/32, R6 should forward packets to

R2.

Solution:

Cisco OER uses three methods of traffic class performance measurement:

Passive monitoring measures the performance metrics of traffic class entries while the traffic is flowing through the device, using NetFlow functionality.

Active monitoring creates a stream of traffic that replicates a traffic class as closely as possible and measures the performance metrics of the traffic. Active monitoring uses integrated Cisco IOS IP Service Level Agreements (IP SLAs) functionality.

Both active and passive monitoring are used to generate a more complete picture of traffic flows within the network.

There is a requirement for active monitoring of ICMP traffic between R6 and 3.3.3.3/32 in this lab:

oer master

policy-rules prfx

logging

!

border 1.1.1.6 key-chain OER interface FastEthernet0/0 internal

interface FastEthernet0/1 external interface Serial0/0/0.62 external

!

learn delay periodic-interval 3 monitor-period 1

mode route control

mode monitor active

!

active-probe echo 3.3.3.3

!

oer border logging local Loopback80 master 1.1.1.6 key-chain OER

!

ip prefix-list prfx seq 5 permit 3.3.3.3/32

!

oer-map prfx 10 match ip address prefix-list prfx

!

R6#

Note that R6 is configured with the command active-probe echo 3.3.3.3. Periodically, R6 will be sending the ICMP probes. If you run the debug ip icmp command on R6, you can see the ICMP echo replies from R3 to the ICMP probes:

*May 22 17:16:35.359: ICMP: echo reply rcvd, src 3.3.3.3, dst 172.16.16.6 *May 22 17:16:35.443: ICMP: echo reply rcvd, src 3.3.3.3, dst 172.16.62.6

Verify the watched prefix 3.3.3.3/32:

R6#show oer master prefix

OER Prefix Statistics:

Pas - Passive, Act - Active, S - Short term, L - Long term, Dly - Delay (ms), Los - Packet Loss (packets-per-million), Un - Unreachable (flows-per-million),

E

- Egress, I - Ingress, Bw - Bandwidth (kbps), N - Not applicable

U

- unknown, * - uncontrolled, + - control more specific, @ - active probe all

Prefix

State

Time Curr BR

CurrI/F

Protocol

PasSDly PasLDly

PasSUn

PasLUn PasSLos PasLLos

ActSDly ActLDly

ActSUn

ActLUn

EBw

IBw

--------------------------------------------------------------------------------

3.3.3.3/32
3.3.3.3/32

R6#

DEFAULT*

36 U

U

Verify the master controller policy:

R6#show oer master policy Default Policy Settings:

backoff 300 3000 300 delay relative 50 holddown 300 periodic 0 mode route control mode monitor active mode select-exit good loss relative 10 unreachable relative 50 resolve delay priority 11 variance 20 resolve utilization priority 12 variance 20 oer-map prfx 10 match ip prefix-lists: prfx backoff 300 3000 300 delay relative 50 holddown 300 periodic 0 mode route control mode monitor active mode select-exit good loss relative 10 unreachable relative 50 resolve delay priority 11 variance 20 resolve utilization priority 12 variance 20

* Overrides Default Policy Setting

R6#

The prefix will go through the different states—“DEFAULT,” “HOLDDOWN,” and “INPOLICY”—as R6 learns about the prefix.

R6#show oer master prefix

OER Prefix Statistics:

Pas - Passive, Act - Active, S - Short term, L - Long term, Dly - Delay (ms), Los - Packet Loss (packets-per-million), Un - Unreachable (flows-per-million),

E

- Egress, I - Ingress, Bw - Bandwidth (kbps), N - Not applicable

U

- unknown, * - uncontrolled, + - control more specific, @ - active probe all

Prefix

State

Time Curr BR

CurrI/F

Protocol

PasSDly PasLDly

PasSUn

PasLUn PasSLos PasLLos

ActSDly ActLDly

ActSUn

ActLUn

EBw

IBw

--------------------------------------------------------------------------------

3.3.3.3/32

HOLDDOWN

321 1.1.1.6

Fa0/1

STATIC

 

N

N

N

N

N

N

U

U

0

0

N

N

R6#

R6#show oer master prefix

OER Prefix Statistics:

Pas - Passive, Act - Active, S - Short term, L - Long term, Dly - Delay (ms), Los - Packet Loss (packets-per-million), Un - Unreachable (flows-per-million),

E

- Egress, I - Ingress, Bw - Bandwidth (kbps), N - Not applicable

U

- unknown, * - uncontrolled, + - control more specific, @ - active probe all

Prefix

State

Time Curr BR

CurrI/F

Protocol

PasSDly PasLDly

PasSUn

PasLUn PasSLos PasLLos

ActSDly ActLDly

ActSUn

ActLUn

EBw

IBw

--------------------------------------------------------------------------------

3.3.3.3/32

INPOLICY

0 1.1.1.6

Fa0/1

STATIC

 

N

N

N

N

N

N

31

35

0

0

N

N

R6#

*May 22 17:19:25.847: OER MC APC:

R6#show ip route stat

3.0.0.0/32 is subnetted, 1 subnets

S

3.3.3.3 [1/0] via 172.16.16.1

S*

0.0.0.0/0 [1/0] via 172.16.62.2 [1/0] via 172.16.16.1

R6#

Note that the static route to the watched prefix 3.3.3.3/32 is added when it is in policy.

Issue:

IP packets that originated from SW2 should arrive on the network 3.3.3.0/24 with either source IP addresses 172.16.16.6 or 172.16.62.6.

Solution:

Translate the source IP address 1.1.1.20 on R6; see the following diagram:

source IP address 1.1.1.20 on R6; see the following diagram: Network Address Translation (NAT) and Cisco
source IP address 1.1.1.20 on R6; see the following diagram: Network Address Translation (NAT) and Cisco

Network Address Translation (NAT) and Cisco OER configuration tasks are related.

Tip

Always read a CCIE lab exam end-to-end, and carefully look for hidden issues that might involve multiple tasks.

The solution also involves a minimal configuration change with a new keyword, oer, that has been added to the ip nat inside source command. When the oer keyword is configured, new NATs are given the source IP address of the interface that Cisco OER has selected for the packet, and Cisco OER forces existing flows to be routed through the interface for which the NAT was created.

Configure NAT on R6:

interface FastEthernet0/0 ip address 1.1.1.6 255.255.255.0

ip nat inside

!

interface Serial0/0/0.62 point-to-point

ip address 172.16.62.6 255.255.255.0

ip nat outside

!

interface FastEthernet0/1 ip address 172.16.16.6 255.255.255.0

ip nat outside

!

ip nat inside source route-map TR1 interface FastEthernet0/1 overload oer

ip nat inside source route-map TR2 interface Serial0/0/0.62 overload oer

!

!

access-list 1 permit 1.0.0.0 0.255.255.255

!

!

route-map

TR2
TR2

permit 10

match ip address 1

!

route-map

TR1
TR1

permit 10

match ip address 1

!

!

Verification:

This step is not required to perform during the lab; it is provided in the answer key for education purposes.

Verify a Cisco OER failover by removing VLAN 16 on the SW1 interface Fa0/1 that is connected to R1. The static routing on R6 would not be able to detect this kind of failure and would continue forwarding traffic to R1.

Verify the OER prefix before VLAN 16 pruning:

R6#show oer master prefix OER Prefix Statistics:

Pas - Passive, Act - Active, S - Short term, L - Long term, Dly - Delay (ms), Los - Packet Loss (packets-per-million), Un - Unreachable (flows-per-million),

E

- Egress, I - Ingress, Bw - Bandwidth (kbps), N - Not applicable

U

- unknown, * - uncontrolled, + - control more specific, @ - active probe all

Prefix

State

Time Curr BR

CurrI/F

Protocol

PasSDly PasLDly

PasSUn

PasLUn PasSLos PasLLos

ActSDly ActLDly

ActSUn

ActLUn

EBw

IBw

--------------------------------------------------------------------------------

3.3.3.3/32

INPOLICY

0 1.1.1.6

Fa0/1
Fa0/1

STATIC

 

N

N

N

N

N

N

31

34

0

0

N

N

R6#

Note that the prefix 3.3.3.3/32 is in policy, and Fa0/1 is used for forwarding as requested in the lab.

Run the following debug commands on R6:

R6#debug oer master prefix 3.3.3.3/32

OER Master Prefix debugging is on R6#debug oer border active-probes OER Border Router Active Probes debugging is on

Remove VLAN 16 on SW1 interface Fa0/1:

SW1#conf t Enter configuration commands, one per line. End with CNTL/Z. SW1(config)#int fa 0/1 SW1(config-if)#no switchport access vlan 16

SW1(config-if)#end

SW1#

Note that the Cisco OER on R6 detected that the prefix 3.3.3.3/32 is unreachable:

R6#

*May 22 18:30:26.711: OER MC

policy 50%, notify TRUE *May 22 18:30:26.711: OER MC PFX 3.3.3.3/32: Check ACT REL delay: delay 31, policy 50%, notify TRUE

R6#

PFX 3.3.3.3/32: Check ACT REL unreachable: unreachable

166666,

In a few minutes:

R6#

*May 22 18:33:17.747: OER MC

policy 50%, notify FALSE *May 22 18:33:17.747: OER MC

unreachable

*May 22 18:33:17.747: OER MC PFX 3.3.3.3/32: Start FWD on new exit, br = 1.1.1.6, i/f = Se0/0/0.62, nexthop 0.0.0.0, seq 1812, proto 2, exact TRUE

*May 22 18:33:17.747: OER MC PFX 3.3.3.3/32: PDP start timer = 15 secs, prefix state =

*May 22 18:33:17.759: OER BR ACTIVE PROBE: Probe deletion completed. probeType = echo, probeTarget = 3.3.3.3, probeTargetPort = 0 probeSource = Default, probeSourcePort = 0, probeNextHop = Default probeIfIndex = 2 *May 22 18:33:17.771: OER BR ACTIVE PROBE: Probe deletion completed. probeType = echo, probeTarget = 3.3.3.3, probeTargetPort R6# = 0 probeSource = Default, probeSourcePort = 0, probeNextHop = Default probeIfIndex = 11 *May 22 18:33:17.975: OER MC PFX 3.3.3.3/32: prefix_status 0 received, br = 1.1.1.6 i/f =

Se0/0/0.62

*May 22 18:33:17.975: OER MC PFX 3.3.3.3/32: PDP start timer = 300 secs,

PFX 3.3.3.3/32: Check ACT REL unreachable: unreachable

166666,

PFX 3.3.3.3/32: Best exit is 1.1.1.6 Se0/0/0.62, based on

CHOOSE
CHOOSE

prefix state =

HOLDDOWN
HOLDDOWN

*May 22 18:33:17.975: %OER_MC-5-NOTICE: Route changed 3.3.3.3/32, BR 1.1.1.6, i/f Se0/0/0.62,

Reason Unreachable,

OOP Reason Unreachable

*May 22 18:33:17.979: OER BR ACTIVE PROBE: Creation of SAA probe completed successfully. probeType = echo, probeTarget = 3.3.3.3, probeTargetPort = 0 probeSource = 172.16.62.6, probeSourcePort = 0, probeNextHop = 172.16.62.2 probeIfIndex = 11, SAA index = 35

R6#

Note that the Cisco OER detected an out of policy (OOP) condition based on the reason “unreachable.” The Cisco OER transitions through the states CHOOSE, to select the new interface S0/0/0.62, and HOLDDOWN, to hold it for a default 5 minutes. State HOLDDOWN is a route-flapping prevention measure.

R6#show oer master prefix OER Prefix Statistics:

Pas - Passive, Act - Active, S - Short term, L - Long term, Dly - Delay (ms),

Los - Packet Loss (packets-per-million), Un - Unreachable (flows-per-million),

E

- Egress, I - Ingress, Bw - Bandwidth (kbps), N - Not applicable

U

- unknown, * - uncontrolled, + - control more specific, @ - active probe all

Prefix

State

Time Curr BR

CurrI/F

Protocol

PasSDly PasLDly

PasSUn

PasLUn PasSLos PasLLos

ActSDly ActLDly

ActSUn

ActLUn

EBw

IBw

--------------------------------------------------------------------------------

3.3.3.3/32

HOLDDOWN

318 1.1.1.6

Se0/0/0.62
Se0/0/0.62

STATIC

 

N

N

N

N

N

N

U

U

0

0

N

N

R6#

Also, at this step, Cisco OER creates a new static route for 3.3.3.3/32 through the S0/0/0.62 interface:

R6#show ip route static

3.0.0.0/32 is subnetted, 1 subnets

S

3.3.3.3 [1/0] via 172.16.62.2

S*

0.0.0.0/0 [1/0] via 172.16.62.2

R6#

[1/0] via 172.16.16.1

In about 5 minutes:

R6#

*May 22 18:38:40.863: OER MC PFX 3.3.3.3/32: PDP choose exit,

*May 22 18:38:40.863: OER MC PFX 3.3.3.3/32: Check ACT REL delay: delay 99, policy 50%, notify FALSE *May 22 18:38:40.863: OER MC PFX 3.3.3.3/32: Check ACT REL unreachable: unreachable 0, policy 50%, notify FALSE

*May 22 18:38:40.863: OER MC PFX 3.3.3.3/32: PDP no start timer,

R6#show oer master prefix

OER Prefix Statistics:

timer, R6#show oer master prefix OER Prefix Statistics: prefix state = HOLDDOWN, 0 prefix state =

prefix state = HOLDDOWN, 0

prefix state = INPOLICY

Pas - Passive, Act - Active, S - Short term, L - Long term, Dly - Delay (ms),

Los - Packet Loss (packets-per-million), Un - Unreachable (flows-per-million),

E

- Egress, I - Ingress, Bw - Bandwidth (kbps), N - Not applicable

U

- unknown, * - uncontrolled, + - control more specific, @ - active probe all

Prefix

State

Time Curr BR

CurrI/F

Protocol

PasSDly PasLDly

PasSUn

PasLUn PasSLos PasLLos

ActSDly ActLDly

ActSUn

ActLUn

EBw

IBw

--------------------------------------------------------------------------------

3.3.3.3/32

INPOLICY

0 1.1.1.6

Se0/0/0.62
Se0/0/0.62

STATIC

 

N

N

N

N

N

N

99

99

0

0

N

N

R6#

Note that the prefix 3.3.3.3/32 is in policy through the S0/0/0/.62 interface:

SW2#ping 3.3.3.3

Type escape sequence to abort.

Sending

5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:

!!!!!

Success

rate is 100 percent (5/5), round-trip min/avg/max = 151/151/151 ms

SW2#

R6#show

ip nat translations

Pro Inside global

Inside local

Outside local

Outside global

icmp 172.16.62.6:25

1.1.1.20:25

3.3.3.3:25

3.3.3.3:25

R6#

Note that the packet is forwarded out the S0/0/0.62 interface of R6 and is translated according to the NAT rules, as specified in the lab.

Do not forget to add the SW1 interface Fa0/1 to VLAN 16 after you complete testing:

SW1#conf t Enter configuration commands, one per line. End with CNTL/Z. SW1(config)#int fa 0/1 SW1(config-if)#switchport access vlan 16

SW1(config-if)#

Note

To obtain a comprehensive view of the configuration tasks in this section, access the Mentor Guide engine. With the Mentor Guide engine, you can enter more than 1000 Cisco IOS Software commands as well as a collection of proprietary commands such as show all.

7. Border Gateway Protocol Section

Issue:

Originate the following prefixes from SW3 with the origin code “incomplete.”

Solution:

 

Do not use the network command to originate these prefixes in Border Gateway Protocol (BGP). Instead, use redistribution. When prefixes are originated in BGP through redistribution, their origin code is set to “incomplete.”

Issue:

 

Do not form a BGP peer relationship between R2 and R4. Use the AS numbers that are given in the exam.

Solution:

R2, R3, and R4 are Internal BGP (IBGP) speakers within the same AS. By default, a full mesh of IBGP neighbor relationships must be formed between IBGP speakers. However, you cannot form a full mesh, because you are instructed not to form a BGP peer relationship between R2 and R4. The remedy for this non-full-mesh requirement is to configure a route reflector on R3.

The following diagram will help you understand the configuration of the BGP section:

help you understand the configuration of the BGP section: Issue: Make sure that all BGP speakers
help you understand the configuration of the BGP section: Issue: Make sure that all BGP speakers

Issue:

Make sure that all BGP speakers in AS64600 have the following prefixes in their BGP and IP routing tables: (1) 192.168.104.0/24, (2) 192.168.105.0/24, and (3) a summary for the remaining prefixes that are advertised by SW3 through BGP. Apply this configuration on R1. The summary must have the same AS path attribute as its constituents.

Solution:

Configure the BGP aggregate command as follows:

aggregate-address 192.168.100.0 255.255.252.0 as-set summary-only

This aggregate covers the prefixes 192.168.100.0, 192.168.101.0, 192.168.102.0, and 192.168.103.0. The specified additional subnets, 192.168.104.0/24 and 192.168.105.0/24, will also be advertised. By default, the longer matching subnets of an aggregate are advertised with

the aggregate. This behavior is suppressed with the summary-only command. Including the as- set option in the aggregate statement can fulfill the second requirement.

Issue:

 

Use the synchronization method on R2 and R3.

Solution:

 

The rule of synchronization requires that all routes learned from an IBGP peer must have matching routes in the forwarding table from a source other than BGP. You can satisfy the synchronization requirement on R3 by redistributing BGP into OSPF on R2. You must disable synchronization on R4, because R4 must receive only the 3.0.0.0 prefix from R3 through EIGRP.

Issue:

 

All BGP speakers should have only a classful prefix of the IP address assigned to the R3 loopback 3 interface in their BGP tables.

Solution:

 

Originate the 3.0.0.0/8 network on R3 into BGP using a network statement without a mask. This will originate the classful prefix for the Class A address 3.0.0.0 into BGP. Using a 3.3.3.0/24 network statement and then aggregating it to 3.0.0.0/8 would not meet the requirement. To synchronize 3.0.0.0/8 on R2, R3 must advertise the classful prefix into OSPF. One way to do this would be to configure an interarea summary.

Issue:

 

On SW3, this major network should be shown as originated from AS100.

Solution:

 

Apply the remove private-as command to the neighbor relationship between R1 and SW3.

Issue:

 

Allow into BGP AS11111 only prefixes that have one of the following AS numbers in their AS path: 51, 524, 523, and 52323. Use the minimal number of statements and characters in the filtering solution.

Solution:

AS path-based filtering can be used to accomplish this goal. Examine the following regular expression:

ip as-path access list 1 permit _5(1|24|23(23)?)_

! !

! ! ! +-------------------- matches other AS numbers or EOL +---------------or optionally an additional 23, for example 52323 ! ! ! ! ! ! +-------------------- 23, for example 523

! ! ! ! ! +---------------------- or

! ! ! ! +------------------------------------- 24, for example 524

! ! ! +-------------------------or

! ! +-------------------------- match 1 for example 51

! +------------------------must match 5, for example 5 +-----------------matches other transit AS numbers or BOL

!

!

!

!

!

!

!

!

!

!

!

!

!

!

!

!

!

!

!

!

!

The regular expression that is displayed includes a few special characters that deserve a detailed description. The parentheses “( )” are reserved regular expression symbols that group all the characters enclosed within them as a single entity. Within the “( )” grouping are a series of vertical bars, “|.” These symbols are reserved regular expressions that represent a logical OR

operation. When combined, you can use these symbols in the following manner: _5(1|24)

This

regular expression will match on an AS number that begins with 5 and is appended by one of two possible combinations, 1 OR 24. The result of this regular expression is that it will match: 51 OR

Issue:

524. The “?” symbol is a reserved regular expression expansion character. Whatever symbol is to the immediate left of the “?” symbol can be present in the desired matching string or it can be absent. For example, the regular expression 52? will match one of two possible strings: 5 or 52.

By grouping the string of digits 23 together in the regular expression of this task (23)? the effect is that the AS number that possesses an additional string of 23 will be matched, for example, 52323 or the additional 23 will be ignored, for example, 523. Finally, the underscore symbol will match on the following: beginning of line, end of line, or some delimiter such as a blank space. Beginning and ending the regular expression with underscores ensures that the entire expression will match one and only one AS number.

Other acceptable expressions would include _5(1|24|23|2323)_ and _ 5(1|24|(23)+)

expression is only 15 characters but assumes that the AS path field will never grow beyond 16 bits. The plus sign (+) indicates “one or more of the previous,” which would match on 23, 2323, 232323, and so on.

The latter

Summarize the received prefixes on R5 with an optimal mask. The summary must not be listed in the BGP tables of the other routers. The solution should work even if new BGP peer relationships are added in the future without any additional configuration.

Solution:

This task can be accomplished by using prefix aggregation under the BGP routing process:

aggregate-address 172.17.0.0 255.255.224.0 summary-only attribute-map NOADV

route-map NOADV permit 10 set community no-advertise

By changing the community attribute to the well-known community no-advertise, you stop R5 from advertising the aggregate to any peer.

R5#sho ip bgp 172.17.0.0/19 BGP routing table entry for 172.17.0.0/19, version 6 Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to any peer) Not advertised to any peer Local, (aggregated by 11111 172.16.50.1) 0.0.0.0 from 0.0.0.0 (172.16.50.1) Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate,

best

Community: no-advertise

R5#

Another solution would be to use the distribute-list out command under the BGP process.

Note

To obtain a comprehensive view of the configuration tasks in this section, access the Mentor Guide engine. With the Mentor Guide engine, you can enter more than 1000 Cisco IOS Software commands as well as a collection of proprietary commands such as show all.

Connectivity verification:

You can verify universal reachability with a simple Tool Command Language (Tcl) script, like the one shown below. You can create it once in Notepad and then paste it into each router. To test for stability, observe the output of the debug ip routing command. It shows you each time that a route goes into or out of the routing table. It is useful for detecting route feedback. Finally, test for optimal paths. The definition of optimal can be related to specific lab tasks, but there are certain general rules that you should enforce. Using the show ip route command with some of its extensions can help you focus on the needed information. For example, use show ip route rip; show ip route | include E; show ip route | include /22; show ip route | include Serial0/0/0.

Simple Tcl Script to Test for Universal Reachability

foreach address {

172.16.123.1

172.16.16.1

172.16.10.1

172.16.17.1

172.16.88.1

172.16.123.2

172.16.25.2

172.16.2.1

172.16.20.5

2.2.2.2

172.16.34.3

172.16.123.3

3.3.3.3

172.16.30.3

172.16.34.4

172.16.40.1

172.16.25.5

172.16.50.1

172.16.16.6

172.16.88.2

172.16.80.1

172.16.17.7

172.16.77.7

192.168.100.1

192.168.101.1

192.168.102.1

192.168.103.1

192.168.104.1

192.168.105.1

172.16.34.40

172.16.140.1

}

ping $address}

{

8. IPv6 Routing Section

Issue:

 

Configure IPv6 addresses and the RIP next generation (RIPng) routing process “frame.” Change the port and multicast address for the process “frame.”

Solution:

 

Before you start configuring the IPv6 routing protocols, enter ipv6 unicast-routing in global configuration mode on the IPv6 routers. Then, configure IPv6 addresses on the Frame Relay link between R1, R2, and R3. Map the remote IPv6 addresses to the local DLCIs. This configuration is similar to IPv4, except that you do not have to provide mapping for the local IPv6 addresses to be able to ping them.

R1:

 

interface Serial0/0/0.123 multipoint

 

ipv6 address 1230::1/16

 

ipv6 address FE80::123:1 link-local

 

ipv6 rip frame enable

frame-relay map ipv6 1230::2 102

 

frame-relay map ipv6 1230::3 103

frame-relay map ipv6 FE80::123:2 102 broadcast frame-relay map ipv6 FE80::123:3 103 broadcast

 

R2:

interface Serial0/0/0

ipv6 address 1230::2/16

ipv6 address 1230::2/16 ipv6 address FE80::123:2 link-local
ipv6 address FE80::123:2 link-local

ipv6 address FE80::123:2 link-local

ipv6 rip frame enable

 

frame-relay map ipv6 1230::1 201

 
   

frame-relay map ipv6 1230::3 201

 

frame-relay map ipv6 FE80::123:1 201 broadcast frame-relay map ipv6 FE80::123:3 201 broadcast

 

R3:

interface Serial0/0/0