Labs

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Work Book 4.0 Page 1 of 87 © 2011 Narbik Kocharians. All rights reserved

Advanced CCIE Routing & Switching

4.0 www.MicronicsTraining.com

Narbik Kocharians CCIE #12410

R&S, Security, SP

VOLI


Table of Content:

Subject Page Volume Topology 8 VolI

3560 Switching Lab 1 Basic 3560 configuration I 14 VolI Lab 2 Basic 3560 configuration II 51 VolI Lab 3 Configuring Trunks 84 VolI Lab 4 Configuring EtherChannels 136 VolI Lab 5 Advanced STP Configuration 156 VolI Lab 6 Multiple Spanningtree (802.1s) 180 VolI Lab 7 Configuring Private VLANs 190 VolI Lab 8 QinQ Tunneling 217 VolI Lab 9 Fallback Bridging 235 VolI

Framerelay Lab 1 HubnSpoke Using Frame Map Statements 242 VolI Lab 2 HubnSpoke Framerelay Pointtopoint 257 VolI Lab 3 Mixture of P2P and Multipoint 262 VolI Lab 4 Multipoint Framerelay W/O Frame maps 267 VolI Lab 5 Framerelay and Authentication 273 VolI Lab 6 Framerelay EndtoEnd Keepalives 282 VolI Lab 7 Tricky Framerelay Configuration 297 VolI Lab 8 Framerelay Multilinking 305 VolI Lab 9 BacktoBack Framerelay connection 312 VolI

ODR Lab 1 On Demand Routing 321 VolI

RIPv2 Lab 1 RIPv2 and Framerelay 327 VolI Lab 2 RIPv2 Authentication 335 VolI Lab 3 Advanced RIPv2 Mini Mock Lab 340 VolI

EIGRP Lab 1 Eigrp configuration 362 VolI Lab 2 Advanced Eigrp Stub Configuration 398 VolI Lab 3 Eigrp & Defaultinformation 407 VolI Lab 4 Eigrp Filtering 418 VolI


Table of Content:

Subject Page Volume OSPF

Lab 1 Advertising Networks 427 VolI Lab 2 Optimization of OSPF & Adjusting Timers 430 VolI Lab 3 OSPF Authentication 437 VolI Lab 4 OSPF Cost 462 VolI Lab 5 OSPF Summarization 467 VolI Lab 6 Virtuallinks and GRE Tunnels 474 VolI Lab 7 OSPF Stub, T/Stub, and NSSAs 484 VolI Lab 8 OSPF Filtering 495 VolI Lab 9 Additional OSPF Filtering 522 VolI Lab 10 Redirecting Traffic in OSPF 531 VolI Lab 11 Database Overload Protection 537 VolI Lab 12 OSPF NonBroadcast Networks 542 VolI Lab 13 OSPF Broadcast Networks 551 VolI Lab 14 OSPF PointtoPoint Networks 555 VolI Lab 15 OSPF PointtoMultipoint Networks 559 VolI Lab 16 OSPF PointtoMulti Network – II 566 VolI Lab 17 OSPF PtoM NonBroadcast Net 573 VolI Lab 18 OSPF and NBMA 579 VolI Lab 19 Forward Address Suppression 588 VolI Lab 20 OSPF NSSA noredistribution & Injection

of default routes 600 VolI

BGP Lab 1 Establishing Neighbor Adjacency 609 VolI Lab 2 Route Reflectors 626 VolI Lab 3 Conditional Adv & Back door 642 VolI Lab 4 Route Dampening 657 VolI Lab 5 Route Aggregation 666 VolI Lab 6 The community Attribute 686 VolI Lab 7 BGP Cost Community 702 VolI Lab 8 BGP & Load Balancing – I 711 VolI Lab 9 BGP Load Balancing – II 715 VolI Lab 10 BGP Unequal Cost Load Balancing 719 VolI Lab 11 BGP Local Preference – I 727 VolI Lab 12 BGP Local Preference – II 738 VolI Lab 13 The ASPath Attribute 746 VolI Lab 14 The Weight Attribute 754 VolI Lab 15 MED 761 VolI Lab 16 Filtering Using ACLs & Prefixlists 778 VolI


Lab 17 Regular Expressions 788 VolI Lab 18 Adv BGP Configurations 805 VolI Lab 19 Administrative Distance 816 VolI Lab 20 BGP Confederation 824 VolI Lab 21 BGP Hiding Local AS Number 829 VolI Lab 22 BGP Allowasin 837 VolI

Policy Based Routing Lab 1 PBR based on Source IP address 843 VolI

Redistribution Lab 1 Basics of RedistributionI 854 VolI Lab 2 Basics of RedistributionII 874 VolI Lab 3 Advanced Redistribution 890 VolI Lab 4 Routing Loops 919 VolI

IP SLA Lab 1 IP SLA 938 VolI Lab 2 Reliable Static Routing using IP SLA 944 VolI Lab 3 Reliable Conditional Default Route

Injection using IP SLA 951 VolI

Lab 4 Object Tracking in HSRP Using SLA 964 VolI Lab 5 Object Tracking 974 VolI

GRE Tunnels Lab 1 Basic Configuration of GRE Tunnels 988 VolI Lab 2 Configuration of GRE Tunnels II 1000 VolI Lab 3 Configuration of GRE Tunnels III 1010 VolI Lab 4 GRE & Recursive loops 1017 VolI

QOS Lab 1 MLS QOS 14 VolII Lab 2 DSCP Mutation 30 VolII Lab 3 DSCPCoS Mapping 38 VolII Lab 4 CoSDSCP Mapping 43 VolII Lab 5 IPPrecedenceDSCP Mapping 49 VolII Lab 6 Individual rate Policing 54 VolII Lab 7 Policed DSCP 60 VolII Lab 8 Aggregate Policer 65 VolII Lab 9 Priority Queuing 70 VolII Lab 10 Custom Queuing 76 VolII Lab 11 WFQ 80 VolII Lab 12 RSVP 84 VolII Lab 13 Match Accessgroup 90 VolII Lab 14 Match Destination & Source Add MAC 95 VolII Lab 15 Match InputInterface 101 VolII Lab 16 Match FRde & Packet Length 104 VolII Lab 17 Match IP Precedence vs. Match Precedence 112 VolII


Lab 18 Match Protocol HTTP URL, MIME & Host 123 VolII Lab 19 Match Frdlci 131 VolII Lab 20 Framerelay Traffic Shaping 135 VolII Lab 21 Framerelay Trafficshaping – II 142 VolII Lab 22 Framerelay Fragmentation 151 VolII Lab 23 Framerelay PIPQ 155 VolII Lab 24 Framerelay DE 162 VolII Lab 25 Framerelay and Compression 165 VolII Lab 26 CBWFQ 178 VolII Lab 27 CBWFQ – II 184 VolII Lab 28 Converting Custom Queuing to CBWFQ 186 VolII Lab 29 LLQ 189 VolII Lab 30 CAR 193 VolII Lab 31 Class Based Policing – I 200 VolII Lab 32 CB Policing – II 210 VolII Lab 33 WRED & CB WRED 215 VolII

NAT Lab 1 Static NAT Configuration 221 VolII Lab 2 Advanced Static NAT Configuration 227 VolII Lab 3 Configuration of Dynamic NAT – I 231 VolII Lab 4 Configuration of Dynamic NAT – II 234 VolII Lab 5 Configuration of Dynamic NAT – III 237 VolII Lab 6 NAT and Load Balancing 241 VolII Lab 7 Configuring PAT 244 VolII Lab 8 Configuring PAR 249 VolII Lab 9 Configuring Static NAT Redundancy W/HSRP 253 VolII Lab 10 Stateful Translation Failover With HSRP 258 VolII Lab 11 Translation of the Outside Source 264 VolII Lab 12NAT on a Stick 267 VolII

IP Services Lab 1 DHCP Configuration 273 VolII Lab 2 HSRP Configuration 277 VolII Lab 3 VRRP Configuration 286 VolII Lab 4 GLBP Configuration 293 VolII Lab 5 IRDP Configuration 305 VolII Lab 6 Configuring DRP 312 VolII Lab 7 Configuring WCCP 314 VolII Lab 8 Core Dump Using FTP 315 VolII Lab 9 HTTP Connection Management 317 VolII Lab 10 Configuting NTP 320 VolII Lab 11 More IP Stuff 329 VolII

IP PrefixList Lab 1 PrefixLists 337 VolII


IPv6 Lab 1 Configuring Basic IPv6 364 VolII Lab 2 Configuring OSPFv3 385 VolII Lab 3 Configuring OSPFv3 MultiArea 394 VolII Lab 4 Summarization of Internal & External N/W 399 VolII Lab 5 OSPFv3 Stub, T/Stub and NSSA networks 408 VolII Lab 6 OSPFv3 Cost and Autocost 420 VolII Lab 7 Tunneling IPv6 Over IPv4 426 VolII Lab 8 Eigrp and IPv6 452 VolII

Security Lab 1 Basic Router Security Configuration 477 VolII Lab 2 Standard Named Access List 484 VolII Lab 3 Controlling Telnet Access and SSH 488 VolII Lab 4 Extended Access List IP and ICMP 495 VolII Lab 5 Extended Access List OSPF & Eigrp 501 VolII Lab 6 Using MQC as a Filtering tool 505 VolII Lab 7 Extended Access List With Established 509 VolII Lab 8 Dynamic Access List 512 VolII Lab 9 Reflexive AccessLists 522 VolII Lab 10 Accesslist & Time Range 529 VolII Lab 11 Configuring Basic CBAC 533 VolII Lab 12 Configuring CBAC 535 VolII Lab 13 Configuring CBAC & Java Blocking 542 VolII Lab 14 Configuring PAM 544 VolII Lab 15 Configuring uRPF 546 VolII Lab 16 Configuring Zone Based Firewall 552 VolII Lab 17 Control Plane Policing 559 VolII Lab 18 Configuring IOS IPS 566 VolII Lab 19 Attacks 576 VolII Lab 20 AAA Authentication 587 VolII

Multicasting Lab 1 Configuring IGMP 592 VolII Lab 2 Dense Mode 610 VolII Lab 3 Static RP Configuration 628 VolII Lab 4 AutoRP 643 VolII Lab 5 AutoRP Filtering & Listener 665 VolII Lab 6 Configuring BSR 687 VolII Lab 7 Configuring MSDP 702 VolII Lab 8 Anycast RP 720 VolII Lab 9 MSDP/MPBGP 730 VolII Lab 10 Configuring SSM 749 VolII Lab 11 HelperMap 760 VolII Lab 12 Bidirectional PIM 767 VolII


MPLS & L3VPNs Lab 1 Configuring Label Distribution Protocol 785 VolII Lab 2 Static & RIPv2 Routing in a VPN 855 VolII Lab 3 OSPF Routing in a VPN 886 VolII Lab 4 Backdoor links & OSPF 905 VolII Lab 5 Eigrp Routing in a VPN 921 VolII Lab 6 BGP Routing in a VPN 937 VolII Lab 7 Complex VPNs and Filters 954 VolII



The Serial connection between R1 and R3

The Serial connection between R4 and R5


Framerelay Switch connections

R1

R2

R3

R4

R5

R6

S0/0

S0/1

S0/2

S0/3

S1/0

S1/1

S1/2

S0/0

S0/0

S0/0

S0/0

S0/0

S0/0

S0/1


Framerelay DLCI connections:

Router Local DLCI Connecting to: R1 102

112 103 104 105 106

R2 R2 R3 R4 R5 R6

R2 201 211 203 204 205 206

R1 R1 R3 R4 R5 R6

R3 301 302 304 305 306

R1 R2 R4 R5 R6

R4 401 402 403 405 406

R1 R2 R3 R5 R6

R5 501 502 503 504 506

R1 R2 R3 R4 R6

R6 601 602 603 604 605

R1 R2 R3 R4 R5


SW3 SW4

SW1 SW2 F0/19 F0/20

F0/19

F0/20

F0/21

F0/22 F0/21

F0/22

F0/23 F0/23

F0/24

F0/24

F0/18


Task 1

The first switch should be configured with a hostname of SW1 and the second switch should be configured with a hostname of SW2

On the First Switch

Switch(config)#Hostname SW1

On the Second Switch

Switch(config)#Hostname SW2

Task 2

Shutdown ports F0/2124 on SW1 and SW2

On Both Switches:

SWx(config)#int range f0/2124 SWx(configifrange)#Shut

Task 3

Configure trunking between SW1 and SW2 using ports F0/19 and F0/20. Use an industry standard trunking protocol for this purpose. Assign a brief meaningful description to these interfaces.

On SW1

SW1(config)#Interface range f0/1920

Lab 7 Configuring Private VLANs


SW1(configifrange)#Switch trunk encap dot1q SW1(configifrange)#Switch mode trunk SW1(configifrange)#Description Trunk to SW2

On SW2

SW2(config)#Interface range f0/1920 SW2(configifrange)#Switch trunk encap dot1q SW2(configifrange)#Switch mode trunk SW2(configifrange)#Description Trunk to SW1

To verify the configuration:

On SW1

SW1#Show int trunk

Port Mode Encapsulation Status Native vlan Fa0/19 on 802.1q trunking 1 Fa0/20 on 802.1q trunking 1

Port Vlans allowed on trunk Fa0/19 14094 Fa0/20 14094

Port Vlans allowed and active in management domain Fa0/19 1 Fa0/20 1

Port Vlans in spanning tree forwarding state and not pruned Fa0/19 1 Fa0/20 none

On SW2

SW2#Show int trunk




Port Vlans allowed and active in management domain Fa0/19 1 Fa0/20 1

Port Vlans in spanning tree forwarding state and not pruned Fa0/19 1 Fa0/20 1

Task 4

Assign IP addressing to the interface of the routers using the following chart and ensure that these routers can ping each other: You should assign a brief meaningful interface description on the switchports.

Router Interface IP address and Subnet mask R1 F0/0 200.1.1.1 /24 R2 F0/0 200.1.1.2 /24 R3 F0/1 200.1.1.3 /24 R4 F0/0 200.1.1.4 /24 R5 F0/1 200.1.1.5 /24 R6 F0/1 200.1.1.6 /24 BB1 F0/1 200.1.1.7 /24 BB2 F0/0 200.1.1.8 /24 BB3 F0/0 200.1.1.9 /24

On R1

R1(config)#Int F0/0 R1(configif)#Ip address 200.1.1.1 255.255.255.0 R1(configif)#No shut

On R2


On R3

R3(config)#Int F0/1


R3(configif)#Ip address 200.1.1.3 255.255.255.0 R3(configif)#No shut

On R4


On R5


On R6

R6(config)#Int F0/1 R6(configif)# Ip address 200.1.1.6 255.255.255.0 R6(configif)#No shut

On BB1

BB1(config)#Int F0/1 BB1(configif)# Ip address 200.1.1.7 255.255.255.0 BB1(configif)#No shut

On BB2

BB2(config)#int F0/0 BB2(configif)#ip address 200.1.1.8 255.255.255.0 BB2(configif)#No shut

On BB3

BB3(config)#int F0/0 BB3(configif)#ip address 200.1.1.9 255.255.255.0 BB3(configif)#No shut

On SW1

SW1(config)#Int F0/1


SW1(configif)#Description R1’s F0/0

SW1(config)#Int F0/2 SW1(configif)#Description R2’s F0/0

SW1(config)#Int range F0/3 , F0/59 , F0/1218 , F0/2124 SW1(configifrange)#Description


SW1(config)#Int F0/12 SW1(configif)#Description BB2’s F0/0


On SW2

SW2(config)#Int range F0/12 , F0/4 , F0/1018 , F0/2124 SW2(configifrange)#Description





To test and verify the configuration:

On R1

R1#Ping 200.1.1.2

Type escape sequence to abort. Sending 5, 100byte ICMP Echos to 200.1.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), roundtrip min/avg/max = 1/2/4 ms


R1#Ping 200.1.1.3


R1#Ping 200.1.1.4


R1#Ping 200.1.1.5


R1#Ping 200.1.1.6


R1#Ping 200.1.1.7


R1#Ping 200.1.1.8


R1#Ping 200.1.1.9

Type escape sequence to abort.


Sending 5, 100byte ICMP Echos to 200.1.1.9, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), roundtrip min/avg/max = 1/2/4 ms

Task 5

Configure the switches such that the ports that are not used are in Administratively down state. Use minimum number of commands for this task.

On SW1

SW1(config)#int range F0/3 , F0/5 , F0/10, F0/1418 , F0/2124 SW1(configifrange)#Shut


On SW1

SW1#Sh int status | Inc Port|connected

Port Name Status Vlan Duplex Speed Type Fa0/1 R1's F0/0 connected 1 afull a100 10/100BaseTX Fa0/2 R2's F0/0 connected 1 afull a100 10/100BaseTX Fa0/4 R4's F0/0 connected 1 afull a100 10/100BaseTX Fa0/12 BB2's F0/0 connected 1 afull a100 10/100BaseTX Fa0/13 BB3's F0/0 connected 1 afull a100 10/100BaseTX Fa0/19 Trunk to SW2 connected trunk afull a100 10/100BaseTX Fa0/20 Trunk to SW2 connected trunk afull a100 10/100BaseTX

On SW2

SW2(config)#int range F0/12 , F0/4 , F0/810, F0/1218 , F0/2124 SW2(configif)#Shut


On SW2

SW2# Sh int status | Inc Port|connected


Port Name Status Vlan Duplex Speed Type Fa0/3 R3's F0/1 connected 1 afull a100 10/100BaseTX Fa0/5 R5's F0/1 connected 1 afull a100 10/100BaseTX Fa0/6 R6's F0/1 connected 1 afull a100 10/100BaseTX Fa0/11 BB1's F0/1 connected 1 afull a100 10/100BaseTX Fa0/19 Trunk to SW1 connected trunk afull a100 10/100BaseTX Fa0/20 Trunk to SW1 connected trunk afull a100 10/100BaseTX

Note the interface description can be extremely helpful especially if the switches are configured in transparent mode, and/or the task asks for the configuration of allowed VLANs on the trunks.

Task 6

Configure Private VLANs based on the following policy:

Router Interface VLANType VLANID R1 F0/0 Primary 10 R2 F0/0 Community 20 R3 F0/1 Community 20 R4 F0/0 Community 30 R5 F0/1 Community 30 R6 F0/1 Isolated 40 BB1 F0/1 Isolated 40 BB2 F0/0 Isolated 40 BB3 F0/0 Isolated 40

PrivateVLANs are typically seen in service provider networks, this feature addresses two major problems that the providers used to face:

1. Number of Clients: If every client was in a VLAN of their own, the provider will be restricted to 4094 clients, which is the maximum number of VLANs on a given switch.

2. Routing between VLANs & IP addressing: Routing between VLANs will be a nightmare, and the number of wasted IP addresses that result from Subnetting will be enormous.

PrivateVLANs solves these two issues, with PrivateVLANs a VLAN is subdivided into sub VLANs or subdomains.

PrivateVLANs consist of one primary, and one or more secondary VLANs, the secondary VLANs


can be either Community VLANs or Isolated VLANs.

A Primary VLAN can have many Community VLANs, but it can ONLY have a Single Isolated VLAN.

Ports in a PrivateVLAN:

There are three types of ports in PrivateVLAN and they are as follows:

1. Promiscuous: A promiscuous port belongs to the primary VLAN; this port can communicate with all ports that are member of a secondary VLAN/s (Community and/or Isolated) that are associated with the primary VLAN that it belongs.

2. Isolated: An isolated port is a host port that belongs to an isolated secondary VLAN. The host ports that are member of a given Isolated VLAN can NOT Communicate with each other. These ports can ONLY communicate with the Port configured as Promiscuous port.

3. Community: A community port is a host port that belongs to a community Secondary VLAN. Community ports can communicate with ports in the same Community VLAN and with the port that is configured as promiscuous ports. These ports can’t Communicate with other ports in other Community VLANs.

On Both Switches:

In order to configure privatevlans, the switches must be configured in Transparent mode as follows:

SWx(config)#vtp mode transparent

The following commands configures the primary VLAN

SWx(config)#vlan 10 SWx(configvlan)#privatevlan primary SWx(configvlan)#Exit

The following two VLANs are defined as the community secondary VLANs, there could be many community VLANs:

SWx(config)#vlan 20 SWx(configvlan)#privatevlan community

SWx(config)#vlan 30


SWx(configvlan)#privatevlan community

There can ONLY be one isolated secondary VLAN:

SWx(config)#vlan 40 SWx(configvlan)#privatevlan isolated

The following command associates the secondary VLANs to the primary:

SWx(config)#vlan 10 SWx(configvlan)#privatevlan association add 20,30,40


On Both Switches:

SWx#Show vlan privatevlan

Primary Secondary Type Ports 10 20 community 10 30 community 10 40 isolated

The output of the above show command displays the secondary VLANs that are created so far and the primary VLAN to which they are associated.

On SW1

The following command sets F0/1 interface in promiscuous mode, assigns the port to primary VLAN 10 and maps VLANs 20, 30 and 40 to this interface:

SW1(config)#Int F0/1 SW1(configif)#Switchport mode privatevlan promiscuous SW1(configif)#Switchport privatevlan mapping 10 add 20,30,40

The ports that belong to a given secondary VLAN must be configured in host mode. The following command sets F0/2 interface in a host mode, associates this port to VLAN 10 (The primary VLAN) and assigns this port to VLAN 20 which was configured as a community secondary VLAN earlier:

SW1(configif)#Int F0/2 SW1(configif)#Switchport mode privatevlan host SW1(configif)#Switchport privatevlan hostassociation 10 20


The following command sets F0/4 interface in a host mode, associates this port to VLAN 10 (The primary VLAN) and assigns this port to VLAN 30 which was configured as a community secondary VLAN earlier:

SW1(configif)#Int F0/4 SW1(configif)#Switchport mode privatevlan host SW1(configif)#switchport privatevlan hostassociation 10 30

The following command sets F0/12 and F0/13 interfaces in a host mode, associates these ports to VLAN 10 (The primary VLAN) and assigns these ports to VLAN 40 which was configured as an isolated secondary VLAN earlier:

SW1(config)#Int range F0/1213 SW1(configif)#Switchport mode privatevlan host SW1(configif)#Switchport privatevlan hostassociation 10 40


On SW1

SW1#Sh vlan pri

Primary Secondary Type Ports 10 20 community Fa0/1, Fa0/2 10 30 community Fa0/1, Fa0/4 10 40 isolated Fa0/1, Fa0/12, Fa0/13

On SW2

SW2(config)#Int F0/3 SW2(configif)#Switchport mode privatevlan host SW2(configif)#Switchport privatevlan hostassociation 10 20

SW2(config)#Int F0/5 SW2(configif)#Switchport mode privatevlan host SW2(configif)#Switchport privatevlan hostassociation 10 30

SW2(config)#Int range F0/6 , F0/11 SW2(configif)#Switchport mode privatevlan host SW2(configif)#switchport privatevlan hostassociation 10 40



On SW2

SW2#Show vlan privatevlan

Primary Secondary Type Ports 10 20 community Fa0/3 10 30 community Fa0/5 10 40 isolated Fa0/6, Fa0/11

To test the configuration:

On R1

R1#Ping 200.1.1.2


R1#Ping 200.1.1.3


R1#Ping 200.1.1.4


R1#Ping 200.1.1.5


R1#Ping 200.1.1.6



R1#Ping 200.1.1.7


R1#Ping 200.1.1.8


R1#Ping 200.1.1.9


Note R1 is able to ping all routers because it is configured to be in promiscuous mode, this interface can be thought of as the default gateway.

On R2

R2#Ping 200.1.1.1


R2#Ping 200.1.1.3



Note R2 is able to ping R1 which is the port in the primary VLAN and R3 which is in the same community VLAN. R2 can NOT communicate with the hosts in the other secondary VLANs. The following verifies this information:

R2#Ping 200.1.1.4

Type escape sequence to abort. Sending 5, 100byte ICMP Echos to 200.1.1.4, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

R2#Ping 200.1.1.5


R2#Ping 200.1.1.6


R2#Ping 200.1.1.7


R2#Ping 200.1.1.8


R2#Ping 200.1.1.9



On R3

R3#Ping 200.1.1.1


R3#Ping 200.1.1.2


Note R3 is able to ping R1 which is the port in primary VLAN and the router in its own community secondary VLAN, which is R2.

R3#Ping 200.1.1.4


R3#Ping 200.1.1.5


R3#Ping 200.1.1.6


R3#Ping 200.1.1.7

Type escape sequence to abort. Sending 5, 100byte ICMP Echos to 200.1.1.10, timeout is 2 seconds: .....


Success rate is 0 percent (0/5)

R3#Ping 200.1.1.8


R3#Ping 200.1.1.9


Note R3 can NOT ping the other routers because they are in another secondary VLAN.

On R4

R4#Ping 200.1.1.1


R4#Ping 200.1.1.5


Note R4 is able to ping R1 which is the port in primary VLAN and the router in its own community secondary VLAN, which is R5.

R4#Ping 200.1.1.2


R4#Ping 200.1.1.3



R4#Ping 200.1.1.6


R4#Ping 200.1.1.7


R4#Ping 200.1.1.8


R4#Ping 200.1.1.9



On R5

R5#Ping 200.1.1.1


R5#Ping 200.1.1.4



Note R5 is able to ping R1 which is the port in primary VLAN and the router in its own community secondary VLAN (R2).

R5#Ping 200.1.1.2


R5#Ping 200.1.1.3


R5#Ping 200.1.1.6


R5#Ping 200.1.1.7


R5#Ping 200.1.1.8


R5#Ping 200.1.1.9




On R6

R6#Ping 200.1.1.1


Note R6 is able to ping R1 which is the port in primary VLAN but it can NOT ping any other router, even though BB1, BB2 and BB3 are in the same VLAN, but remember that the VLAN is defined as isolated; the hosts in isolated VLAN do NOT have reachability to each other.

R6#Ping 200.1.1.2


R6#Ping 200.1.1.3

Type escape sequence to abort. Sending 5, 100byte ICMP Echos to 200.1.1.3, timeout is 2 seconds:

..... Success rate is 0 percent (0/5)

R6#Ping 200.1.1.4


R6#Ping 200.1.1.5



Sending 5, 100byte ICMP Echos to 200.1.1.5, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

R6#Ping 200.1.1.7


R6#Ping 200.1.1.8


R6#Ping 200.1.1.9


On BB1

BB1#Ping 200.1.1.1


Note BB1 is able to ping R1 which is the port in primary VLAN but it can NOT ping any other router, even though R6, BB2 and BB3 are in the same VLAN, but remember that the VLAN is defined as an isolated secondary VLAN; the hosts in isolated VLAN do NOT have reachability to each other.

BB1#Ping 200.1.1.2



BB1#Ping 200.1.1.3


BB1#Ping 200.1.1.4


BB1#Ping 200.1.1.5


BB1#Ping 200.1.1.6


BB1#Ping 200.1.1.8


BB1#Ping 200.1.1.9


On BB2

BB2#Ping 200.1.1.1




BB2#Ping 200.1.1.2


BB2#Ping 200.1.1.3


BB2#Ping 200.1.1.4


BB2#Ping 200.1.1.5


BB2#Ping 200.1.1.6



BB2#Ping 200.1.1.7


BB2#Ping 200.1.1.9


On BB3

BB3#Ping 200.1.1.1



BB3#Ping 200.1.1.2


BB3#Ping 200.1.1.3


BB3#Ping 200.1.1.4



Sending 5, 100byte ICMP Echos to 200.1.1.4, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

BB3#Ping 200.1.1.5


BB3#Ping 200.1.1.6


BB3#Ping 200.1.1.7


BB3#Ping 200.1.1.8


Task 7

Reconfigure the IP addressing of the hosts that belong to the two community secondary VLANs based on the following chart and provide InterVlan routing between them: The hosts in the other secondary VLANs should still be able to reach the host in the primary VLAN. You can use static routes and any IP addressing to accomplish this task.


Routers / Interface IP address VLANID R2 – F0/0 R3 – F0/1

202.1.1.2 /24 202.1.1.3 /24

2020

R4 – F0/0 R5 – F0/1

203.1.1.4 /24 203.1.1.5 /24

3030

On R2

R2(config)#int f0/0 R2(configif)#ip addr 202.1.1.2 255.255.255.0

R2(config)#ip route 0.0.0.0 0.0.0.0 202.1.1.100

On R3


R3(config)#ip route 0.0.0.0 0.0.0.0 202.1.1.100

On R4


R4(config)#ip route 0.0.0.0 0.0.0.0 203.1.1.100

On R5


R5(config)#ip route 0.0.0.0 0.0.0.0 203.1.1.100

On SW1

SW1(config)#IP routing

Note two IP addresses are configured under interface VLAN 10, a primary and a secondary, the primary IP address is used by the hosts in VLAN 20 and the secondary is used by the hosts in VLAN 30. The “Privatevlan mapping” command maps the secondary VLANs to their layer 3 VLAN interface, in this case VLAN 10 which is the layer 3 interface of the primary VLAN.


SW1(config)#int vlan 10 SW1(configif)#ip address 202.1.1.100 255.255.255.0 SW1(configif)#ip address 203.1.1.100 255.255.255.0 sec SW1(configif)#privatevlan mapping 20,30

With the “Privatevlan mapping” interface configuration command, secondary VLANs can be added or removed using the “Privatevlan mapping add, or Privatevlan mapping remove” interface configuration command. After this command is entered, you should get the following messages:

%PV6PV_MSG: Created a private vlan mapping, Primary 10, Secondary 20 %PV6PV_MSG: Created a private vlan mapping, Primary 10, Secondary 30


On SW1

SW1#Show interfaces privatevlan mapping

Interface Secondary VLAN Type vlan10 20 community vlan10 30 community


On R2

R2#Ping 203.1.1.4


R2#Ping 203.1.1.5


On BB1


BB1#Ping 200.1.1.1


Task 8

Erase the startup config and reload the routers before proceeding to the next task.


Advanced CCIE Routing & Switching

4.0

www.MicronicsTraining.com

Narbik Kocharians CCIE #12410

R&S, Security, SP

Framerelay


R1 R1

R4

R3

R2

S0/0

S0/0

S0/0

S0/0

104 103

102

401 301

201

10.1.100.1 /24

10.1.100.4 /24

10.1.100.3 /24

10.1.100.2 /24

IP addressing and DLCI information Chart:

Routers IP address Local DLCI Connecting to: R1’s Framerelay interface S0/0 10.1.100.1 /24 102

103 104

R2 R3 R4

R2’s Framerelay interface S0/0 10.1.100.2 /24 201 R1



Lab 1 – HubnSpoke using Framerelay map statements


Task 1

Configure a framerelay Hub and spoke using framerelay map statements. Use the IP addressing in the above chart. Disable inversearp such that the routers do not generate inversearp request packets, and ensure that only the assigned DLCIs are used and mapped, these mappings should be as follows:

Ø On R1: DLCIs 102, 103 and 104 should be mapped to R2, R3 and R4 respectively.

Ø On R2, R3 and R4: DLCIs 201, 301 and 401 should be used on R2, R3 and R4 respectively for their mapping to R1 (The hub).

In the future Eigrp routing protocol will be configured on these routers, ensure that the routers can handle the Multicast traffic generated by the Eigrp routing protocol. DO NOT configure any subinterface(s) to accomplish this task.

On R1

R1(config)#Int S0/0 R1(configif)#IP address 10.1.100.1 255.255.255.0 R1(configif)#Encapsulation frame R1(configif)#Framerelay map ip 10.1.100.2 102 broadcast R1(configif)#Framerelay map ip 10.1.100.3 103 broadcast R1(configif)#Framerelay map ip 10.1.100.4 104 broadcast R1(configif)#NO framerelay inversearp R1(configif)#NO shut


On R1

R1#Show framerelay map

Serial0/0 (up): ip 10.1.100.2 dlci 102(0x66,0x1860), static, broadcast, CISCO, status defined, inactive




Note you may see DLCIs 105 and 106 mapped to 0.0.0.0 IP address, these dynamic mappings may not affect Unicast traffic, but they will affect Multicast and/or Broadcast traffic, therefore, they should be removed from the mapping table. The “clear framerelay inarp” command will NOT have any effect on these entries, whereas, saving the configuration and then reloading the routers will definitely clear the 0.0.0.0 mappings. Another way to clear the “0.0.0.0” mapping is to remove the encapsulation and reconfigure the encapsulation back again, but once the encapsulation is removed, the framerelay commands configured under the interface are also removed.

The output of the above show command shows that the DLCIs are all in “inactive” status, this means that the problem is on the other side of the VC, in this case, the other end of these VCs are not configured yet, and once they are configured, the status should transition to active state.

Let’s configure the spoke routers:

On R2

R2(config)#Int S0/0 R2(configif)#Ip address 10.1.100.2 255.255.255.0 R2(configif)#Encapsulation frame R2(configif)#Framerelay map ip 10.1.100.1 201 broadcast R2(configif)#NO framerelay inversearp R2(configif)#NO shut


On R2

Let’s start with layer one and see if we have a serial cable connected to the Framerelay switch, if so, which end of the cable is connected to our router, DTE or DCE?

The output of the following show command shows that the DTE end of the cable is connected to our local router, and the “clocks detected” tells us that we are receiving clocking from a DCE device. This should always be the first step in troubleshooting framerelay. If the output of the following command showed that we have the DCE end of the cable connected to our router, then, the local router has to provide clocking, which means that the “clockrate” command MUST be configured or else the VC will NOT transition into UP/UP state.

R2#Show controller S0/0 | Inc clocks

DTE V.35 TX and RX clocks detected.

In the next step, we should see if the local router is exchanging LMIs with the framerelay switch.

NOTE: Keepalive LMIs are exchanged every 10 seconds, which means that if the framerelay switch is


configured correctly and the LMI types are also configured correctly (They match on both ends), then, you should see the number of status Enquires sent and received increment every 10 seconds.

R2#Show framerelay lmi | Inc Num

Num Status Enq. Sent 68 Num Status msgs Rcvd 69 Num Update Status Rcvd 0 Num Status Timeouts 0

R2#Show framerelay lmi | Inc Num

Num Status Enq. Sent 69 Num Status msgs Rcvd 70 Num Update Status Rcvd 0 Num Status Timeouts 0

Next the framerelay maps are checked:

R2#Show framerelay map 201

Serial0/0 (up): ip 10.1.100.1 dlci 201(0xC9,0x3090), static, broadcast, CISCO, status defined, active

NOTE: The output of the above show command reveals that the remote IP address of 10.1.100.1 is mapped to the local DLCI of 201. Make sure you see the correct IP address.

In the paranthesis, DLCI 201, is presented in Hexadecimal and Q922 format. If the Hexadecimal value of 0xC9 is converted to decimal, the result is 201, which is the local DLCI number.

The second Hexadecimal value of 0x3090, indicates how the DLCI is split into two sections within the Framerelay header; a DLCI is a 10 bit digit and the first 6 bits (The most significant 6 bits) are in the first byte and the last 4 bits of the DLCI, is found in the beginning of the second byte of the Frame relay frame, as follows:

Frame Relay header structure

Notice how the 10 bits are divided? 6 bits are in the first BYTE and the remaining 4 bits are in the second Byte.

If the hex value of 0x3090 is converted to decimal, you will once again see a DLCI value of 201. As follows:


Convert 0x3090 to Binary:

3 0 9 0 0011 0 0 0 0 1001 0000

Take the most significant 6 bits, in this case: 001100

Take the most significant 4 bits of the second byte, in this case: 1001

Note the most significant 6 bits of the first byte and the most significant 4 bits of the second byte are concatenated into a 10 bit value, as follows:

0011001001

If the above binary number is converted to decimal (1 + 8 + 64 + 128), you should get 201.

In the final step, an end to end reachability is tested:

R2#Ping 10.1.100.1


Let’s configure R3:

On R3

R3(config)#Int S0/0 R3(configif)#Ip address 10.1.100.3 255.255.255.0 R3(configif)#Encapsulation frame R3(configif)#Framerelay map ip 10.1.100.1 301 broadcast R3(configif)#NO framerelay inversearp R3(configif)#NO shut


On R3

R3#Ping 10.1.100.1



!!!!! Success rate is 100 percent (5/5), roundtrip min/avg/max = 56/56/60 ms

R3#Show frame map

Serial0/0 (up): ip 10.1.100.1 dlci 301(0x12D,0x48D0), static, broadcast, CISCO, status defined, active

Let’s configure R4:

On R4

R4(config)#Int S0/0 R4(config)#Ip address 10.1.100.4 255.255.255.0 R4(config)#Encapsulation frame R4(config)#Framerelay map ip 10.1.100.1 401 broadcast R4(config)#NO framerelay inversearp R4(config)#NO shut


On R4

R4#Ping 10.1.100.1



Serial0/0 (up): ip 10.1.100.1 dlci 401(0x191,0x6410), static, broadcast, CISCO, status defined, active

Task 2

Ensure that every router can ping every IP address connected to the cloud. When configuring this task, ensure that the hub router does NOT receive redundant routing traffic.


NOTE: Every IP address connected to the cloud also includes the local router’s IP address. Let’s test the existing situation:

On R1

R1#Ping 10.1.100.1


The ping is NOT successful. Let’s enable the “Debug Framerelay packet” and try the ping again:

R1#Debug Framerelay packet Frame Relay packet debugging is on

R1#Ping 10.1.100.1


Serial0/0:Encaps failedno map entry link 7(IP). Serial0/0:Encaps failedno map entry link 7(IP). Serial0/0:Encaps failedno map entry link 7(IP). Serial0/0:Encaps failedno map entry link 7(IP). Serial0/0:Encaps failedno map entry link 7(IP). Success rate is 0 percent (0/5)

Let’s disable the debug:

On R1

R1#u all

The output of the above debug states that there is NO mapping and encapsulation failed because of that; Framerelay can be configured in two different ways: Multipoint and Pointtopoint. There is ONLY one way to configure framerelay in a pointtopoint manner, and that’s through a pointtopoint subinterface configuration, whereas, a multipoint can be configurd in two ways:

• Perform the entire configuration directly under the main interface. • Configure a subinterface in a multipoint manner.

Since the entire configuration was performed without the use of subinterfaces, this is a multipoint


interface. In a multipoint framerelay configuration, two conditions must be met before an IP address is reachable:

A. The destination IP address must be in the routing table with a valid next hop.

B. There must be a framerelay mapping for that destination.

In this case the destination IP address is in the routing table, but the framerelay mapping is missing.

When configuring the framerelay mapping, you can use any active DLCI:

On R1

R1(config)#Interface S0/0 R1(configif)#Framerelay map ip 10.1.100.1 102

NOTE: Since the local router will NOT be sending Multicast or Broadcast traffic to itself, there is no need to add the “broadcast” keyword for this configuration.


On R1

R1#Ping 10.1.100.1


Let’s test R2’s reachability, we already know that it needs a framerelay map or else it will not be able to ping its own IP address, let’s configure one and test:

On R2

R2(config)#Int S0/0 R2(configif)#Framerelay map ip 10.1.100.2 201


On R2

R2#Ping 10.1.100.2



Let’s see if R2 can ping the other spokes:

On R2

R2#Ping 10.1.100.3


R2#Ping 10.1.100.34


Do we have a framerelay mappings for these destinations? Let’s check:

On R2


Serial0/0 (up): ip 10.1.100.2 dlci 201(0xC9,0x3090), static, CISCO, status defined, active

Serial0/0 (up): ip 10.1.100.1 dlci 201(0xC9,0x3090), static, broadcast, CISCO, status defined, active

NOTE: There are two framerelay mappings, one for 10.1.100.2 and the second one is for 10.1.100.1 IP addresses. Let’s add two more framerelay mappings, one for 10.1.100.3 and the second one for 10.1.100.4:

On R2

R2(config)#Int S0/0 R2(configif)#Framerelay map ip 10.1.100.3 201 R2(configif)#Framerelay map ip 10.1.100.4 201


There are two points that you need to remember:

a. The destination IP address must be in the routing table with a valid next hop.

b. There must be a framerelay mapping for that destination.


On R2

R2#Ping 10.1.100.3


Let’s turn on the “Debug Framerelay packet” and ping again and see the result:

On R2

R2#Deb frame pack Frame Relay packet debugging is on

R2#Ping 10.1.100.3


Serial0/0(o): dlci 201(0x3091), pkt type 0x800(IP), datagramsize 104. Serial0/0(o): dlci 201(0x3091), pkt type 0x800(IP), datagramsize 104. Serial0/0(o): dlci 201(0x3091), pkt type 0x800(IP), datagramsize 104. Serial0/0(o): dlci 201(0x3091), pkt type 0x800(IP), datagramsize 104. Serial0/0(o): dlci 201(0x3091), pkt type 0x800(IP), datagramsize 104.

Success rate is 0 percent (0/5)

It seems like the local router (R2) is sending the packets out, let’s enable the same debugging on R3 and see the result:

On R2

R2#Ping 10.1.100.3



On R3

Serial0/0(i): dlci 301(0x48D1), pkt type 0x800, datagramsize 104 Serial0/0:Encaps failedno map entry link 7(IP)

It looks like R3 is missing framerelay map back to R2. Let’s configure a framerelay map on R3 for R2 and test again:

On R3



On R2

R2#Ping 10.1.100.3


Perfect…..Let’s do the same on R4.

On R4



On R2

R2#Ping 10.1.100.4



!!!!! Success rate is 100 percent (5/5), roundtrip min/avg/max = 96/100/108 ms

When configuring the framerelay mapping from one spoke to another spoke, the “broadcast” keyword should not be used, if this keyword is used, the hub router will receive redundant routing traffic. This can be verified by running RIPv2 and performing a “debug ip rip” command on the hub router.

Task 3

Configure the routers such that the LMI status inquiries are sent every 5 seconds and Full Status LMI requests are sent every 3 cycles instead of 6.

By default framerelay routers generate LMI Status inquiries every 10 seconds, and a full status inquiry every 6 th cycle (Every 60 seconds). The interval for status inquiries can be changed using the “Keepalive” command, whereas, the “Framerelay lmin391dte” command can be used to change the interval for the complete status inquiries.

NOTE: The output of the following debug command reveals the status inquiries and full status inquiries:

On R1

R1#Debug frame lmi

Serial0/0(out): StEnq, myseq 125, yourseen 124, DTE up datagramstart = 0x3F401ED4, datagramsize = 14 FR encap = 0x00010308 00 75 95 01 01 01 03 02 7D 7C

Serial0/0(in): Status, myseq 125, pak size 14 RT IE 1, length 1, type 1 KA IE 3, length 2, yourseq 125, myseq 125

Serial0/0(out): StEnq, myseq 126, yourseen 125, DTE up datagramstart = 0x3F6B0294, datagramsize = 14 FR encap = 0x00010308 407: 00 75 95 01 01 01 03 02 7E 7D

Serial0/0(in): Status, myseq 126, pak size 14 RT IE 1, length 1, type 1


KA IE 3, length 2, yourseq 126, myseq 126

Serial0/0(out): StEnq, myseq 127, yourseen 126, DTE up datagramstart = 0x3F400C14, datagramsize = 14 FR encap = 0x00010308 00 75 95 01 01 01 03 02 7F 7E Serial0/0(in): Status, myseq 127, pak size 14 RT IE 1, length 1, type 1 KA IE 3, length 2, yourseq 127, myseq 127

Serial0/0(out): StEnq, myseq 128, yourseen 127, DTE up datagramstart = 0x3F6AF394, datagramsize = 14 FR encap = 0x00010308 00 75 95 01 01 01 03 02 80 7F Serial0/0(in): Status, myseq 128, pak size 14 RT IE 1, length 1, type 1 KA IE 3, length 2, yourseq 128, myseq 128

Serial0/0(out): StEnq, myseq 129, yourseen 128, DTE up datagramstart = 0x3F644ED4, datagramsize = 14

FR encap = 0x00010308 00 75 95 01 01 01 03 02 81 80 Serial0/0(in): Status, myseq 129, pak size 14 RT IE 1, length 1, type 1 KA IE 3, length 2, yourseq 129, myseq 129

Serial0/0(out): StEnq, myseq 130, yourseen 129, DTE up datagramstart = 0x3F6B03D4, datagramsize = 14 FR encap = 0x00010308 00 75 95 01 01 00 03 02 82 81

Serial0/0(in): Status, myseq 130, pak size 59 RT IE 1, length 1, type 0 KA IE 3, length 2, yourseq 130, myseq 130

PVC IE 0x7 , length 0x3 , dlci 102, status 0x2 PVC IE 0x7 , length 0x3 , dlci 103, status 0x2 PVC IE 0x7 , length 0x3 , dlci 104, status 0x2 PVC IE 0x7 , length 0x3 , dlci 105, status 0x0 PVC IE 0x7 , length 0x3 , dlci 106, status 0x0

Note the status inquiries are sent every 10 seconds, these messages are “type 1s”, whereas, the complete status inquiries are generated by the local router every 6 th cycle, these message are “type 0” messages, and when the framerelay switch receives these messages it responds with all the DLCIs that are


configured for that given router.

To change these timers:

On all routers

Rx(config)#Interface S0/0 Rx(configif)#Keepalive 5 Rx(configif)#Framerelay lmin391dte 3


Rx#Debug frame LMI

*Nov 24 20:13:52.411: Serial0/0(out): StEnq, myseq 221, yourseen 220, DTE up *Nov 24 20:13:52.411: datagramstart = 0x3F6AEFD4, datagramsize = 14 *Nov 24 20:13:52.411: FR encap = 0x00010308 *Nov 24 20:13:52.411: 00 75 95 01 01 01 03 02 DD DC

*Nov 24 20:13:52.415: Serial0/0(in): Status, myseq 221, pak size 14 *Nov 24 20:13:52.415: RT IE 1, length 1, type 1 *Nov 24 20:13:52.415: KA IE 3, length 2, yourseq 221, myseq 221

*Nov 24 20:13:57.411: Serial0/0(out): StEnq, myseq 222, yourseen 221, DTE up *Nov 24 20:13:57.411: datagramstart = 0x3F400D54, datagramsize = 14 *Nov 24 20:13:57.411: FR encap = 0x00010308 *Nov 24 20:13:57.411: 00 75 95 01 01 01 03 02 DE DD

*Nov 24 20:13:57.415: Serial0/0(in): Status, myseq 222, pak size 14 *Nov 24 20:13:57.415: RT IE 1, length 1, type 1 *Nov 24 20:13:57.415: KA IE 3, length 2, yourseq 222, myseq 222

*Nov 24 20:14:02.411: Serial0/0(out): StEnq, myseq 223, yourseen 222, DTE up *Nov 24 20:14:02.411: datagramstart = 0x3F6AF394, datagramsize = 14 *Nov 24 20:14:02.411: FR encap = 0x00010308 *Nov 24 20:14:02.411: 00 75 95 01 01 00 03 02 DF DE

*Nov 24 20:14:02.423: Serial0/0(in): Status, myseq 223, pak size 59 *Nov 24 20:14:02.423: RT IE 1, length 1, type 0 *Nov 24 20:14:02.423: KA IE 3, length 2, yourseq 223, myseq 223 *Nov 24 20:14:02.423: PVC IE 0x7 , length 0x3 , dlci 102, status 0x2 *Nov 24 20:14:02.423: PVC IE 0x7 , length 0x3 , dlci 103, status 0x2 *Nov 24 20:14:02.423: PVC IE 0x7 , length 0x3 , dlci 104, status 0x2 *Nov 24 20:14:02.423: PVC IE 0x7 , length 0x3 , dlci 105, status 0x0 *Nov 24 20:14:02.423: PVC IE 0x7 , length 0x3 , dlci 106, status 0x0

Note initially the router and the framerelay switch exchange two “type 1” inquiries, and the third


message that the local router generates is a “type 0” messages which tells the switch to respond with all the DLCIs.

Task 4

Erase the startup configuration and reload the routers before proceeding to the next lab.


IP addressing:

Router Interface / IP address DLCI assignment R1 S0/1 = 200.1.1.1 /24 113

R3 S0/1 = 200.1.1.3 /24 113

Task 1

Configure Framerelay between R1 and R3, you should use the IP address, interface and the DLCIs provided in the IP Addressing table above.

In this scenario we do not have a framerelay switch connecting the routers; these routers are connected back to back using a DTEßà DCE serial cable. The router that is connected to the DCE side should provide the clocking using the “Clock rate” interface configuration command, the DCE side can be determined using the “Show controller S 0/1” command as follows:

R1#Sh controller S 0/1 | Inc clock

DCE V.35, clock rate 64000

In this case since the framerelay switch does NOT exist, the LMIs should be disabled using the “No Keepalive” interface configuration command, and the framerelay mapping should be done statically. When configuring the Framerelay mapping, the DLCIs should be identical on both ends.

Lab 9 – BacktoBack Framerelay connection


On R1

R1(config)#interface Serial0/1 R1(configif)#ip address 200.1.1.1 255.255.255.0 R1(configif)#encapsulation framerelay R1(configif)#NO keepalive R1(configif)#clock rate 64000 R1(configif)#framerelay map ip 200.1.1.3 113 R1(configif)#NO shut

On R3

R3(config)#interface Serial0/1 R3(configif)#ip address 200.1.1.3 255.255.255.0 R3(configif)#encapsulation framerelay R3(configif)#NO keepalive R3(configif)#framerelay map ip 200.1.1.1 113

To verify & test the configuration:

On R1

R1#Ping 200.1.1.3


R1#Show framerelay lmi R1#

Note there are no LMIs, because they are disabled.

R1#Show framerelay pvc

PVC Statistics for interface Serial0/1 (Frame Relay DTE)

Active Inactive Deleted Static Local 1 0 0 0 Switched 0 0 0 0 Unused 0 0 0 0

DLCI = 113, DLCI USAGE = LOCAL, PVC STATUS = STATIC, INTERFACE = Serial0/1


input pkts 5 output pkts 10 in bytes 520 out bytes 1040 dropped pkts 0 in pkts dropped 0 out pkts dropped 0 out bytes dropped 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec pvc create time 00:03:53, last time pvc status changed 00:02:39


Serial0/1 (up): ip 200.1.1.3 dlci 113(0x71,0x1c10), static, CISCO

Task 2

Configure the routers such that R1 uses DLCI 103 to send and DLCI 301 to receive packets, whereas, R3 should use DLCI 301 to send and DLCI 103 to receive packets. You should configure interface S0/1 to accomplish this task.

In this task we are asked to configure these routers to use different DLCIs, 103 connecting R1 to R3 and 301 connecting R3 to R1.

On R1

R1(config)#interface Serial0/1 R1(configif)#ip address 200.1.1.1 255.255.255.0 R1(configif)#encapsulation framerelay R1(configif)#NO keepalive R1(configif)#clock rate 64000

The following command removes the framerelay mapping that was configured in the previous task and adds the new mapping:

R1(configif)#NO framerelay map ip 200.1.1.3 113 R1(configif)#framerelay map ip 200.1.1.3 103

On R3

R3(config)#interface Serial0/1


R3(configif)#ip address 200.1.1.3 255.255.255.0 R3(configif)#encapsulation framerelay R3(configif)#NO keepalive R3(configif)#NO framerelay map ip 200.1.1.1 113 R3(configif)#framerelay map ip 200.1.1.1 301

To verify and test the configuration:

On Both Routers:

#Debug Framerelay packet

On R1

R1#Ping 200.1.1.3


You should see the following debug output on R1 and R3:

On R1

Serial0/1(o): dlci 103(0x1871), pkt type 0x800(IP), datagramsize 104. Serial0/1(o): dlci 103(0x1871), pkt type 0x800(IP), datagramsize 104. Serial0/1(o): dlci 103(0x1871), pkt type 0x800(IP), datagramsize 104. Serial0/1(o): dlci 103(0x1871), pkt type 0x800(IP), datagramsize 104. Serial0/1(o): dlci 103(0x1871), pkt type 0x800(IP), datagramsize 104.

On R3

Serial0/1: FR invalid/unexpected pak received on DLCI 103 Serial0/1: FR invalid/unexpected pak received on DLCI 103 Serial0/1: FR invalid/unexpected pak received on DLCI 103 Serial0/1: FR invalid/unexpected pak received on DLCI 103 Serial0/1: FR invalid/unexpected pak received on DLCI 103

NOTE: The output of the debug messages on R3 reveals the reason that the ping was NOT successful. It’s telling us that it received 5 invalid and unexpected packets on DLCI 103. The reason the local router (R3) sees R1’s DLCI is because they are directly connected. To fix this problem, R3 can be configured to receive data on DLCI 103 and send on DLCI 301, as follows:


On R3

R3(config)#int S0/1 R3(configif)#framerelay interfacedlci 103


On R1

R1#Ping 200.1.1.3 repeat 4

On R3

Serial0/1(i): dlci 103(0x1871), pkt type 0x800, datagramsize 104 Serial0/1(o): dlci 301(0x48D1), pkt type 0x800(IP), datagramsize 104




Note the incoming traffic uses DLCI 103, whereas, the outgoing traffic uses DLCI 301. Let’s try to ping R1 and see why the pings are unsuccessful:


On R3


On R1

Serial0/1: FR invalid/unexpected pak received on DLCI 301 Serial0/1: FR invalid/unexpected pak received on DLCI 301 Serial0/1: FR invalid/unexpected pak received on DLCI 301 Serial0/1: FR invalid/unexpected pak received on DLCI 301

Note we are experiencing the same problem on R3, the traffic comes in on DLCI 301 and the local router is NOT aware of this DLCI. To fix this problem:


R1(config)#int S0/1 R1(configif)#framerelay interfacedlci 301


On R3


Type escape sequence to abort. Sending 4, 100byte ICMP Echos to 200.1.1.1, timeout is 2 seconds: !!!! Success rate is 100 percent (4/4), roundtrip min/avg/max = 28/29/32 ms

On R1

Serial0/1(i): dlci 301(0x48D1), pkt type 0x800, datagramsize 104 Serial0/1(o): dlci 103(0x1871), pkt type 0x800(IP), datagramsize 104




R1#Show frame map

Serial0/1 (up): ip 200.1.1.3 dlci 103(0x67,0x1870), static, CISCO

On R3

R3#Show frame map

Serial0/1 (up): ip 200.1.1.1 dlci 301(0x12D,0x48D0), static, CISCO


Task 3

Reconfigure R1 as a framerelay switch and a router connecting to R3, whereas, R3 should be configured as a router connecting to R1 using S0/1 interface. R1 should use DLCI 103 for its connection to R3 and R3 should use DLCI 301 for its connection to R1. You should NOT disable LMIs to accomplish this task.

On R1

R1(config)#frame switching

R1(config)#int S0/1 R1(configif)#ip addr 200.1.1.1 255.255.255.0 R1(configif)#encap framerelay R1(configif)#clock rate 64000

R1(configif)#frame map ip 200.1.1.3 103 R1(configif)#frame interfacedlci 301 R1(configif)#framerelay intftype dce

On R3

R3(configif)#int S0/1 R3(configif)#ip addr 200.1.1.3 255.255.255.0 R3(configif)#encap framerelay R3(configif)#frame map ip 200.1.1.1 301


On R1

R1#Show frame lmi | B Num

Num Status Enq. Rcvd 11 Num Status msgs Sent 11 Num Update Status Sent 0 Num St Enq. Timeouts 0

On R3

R3#Show framerelay lmi | B Num

Num Status Enq. Sent 18 Num Status msgs Rcvd 19 Num Update Status Rcvd 0 Num Status Timeouts 0 Last Full Status Req 00:00:00 Last Full Status Rcvd 00:00:00



Serial0/1 (up): ip 200.1.1.1 dlci 301(0x12D,0x48D0), static, CISCO, status defined, active

R3#Ping 200.1.1.1


Task 4

Erase the startup configuration and reload the routers before proceeding to the next lab.


Lab Setup:

Ø Configure F0/19 interface of SW1 and SW2 as a Dot1Q trunk.

Ø Configure SW1 and SW2 in VTP domain called TST

Ø Configure F0/1 and F0/2 interface of SW1 in VLAN 100.

Ø Configure F0/3 interface of SW2 as a Dot1Q trunk.

Ø Configure F0/1 interface of R3 as a Dot1Q trunk for VLAN 100.

You can copy and paste the initial configuration from the init directory

IP addressing:

Router Interface / IP address VLAN R1 F0/0 = 10.1.1.1 /24 100 R2 F0/0 = 10.1.1.2 /24 100 R3 F0/1.100 = 10.1.1.3 /24 100

Lab 1 – MLS QOS


Task 1

Assign a hostname of SW1 to Switch 1 and a hostname of SW2 to Switch 2. Shutdown all unused ports on these switches.

On Switch 1

Switch(config)#Host SW1

SW1(config)#Int range f0/318 , F0/2024 SW1(configifrange)#Shut

On Switch 2

Switch(config)#Host SW2

SW2(config)#Int range f0/12 , F0/418 , F0/2024 SW2(configifrange)#Shut

Task 2

Configure SW1’s port F0/2 such that it marks All ingress traffic with a CoS marking of 2. For verification purpose, R3 should be configured to match on CoS values of 0 – 7 ingress on its F0/1.100 subinterface.

In this step R3 is configured to match on incoming CoS values of 0 – 7, this is done so the policy can be tested and verified.

On R3

R3(config)#classmap cos0 R3(configcmap)#match CoS 0









R3(config)#Policymap TST R3(configpmap)#Class cos0 R3(configpmap)#Class cos1 R3(configpmap)#Class cos2 R3(configpmap)#Class cos3 R3(configpmap)#Class cos4 R3(configpmap)#Class cos5 R3(configpmap)#Class cos6 R3(configpmap)#Class cos7

R3(config)#Int F0/1.100 R3(configsubif)#Servicepolicy in TST

On SW1

By default, QOS is disabled and the switch will NOT modify the CoS, IPPrecedence or the DSCP values of received traffic. To verify:

SW1#Show mls qos

QoS is disabled QoS ip packet dscp rewrite is enabled

The following command enables MLS QOS; to perform any kind of QOS configuration, MLS QOS must be enabled.

SW1(config)#MLS QOS


On SW1


SW1#Show mls qos

QoS is enabled QoS ip packet dscp rewrite is enabled

To continue with the configuration:

SW1(config)#int F0/1

The following command assigns a default CoS value of 2 to untagged traffic received through this interface.

SW1(configif)#mls qos cos 2


On SW1

SW1#Show mls qos inter f0/1

FastEthernet0/1 trust state: not trusted trust mode: not trusted trust enabled flag: ena COS override: dis default COS: 2 DSCP Mutation Map: Default DSCP Mutation Map Trust device: none qos mode: portbased


On R1

R1#Ping 10.1.1.3

Type escape sequence to abort. Sending 5, 100byte ICMP Echos to 10.1.1.3, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), roundtrip min/avg/max = 1/1/4 ms

To verify the test:


On R3

R3#Show policymap interface | S cos0

Classmap: cos0 (matchall) 4 packets, 472 bytes 5 minute offered rate 0 bps Match: cos 0



Note, even though the interface is configured with “Mls qos cos 2” the traffic coming in on that interface is NOT affected. To mark ALL traffic with a CoS marking of 2, which means all traffic regardless of their marking, the port must be configured to override the existing CoS.

The “mls qos cos” command on its own does NOTHING, it should be combined with either the “Mls qos cos override” or “Mls qos trust cos”. When its combined with “MLS qos trust cos”, ONLY the untagged traffic is affected, but if it’s combined with “MLS qos cos override”, then, all traffic (Tagged or untagged) is affected.

The following command configures the switch port to trust the CoS value in ALL incoming traffic through F0/2 interface, the “Mls qos cos override” command will be tested later:

SW1(config)#int F0/1 SW1(configif)#mls qos trust cos


On SW1

SW1#Sh mls qos interface f0/1

FastEthernet0/1 trust state: trust cos trust mode: trust cos trust enabled flag: ena COS override: dis default COS: 2 DSCP Mutation Map: Default DSCP Mutation Map


Trust device: none qos mode: portbased


On R3

R3#Clear counters Clear "show interface" counters on all interfaces [confirm]

Press Enter to allow the counters to be cleared

On R1

R1#Ping 10.1.1.3


To verify the test:

On R3

R3#Sh policymap inter | S cos0




Note the output of the above show command reveals that all traffic that sourced from R1 is marked with a CoS value of 0; the reason for this outcome is because SW1 is configured with “Mls qos” global configuration command, therefore, the switch will mark all untagged incoming traffic through its F0/1 interface with a CoS value of 2.


Task 3

Configure SW1 and R1 as follows:

• F0/1 interface of SW1 should be configured as a Dot1q trunk. • Disable “Mls QOS” and remove the “Mls qos cos 2” command from F0/1

interface of SW1. • Configure F0/0.100 subinterface on R1, this subinterface should be configured

based on the following:

• R1’s F0/0.100 interface should be configured as trunk for VLAN 100 • R1’s F0/0.100 should be assigned an IP address of 10.1.1.1 /24 • R1’s F0/0.100 should be configured to mark all egress traffic with a CoS

value of 6.

On SW1

SW1(config)#int F0/1 SW1(configif)#Default inter f0/1

SW1(config)#int F0/1 SW1(configif)#swi trunk enc do SW1(configif)#swi mode trunk

SW1(config)#NO Mls qos

To verify the configuration

On SW1

SW1#Show int trunk



Port Vlans allowed and active in management domain Fa0/1 1,100 Fa0/19 1,100


Port Vlans in spanning tree forwarding state and not pruned Fa0/1 none Fa0/19 1,100

On R1

R1(config)#Default inter F0/0

R1(configif)#int F0/0.100 R1(configsubif)#encap dot1 100 R1(configsubif)#ip addr 10.1.1.1 255.255.255.0

R1(config)#Policymap TST R1(configpmap)#class classdefault R1(configpmapc)#set cos 6

R1(configpmapc)#int F0/0.100 R1(configsubif)#servicepolicy out TST


On R3

R3#Clear counters

On R1

R1#Ping 10.1.1.3 rep 60

Type escape sequence to abort. Sending 60, 100byte ICMP Echos to 10.1.1.3, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (60/60), roundtrip min/avg/max = 1/1/4 ms

On R3

R3#Sh policymap inter | S cos60


Note traffic generated by R1 has a CoS marking of 6.


Task 4

SW1 should be configured to trust the CoS marking of any traffic coming through its F0/1 interface.

On SW1

SW1(config)#mls qos

SW1(config)#int F0/1 SW1(configif)#mls qos trust CoS

To test the configuration

On R3

R3#Clear counters

On R1



Note the output of the following show command reveals that the traffic retained its CoS marking.

On R3



Task 5

Configure R1, R2 & SW1 using the following policy:


1. If the ingress traffic from R2 is NOT marked with a CoS value, SW1 should be configured to mark that traffic with a CoS value of 0.

2. If the ingress traffic from R1 is NOT tagged, SW1 should be configured to rewrite the CoS value to 1, however, if the traffic is tagged, SW1 should NOT rewrite the CoS value of the incoming traffic.

To configure the first policy:

Since the “Mls Qos” command is configured on SW1, when traffic without a CoS marking enters any port on SW1, that traffic is marked with a CoS value of 0, therefore, SW1 does NOT need to be configured for this policy:

To verify and test the first policy:

On R3

R3#Clear counter

On R2

R2#Ping 10.1.1.3 rep 60


On R3

Since the traffic generated by R2 did not have a CoS marking, the traffic will arrive with a CoS marking of zero.




Classmap: cos0 (matchall) 60 packets, 7080 bytes


5 minute offered rate 0 bps Match: cos 0

To configure the second policy:

The “Mls qos trust cos” command that was configured in the previous task will trust the CoS value in the incoming traffic and will NOT rewrite the CoS value; since the task stats that the untagged traffic should be rewritten to a CoS value of 1, whereas, the tagged traffic should NOT be affected at all, the following should be configured:


On R3

R3#Clear counters

On SW1

SW1(config)#Int F0/1 SW1(configif)#mls qos cos 1

The above command ONLY affects the untagged traffic, since R1’s F0/1 interface is configured as a truck link, this configuration should NOT have any affect. The following show command reveals this information:

On R1


Type escape sequence to abort. Sending 10, 100byte ICMP Echos to 10.1.1.3, timeout is 2 seconds: !!!!!!!!!! Success rate is 100 percent (10/10), roundtrip min/avg/max = 1/1/4 ms

On R3

The output of the following show command reveals that the traffic from R1 retained its CoS value of 6:

R3#Sh policymap inter | s cos6



To test the untagged traffic:

On R1

R1(config)#int F0/0.100 R1(configsubif)#encap dot1 100 native

NOTE: In the above and the following configuration, VLAN 100 is configured to be the Native VLAN so the traffic arrives with NO tagging:

On SW1

SW1(configif)#int F0/1 SW1(configif)#swi trunk native vlan 100

To see SW1’s configuration:

On SW1

SW1#Sh run int F0/1 | B interface

interface FastEthernet0/1 switchport trunk encapsulation dot1q switchport trunk native vlan 100 switchport mode trunk mls qos cos 1 mls qos trust cos


On SW1

SW1#Sh interface trunk


(The rest of the output is omitted)

On R3

R3#Clear counters


On R1

R1#Ping 10.1.1.3 rep 100

Type escape sequence to abort. Sending 100, 100byte ICMP Echos to 10.1.1.3, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (100/100), roundtrip min/avg/max = 1/1/4 ms

On R3







The following shows R1’s policymap configuration:

On R1

R1#Show policymap TST

Policy Map TST Class classdefault set cos 6


Task 6

SW2 should be configured such that it marks all traffic from any router/s connected to SW1 (Tagged or Untagged) with a CoS value of 7. DO NOT configure R1, R2 or SW1 to accomplish this task.

On SW2

SW2(config)#MLS QOS

NOTE: This configuration is performed on the trunk link of SW2 so it can affect all traffic coming from SW1; this affects the traffic that has marking, the traffic that does NOT have any marking, tagged or untagged:

SW2(config)#int F0/19 SW2(configif)#mls qos cos 7 SW2(configif)#mls qos cos override


On SW2

SW2#Sh mls qos inter f0/19

FastEthernet0/19 trust state: not trusted trust mode: not trusted trust enabled flag: ena COS override: ena default COS: 7 DSCP Mutation Map: Default DSCP Mutation Map Trust device: none qos mode: portbased


On R3

R3#Clear counter

On R1

R1#Ping 10.1.1.3 rep 100


Type escape sequence to abort. Sending 100, 100byte ICMP Echos to 10.1.1.3, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (100/100), roundtrip min/avg/max = 1/1/4 ms

On R3

Note the traffic matched to CoS 7



On R2

R2#Ping 10.1.1.3 rep 200

Type escape sequence to abort. Sending 200, 100byte ICMP Echos to 10.1.1.3, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (200/200), roundtrip min/avg/max = 1/1/4 ms

On R3



Note all traffic regardless of their marking are marked with a CoS value of 7.


Task 7

Erase the startup configuration on R13 and SW1 & SW2 and reload these routers and switches before proceeding to the next lab.


Lab Setup:

The lab topology and setup is based on the previous lab, with the exception of R3’s configuration and the F0/3 interface of SW2; R3’s F0/1 interface should be configured with an IP address of 10.1.1.3 /24 and the F0/3 interface of SW2 should be configured in VLAN 100.

You can copy and paste the initial configuration from the init directory

Task 1

Configure an MQC on R1 such that all packets going out of its F0/0 interface are marked with a DSCP value of 1. For verification purpose, R3’s F0/1 interface should be configured to match on DSCP 07 for all ingress traffic. Ensure that “Mls qos” is disabled on both switches.

On Both Switches:

SWx#Sh mls qos

Lab 2 – DSCPMutation


QoS is disabled

QoS ip packet dscp rewrite is enabled

The following configuration on R1 marks all egress traffic with a DSCP value of 1:

On R1

R1(config)#Policymap TST R1(configpmap)#class classdefault R1(configpmapc)#set ip dscp 1

R1(config)#int F0/0 R1(configif)#Servicepolicy out TST

On R3

The following configuration is done for verification and testing purposes:

R3(config)#Classmap DSCP0 R3(configcmap)#match ip dscp 0








R3(config)#policymap TST R3(configpmap)#Class DSCP0


R3(configpmap)#Class DSCP1 R3(configpmap)#Class DSCP2 R3(configpmap)#Class DSCP3 R3(configpmap)#Class DSCP4 R3(configpmap)#Class DSCP5 R3(configpmap)#Class DSCP6 R3(configpmap)#Class DSCP7

R3(config)#int F0/1 R3(configif)#servicepolicy in TST


On R1

R1#Ping 10.1.1.3 rep 10

Type escape sequence to abort. Sending 10, 100byte ICMP Echos to 10.1.1.3, timeout is 2 seconds: .!!!!!!!!! Success rate is 90 percent (9/10), roundtrip min/avg/max = 1/1/4 ms

On R3

R3#Sh Policymap inter | S DSCP1

Classmap: DSCP1 (matchall) 9 packets, 1026 bytes 5 minute offered rate 0 bps Match: ip dscp 1

Note since “Mls qos” is disabled on both switches, the packets traversing the switches will retain their marking.

Task 2

Configure SW2 such that if the incoming traffic is marked with DSCP 1, they are overwritten to a DSCP value of 60. DO NOT configure a classmap or Policymap to accomplish this task. Use R3 to verify the configuration.

DSCP Mutation can be configured to accomplish this task; there are five steps in configuring DSCP


mutation, and they are as follows:

Step 1: Mls qos MUST be enabled:

On SW2

SW2(config)#Mls qos

To verify the configuration of this step:

On SW2

SW2#Show mls QoS


Step 2: In this step a custom DSCPMutation map is configured, remember that if this custom mapping is NOT configured, the default DSCPMutation map will be used, the default DSCPMutation map can NOT be changed and it is configured as one to one, meaning that the incoming DSCP value will always match to the same outgoing DSCP value:

In this step a custom DSCPMutation map named TST is configured, this custom DSCPMutation maps the incoming DSCP value (in this case 1) to an outgoing DSCP value of 60:

To see the default DSCPMutation map:

SW2#Show mls qos map dscpmutation

Dscpdscp mutation map: Default DSCP Mutation Map: d1 : d2 0 1 2 3 4 5 6 7 8 9 0 : 00 01 02 03 04 05 06 07 08 09 1 : 10 11 12 13 14 15 16 17 18 19 2 : 20 21 22 23 24 25 26 27 28 29 3 : 30 31 32 33 34 35 36 37 38 39 4 : 40 41 42 43 44 45 46 47 48 49 5 : 50 51 52 53 54 55 56 57 58 59 6 : 60 61 62 63

Note the d1: column (highlighted in yellow) specifies the most significant digit of the DSCP value of


incoming packets, whereas, the d2: row (highlighted in blue) specifies the least significant digit of the DSCP value of incoming packets.

The intersection of the d1 and d2 values (this is the body of the output) provides the DSCP value of the outgoing packets.

NOTE: the output of the above show command reveals that the incoming DSCP value of 1, is re written to the outgoing DSCP value of 1.

Let’s configure a custom DSCPMutation map called TST that maps the incoming DSCP value of 1 to an outgoing DSCP value of 60:

SW2(config)#Mls qos map dscpmutation TST 1 to 60


On SW2

SW2#Show mls qos map dscpmutation TST

Dscpdscp mutation map: TST: d1 : d2 0 1 2 3 4 5 6 7 8 9 0 : 00 60 02 03 04 05 06 07 08 09 1 : 10 11 12 13 14 15 16 17 18 19 2 : 20 21 22 23 24 25 26 27 28 29 3 : 30 31 32 33 34 35 36 37 38 39 4 : 40 41 42 43 44 45 46 47 48 49 5 : 50 51 52 53 54 55 56 57 58 59 6 : 60 61 62 63

Step 3: In this step, the custom DSCPMutation map called TST is applied to the F0/19 interface (Trunk interface) of SW2

SW2(config)#int F0/19 SW2(configif)#mls qos dscpmutation TST


On SW2

SW2#Show mls qos int F0/19 | Inc DSCP


DSCP Mutation Map: TST

Step 4: Remember, if the “Mls qos trust DSCP” is NOT configured, the configuration will NOT have any affect on the packets:

To see the trust trust state (What’s being trusted) of the F0/19 interface:

On SW2

SW2#Show mls qos int F0/19 | Inc trust state

trust state: not trusted

On SW2

SW2(config)#int F0/19 SW2(configif)#mls qos trust dscp


On SW2

SW2#Show mls qos int F0/19 | Inc trust state

trust state: trust dscp

NOTE: If CoS was trusted, the output of the above command would have stated “trust state: trust CoS”, since ONLY DSCP is trusted, the trust state is DSCP.

Step 5: Ensure that the DSCP rewrites are enabled, if this is disabled, then, the DSCP marking will NOT be rewritten.

To verify if the DSCP rewrites are enabled:

On SW2

SW2#Show mls qos



If the DSCP rewrites are disabled, then, the DSCP marking in the outgoing packets will NOT be re written. There are times that this feature must be disable, to disable this feature, the “NO mls qos rewrite ip dscp” global command can be used.

To prepare R3 for verification purpose:

On R3

The following configuration is required for testing and verification.


R3(config)#policymap TST R3(configpmap)#Class DSCP60

Remember, the policymap TST is already applied.


On SW2

R3#Show policymap TST

Policy Map TST Class DSCP0 Class DSCP1 Class DSCP2 Class DSCP3 Class DSCP4 Class DSCP5 Class DSCP6 Class DSCP7 Class DSCP60


On R3

R3#clear counters

On R1


R1#Ping 10.1.1.3 rep 60


On R3

R3#Show policymap interface | S DSCP60

Classmap: DSCP60 (matchall) 60 packets, 6840 bytes 5 minute offered rate 0 bps Match: ip dscp 60

Task 3

Configure the “Default interface F0/1” command on R3 before proceeding to the next lab.

Labs

Documents

subject page volumetopology

volilab9 bgploadbalancingii

volilab22 bgpallowasin

volilab11 bgplocalpreferencei

volilab20 bgpconfederation

volilab12 bgplocalpreferenceii

volilab8 bgploadbalancing

volilab15 med