Are you a CCNP or CCIE student looking to challenge your perfect knowledge of Catalyst switchport commands?
Take the latest SWITCH Command Recall exam by clicking the link below. Good luck – and let us know how you scored in the comments area of this post.
Remember to read, AND TYPE, very carefully! I failed my first attempt due to just plain sloppiness. 
SWITCH Command Recall Exam – L2/L3 Ports
For success designing and implementing Cisco Wireless solutions, a CCNA Wireless student needs to be familiar with the options for various wireless topologies. Two were defined by the 802.11 committees, while others were made possible thanks to excellent developments by wireless vendors like Cisco Systems.
While not popular, it is possible to have wireless devices communicate directly with no central device managing the communications. This is called the Ad Hoc network topology and is one of the two topologies defined by the 802.11 committees. In the Ad Hoc type topology, one device sets a group name and radio parameters, and another device uses this information to connect to the wireless network.
This type of wireless network topology is referred to as an Independent Basic Service Set (IBSS). This is easy to remember as we know the devices are working independently of an access point (AP).
When an access point is used to create the network, the official term is network infrastructure mode for the network. There is a Basic Service Set (BSS) setup that uses a single access point, or the Extended Service Set (ESS) that uses multiple access points in order to extend the reach of the wireless network.
Access points running in the network infrastructure mode are often described as a cross between hubs and bridges. The APs act like hubs in that they service a single collision domain and must operate in a half duplex fashion. Fortunately for the AP, it does possess intelligence beyond a simple hub, however, and processes frames and forwards these based on MAC address information.
Perhaps your network contains clients that you want to connect to the wired infrastructure but these devices are in a location where it is difficult to extend actual physical wires. This is the perfect time to have the access point function as a workgroup bridge. The access point extends the wired LAN out to these wireless devices.
In this case, the job of the access point is to strengthen the wireless signal from another access point. Perhaps it is strengthening the signal of an access point acting in the workgroup bridge role. When repeaters are used, there must be overlap in the access point cell coverage. In order to provide optimal performance, the overlap needs to be 50%.
These access points are typically used within a few miles of each other and are used to connect two or more LANs. The Cisco technology allows the configuration of point-to-point or point-to-multipoint topologies.
The outdoor mesh network features an access point acting as a root device. This AP has an Ethernet connection to a distribution network and it associates with a Wireless LAN Controller (WLC). The other access points in the design act as mesh APs. All these devices need is power and can act as repeaters as required in order to allow all devices to reach the root access point. While the IEEE is working on a mesh standard called 802.11s, the Cisco solution features Adaptive Wireless Path Protocol (AWPP). AWPP promotes the mesh devices finding the best path back to the root AP.
We wanted to provide our students with advance notification of some upcoming online classes here at INE. While we hope to see many students in the actual live events, on-demand versions will indeed be made available the week following the live, online version.
Join the INE Experts Online in September and October
September 13 – 17th, 2010 CCNA Wireless 5-Day Bootcamp
September 15 – 17th, 2010 Security for CCIE R&S Candidates 3-Day Bootcamp
September 29 – Oct 1, 2010 IPv4/IPv6 Multicast 3-Day Bootcamp
October 4 – 9th, 2010 Online 6-Day CCIE R&S Bootcamp with K. Barker and A. Sequeira
As you may have noticed, INE does a wide variety of training in the Cisco space. 
This blog post goes out to all those folks who have recently begun their Cisco training.
This month we delivered new live classes on CCNA and CCNP. We are excited for and encourage our students at every level in their journey. In that light, we have gathered a collection of Videos Answers, targeted at the CCNA level, with a few topics leaking into security and CCNP. These videos were primarily created as quick (under 10 minutes each) Video Answers to questions that various learners have had.
Take a look at the list of topics, and if there are 1 or 2 you feel you would benefit from, feel free to enjoy them.
Here are a few of the topics (in no particular order):
and more…
You can view them using this link here on YouTube
You may also use this link: http://www.youtube.com/user/Keith6783
If you want to look further into learning, we offer a full suite of self-paced workbooks, videos, and interactive learning tools.
Best wishes, and happy studies-
Keith
Congratulations to the winners of the CCNA Live Bootcamp.
If your email address is listed below then you will be enrolled into the CCNA Live Bootcamp scheduled to start Monday, August 9th at 9:00 a.m. PDT. You will receive an additional email from your bootcamp coordinator, Marla Horstkotte (mhorstkotte@ine.com), confirming your enrollment. You will also receive the recorded version of the bootcamp once it is completed.
The winners are:
cret###an@gmail.com
en###5@itelgua.com
eu###ashkin@gmail.com
vr###om@gmail.com
esla###iny@gmail.com
A Special Offer From INE
We would like to thank everyone who signed up for the opportunity to win a seat in the upcoming CCNA Live Bootcamp. Due to the overwhelming demand, we would like to extend you an offer to purchase this excellent class for 50% off. Offer is good until Monday, August 9th and includes both the live class and the recorded class-on-demand version. Use discount code LIVECCNA when you purchase the CCNA Live Bootcamp. Even if you are unable to attend the live version of this class, this is a great opportunity to get the class-on-demand for only $247.50!
Looking to pass your CCNA exam? Or you are a CCNP/CCIE candidate looking to get a better understanding of the fundamentals. Starting August 9th at 9:00 a.m., we will be running a live on-line CCNA bootcamp covering both the ICDN1 and ICDN2 exams! More information on this class can be found here.
We will be selecting five lucky winners to attend the live class free of charge. Just sign-up and confirm your email address below. This is a great opportunity to get the best training in the world absolutely free, with no strings attached. We will notify the five lucky winners on Friday, August 6th.
Update: Winners Selected!
Are you wondering what the month of August 2010 will bring for INE fans?
Try all new, online bootcamps in the following disciplines:
Watch the blog and your email for all of the exciting new details.
Join the INE Experts Online in August
Thank you to all those who have submitted questions and comments to our blog and our CCIE Instructors. If you have a question, please email them to blog@ine.com.
Question 1:
Can anyone explain what is VPN intercept?
–
Bhavik Joshi
VPN Intercept can mean a few different things, depending on the specific context.
One interpretation is from a driver perspective, where a VPN connection breaks the binding between TCP/IP and the physical interface, acting as a shim. See also:
http://www.informit.com/articles/article.aspx?p=25042
Another meaning can be in regards to intercepting SSL traffic.
See also:
http://www.howtoforge.com/ssl_vpn_one_time_passcodes_mutual_authentication
PPTP attacks:
http://www.sans.org/security-resources/malwarefaq/pptp-vpn.php
Cisco – VPN-based IPv4 Lawful Intercept Taps -
https://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/lawful_intercept/76LIch2.html#wp1058552
Answered by: Marvin Greenlee, CCIE #12237
Question 2:
Dear Valuable Technical Teachers and Friends,
First of all , i wish and thank you for your great support to those who are
all preparing Network studies. I’ve completed my CCNA two years back.Now am
preparing for next step. At this point, i have bit confusion of deciding
whether can i do CCNP or CCIE(R&S). I would like to reach a top level in
Cisco Networking technology.So am requesting your suggestions, which is best
for me.Also can you suggest any good simulators to improve my practical skills.
–
Thanks,
K.Saleem Jaffer
Thanks for the question. Having the CCIE certification makes for an excellent stepping stone in a technical career. An important aspect to successfully passing the CCIE lab exam, is a very solid understanding of all the technologies involved. A great way to prepare for this is through the CCNP level of studies. If a person chooses that path, they would do well to take time to learn the technologies while studying CCNP, and not have the feeling of just learning enough to pass a CCNP written exam. By truly learning the core technologies in CCNP, it will serve as a springboard into the CCIE studies. Many candidates waste large amounts of time in complex configurations, because they are lacking the basic understanding of the protocols and technologies that make up the scenario. I would recommend a 1-2 yr plan, that begins with CCNP, carries into CCIE studies, and end with you attaining your CCIE. Best wishes in your studies and journey.
Keith
Answered by: Keith Barker, CCIE #6783
Question 3:
Hi.
would u mind please, explaining the benefit of command “area x nssa default-information-originate” ? i know how we use it but i don’t know its benefit? and do we use this command on ALL of the routers or just ABR? when we don’t use this what will happen?
thanks a lot
timaz mohsenzadeh
The benefit of having a default route is that you have somewhere to send traffic when you don’t have more specific information.
One point of using stub areas in OSPF is to minimize the information in the OSPF database.
With a stub area, you will have some OSPF routes, but not external routes (E1/E2) in the stub area. So, if somewhere else across the topology, there is redistribution happening, the device in the stub area won’t know about the redistributed networks. Having a default route out to the ABR can be all that a stub area needs, if the ABR has the routing information to send the traffic forward to the destination.
The R&S Advanced Technologies Class section on OSPF area types shows the difference of not having this command, as well as looking at the contents of the OSPF database.
Marvin
Answered by: Marvin Greenlee, CCIE #12237
Question 4:
Hi everybody
I have a question regarding ISDN Backup. I have two cisco routers 800 (IOS 12.4(15)T5) and 1600 (IOS 12.1(4)).
The 800 router is the primary link with SHDSL and the backup router is the 1600 with ISDN.
I have OSPF running between these two routers and HSRP. Now when the primary link (SHDSL) fails,
the Backup router (1600) should take over. How can I solve this problem. Or what is a suitable solution.
I have searched various forums and cisco, but I can’t find any sample according my example.
I am going to be an CCNA. But I guess there is much left to learn.Thanks for your help.
Regards Alen
Firstly, you dont need OSPF unless you have IGP requirements for other routers behind the border rouers (the 800 and the 1600). You only need HSRP running between the routers and static reliable route on the primary gateway (SHDSL). Next, configure HSRP to track the static route object in the primary router, and lower the priority when the static route fails. Your Cisco 800 should support this functionaly, and the 1600 only needs to know if the active router changes. So here are the steps
1) Create an IP SLA object in the 800 router, pinging your provider’s IP (”ip sla” commad)
2) Create an object tracking the state of IP SLA ping object (”track” commad)
3) Create a static default route in the 800 pointing to you ISP and tracking the object above
4) Configure static default route in the 1600
5) Configure HSRP so that 800 is the primary gateway
6) Configure the HSRP to track the object you created before (”standby XX track” command)
7) Ensure HSRP is configured to preempt so primary router may kick back in when the link recovers
This will ensure automatic switchover upon the lost of primary connection and automatic retun back to normal. You may want to read
http://www.cisco.com/en/US/docs/ios/12_3/12_3x/12_3xe/feature/guide/dbackupx.html
for more information on reliable static routes.
Answered by: Petr Lapukhov’s, CCIE #16379
Sometimes its the simple things that are struggled with. RIP is one of those. Most CCIE candidates understand that we can change the interface or global parameters for updates, unicast, multicast, etc. What does take some time, is figuring out the global timers, especially if a person is not sure how they interact.
In this post, we will address the RIP process level timers for update, invalid, hold down and flush. I don’t want you to sleep during this, so we will save that one for later.
Timers Basic, all in seconds:
Update: how often to send updates in seconds
Invalid: how many seconds, since seeing a valid update, to consider the route invalid, and placing the route into hold down
Hold Down: Once in hold down, how long (in seconds) to “not believe” any equal or less impressive (worse) route updates for routes that are in hold down
Flush: how many seconds, since the last valid update, until we throw that route in the trash (garbage collection for un-loved non-updated routes)
Here is our topology. Keep your attention on R2, and that will be the focal point for this lesson.
Let’s set up some unique values, so we can see the results.
Defaults are:
Update: 30
Invalid: 180
Hold Down: 180
Flush: 240
We will use 30, 40, 10 and 90 respectively.
R2(config)#router rip R2(config-router)#timers basic 30 40 10 90
We can see the results of our changes with show ip protocols.
R2#show ip protocols
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 23 seconds
Invalid after 40 seconds, hold down 10, flushed after 90
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv Triggered RIP Key-chain
FastEthernet0/0 2 2
FastEthernet0/1 2 2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
10.0.0.0
Routing Information Sources:
Gateway Distance Last Update
10.23.0.3 120 00:00:03
Distance: (default is 120)
We can see that R2 is learning 2 routes from R3, the 10.33.0.0/24 and 10.77.0.0/24 R2 received the last update 7 seconds ago, based on the output.
R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 4 subnets
C 10.12.0.0 is directly connected, FastEthernet0/1
C 10.23.0.0 is directly connected, FastEthernet0/0
R 10.34.0.0 [120/1] via 10.23.0.3, 00:00:07, FastEthernet0/0
R 10.77.0.0 [120/8] via 10.23.0.3, 00:00:07, FastEthernet0/0
Let’s enable debugging so we can see the play by play.
R2#debug ip routing IP routing debugging is on R2#debug ip rip RIP protocol debugging is on
Here is an update from R3. Notice the time stamp of 1:24:23. This will be the last one sent from R3. (Because we’ll configure R3 to go passive in a moment). Also, notice that we are sending and update as well. An update schedule of 30 seconds, based on the RFC for RIP, may be 30 seconds, + or – 5 seconds, to avoid synchronization. Let’s focus on the learned 10.77.0.0 network with a hop count of 8.
R2# 01:24:23: RIP: received v2 update from 10.23.0.3 on FastEthernet0/0 01:24:23: 10.34.0.0/24 via 0.0.0.0 in 1 hops 01:24:23: 10.77.0.0/24 via 0.0.0.0 in 8 hops R2# 01:24:24: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2) 01:24:24: RIP: build update entries 01:24:24: 10.23.0.0/24 via 0.0.0.0, metric 1, tag 0 01:24:24: 10.34.0.0/24 via 0.0.0.0, metric 2, tag 0 01:24:24: 10.77.0.0/24 via 0.0.0.0, metric 9, tag 0 R2# 01:24:27: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2) 01:24:27: RIP: build update entries 01:24:27: 10.12.0.0/24 via 0.0.0.0, metric 1, tag 0
After the update from R3, learned on Fa0/0, I used the passive-interface default command on R3 inside of the router rip process. While we wait for the invalid time to occur, due to the missing routes, we can entertain ourselves by seeing updates being sent from R2, at 30 second intervals.
R2# 01:24:53: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2) 01:24:53: RIP: build update entries 01:24:53: 10.23.0.0/24 via 0.0.0.0, metric 1, tag 0 01:24:53: 10.34.0.0/24 via 0.0.0.0, metric 2, tag 0 01:24:53: 10.77.0.0/24 via 0.0.0.0, metric 9, tag 0 R2# 01:24:56: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2) 01:24:56: RIP: build update entries 01:24:56: 10.12.0.0/24 via 0.0.0.0, metric 1, tag 0
It has been 40 seconds since the last updates from R3, and 40 seconds was our invalid timer setting. (Our last update was 1:24:23, and now it is 1:25:03). The routes enter hold down, which means the router will not believe any new updates regarding these routes. Hold down is intended to assist in avoiding inaccurate routing by rumor information while the network converges. The exception would be if a route with a better (lower) metric was received by R2 for the 10.77.0.0, R2 would use it. (In our example, 10.77.0.0 had a metric of 8. If R2 learned about the 10.77.0.0 with a metric of 7 or lower from a neighbor, it would use it if learned during the hold down.)
R2# 01:25:03: RT: delete route to 10.34.0.0 via 10.23.0.3, rip metric [120/1] 01:25:03: RT: no routes to 10.34.0.0, entering holddown 01:25:03: RT: NET-RED 10.34.0.0/24 01:25:03: RT: delete route to 10.77.0.0 via 10.23.0.3, rip metric [120/8] 01:25:03: RT: no routes to 10.77.0.0, entering holddown 01:25:03: RT: NET-RED 10.77.0.0/24
R2 advertises a poisoned route for the networks in hold down. This is a triggered update, and not based on the normal 30 second update timer.
R2# 01:25:05: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2) 01:25:05: RIP: build flash update entries 01:25:05: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:05: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:05: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2) 01:25:05: RIP: build flash update entries 01:25:05: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:06: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0
R1, sends us a poison-reverse update, regarding the same networks. This intentionally overrides the split horizon rule which is in place on Ethernet interfaces by default.
R2# 01:25:08: RIP: received v2 update from 10.12.0.1 on FastEthernet0/1 01:25:08: 10.34.0.0/24 via 0.0.0.0 in 16 hops (inaccessible) 01:25:08: 10.77.0.0/24 via 0.0.0.0 in 16 hops (inaccessible) R2# 01:25:10: RIP: received v2 update from 10.12.0.1 on FastEthernet0/1 01:25:10: 10.34.0.0/24 via 0.0.0.0 in 16 hops (inaccessible) 01:25:10: 10.77.0.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Another normal update, being sent by R2, including the poisoned routes.
R2# 01:25:22: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2) 01:25:22: RIP: build update entries 01:25:22: 10.23.0.0/24 via 0.0.0.0, metric 1, tag 0 01:25:22: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:22: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:22: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2) 01:25:22: RIP: build update entries 01:25:22: 10.12.0.0/24 via 0.0.0.0, metric 1, tag 0 01:25:22: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:22: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0
While the routes are in hold down, the router still forwards packets to those networks, based on the last information that it last learned about how to reach those networks. The routes will show up as “possibly down”.
R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 4 subnets
C 10.12.0.0 is directly connected, FastEthernet0/1
C 10.23.0.0 is directly connected, FastEthernet0/0
R 10.34.0.0/24 is possibly down,
routing via 10.23.0.3, FastEthernet0/0
R 10.77.0.0/24 is possibly down,
routing via 10.23.0.3, FastEthernet0/0
So were is the removal of the hold down. The timer was only 10 seconds? Better late than never. Even though the hold down timer was set to 10 seconds, the hold down timer has to expire and then the next poisoned route received causes the routes to be removed from hold down. Our routes went into hold down at 25:03, it is now 25:36. Regardless of the hold down timer setting, if we didn’t receive any poisoned updates from neighbors, the hold down would stay until the flush timer removes the route completely.
R2# 01:25:36: RIP: received v2 update from 10.12.0.1 on FastEthernet0/1 01:25:36: 10.34.0.0/24 via 0.0.0.0 in 16 hops (inaccessible) 01:25:36: RT: 10.34.0.0 came out of holddown 01:25:36: 10.77.0.0/24 via 0.0.0.0 in 16 hops (inaccessible) 01:25:36: RT: 10.77.0.0 came out of holddown
Even though the routes are done with their hold down, R2 still will show the route as possibly down, and will continue to do so until the flush timer expires.
R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 4 subnets
C 10.12.0.0 is directly connected, FastEthernet0/1
C 10.23.0.0 is directly connected, FastEthernet0/0
R 10.34.0.0/24 is possibly down,
routing via 10.23.0.3, FastEthernet0/0
R 10.77.0.0/24 is possibly down,
routing via 10.23.0.3, FastEthernet0/0
Another update clicks off, and then we approach the 90 second flush timer
R2# 01:25:49: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2) 01:25:49: RIP: build update entries 01:25:49: 10.23.0.0/24 via 0.0.0.0, metric 1, tag 0 01:25:49: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:49: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:49: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2) 01:25:49: RIP: build update entries 01:25:49: 10.12.0.0/24 via 0.0.0.0, metric 1, tag 0 01:25:49: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:49: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0
Based on the last valid update of 1:24:23, and now that it is 1:25:53, 90 seconds are up (flush timer) and the routes are deleted.
R2# 01:25:53: RT: delete subnet route to 10.34.0.0/24 01:25:53: RT: NET-RED 10.34.0.0/24 01:25:53: RT: delete subnet route to 10.77.0.0/24 01:25:53: RT: NET-RED 10.77.0.0/24
Now the routes don’t show up in the routing table either.
R2# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 2 subnets
C 10.12.0.0 is directly connected, FastEthernet0/1
C 10.23.0.0 is directly connected, FastEthernet0/0
If we use context sensitive help, we find one more parameter for the timers:
R2(config-router)#timers basic 30 40 10 90 ? <1-4294967295> Sleep time, in milliseconds
And we’ll save that one for another blog.
Best wishes,
Keith
This blog post is taken from the INE Resources area Understanding Frame-Relay Traffic Shaping presentation by Brian Dennis.
Overview
Frame-Relay traffic shaping is designed to control the amount of traffic the router sends out of an interface or out of a particular DLCI. Common reasons for Frame-Relay traffic shaping are:
Traffic shaping is designed to delay excess traffic, whereas policing is designed to drop excess traffic.
Terminology
The Formula
CIR, Tc, and Bc are related mathematically by the following formula:
CIR = Bc/(Tc/1000)
Notice the division of Tc by 1000 is used to convert milliseconds into seconds – the common measurement of CIR and Bc.
Example 1
Task:
The port speed of your serial interface is 192Kbps. You must shape the interface to send at 128Kbps.
Solution:
interface serial 0/0 encapsulation frame-relay frame-relay traffic-shaping frame-relay class MYCLASS ! map-class frame-relay MYCLASS frame-relay cir 128000
Example 2
Task:
The port speed is 384K. The router should send at a rate of 192K. The router should throttle down to 128K upon the receipt of BECNs. Allow the router to burst up to port speed.
Solution:
interface serial 0/0 encapsulation frame-relay frame-relay traffic-shaping frame-relay class MYCLASS ! map-class frame-relay MYCLASS frame-relay cir 192000 frame-relay be 24000 frame-relay mincir 128000 frame-relay adpative-shaping becn
Example 3
Task:
The port speed is 384K. The router should send at a rate of 128K. The router should throttle down to 64K upon the receipt of BECNs. Allow the router to burst up to port speed. Use a timing interval of 100 ms.
Solution:
interface serial 0/0 encapsulation frame-relay frame-relay traffic-shaping frame-relay class MYCLASS ! map-class frame-relay MYCLASS frame-relay cir 128000 frame-relay bc 12800 frame-relay be 25600 frame-relay adpative-shaping becn
