CCIE R&S Advanced Technologies Class v4.5 - Frame Relay Traffic Shaping (FRTS)

Transcript

1	Introduction	0h 43m
2	Using the Cisco Documentation	0h 52m
3	Ethernet Overview, Layer 2 Switchports, Trunking, ISL, 802.1q, DTP	0h 47m
4	VTP, VTP Authentication, VTP Pruning	1h 02m
5	VTP Prune Eligible List, VTP Transparent, VTP Troubleshooting, Trunk Allowed List, Extended VLANs	0h 48m
6	VLAN and VTP Review	0h 19m
7	SVIs, Native Routed Interfaces, Router-on-a-Stick	0h 46m
8	Layer 2 EtherChannel, EtherChannel Load Balancing, Layer 3 EtherChannel	0h 57m
9	802.1q Tunneling, Layer 2 Protocol Tunneling, EtherChannel over 802.1q Tunneling	1h 03m
10	STP Root Bridge Election, STP Root Port Election, STP Designated Port Election, STP Priority, STP Cost, STP Port-Priority	1h 46m
11	STP Review	0h 12m
12	STP Timers, STP PortFast	0h 34m
13	STP UplinkFast	0h 11m
14	STP BackboneFast	0h 12m
15	STP BPDU Filter	0h 13m
16	STP BPDU Guard	0h 11m
17	STP Root Guard	0h 11m
18	STP Loop Guard, Unidirectional Link Detection (UDLD)	0h 11m
19	Multiple Spanning-Tree Protocol (MST)	0h 40m
20	Rapid Spanning-Tree Protocol (RSTP), Rapid-PVST	0h 18m
21	MST with Multiple Regions	0h 33m
22	Flex Links	0h 16m
23	Frame Relay	0h 39m
24	Frame Relay Configuration Part 1	0h 34m
25	Frame Relay Configuration Part 2	0h 41m
26	Frame Relay Switching	0h 27m
27	Back-to-Back Frame Relay	0h 08m
28	Frame-Relay End-to-End Keepalives	0h 18m
29	PPP, PPP PAP Authentication, PPP CHAP Authentication	0h 59m
30	PPPoFR, PPPoE	0h 40m
31	Transparent Bridging, IRB	0h 32m
32	Fallback Bridging	0h 14m
33	IP Routing Overview, Switching Paths, Static Routing	0h 42m
34	Static Routing Examples	0h 25m
35	IP Default-Gateway, IP Default-Network	0h 14m
36	On-Demand Routing (ODR)	0h 07m
37	Floating Static Routes	0h 10m
38	Backup Interface	0h 29m
39	Enhanced Object Tracking, IP SLA, Reliable Static Routing	0h 21m
40	Policy Routing	0h 43m
41	GRE Tunneling, GRE Recursive Routing Errors	0h 27m
42	Reliable Backup Interface with GRE	0h 25m
43	RIP Overview, RIP Versions, RIP Auto-Summary	0h 48m
44	RIP Split-Horizon, RIP Timers	0h 22m
45	RIP Broadcast Updates, IP Directed Broadcast, IP Broadcast-Address, Smurf Attacks, Fraggle Attacks	0h 16m
46	RIP Unicast Updates	0h 03m
47	RIP Offset-List	0h 18m
48	RIP Authentication	0h 11m
49	RIP Summarization	0h 10m
50	Prefix-Lists, RIP Distribute-List Filtering, RIP Administrative Distance Filtering	0h 48m
51	RIP Default Routing, RIP Conditional Default Routing	0h 18m
52	RIP Triggered, RIP Validate Update Source,	0h 12m
53	EIGRP Overview	0h 29m
54	EIGRP Auto-Summary	0h 07m
55	EIGRP Split-Horizon	0h 11m
56	EIGRP Update Types, EIGRP Neighbor, EIGRP Passive-Interface	0h 24m
57	EIGRP Hello-Interval, EIGRP Hold-Time	0h 05m
58	EIGRP Authentication	0h 11m
59	EIGRP Time Based Authentication	0h 25m
60	EIGRP Path Selection, EIGRP Metric Weights, EIGRP Traffic Engineering	0h 47m
61	EIGRP Unequal Cost Load Balancing, EIGRP Variance	0h 19m
62	EIGRP QUERY, EIGRP Summarization, EIGRP Leak-Map	0h 28m
63	EIGRP Stub Router Advertisement	0h 22m
64	EIGRP Default Routing	0h 13m
65	EIGRP Route Filtering	0h 11m
66	EIGRP Router-ID	0h 07m
67	Miscellaneous EIGRP Features	0h 02m
68	OSPF Overview	0h 27m
69	Establishing OSPF Adjacencies, Understanding the OSPF Database	0h 43m
70	OSPF Network Type Broadcast, OSPF DR/BDR Election, OSPF over NBMA, OSPF Network Type Non-Broadcast and Point-to-Multipoint	0h 56m
71	OSPF Network Type Point-to-Point, OSPF Network Type Mismatch	0h 13m
72	OSPF Network Type Point-to-Multipoint Non-Broadcast, OSPF Per Neighbor Cost	0h 17m
73	OSPF Network Type Loopback	0h 02m
74	OSPF Path Selection	0h 27m
75	OSPF Convergence Timers	0h 09m
76	OSPF Authentication	0h 12m
77	OSPF Summarization	0h 32m
78	OSPF Stub Areas, OSPF Totally Stubby Areas, OSPF NSSAs, OSPF Totally NSSAs	0h 40m
79	Controlling OSPF NSSA Redistribution	0h 02m
80	OSPF Type 7 to 5 Translator Election, OSPF LSA Type 3 Filter, OSPF Forwarding Address Suppression	0h 24m
81	Route Redistribution Overview	0h 36m
82	Route Redistribution Configuration & Verification, Connected Redistribution	0h 22m
83	OSPF External Path Selection, TCL PING Scripting	0h 33m
84	Routing Loops Overview, EIGRP Route Loop Prevention	0h 55m
85	Metric Based Routing Loops, Route Tagging	0h 46m
86	Administrative Distance Based Routing Loops, Debug IP Routing, IP Route Profile	0h 58m
87	BGP Overview, BGP Peering Types	0h 51m
88	Establishing BGP Peerings, EBGP Multihop, BGP Neighbor Disable Connected Check, BGP TTL Security	0h 49m
89	BGP 4-Byte ASNs	0h 20m
90	BGP Local AS, BGP Peer Groups	0h 30m
91	BGP Next-Hop Self, BGP Next-Hop Processing	0h 30m
92	BGP Route Reflectors	0h 37m
93	Large Scale BGP Route Reflectors with Clusters	0h 34m
94	BGP Confederation	0h 37m
95	BGP NLRI Advertisements, BGP Network Statement, BGP Redistribution	0h 43m
96	BGP Aggregation, BGP Aggregation & Summary-Only, BGP Aggregation & Unsuppress-Map	0h 46m
97	BGP Origin, BGP Aggregation & AS-Set, BGP Aggregation & Advertise-Map	0h 22m
98	BGP Conditional Route Injection	0h 21m
99	BGP Bestpath Selection, BGP Multipath, BGP Weight	0h 53m
100	BGP Local Preference, BGP Local Preference and Communities, BGP AS-Path Prepending,	0h 30m
101	BGP MED, BGP MED Missing As Worst, BGP Deterministic MED	0h 17m
102	BGP Communites, BGP Regular Expressions	0h 43m
103	BGP Filtering, BGP Convergence Timers, BGP Default Routing, Miscellaneous BGP Features	0h 24m
104	MPLS Overview, MPLS Label Distribution Protocol (LDP)	1h 05m
105	MPLS Tunnels, MPLS Penultimate Hop Popping (PHP)	0h 40m
106	MPLS Layer 3 VPNs Overview, VRF Lite	0h 36m
107	MPLS Layer 3 VPNs and VPNv4 BGP	1h 08m
108	MPLS Layer 3 VPN Verification & Troubleshooting	0h 49m
109	MPLS Layer 3 VPN OSPF PE-CE Routing Overview	0h 06m
110	MPLS Layer 3 VPN OSPF PE-CE Routing Path Selection & Sham-Links	2h 01m
111	MPLS Layer 3 VPN OSPF PE-CE Routing Loop Prevention & Down-Bit, OSPF Capability VRF-Lite	0h 40m
112	IPv6 Overview, IPv6 ICMPv6 ND, IPv6 over NBMA	0h 44m
113	IPv6 Routing Overview, IPv6 Static Routing	0h 28m
114	IPv6 RIPng	0h 20m
115	IPv6 EIGRPv6	0h 09m
116	IPv6 OSPFv3	0h 31m
117	MP-BGP for IPv6	0h 26m
118	IPv6 Tunneling	1h 13m
119	Multicast Overview, IGMP	0h 34m
120	PIM Overview	0h 18m
121	PIM Dense Mode	1h 03m
122	PIM Sparse Mode	0h 30m
123	PIM Sparse Mode Configuration	0h 36m
124	PIM Sparse Mode RPF & RP Troubleshooting	0h 27m
125	Auto-RP, Multicast over GRE Tunnels	0h 53m
126	Bootstrap Router (BSR), Bidirectional PIM, Source Specific Multicast (SSM)	0h 40m
127	MSDP, Anycast RP	0h 27m
128	IPv6 Multicast Routing	0h 24m
129	QoS Overview, IntServ QoS, DiffServ QoS, IP Precedence, DSCP, MQC, HQF	0h 41m
130	MQC Classification	0h 44m
131	FIFO, FQ, WFQ, CBWFQ, HQF	0h 50m
132	LLQ	0h 23m
133	WRED	0h 31m
134	Traffic Shaping, Traffic Policing	0h 40m
135	Frame Relay Traffic Shaping (FRTS)	0h 33m
136	RSVP	0h 07m
137	Catalyst 3560 QoS	1h 00m
138	IOS Security Overview, Access Lists (ACLs)	0h 58m
139	Time Based ACLs, Dynamic ACLs	0h 33m
140	Reflexive ACLs	0h 21m
141	TCP Intercept, Content Based Access Control (CBAC)	0h 34m
142	Zone Based Policy Firewall (ZBPF)	1h 09m
143	AAA, Local Authentication, Local Authorization, Role Based CLI Access	0h 43m
144	Port Security, Static CAM Entries, Storm Control, 802.1X Authentication, PACLs, RACLs, VLAN Access Maps (VACLs)	0h 48m
145	DHCP Snooping, Dynamic ARP Inspection (DAI), IP Source Guard	0h 12m
146	Protected Ports, Private VLANs	0h 25m
147	IP Services Overview, HSRP	1h 10m
148	VRRP, GLBP	0h 28m
149	NAT	0h 42m
150	DHCP, DNS	0h 30m
151	NetFlow	0h 09m
152	WCCP, Miscellaneous IP Services	0h 06m
153	System Management Overview, NTP, NTP Authentication	0h 24m
154	SNMP, RMON	0h 38m
155	Syslog, Telnet, SSH, Banners	0h 21m
156	EEM Scripting, Miscellaneous System Management	0h 26m
Total Duration		81h 42m

Slides - Diagrams

Slides - Introduction

Slides - Ethernet Switching

Slides - Advanced Ethernet Switching

Slides - Frame Relay

Slides - PPP

Slides - Transport Bridging

Slides - Redistribution

Slides - IOS Security

Slides - Layer 2 Security

Slides - IP Services

Slides - System Management

0:00:13	In our next section for QoS, we're going to look at
0:00:15	frame relay traffic shaping which is similar to the previous
0:00:19	generic traffic shaping we looked at with the exception that
0:00:22	it allows the different shape rates on a permanent virtual
0:00:25	circuit basis that's going to allow us to have different
0:00:28	rates that are applied to different circuits.
0:00:31	Now the typical case that we would need this is if we were to
0:00:36	look at our diagram here where we have Router 5
0:00:38	connected to the frame relay network and it has multiple
0:00:42	PVCs that are connecting to different Layer 2 portions of
0:00:47	the network, so we have connections to Router 4
0:00:50	to Router 1, to Router 3, to Router 2
0:00:54	Now in this type of design, Router 5 is sharing these
0:00:58	four Layer 2 connections with one physical interface.
0:01:02	So regardless what the provision rate of the underlying
0:01:05	circuits is, they're all going to be contending for the same
0:01:09	bandwidth at the physical interface.
0:01:13	So this means with frame relay when we are doing shaping
0:01:16	we have two levels of hierarchy.
0:01:18	We have a shaping rate that is going to apply to the virtual
0:01:21	circuit, then the interface queue that is going to
0:01:25	apply to the actual physical serialization of the interface.
0:01:32	So regardless of what we configure the per virtual
0:01:34	circuit rate as, it doesn't make sense to ever exceed
0:01:39	what the actual physical rate of the transmit ring is.
0:01:43	Now what I mean by this if Router 5's physical interface here
0:01:47	serial 0/0/0
0:01:50	was a T1 interface
0:01:52	that is clocked at 1.536 Megabits per second
0:01:58	which essentially is 24 channels of DS0
0:02:02	where DS0 is 24 or excuse me, 64 kilobits per second
0:02:09	it means that the 1.5 Megs this is the physical rate of the interface
0:02:14	or essentially the access rate.
0:02:18	Therefore regardless of what we configure the shaping on the
0:02:20	individual circuits, it doesn't ever make sense to go over
0:02:24	1.5 Megabits per second.
0:02:29	Now inside this 1.5 Meg rate, we could configure circuit
0:02:34	number 504 to be shaped to 512
0:02:38	we could configure 502 to be shaped to 256
0:02:42	and then for 501 and 503 to contend for the rest of the bandwidth.
0:02:49	Unfortunately, the disadvantage of doing frame relay traffic shaping
0:02:52	is there's no way to inform one circuit
0:02:56	about the transmission rate of another circuit.
0:03:00	So it means that if we configure the shaping,
0:03:02	and say that for circuit number 504, we're enforcing
0:03:06	a rate of 512 k
0:03:08	regardless of whether circuit 502 is actually using its
0:03:12	bandwidth of 256
0:03:14	there's never a situation where 512 is ever going to be
0:03:18	exceeded for circuit number 504
0:03:23	So essentially there's two schools of thought for this
0:03:25	type of design that either we could configure the shaping
0:03:29	to enforce the rate to make sure that there's not any
0:03:31	over subscription or we could just leave shaping completely
0:03:35	off and let the individual circuits burst to the maximum
0:03:39	of the serialization rate.
0:03:41	But again, the issue that we run into is that they are all
0:03:44	contending for the same interface's physical hardware queue.
0:03:50	So even though they're different virtual circuits
0:03:52	since they're still sharing the same physical interface
0:03:54	they're all going to end up put into one final queue
0:03:57	before it actually goes out onto the link.
0:04:02	Now implementation wise, there's two different methods that
0:04:04	we can use to accomplish frame relay traffic shaping
0:04:07	the legacy mechanism that's going to use the frame relay
0:04:11	map class which again, not to be confused with the
0:04:15	class map that is used for the module of the quality of service
0:04:18	or shaping inside the MQC.
0:04:22	Now the main difference between the two is the
0:04:25	usage of the frame relay traffic shaping command.
0:04:29	When this is applied on the main serial interface
0:04:32	it means that we are doing legacy frame relay traffic shaping.
0:04:37	This also implies that the PVC's shaping rate
0:04:41	would need to be defined under the map class.
0:04:45	So under the map class, we specify the frame relay
0:04:48	CIR, we could specify the BC, the BE
0:04:52	then we could do adaptive shaping either to BECN
0:04:55	Backwards Explicit Congestion Notification
0:04:58	the FECN, the Forward Explicit Congestion Notification
0:05:02	or foresight which is an additional feature that the
0:05:08	frame relay switches in the transit network can support
0:05:10	to signal the end hosts or the actual end CPE devices like the routers
0:05:18	to signal them the conditions of the frame relay cloud.
0:05:21	Now regardless of what we configure the rate is
0:05:25	whatever we configure the BC, the BE, then we need to apply
0:05:28	the map class either to the circuit or to the interface.
0:05:34	The difference between them when we use the frame relay
0:05:37	class command, this is going to apply to the interface
0:05:40	and then inherently all circuits that are assigned to that interface.
0:05:46	If we apply the class command under the frame relay interface
0:05:49	DLCI, that is going to apply just to that individual circuit.
0:05:55	Now we looked at this before in our Layer 2 configurations
0:05:59	when we were dealing with the frame relay end to end keepalives
0:06:02	where the key point is that if we want separate rates for
0:06:05	different circuits, we need to make sure to apply the
0:06:08	classes to the circuits themselves, not to the
0:06:11	main interface.
0:06:14	So ultimately, when we're done when we look at the
0:06:16	show traffic shape
0:06:19	this is going to show us the individual shaped rates that are
0:06:21	applied to the different circuits.
0:06:23	If we don't manually configure a rate, then the CIR is going to
0:06:29	default to 56 k
0:06:30	The second option would be to use the HQF along with
0:06:36	legacy frame relay traffic shaping
0:06:38	which means that the shaped rate is still defined inside
0:06:43	of the frame relay map class
0:06:46	but inside of the map class, we are calling a service policy
0:06:52	where inside of the service policy we are then defining our
0:06:55	individual fancy queues.
0:06:58	So inside the shape rate we could do a bandwidth reservation
0:07:01	for web traffic, we could do prioritization for voice
0:07:06	we could do marking, we could do random detection
0:07:09	so basically any of the features that we could already do
0:07:12	in the hierarchical queuing framework, then we can essentially
0:07:16	do it inside of the legacy frame relay traffic shaping.
0:07:19	Now one key point to note here is that the maximum
0:07:22	bandwidth that is reservable based on either the priority command
0:07:28	or the bandwidth command, this is now going to be controlled
0:07:31	by the frame relay minimum CIR
0:07:33	which is the normal CIR divided by two.
0:07:39	So minCIR is normally used when you're doing a adaptive shaping
0:07:42	to either BECN or FECN
0:07:45	so the backwards explicit or forwards explicit congestion notifications
0:07:51	which traditionally was the value that was guaranteed by
0:07:53	the service provider, the minimum CIR
0:07:56	where the CIR is the average rate that the shaping algorithm is
0:08:00	trying to achieve.
0:08:03	So the big thing that's confusing here with frame relay traffic shaping
0:08:08	is that the terms that Cisco shaping algorithm use
0:08:12	is different than what the service providers would
0:08:14	describe the circuit as
0:08:16	where the service provider says the CIR, the Committed Information Rate
0:08:21	is what you're actually guaranteed on the circuit
0:08:24	this is what Cisco shaping algorithm says is the minimum CIR
0:08:28	where they're saying that there's a disconnect potentially
0:08:31	between what you're actually guaranteed and what you're
0:08:34	trying to average where the CIR simply controls what you're
0:08:37	averaging, not what the actual circuit can support.
0:08:43	Now once we apply the module of the quality of service onto the
0:08:47	legacy frame relay traffic shaping, the interface itself
0:08:51	becomes two separate first in first out queues
0:08:55	and the reason it does this is to allow us to do fragmentation
0:08:59	and interleaving. Now what fragmentation means
0:09:03	is just like an IP fragmentation where the router is going to
0:09:06	take our final packet size and break it down into multiple
0:09:11	smaller packets.
0:09:12	But in the case of frame relay, we're doing this at a Layer 2
0:09:15	basis as opposed to our normal Layer 3 IP fragmentation.
0:09:22	Once we break the packets up into separate fragments
0:09:24	we can then take our priority packets and interleave them
0:09:28	or basically send them between the non-priority packets.
0:09:33	So the idea behind fragmentation and interleaving is that when we
0:09:37	look at the amount of time it takes to serialize the traffic
0:09:41	on a per interval basis
0:09:44	we want to make sure that the voice packets do not have
0:09:47	to wait more than 1 TC in order to be sent.
0:09:53	And the big reason that this is a problem is that when we
0:09:56	look at speeds that are lower than 768 k, the serialization
0:10:00	delay does start to affect how long it's going to take to send the
0:10:04	voice packet on the interface.
0:10:08	Now whether this is really going to be an issue or not
0:10:10	within the routing and switching lab exam, it's probably not
0:10:14	as likely because most of this stuff is going to be reserved
0:10:17	for the CCIE Voice
0:10:18	where the actual detailed calculations of the QoS
0:10:22	that you would need to take into account what is the
0:10:25	actual voice codec and what is the overhead for that
0:10:30	then whether you're doing RTP header compression
0:10:33	and then calculate what is the fragment size that you need
0:10:36	over frame relay to make sure that your voice payload
0:10:40	does not take more than one time committed interval
0:10:44	in order to be serialized on the interface.
0:10:48	But in our case just like the legacy traffic shaping
0:10:52	or the -- not the legacy traffic shaping -- the generic traffic shaping
0:10:55	where the burst committed interval is automatically
0:10:59	going to be calculated for us.
0:11:02	So as long as we specify what the average rate is
0:11:06	then the module of the quality of service is automatically
0:11:09	going to calculate the rest of the values.
0:11:14	Now the other option for this is the module of the quality of service
0:11:17	based frame relay traffic shaping where the main difference
0:11:21	is now the shaped rate is defined under the service policy
0:11:27	not inside the map class.
0:11:30	When we apply this to the interface, it still needs to be
0:11:33	referenced from a frame relay map class
0:11:36	but we do not need to issue the frame relay traffic
0:11:39	shaping command and there's essentially no parameters
0:11:43	that are configured inside of the map class with the exception
0:11:47	of the service policy itself.
0:11:51	So when you're deciding which one you're going to use
0:11:53	either the legacy frame relay traffic shaping or the MQC
0:11:57	based frame relay traffic shaping, the main difference is
0:12:00	where do you need to configure the shaping. If you're configuring the
0:12:04	shaping under the map class, then you're doing legacy frame
0:12:07	relay traffic shaping. If you're configuring the shaped rate under
0:12:12	the policy map, then you're doing MQC based frame relay traffic shaping.
0:12:17	So let's look at a case here where we're doing both
0:12:22	on Router 2 we will do the legacy frame relay traffic shaping
0:12:29	on serial 0/0 that's going to be for circuit number 205
0:12:34	that goes out towards Router 5
0:12:37	where for Router 5, as we go back to these other circuits
0:12:41	205, 503, 501, 504
0:12:44	these are going to be applied using the module of the quality of service's
0:12:47	frame relay traffic shaping.
0:12:49	So first on Router 2, we'll go to global config and define
0:12:55	the map class which again, not to be confused with the
0:12:59	class map as map class is specifically for frame relay traffic shaping.
0:13:06	So we'll give the class a name, I'll call this DLCI205
0:13:11	and inside the map class we need to specify what is the
0:13:14	frame relay CIR
0:13:18	If we do not specify the CIR on a particular circuit
0:13:21	again, this is going to default to 56 k once frame relay traffic
0:13:25	shaping is turned on.
0:13:28	So let's assume in this case between Router 2 and
0:13:30	Router 5 that we're going to shape to a rate of 512 k
0:13:36	We could see the maximum is 45 megabits per second
0:13:39	because that's the maximum speed that frame relay supports
0:13:42	is a DS3 interface.
0:13:48	So the CIR just like the generic traffic shaping
0:13:51	in the module of the quality of service this is a bit per second value.
0:13:57	Now when you look at the difference between the policing
0:13:59	and the shaping, make sure that you use the context sensitive
0:14:02	help on the command line because some of these options
0:14:05	take the configurations in bits
0:14:08	some of them take them in bytes
0:14:11	and ultimately depending on what particular values the question is
0:14:14	asking for, it's going to be different whether the IOS is
0:14:19	taking the units in bits or bytes.
0:14:24	So on Router 2 here, we'll say that the CIR is 512000
0:14:28	we're not going to add any other arguments here.
0:14:33	At the interface level, we'll now say frame relay traffic shaping
0:14:39	if we look at the show traffic shape now
0:14:44	it says that there's five different circuits
0:14:47	that have traffic shaping applied
0:14:50	and they all have a target rate of 56000
0:14:54	so this again is essentially the default CIR that is applied down
0:14:57	to all of the individual PVCs
0:15:01	In my particular case, I want to apply this class to circuit number 205
0:15:06	which is located on the sub interface serial 0/0.1
0:15:13	Now since there's only one circuit on this link,6
0:15:17	it's not going to make a difference whether I say
0:15:19	frame relay class DLCI205
0:15:23	or I go under the frame relay interface DLCI 205
0:15:27	and then specify the class
0:15:31	where technically you can do both and the one at the
0:15:35	individual PVC level is going to take precedence over the
0:15:38	one that's configured at the interface level.
0:15:41	But again, since there's only one particular circuit on this link
0:15:45	it's not going to make a difference whether I apply
0:15:48	it on the link itself or specifically under the circuit.
0:15:52	We should see now it says that the target rate is 512000
0:16:01	The excess burst is zero by default
0:16:05	and the interval just like in generic traffic shaping is
0:16:09	automatically going to be calculated based on the
0:16:11	CIR and what the BC is.
0:16:16	So we would see if we went to the map class
0:16:21	map class frame relay DLCI 205
0:16:26	and it changed the CIR, if we said frame relay CIR and let's
0:16:30	say we said it to the maximum which is 45 Megs
0:16:34	If we look at the show traffic shape,
0:16:38	we can see now for 45 million bits per second
0:16:41	the interval size changes down to 16
0:16:47	so essentially as the target rate or the CIR goes up
0:16:51	it means the TC must go down
0:16:54	because to send more traffic per second,
0:16:58	it means that we need more intervals per second.
0:17:01	Now it doesn't really matter what the interval size is or what
0:17:05	the sustained burst is
0:17:07	unless we care about the specific delay that is going to be
0:17:11	incurred when we actually serialize a packet onto the interface.
0:17:15	So if we were configuring our CIR again at 512000
0:17:20	it says that this interval size is 125 milliseconds
0:17:28	which essentially means that we have eight intervals per second.
0:17:33	So if we were to take the target rate which is 512000
0:17:36	and divide it by eight
0:17:38	it means that the default burst committed is 64000 bits.
0:17:43	Now in this output for show traffic shape, it doesn't actually
0:17:46	show 64000 bits here under sustained
0:17:49	this is essentially just a cosmetic bug.
0:17:52	So it's showing the wrong value than it's actually used there.
0:17:56	The BC is calculated based on the target rate
0:17:59	and the interval size.
0:18:01	If the interval size is a 125 milliseconds
0:18:06	if we were to take a thousand milliseconds which is one second
0:18:09	divided by 125
0:18:11	it means there's eight intervals per second
0:18:16	if we then take 512000 divided by eight
0:18:20	that's how much traffic we're sending per interval
0:18:23	in order to achieve the average over the second.
0:18:28	This would then imply if I were to divide this in half
0:18:31	and say that my frame relay BC was half of what it was
0:18:37	before, what should happen to the interval size?
0:18:42	If I'm now sending half as much traffic per interval
0:18:47	it would then mean we need twice as many intervals per
0:18:51	second in order to achieve the same average, so if we
0:18:54	look at the show traffic shape, we should see the interval
0:18:57	is going to be 125 divided by two
0:19:00	which it is somewhere about 62, 62.5
0:19:05	If I were to cut this in half again let's say down to 16000
0:19:10	it's going to be somewhere around 31, 32
0:19:13	so again, the time committed is going to be implicitly calculated
0:19:18	based on what the average rate is and what is the burst committed.
0:19:22	If we want to give us excess credit
0:19:26	so that if we did not send enough traffic in one individual interval
0:19:29	I want to make up for it in later intervals
0:19:32	we would set the frame relay BE
0:19:37	but again, it doesn't make sense from the queuing algorithm's
0:19:40	point of view to make the BE plus the BC
0:19:46	be more than the physical clocking of the link.
0:19:51	So technically, I could set the burst and excess to be
0:19:53	whatever I want. I could set it to be 16 million
0:19:58	but it doesn't make sense to do this because even if I
0:20:01	built up that credit, the transmit ring of the interface is
0:20:04	not going to be able to support that amount of transmission.
0:20:09	So typically when you look at the maximum BE value whether this
0:20:12	is related to frame relay traffic shaping or generic traffic shaping
0:20:16	the maximum BE would be the difference between the physical
0:20:21	clocking and what you are averaging, so essentially the
0:20:26	access rate minus the CIR
0:20:28	on a per interval basis.
0:20:32	So in this particular case, if we said that the interval size
0:20:35	was 31 milliseconds
0:20:38	where if we took a thousand milliseconds divided by 31
0:20:44	it means we have 32 intervals per second.
0:20:48	In 32 intervals, if I send 16 thousand bits per
0:20:52	interval, it means I'm averaging 512 thousand bits per second.
0:21:00	Now if I knew that the physical link clocking was 1536000
0:21:08	so again, this would be a true T1 that is 64 k
0:21:14	times 24 channels, so it's 24 channels of DS 0
0:21:18	where DS 0 is 64 kilobits per second
0:21:21	64 times 24 is 1536
0:21:28	so if I knew that the physical link was clocked at 1536000 bits per second
0:21:34	and I'm already averaging
0:21:38	it means that this is how much space is left over
0:21:40	based on the physical serialization.
0:21:43	If I were to look at this on a per interval basis, so then
0:21:47	divide it by 32
0:21:48	it means that logically the maximum BE
0:21:53	would be 32 thousand.
0:21:57	I could technically configure it to be anything smaller than that
0:22:00	but it doesn't make sense to go larger than that
0:22:03	because the serialization physically is not going to support it.
0:22:08	Now again, if I wanted to apply specific queuing inside of the
0:22:11	shaped rate, then I'm going to call a service policy from
0:22:16	inside of the map class. If I don't want to do anything
0:22:19	else specific to the module of the quality of service
0:22:22	then this is the only configuration I need to do
0:22:24	is just define the map class
0:22:29	then apply the map class either to the interface or to the
0:22:32	circuit level.
0:22:34	Ok, but again, this frame relay BE is not really going to make
0:22:36	sense in this case because it's exceeding what the physical
0:22:39	clocking of the link would be.
0:22:43	If we look at the show traffic shape
0:22:47	again, it says for our target rate of 512 k
0:22:50	with the sustain bits per interval of 16000
0:22:54	it means that we have a 31 millisecond interval.
0:23:00	This byte limit here, this is going to be the burst committed
0:23:03	in bytes. Now again, the other variation for this
0:23:07	would be to configure the shaping under the service policy
0:23:13	then call the service policy from the map class.
0:23:16	So that's going to be considered MQC based frame relay traffic shaping
0:23:22	when the shaper is defined inside the MQC, not defined
0:23:25	under the legacy map class.
0:23:29	So let's say on Router 5 we want to apply the same
0:23:32	type of rate that's going down to Router 2
0:23:34	we want to apply 512 k
0:23:37	so we'll configure a policy map
0:23:41	We'll say shape 512
0:23:46	say 512 that says for class class-default
0:23:50	apply an average shaper
0:23:54	for 512000
0:24:03	Next I need to define the map class
0:24:06	say map class DLCI 502
0:24:12	map class frame relay
0:24:13	DLCI 502
0:24:16	and from here I'm going to call the service policy
0:24:20	that is shape 512
0:24:25	and this is applied output.
0:24:32	Then at the link level if we look at where the particular
0:24:36	DLCI is if we show frame relay PVC
0:24:42	and look for the -- PVC include capital DLCI
0:24:50	it says that circuit number 502 this is applied on the main interface.
0:24:58	So now I essentially have two options.
0:25:00	I could go to the main interface and say
0:25:03	so interface serial 0/0/0
0:25:06	I could say frame relay class
0:25:11	then the name DLCI 205
0:25:13	which means this is going to apply to all of the circuits.
0:25:18	Now if I do not want this to apply to routers 1, 3 and 4
0:25:23	then I would not apply it to the interface
0:25:27	I would go to the frame relay interface dlci
0:25:33	and say class DLCI 502
0:25:38	The difference now being instead of saying show traffic
0:25:41	shape, I'm going to do my normal module of the quality of service
0:25:44	verification which is the show policy map interface ser0/0/0
0:25:52	Now what we should notice is different here
0:25:55	is that when the policy is applied, it says it's applied to the
0:25:59	interface, but specifically to that individual circuit.
0:26:06	So this is the individual circuit's shaping queue
0:26:09	or the per VC queue
0:26:12	as opposed to the one physical interface queue that all of the
0:26:17	DLCIs are contending for.
0:26:21	So the difference then becomes do I want to apply the shaper
0:26:26	as an aggregate to all of the PVCs or do I want to
0:26:31	shape the PVCs individually.
0:26:34	And it really depends on what the design of the
0:26:36	frame relay network is, so let's say that on Router 5
0:26:40	we know that the physical clocking in the link is T1
0:26:43	so it's 1.536 megabits per second.
0:26:49	If the service provider says that you're allowed to send
0:26:51	768, but I don't care of which circuits you send it on
0:26:57	as long as your aggregate is never larger than 768
0:27:02	This means that if I applied a generic traffic shaping
0:27:06	policy directly to the interface, it would say this is applying to
0:27:11	the interface's queue, not the individual virtual circuit queues.
0:27:17	So essentially in that case, circuits 501, 2, 3 and 4
0:27:20	would all be contending for the same 768
0:27:26	where in this specific configuration since the shaper goes onto the
0:27:29	individual DLCI, DLCI 502 is saying
0:27:34	my rate is 512 k
0:27:36	I'm not contending with the other circuits for that rate.
0:27:42	But again, this is all going to be based on the physical
0:27:46	serialization of the link and then the rate at which
0:27:49	the provider is policing inbound.
0:27:53	So typically the outbound shaping rate would want to
0:27:56	match the provider's inbound policing rate
0:27:59	because if they're policing at 256 k, it doesn't make sense
0:28:03	to shape at 512 because we know half of the traffic is going to be
0:28:05	dropped. There's a question, "Is it possible to end up with both
0:28:09	MQC and legacy traffic shaping inadvertently applied?"
0:28:12	The parser actually will prevent you from doing this.
0:28:17	It'll give you an error message saying that either
0:28:19	you cannot use the frame relay traffic shaping command or
0:28:22	you must use frame relay traffic shaping
0:28:25	so now on Router 5, if we show run interface serial 0/0/0
0:28:31	notice here that I do not have the frame relay traffic
0:28:34	shaping command configured.
0:28:39	I'll say not shut down there. So now let me say on
0:28:42	DLCI 502
0:28:45	I'm going to remove the class, then on the main interface
0:28:50	I'll say frame relay traffic shaping
0:28:55	then under the circuit, apply the class
0:29:05	If we look at the show policy map interface serial 0/0/0
0:29:12	the policy's not applied.
0:29:15	If we show run interface serial 0/0/0
0:29:20	the class is there
0:29:24	but the show policy map interface, it doesn't have any output.
0:29:28	So you'll see some versions will complain about it
0:29:30	this particular version didn't, but we can tell from the output
0:29:34	that it's not actually applied correctly.
0:29:36	So now if I remove frame relay traffic shaping
0:29:43	and show policy map interface
0:29:48	it should be applied. Ok, if we show run map class
0:29:53	service policy output shape 512
0:29:59	and I may need to remove this and reapply it.
0:30:01	Let's say show policy map interface serial 0/0/0
0:30:09	No it's not applied, so let me try removing it
0:30:17	so no class
0:30:21	and applying it again, so as I mentioned before
0:30:24	for any of these configurations, the final verification is always
0:30:29	going to be show policy map interface.
0:30:31	If that doesn't show the counters, it means that
0:30:34	either your policy is wrong or you have applied it wrong.
0:30:38	So it could be that your classification is wrong like your
0:30:41	match is not correct or you're referencing the wrong classes
0:30:45	or you have it applied to the wrong interface.
0:30:49	So in the case of frame relay, maybe you have it applied on the
0:30:52	sub interface where it's supposed to be on the main interface or vice versa.
0:31:08	So now we can see on Router 5 once I removed the policy
0:31:10	and then reapplied it, it does show that it's applied
0:31:12	on DLCI 502
0:31:16	So what's different about this config also is that the
0:31:20	other circuits that I did not apply the shaper on
0:31:24	there's no rate applied to them.
0:31:26	So they are only contending for the interface's
0:31:30	software queue, they do not have per virtual
0:31:33	circuit queues configured.
0:31:36	So technically they would be able to use up to the serialization
0:31:40	only circuit number 502 is now being limited to 512 k

Now Viewing

CCIE R&S Advanced Technologies Class v4.5
Title:	CCIE R&S Advanced Technologies Class v4.5
Duration:	81h 42m
The CCIE Routing & Switching Advanced Technologies Class is the first step in understanding CCIE level technologies and is a companion to the Advanced Technologies Lab Workbook. Each technology you need to know for the CCIE Routing & Switching lab will be described in detail using an instructor led hands on demonstration. The class consists of over 80 hours of in depth explanations and examples.
Get instant access to our entire library!
	Sign Up
Download this Course
$299.00	Add to Cart

Frame Relay Traffic Shaping (FRTS)

Create Bookmark