Well I am still here....chugging away with 30+ hours a week or so towards CCIE lab preparation. It IS hard work....I spent the last week going through the two preparatory Lab Books for Narbik's class that I am taking from micronicstraining.com in February. I am really looking forward to this! Since finishing those up though, I am back going through some INE Volume II labs. Did one on Tuesday...got killed with some Catalyst QoS stuff that I had never seen before, and some IP services items that I had just forgotten. I am going back through Vol I today on the portions where I was lacking. I was going to do a brief thing here on Cat QoS, but I found a blog article from the guys at INE that say it better than I ever could.
http://blog.ine.com/tag/per-vlan/
Showing posts with label QoS. Show all posts
Showing posts with label QoS. Show all posts
Thursday, January 6, 2011
Saturday, March 20, 2010
Last nights problem...
So my post last night was concerned with the fragment size noted in the show ppp multilink command. Well, I figured it out after about an hour of thinking; I then verified this morning. If you calculate the fragment size at 160 bytes, LFI is automatically going to halve that for a multilink with 2 attached links (because each additional link comprises that percentage of the overall bandwidth). Now the 72 number is funny, because it should be 80 right? Well, turns out LFI is smart enough to know 80bytes is the maximum packet size on that link in order to get the 10ms serialization time. It is also smart enough to know that using ppp you are going to have 6 bytes of ppp header overhead added to each fragment, as well as another 2 bytes to keep track of the fragments. So all in all, you have 72 + 6 + 2 = 80...and voila.
So check it out. I killed serial 0/1, and the bandwidth changes, but not the fragment size...proving that it calculated the fragment size, and then halved it because there were two equal bandwidth links. Nice. I still need to find out what the weight number is there...little research after this to find that out.
So check it out. I killed serial 0/1, and the bandwidth changes, but not the fragment size...proving that it calculated the fragment size, and then halved it because there were two equal bandwidth links. Nice. I still need to find out what the weight number is there...little research after this to find that out.
Friday, March 19, 2010
MLP Fragmenting and Interleaving
I mainly wanted to post this here for future reference, but I labbed up link fragmentation and interleaving on PPP links tonight. Cisco recommends this on links slower than 768kbps. MLP interleaving determines fragment size based on the configured link bandwidth, and what you as the network admin put as the delay within the ppp mulitlink fragment statement. For those math lovers out there, the formula is:
delay in seconds * configured bandwidth (i.e. 10ms on 128k line would be .01 * 128000 = 1280 bits/160bytes
Here was my interface configs:
Notice that the delay is put in ms in the ppp multilink fragment delay command. Here is some interesting output:
Now the bandwidth here is configured at 64kbps per interface, with 2 in the bundle...so 128k combined. I configured the delay at 10ms, so if we use our formula we should get: .01* 128000 = 1280/8 = 160 bytes. But what the duece! Why does it say right there that the frag size is 72? The QoS book says that it should be 160bytes as well. Now I know multilink PPP will split the traffic among the lines, but I am a bit confused. Any clarification on why this is happening would be awesome.
Oh and btw...to clear that pesky neighbor route thats comes with PPP anyways:
just issue the no peer neighbor-route on your multilink interface...annoying.
delay in seconds * configured bandwidth (i.e. 10ms on 128k line would be .01 * 128000 = 1280 bits/160bytes
Here was my interface configs:
interface Multilink1
ip address 172.16.12.2 255.255.255.0
fair-queue 10 512 14
ppp multilink
ppp multilink fragment delay 10
ppp multilink interleave
ppp multilink group 1
!
interface Serial0/0
bandwidth 64
no ip address
encapsulation ppp
ppp multilink
ppp multilink group 1
!
interface Serial0/1
bandwidth 64
no ip address
encapsulation ppp
ppp multilink
ppp multilink group 1
Notice that the delay is put in ms in the ppp multilink fragment delay command. Here is some interesting output:
Now the bandwidth here is configured at 64kbps per interface, with 2 in the bundle...so 128k combined. I configured the delay at 10ms, so if we use our formula we should get: .01* 128000 = 1280/8 = 160 bytes. But what the duece! Why does it say right there that the frag size is 72? The QoS book says that it should be 160bytes as well. Now I know multilink PPP will split the traffic among the lines, but I am a bit confused. Any clarification on why this is happening would be awesome.
Oh and btw...to clear that pesky neighbor route thats comes with PPP anyways:
C 172.16.12.1/32 is directly connected, Multilink1
just issue the no peer neighbor-route on your multilink interface...annoying.
Shaping...Cont.
I was having some trouble after looking at the output pasted in my previous post regarding shaping. What is the difference in these commands:
shape average 64000
shape peak 64000
Both have a byte limit of 2000 bytes per Tc, the same Tc, and average rate. The only differences were the target rate, and increment bytes. Well, the difference was truly in those numbers. Sure, both can send 2000 bytes per interval, if the bytes are in the bucket. But the true difference is that with the shape peak command, the higher number of bits can be realized. This is because of the increment bytes. When you shape to the peak you get Bc + Be replenished every Tc, letting you truly send 2000 bytes per interval. When you shape to the average you only get Bc every Tc, so under periods of high congestion you will only be able to send 1000 bytes, even though you have the ability to send 2000, because your Be bucket is empty, and only your Bc is getting filled back up every Tc. Once the network becomes a little less congested, you should once again be able to send those 2000 bytes. Thanks to great archived posts on techexams.net and INE's blog by Petr for clearing this up in my head.
I scheduled my exam for Tues. the 23rd.
shape average 64000
shape peak 64000
Both have a byte limit of 2000 bytes per Tc, the same Tc, and average rate. The only differences were the target rate, and increment bytes. Well, the difference was truly in those numbers. Sure, both can send 2000 bytes per interval, if the bytes are in the bucket. But the true difference is that with the shape peak command, the higher number of bits can be realized. This is because of the increment bytes. When you shape to the peak you get Bc + Be replenished every Tc, letting you truly send 2000 bytes per interval. When you shape to the average you only get Bc every Tc, so under periods of high congestion you will only be able to send 1000 bytes, even though you have the ability to send 2000, because your Be bucket is empty, and only your Bc is getting filled back up every Tc. Once the network becomes a little less congested, you should once again be able to send those 2000 bytes. Thanks to great archived posts on techexams.net and INE's blog by Petr for clearing this up in my head.
I scheduled my exam for Tues. the 23rd.
Thursday, March 18, 2010
Shaping--Part 2
Just following up a bit after my last post. Remember I ended up shaping to the average with 64000 bps as my shaping rate? I ended up with a policy that looked like this:
Now I went in a did a bit of reconfiguration. Heres what I did:
Now look at the output of a show policy-map interface:
So here you can probably see some differences from above. Right off the bat you should notice that the target rate is double what we had originally configured! Our bucket of tokens now is Bc + Be, instead of just Bc in our previous example. We get our target shaping rate from the following formula:
Rate = configured rate(1 + Be/Bc) or 64000 (1+(8000/8000)) or 64000(2)....128
So essentially this guy is configured to send up to 2000 bytes (8000 bits x 2) each 125ms interval (if the bucket(s) have that many tokens of course!). But also notice the increment bytes in this example. They are double what they were in the previous example. This is because when you shape to the peak, Bc + Be are going to be replenished each Tc.
Now I went in a did a bit of reconfiguration. Heres what I did:
R2(config)#policy-map shape_all
R2(config-pmap)#class class-default
R2(config-pmap-c)#no shape average 64000
R2(config-pmap-c)#shape peak 64000
Now look at the output of a show policy-map interface:
So here you can probably see some differences from above. Right off the bat you should notice that the target rate is double what we had originally configured! Our bucket of tokens now is Bc + Be, instead of just Bc in our previous example. We get our target shaping rate from the following formula:
Rate = configured rate(1 + Be/Bc) or 64000 (1+(8000/8000)) or 64000(2)....128
So essentially this guy is configured to send up to 2000 bytes (8000 bits x 2) each 125ms interval (if the bucket(s) have that many tokens of course!). But also notice the increment bytes in this example. They are double what they were in the previous example. This is because when you shape to the peak, Bc + Be are going to be replenished each Tc.
QoS on a Catalyst 2950
Well, hacked away using some commands on a 2950 today, and pushed through the QoS exam guide by Wendell Odom for the second time (this time hand-writing notes). I feel really comfortable now with the theory, and am trying to apply some hands-on training. Too bad there are not that many QoS labs guides out there. Here's what I did...I'll try to explain along the way:
This is a simple...trust the cos values sent by the ip phone if it is discovered on the port using CDP version 2. The switch here is telling it to overwrite packets sent from any connected pc with a COS of 0, or best effort.
Here we are trusting the COS markings that come in, and remarking any untagged frames with a COS of 7.
Here we use the override command to say, "I dont care if your tagged with a COS value..we are re-writing you with a COS of 7." You can see the COS override is set to ena...or enabled. This command also turns the trust state to untrusted, so that ALL COS values are overwritten.
This last little bit was just to show that re-using the mls qos trust cos, resets the trust cos, and disables the cos override flag.
2950(config-if)#mls qos trust device cisco-phone
*Feb 28 18:41:56 CST: CDP-PA: version 2 packet sent out on FastEthernet0/1no shut
*Feb 28 18:41:56 CST: %TB-5-TRUST_DEVICE_LOST: cisco-phone no longer detected on port Fa0/1, port set to untrusted. \\This happened when I unplugged the phone\\
2950#sh mls qos int fa0/1
FastEthernet0/1
trust state: not trusted
trust mode: not trusted
COS override: dis
default COS: 0
pass-through: none
trust device: cisco-phone
This is a simple...trust the cos values sent by the ip phone if it is discovered on the port using CDP version 2. The switch here is telling it to overwrite packets sent from any connected pc with a COS of 0, or best effort.
2950(config-if)mls qos trust cos
2950(config-if)mls qos cos 7
FastEthernet0/1
trust state: trust cos
trust mode: trust cos
COS override: dis
default COS: 7
pass-through: none
trust device: none
Here we are trusting the COS markings that come in, and remarking any untagged frames with a COS of 7.
2950(config-if)#mls qos cos override
FastEthernet0/1
trust state: not trusted
trust mode: not trusted
COS override: ena
default COS: 7
pass-through: none
trust device: none
Here we use the override command to say, "I dont care if your tagged with a COS value..we are re-writing you with a COS of 7." You can see the COS override is set to ena...or enabled. This command also turns the trust state to untrusted, so that ALL COS values are overwritten.
2950(config-if)mls qos trust cos
interface FastEthernet0/1
switchport access vlan 19
switchport mode access
mls qos cos 7
mls qos trust cos
spanning-tree portfast
end
2950(config-if)#do sh mls qos int fa0/1
FastEthernet0/1
trust state: trust cos
trust mode: trust cos
COS override: dis
default COS: 7
pass-through: none
trust device: none
This last little bit was just to show that re-using the mls qos trust cos, resets the trust cos, and disables the cos override flag.
Tuesday, March 16, 2010
Shaping Calculations
Small post here on traffic shaping calculations. I am thinking of taking the 642-642 QoS test next Tuesday, so I am really trying to re-read the book, and drive the topics home with some note-taking and lab exercises. Basically I have a topology that looks like this (sorry for the lack of visio!):
Host1(client)---R1---R2----Server1 (HTTP/FTP)
The access rate of the link (i.e. clock rate is 128000bps), the CIR given by the ISP is 64kbps. So we need to configure shaping so that our ISP does not drop our traffic. This is a REALLY basic example guys. Here is the config on R2 to shape traffic back to R1:
I then initiated a huge file download using both FTP and HTTP to engage the shaper. Here is the output of my show policy-map interface serial 0/1:
This, needs a bit of explaining. You can clearly see that the offered rate is at or below our configured shaping rate (63,000 bps at the top). Our target rate is what we configured, 64000. The "byte limit" is correct at 2000 bytes because it equals Bc + Be (8000+8000/8). This is how much the router can send per time interval (125ms). So every 125ms the router will send 2000 bytes in order to conform the traffic to 64kpbs. The Bc bucket is 8000 bits, and by default the Be bucket is = Bc bucket. These values were derived from the shaping rule (if shaping rate is < 320kbps then Bc = 8000; if it is greater than 320kbps then Tc defaults to .025 and Bc can be calculated by the formula Bc = Tc*CIR). The last item is the Increment bytes. Tokens are replenished at Bc per Tc. So every 125ms, Bc (or 1000 bytes) will be put back into the buckets.
Host1(client)---R1---R2----Server1 (HTTP/FTP)
The access rate of the link (i.e. clock rate is 128000bps), the CIR given by the ISP is 64kbps. So we need to configure shaping so that our ISP does not drop our traffic. This is a REALLY basic example guys. Here is the config on R2 to shape traffic back to R1:
policy-map shape_all
class class-default
shape average 64000
!
interface Serial0/1
bandwidth 64
ip address 172.16.12.2 255.255.255.0
service-policy output shape_all
I then initiated a huge file download using both FTP and HTTP to engage the shaper. Here is the output of my show policy-map interface serial 0/1:
This, needs a bit of explaining. You can clearly see that the offered rate is at or below our configured shaping rate (63,000 bps at the top). Our target rate is what we configured, 64000. The "byte limit" is correct at 2000 bytes because it equals Bc + Be (8000+8000/8). This is how much the router can send per time interval (125ms). So every 125ms the router will send 2000 bytes in order to conform the traffic to 64kpbs. The Bc bucket is 8000 bits, and by default the Be bucket is = Bc bucket. These values were derived from the shaping rule (if shaping rate is < 320kbps then Bc = 8000; if it is greater than 320kbps then Tc defaults to .025 and Bc can be calculated by the formula Bc = Tc*CIR). The last item is the Increment bytes. Tokens are replenished at Bc per Tc. So every 125ms, Bc (or 1000 bytes) will be put back into the buckets.
Saturday, March 13, 2010
Saturday!
Well I am finishing off the 642-642 CBTNuggets today, and purchasing stuff of ebay for my CCIE home rack. I am planning on using INE's topology, so I am building around that. Here's what I am getting:
If its yellow I already have it. The white ones I still need to get. I am planning on selling (if he still wants it), my current desktop rack (12U) and 24-port 2950 to a co-worker. I am pretty stoked, I think that its going to be a cool journey.
| Device | Type | WAN | LAN | |
| R1 | 2620XM | (2) WIC-1T | FE | |
| R2 | 2620XM | (2) WIC-1T | FE | |
| R3 | 2611XM | NM-4A/S | (2)FE | |
| R4 | 3640 | (2) WIC-1T | (2)FE | |
| R5 | 3640 | NM-4T | (2)FE | |
| R6 | 3640 | (1) WIC-1T | (2)FE | |
| SW1 | 3550 | |||
| SW2 | 3550 | |||
| SW3 | 3550 | |||
| SW4 | 3550 | |||
| BB1 | 2620XM | NM-8A/S | ||
| BB2 | 2509 | (1) AUI Trans | octal | |
| BB3 | 2509 | 1 | (1) AUI Trans | octal |
| Rack-28U |
If its yellow I already have it. The white ones I still need to get. I am planning on selling (if he still wants it), my current desktop rack (12U) and 24-port 2950 to a co-worker. I am pretty stoked, I think that its going to be a cool journey.
Wednesday, March 10, 2010
QoS 642-642 Progress
So, I finished the QoS book by Odom....awesome read! I need to go through and make some notes for the chapters though...sort of a second "glance through." I also picked up the nugget monthly streaming subscription; and am a pretty good way through them now. Good progress, I need some lab reinforcement and I should be good. Anyone know any good QoS labs (I have the ONT portfolio....).
Saturday, February 27, 2010
Reading QoS
Well I bought the Cisco QoS Exam Certification Guide, as well as the CCIE Routing and Switching Certification Guide (4th ed.). Though I am returning the R&S guide because the companion cd was not in there! They are sending me another though, so all is well. I am about 105~ pages into the QoS guide, mostly refresher, but Odom writes quite elegantly on the subject. I really want to just knock this one out in a couple weeks, so after reading the books I will contemplate purchasing the CBT Nuggets to get Jeremy's perspective on it, and then a little labbing before the exam. I really have some QoS work to do at work...so this is pretty beneficial to everyone involved. More to come...sorry for the delayed writing. BTW...probably changing blog sites soon...will know shortly.
Sunday, February 21, 2010
Passed ONT, CCNP is complete!!!
Well, delayed posting, but I did past my ONT last Saturday with a 956! My CCNP journey is now complete, and I am starting preparations now for my CCIE R&S studies. I covered ALOT of material during my CCNP studies, some of which I am sure that I have forgotten. So I will have to hit those topics again on my journey. Now for my experiences on the test! Nothing was unexpected, everything on the blueprint was pretty much tested on. I was a little disappointed that one area I studied pretty hard in had no questions on my test :( but such is life I guess. Overall it was very fair, and the lab/sims were fairly straightforward and easy. *But* they do test your knowledge on the matter! Dont underestimate or under-read them. It is important that you pay close attention to the question that they are asking, and answer it accordingly. Also, wireless...ahhh wireless. Just know your stuff, security, setup, etc. They test on all of it.
Sunday, February 7, 2010
Been Quiet
I dont know if anyone actually follows this or not, but I've been a bit quiet lately. Trying to re-read some of the areas in the book that I think I am a bit deficient in like wireless, wireless system specs, wireless security, etc...The little things like EAP, LEAP, EAP-FAST seem to be escaping me and I am not doing well at retaining them. So, I scheduled my exam for this coming Saturday regardless. I will hopefully cap my CCNP this weekend then, and move on to studying the things I have forgotten in lieu to my CCIE written exam. Stay tuned, tomorrow I have drawn up a lab so that I can physically (using wireshark) see the differences in IPSEC tunnel/transport modes, and also go in-depth on the pre-classify commands (I saw a really good article on Cisco Ninja that I want to replicate).
Sunday, January 31, 2010
Shaping and Policing Traffic
Sorry I have been quiet lately. Been reading alot in the Exam Guide, and hitting some labs up. I recently downloaded the INE V1 Free Chapter, which was actually QoS stuff, and worked through it. I grabbed some pretty good info, inluding how to configure sla monitors as jitters to generate voice traffic on a network. Heres the config for that:
You can of course change the port numbers, ip address, and codec used. It works pretty darn good if you want to make sure your classes and or policies are doing what they are suppose to.
I was also going through the Lab Portfolio for the exam and found a couple of different ways to police and shape traffic. You can actually do it in your policy-maps, or at the interface level which is the legacy configuration method. The policy-maps just allow you a bit more granularity, and flexibility as you can apply them to multiple interfaces. Here are the configs:
Traffic Shaping
Rate-Limiting (aka policing)
Now you can do other things that transmitting or dropping the packets like marking, or re-marking them. I just wanted to show you all a basic example of how this could be done within a policy-map, or at the interface level. Good to know more than one way to do things when troubleshooting a problem, or attempting the CCIE lab :)
Good link:http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a008017405e.shtml
[on the router you want to generate traffic]
ip sla monitor 1
type jitter dest-ipaddr 172.16.11.3 dest-port 16384 codec g729a
freq 1
timeout 1000
ip sla monitor schedule 1 life forever start-time now
[on the router you want to send packets back]
rtr responder, OR ip sla monitor responder
You can of course change the port numbers, ip address, and codec used. It works pretty darn good if you want to make sure your classes and or policies are doing what they are suppose to.
I was also going through the Lab Portfolio for the exam and found a couple of different ways to police and shape traffic. You can actually do it in your policy-maps, or at the interface level which is the legacy configuration method. The policy-maps just allow you a bit more granularity, and flexibility as you can apply them to multiple interfaces. Here are the configs:
Traffic Shaping
[GTS (Generic Traffic Shaping)]
interface multilink 1
traffic-shape rate
[MQC]
policy-map DEFAULT_SHAPING
class class-default
shape average [bps]
interface multilink 1
service-policy output DEFAULT_SHAPING
Rate-Limiting (aka policing)
[CAR (committed access rate policing)]
interface multilink 1
rate-limit output 56000 1500 4000 conform-action continue exceed-action drop
[MQC]
policy-map DEFAULT_POLICING
class class-default
police rate 56000 conform-action transmit exceed-action drop
interface multilink 1
service-policy output DEFAULT_POLICING
Now you can do other things that transmitting or dropping the packets like marking, or re-marking them. I just wanted to show you all a basic example of how this could be done within a policy-map, or at the interface level. Good to know more than one way to do things when troubleshooting a problem, or attempting the CCIE lab :)
Good link:http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a008017405e.shtml
Friday, January 15, 2010
NBAR (Network-based application recognition)
So I HAVE been studying every night this week, and have found myself putting off my blogging in order to play COD:MW2 :) So I am going to try and write a couple of these out tonight. First, NBAR!
Cisco Link: NBAR!!!
So NBAR provides to your network basically the equivalent of an application layer packet sniffer. It was originally conceived to assist in providing quality of service more granularly to applications that traverse the network. You can call out things such as http, gnutella, bittorrent, etc....and you router or device can recognize the data and place it, or classify it, however you saw fit. Here is a good example of an NBAR config:
Some IOS's have different applications installed on them, but Cisco releases PLDM's, or packet description module language packs that you can install on your system to add more, or to update application signatures. This is a pretty cool feature, that as you can see, can also double as a security measure, stopping unwanted traffic at the application level. I did not show any here (I simply dropped http packets), but you can apply different ip precendence, and DSCP marking to traffic that matches an NBAR match statement.
Cisco Link: NBAR!!!
So NBAR provides to your network basically the equivalent of an application layer packet sniffer. It was originally conceived to assist in providing quality of service more granularly to applications that traverse the network. You can call out things such as http, gnutella, bittorrent, etc....and you router or device can recognize the data and place it, or classify it, however you saw fit. Here is a good example of an NBAR config:
lunde-edge(config)#class-map match-all MATCH_HTTP
lunde-edge(config-cmap)#match protocol http ? \\this is NBAR
c-header-field Client general Header Field
host Server Host Name
mime Match MIME Type
s-header-field Server general Header Field
url Match URL String \\you can match a url!
lunde-edge(config)#policy-map MATCH_HTTP \\create your policy-map
lunde-edge(config-pmap)#class MATCH_HTTP \\bind your class to policy
lunde-edge(config-pmap-c)#drop \\your **action**
lunde-edge(config)#int vlan1
lunde-edge(config-if)#service-policy [input\output] MATCH_HTTP \apply your policy
lunde-edge#show class-map \\display your class-map
Class Map match-all MATCH_HTTP (id 2)
Match protocol http
Class Map match-any class-default (id 0)
Match any
lunde-edge#show policy-map \\display your policy map
Policy Map MATCH_HTTP
Class HTTP_MATCH
Class MATCH_HTTP
drop
Some IOS's have different applications installed on them, but Cisco releases PLDM's, or packet description module language packs that you can install on your system to add more, or to update application signatures. This is a pretty cool feature, that as you can see, can also double as a security measure, stopping unwanted traffic at the application level. I did not show any here (I simply dropped http packets), but you can apply different ip precendence, and DSCP marking to traffic that matches an NBAR match statement.
Friday, January 8, 2010
Cisco Modular QoS CLI (MQC)
- Define class-maps (define "what" to match)
- Define policy-map (define what to do with your matches)
- Assign service policy (apply what you have defined to an interface)
show class-map
show policy-map (interface)
- class-map [word, match-all, match-any]
- match [access-group, protocol, etc...] option
- policy-map [name] ***ONE POLICY MAP PER INTERFACE PER DIRECTION***
- class-map [name]
- what do we want to do with it???
- (interface)service-policy [input, output] [name]
Thursday, January 7, 2010
QOS
So I began yet another QOS venture tonight. Watched the nuggets video(s). Here are just some random notes. They will probably be of no use to anybody but me, but here they are:
TOP NETWORK CULPRITS (in terms of good service over the wire!)
CONGESTION AVOIDANCE MECHANIMS
-Shaping traffic merely queues packets when a pre-defined limit is reached
METHODS OF IMPLEMENTING QOS
TOP NETWORK CULPRITS (in terms of good service over the wire!)
- Lack of bandwidth
- Packet loss
- Delay
- Jitter (variation of delay...i.e. on packet has 20ms delay, next 5, next 55...
- Best Effort (it gets there when it gets there!! like a bitchy old mail lady who is disgruntled with her job)
- Integrated Services Model (reserved bandwidth from point A ----> point B using RSVP) intserv
- Differentiated Services Model (this is the best...puts up and breaks down as packets traverse interface)
- Do a network audit and identify the critical applications
- Identify the application requirements (i.e. what protocols...bandwidth...etc)
- Divide that traffic into groups (i.e. classify it into approx. 4-11 groups)
- Create and apply policy to those groups
CONGESTION AVOIDANCE MECHANIMS
- FIFO and Tail-drop
- Random early detection (RED)
- Weighted random early detection (WRED)
-Shaping traffic merely queues packets when a pre-defined limit is reached
METHODS OF IMPLEMENTING QOS
- CLI (hardest method)
- MQC (modular QOS CLI)
- AutoQOS (cisco proprietary)
- SDM
- QPM (plug-in of CiscoWorks)
Subscribe to:
Posts (Atom)