Re: OT: rate-limiting proofs [7:54134]
So, Chuck, was the wrong bandwidth statement problem ? Sasa Milic wrote: > > You have specified bandwidth 64000, shouldn't it be just 64 ? > With 64000, router thinks that there is enough bandwidth available, > and policy-map doesn't do anything, but drops occur later, at > interface level buffers. > > Chuck's Long Road wrote: > > > > ""Steven A. Ridder"" wrote in message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > that's the best command to show the output > > > > > > > CL: unfortunately, as the following output indicates, even when all packets > > were being dropped ( apparently ) there was no indication of this. > > > > Router_1#sh policy int s 0 > > > > Serial0 > > > > Service-policy output: 200filter (1289) > > > > Class-map: pingr5 (match-all) (1291/2) > > 0 packets, 0 bytes > > 5 minute offered rate 0 bps, drop rate 0 bps > > Match: ip precedence 5 (1295) > >police: > > 8000 bps, 1500 limit, 1500 extended limit > > conformed 0 packets, 0 bytes; action: transmit > > exceeded 0 packets, 0 bytes; action: drop > > conformed 0 bps, exceed 0 bps violate 0 bps > > > > Class-map: pingr6 (match-all) (1299/3) > > 876 packets, 73152 bytes > > 5 minute offered rate 0 bps, drop rate 0 bps > > Match: ip precedence 6 (1303) > > police: > > 8000 bps, 1500 limit, 1500 extended limit > > conformed 60 packets, 7872 bytes; action: transmit > > exceeded 0 packets, 0 bytes; action: drop > > conformed 0 bps, exceed 0 bps violate 0 bps > > > > Class-map: pingr7 (match-all) (1307/4) > > 0 packets, 0 bytes > > 5 minute offered rate 0 bps, drop rate 0 bps > > Match: ip precedence 7 (1311) > > police: > > 8000 bps, 1500 limit, 1500 extended limit > > conformed 0 packets, 0 bytes; action: transmit > > exceeded 0 packets, 0 bytes; action: drop > > conformed 0 bps, exceed 0 bps violate 0 bps > > > > Class-map: class-default (match-any) (1315/0) > > 19228 packets, 27705238 bytes > > 5 minute offered rate 0 bps, drop rate 0 bps > > Match: any (1319) > > Router_1# > > > > > -- > > > > > > RFC 1149 Compliant. > > > > > > > > > > > > ""Chuck's Long Road"" wrote in message > > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > ""Priscilla Oppenheimer"" wrote in message > > > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > > Chuck's Long Road wrote: > > > > > > > > > > > > I'm putting in some rack time to review certain QoS features. > > > > > > Configuration > > > > > > is not really a problem. MQC makes this really easy :-> > > > > > > > > > > > > However, I am attempting to observe results, and I am finding > > > > > > that I am > > > > > > unable to make bad things happen, such as packet drops. > > > > > > > > > > > > I am pinging from three different routers on a token ring to 3 > > > > > > other routers > > > > > > via a 64K frame relay. The router that bridges the token ring > > > > > > and frame > > > > > > networks has the policy configured. > > > > > > > > > > You would have to exceed 64 Kbps for drops to occur, wouldn't you? Do > > > you > > > > > have any idea how much bandwidth you're using on the Token Ring side? > > > What > > > > > does show int show for load? > > > > > > > > > > I'm thinking you'll need to do more than ping. The problem with > > Cisco's > > > > ping > > > > > is that it doesn't let you specify how much time between pings, > > > sometimes > > > > > called an interval. The timeout value is for unsucessful pings. But > > what > > > > you > > > > > need is a configurable interval between the sending of pings, > > > successful > > > > or > > > > > not. A real operating system or real ping tool would let you do this. > > > ;-) > > > > > > > > > > > > CL: I finally was able to get some bad things to happen. > > > > > > > > token ring domain border router - frame relay domain > > > > > > > > I just started pinging from both sides, over an extended period of > time. > > > To > > > > judget from the result, given the rudimentary configurations, it takes > a > > > > minute or two for the rate limits to apply. There is an "average" > > traffic > > > > rate. > > > > > > > > three routers from each domain pinging the other side, packet sizes > 1500 > > > > bytes, and I lowered the timeout value to 1 second from the default > two > > > > seconds. By the time I added the sixth router's traffic, everybody > > started > > > > timing out. It took a minute or two for traffic to start going through > > > again > > > > after I stopped traffic from a router or two. I'll have to look into > the > > > > defaults more closely. > > > > > > > > There has got to be a better show command than the "show policy-map > > > > interface etc" for this. > > > > > > > > Back to the docs. > > > > > > > > > > > > > > > > > > > > > > > > > > Ping in the MS-DOS prompt on Windows doesn't have this ei
Re: OT: rate-limiting proofs [7:54134]
Priscilla Oppenheimer wrote: > > I'm thinking you'll need to do more than ping. The problem with Cisco's ping > is that it doesn't let you specify how much time between pings, sometimes > called an interval. The timeout value is for unsucessful pings. But what you > > Some UNIXes have a -f (flood) option that will let you really whip the pings out. You can set interval on cisco to be zero, and it will flood, without waiting for reply. Sasa CCIE 8635 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=54253&t=54134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OT: rate-limiting proofs [7:54134]
Hm, interesting. I'm using rate-limit on internet routers to limit ICMP and SYN packets, and I clearly see drops. Also, I'm using NBAR with policy-map to block some HTTP GET requests, and, again, I see drops. But, you are mixing these two (policy + rate-limit inside it), and it doesnt' work. Could it be because drops aren't occuring because of policy-map ? You have specified bandwidth 64000, shouldn't it be just 64 ? With 64000, router thinks that there is enough bandwidth available, and policy-map doesn't do anything, but drops occur later, at interface level buffers. Hopt this helps. Regards, Sasa CCIE 8635 Chuck's Long Road wrote: > > ""Steven A. Ridder"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > that's the best command to show the output > > > > CL: unfortunately, as the following output indicates, even when all packets > were being dropped ( apparently ) there was no indication of this. > > Router_1#sh policy int s 0 > > Serial0 > > Service-policy output: 200filter (1289) > > Class-map: pingr5 (match-all) (1291/2) > 0 packets, 0 bytes > 5 minute offered rate 0 bps, drop rate 0 bps > Match: ip precedence 5 (1295) >police: > 8000 bps, 1500 limit, 1500 extended limit > conformed 0 packets, 0 bytes; action: transmit > exceeded 0 packets, 0 bytes; action: drop > conformed 0 bps, exceed 0 bps violate 0 bps > > Class-map: pingr6 (match-all) (1299/3) > 876 packets, 73152 bytes > 5 minute offered rate 0 bps, drop rate 0 bps > Match: ip precedence 6 (1303) > police: > 8000 bps, 1500 limit, 1500 extended limit > conformed 60 packets, 7872 bytes; action: transmit > exceeded 0 packets, 0 bytes; action: drop > conformed 0 bps, exceed 0 bps violate 0 bps > > Class-map: pingr7 (match-all) (1307/4) > 0 packets, 0 bytes > 5 minute offered rate 0 bps, drop rate 0 bps > Match: ip precedence 7 (1311) > police: > 8000 bps, 1500 limit, 1500 extended limit > conformed 0 packets, 0 bytes; action: transmit > exceeded 0 packets, 0 bytes; action: drop > conformed 0 bps, exceed 0 bps violate 0 bps > > Class-map: class-default (match-any) (1315/0) > 19228 packets, 27705238 bytes > 5 minute offered rate 0 bps, drop rate 0 bps > Match: any (1319) > Router_1# > > > -- > > > > RFC 1149 Compliant. > > > > > > > > ""Chuck's Long Road"" wrote in message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > ""Priscilla Oppenheimer"" wrote in message > > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > Chuck's Long Road wrote: > > > > > > > > > > I'm putting in some rack time to review certain QoS features. > > > > > Configuration > > > > > is not really a problem. MQC makes this really easy :-> > > > > > > > > > > However, I am attempting to observe results, and I am finding > > > > > that I am > > > > > unable to make bad things happen, such as packet drops. > > > > > > > > > > I am pinging from three different routers on a token ring to 3 > > > > > other routers > > > > > via a 64K frame relay. The router that bridges the token ring > > > > > and frame > > > > > networks has the policy configured. > > > > > > > > You would have to exceed 64 Kbps for drops to occur, wouldn't you? Do > > you > > > > have any idea how much bandwidth you're using on the Token Ring side? > > What > > > > does show int show for load? > > > > > > > > I'm thinking you'll need to do more than ping. The problem with > Cisco's > > > ping > > > > is that it doesn't let you specify how much time between pings, > > sometimes > > > > called an interval. The timeout value is for unsucessful pings. But > what > > > you > > > > need is a configurable interval between the sending of pings, > > successful > > > or > > > > not. A real operating system or real ping tool would let you do this. > > ;-) > > > > > > > > > CL: I finally was able to get some bad things to happen. > > > > > > token ring domain border router - frame relay domain > > > > > > I just started pinging from both sides, over an extended period of time. > > To > > > judget from the result, given the rudimentary configurations, it takes a > > > minute or two for the rate limits to apply. There is an "average" > traffic > > > rate. > > > > > > three routers from each domain pinging the other side, packet sizes 1500 > > > bytes, and I lowered the timeout value to 1 second from the default two > > > seconds. By the time I added the sixth router's traffic, everybody > started > > > timing out. It took a minute or two for traffic to start going through > > again > > > after I stopped traffic from a router or two. I'll have to look into the > > > defaults more closely. > > > > > > There has got to be a better show command than the "show policy-map > > > interface etc" for this. > > > > > > Back to the docs. > > > > > > > > > > > > > > > >
Re: OT: rate-limiting proofs [7:54134]
""Steven A. Ridder"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > that's the best command to show the output > CL: unfortunately, as the following output indicates, even when all packets were being dropped ( apparently ) there was no indication of this. Router_1#sh policy int s 0 Serial0 Service-policy output: 200filter (1289) Class-map: pingr5 (match-all) (1291/2) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip precedence 5 (1295) police: 8000 bps, 1500 limit, 1500 extended limit conformed 0 packets, 0 bytes; action: transmit exceeded 0 packets, 0 bytes; action: drop conformed 0 bps, exceed 0 bps violate 0 bps Class-map: pingr6 (match-all) (1299/3) 876 packets, 73152 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip precedence 6 (1303) police: 8000 bps, 1500 limit, 1500 extended limit conformed 60 packets, 7872 bytes; action: transmit exceeded 0 packets, 0 bytes; action: drop conformed 0 bps, exceed 0 bps violate 0 bps Class-map: pingr7 (match-all) (1307/4) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip precedence 7 (1311) police: 8000 bps, 1500 limit, 1500 extended limit conformed 0 packets, 0 bytes; action: transmit exceeded 0 packets, 0 bytes; action: drop conformed 0 bps, exceed 0 bps violate 0 bps Class-map: class-default (match-any) (1315/0) 19228 packets, 27705238 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any (1319) Router_1# > -- > > RFC 1149 Compliant. > > > > ""Chuck's Long Road"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > ""Priscilla Oppenheimer"" wrote in message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > Chuck's Long Road wrote: > > > > > > > > I'm putting in some rack time to review certain QoS features. > > > > Configuration > > > > is not really a problem. MQC makes this really easy :-> > > > > > > > > However, I am attempting to observe results, and I am finding > > > > that I am > > > > unable to make bad things happen, such as packet drops. > > > > > > > > I am pinging from three different routers on a token ring to 3 > > > > other routers > > > > via a 64K frame relay. The router that bridges the token ring > > > > and frame > > > > networks has the policy configured. > > > > > > You would have to exceed 64 Kbps for drops to occur, wouldn't you? Do > you > > > have any idea how much bandwidth you're using on the Token Ring side? > What > > > does show int show for load? > > > > > > I'm thinking you'll need to do more than ping. The problem with Cisco's > > ping > > > is that it doesn't let you specify how much time between pings, > sometimes > > > called an interval. The timeout value is for unsucessful pings. But what > > you > > > need is a configurable interval between the sending of pings, > successful > > or > > > not. A real operating system or real ping tool would let you do this. > ;-) > > > > > > CL: I finally was able to get some bad things to happen. > > > > token ring domain border router - frame relay domain > > > > I just started pinging from both sides, over an extended period of time. > To > > judget from the result, given the rudimentary configurations, it takes a > > minute or two for the rate limits to apply. There is an "average" traffic > > rate. > > > > three routers from each domain pinging the other side, packet sizes 1500 > > bytes, and I lowered the timeout value to 1 second from the default two > > seconds. By the time I added the sixth router's traffic, everybody started > > timing out. It took a minute or two for traffic to start going through > again > > after I stopped traffic from a router or two. I'll have to look into the > > defaults more closely. > > > > There has got to be a better show command than the "show policy-map > > interface etc" for this. > > > > Back to the docs. > > > > > > > > > > > > > > Ping in the MS-DOS prompt on Windows doesn't have this either, at least > > not > > > the version I'm using. But ping under UNIX does, although it may not let > > you > > > set the interval low enough. Some UNIXes have a -f (flood) option that > > will > > > let you really whip the pings out. And a ping utility would let you do > > that > > > too. For example, I use iNetTools from WildPackets. > > > > > > Are you trying to consume bandwidth just by using router tools or could > > you > > > use a host also? Then there are many more options, of course. > > > > > > Hmm, what are some other ways to consume bandwidth by just configuring > > > router options. Gazillions of SAPs? Gazillions of AppleTalk networks > with > > > RTMP? Can you FTP or RCP stuff to and from the routers? > > > > > > ___ > > > > > > Priscilla Oppenheimer > > > www.troubleshootingnetworks.com >
Re: OT: rate-limiting proofs [7:54134]
that's the best command to show the output -- RFC 1149 Compliant. ""Chuck's Long Road"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > ""Priscilla Oppenheimer"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > Chuck's Long Road wrote: > > > > > > I'm putting in some rack time to review certain QoS features. > > > Configuration > > > is not really a problem. MQC makes this really easy :-> > > > > > > However, I am attempting to observe results, and I am finding > > > that I am > > > unable to make bad things happen, such as packet drops. > > > > > > I am pinging from three different routers on a token ring to 3 > > > other routers > > > via a 64K frame relay. The router that bridges the token ring > > > and frame > > > networks has the policy configured. > > > > You would have to exceed 64 Kbps for drops to occur, wouldn't you? Do you > > have any idea how much bandwidth you're using on the Token Ring side? What > > does show int show for load? > > > > I'm thinking you'll need to do more than ping. The problem with Cisco's > ping > > is that it doesn't let you specify how much time between pings, sometimes > > called an interval. The timeout value is for unsucessful pings. But what > you > > need is a configurable interval between the sending of pings, successful > or > > not. A real operating system or real ping tool would let you do this. ;-) > > > CL: I finally was able to get some bad things to happen. > > token ring domain border router - frame relay domain > > I just started pinging from both sides, over an extended period of time. To > judget from the result, given the rudimentary configurations, it takes a > minute or two for the rate limits to apply. There is an "average" traffic > rate. > > three routers from each domain pinging the other side, packet sizes 1500 > bytes, and I lowered the timeout value to 1 second from the default two > seconds. By the time I added the sixth router's traffic, everybody started > timing out. It took a minute or two for traffic to start going through again > after I stopped traffic from a router or two. I'll have to look into the > defaults more closely. > > There has got to be a better show command than the "show policy-map > interface etc" for this. > > Back to the docs. > > > > > > > > Ping in the MS-DOS prompt on Windows doesn't have this either, at least > not > > the version I'm using. But ping under UNIX does, although it may not let > you > > set the interval low enough. Some UNIXes have a -f (flood) option that > will > > let you really whip the pings out. And a ping utility would let you do > that > > too. For example, I use iNetTools from WildPackets. > > > > Are you trying to consume bandwidth just by using router tools or could > you > > use a host also? Then there are many more options, of course. > > > > Hmm, what are some other ways to consume bandwidth by just configuring > > router options. Gazillions of SAPs? G
Re: OT: rate-limiting proofs [7:54134]
""Priscilla Oppenheimer"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Chuck's Long Road wrote: > > > > I'm putting in some rack time to review certain QoS features. > > Configuration > > is not really a problem. MQC makes this really easy :-> > > > > However, I am attempting to observe results, and I am finding > > that I am > > unable to make bad things happen, such as packet drops. > > > > I am pinging from three different routers on a token ring to 3 > > other routers > > via a 64K frame relay. The router that bridges the token ring > > and frame > > networks has the policy configured. > > You would have to exceed 64 Kbps for drops to occur, wouldn't you? Do you > have any idea how much bandwidth you're using on the Token Ring side? What > does show int show for load? > > I'm thinking you'll need to do more than ping. The problem with Cisco's ping > is that it doesn't let you specify how much time between pings, sometimes > called an interval. The timeout value is for unsucessful pings. But what you > need is a configurable interval between the sending of pings, successful or > not. A real operating system or real ping tool would let you do this. ;-) CL: I finally was able to get some bad things to happen. token ring domain border router - frame relay domain I just started pinging from both sides, over an extended period of time. To judget from the result, given the rudimentary configurations, it takes a minute or two for the rate limits to apply. There is an "average" traffic rate. three routers from each domain pinging the other side, packet sizes 1500 bytes, and I lowered the timeout value to 1 second from the default two seconds. By the time I added the sixth router's traffic, everybody started timing out. It took a minute or two for traffic to start going through again after I stopped traffic from a router or two. I'll have to look into the defaults more closely. There has got to be a better show command than the "show policy-map interface etc" for this. Back to the docs. > > Ping in the MS-DOS prompt on Windows doesn't have this either, at least not > the version I'm using. But ping under UNIX does, although it may not let you > set the interval low enough. Some UNIXes have a -f (flood) option that will > let you really whip the pings out. And a ping utility would let you do that > too. For example, I use iNetTools from WildPackets. > > Are you trying to consume bandwidth just by using router tools or could you > use a host also? Then there are many more options, of course. > > Hmm, what are some other ways to consume bandwidth by just configuring > router options. Gazillions of SAPs? Gazillions of AppleTalk networks with > RTMP? Can you FTP or RCP stuff to and from the routers? > > ___ > > Priscilla Oppenheimer > www.troubleshootingnetworks.com > www.priscilla.com > > > > > class-map match-all pingr6 > > match ip precedence 6 > > class-map match-all pingr7 > > match ip precedence 7 > > class-map match-all pingr5 > > match ip precedence 5 > > ! > > policy-map 200filter > > class pingr5 > > police 8000 1500 1500 conform-action transmit > > exceed-action drop > > class pingr6 > > police 8000 1500 1500 conform-action transmit > > exceed-action drop > > class pingr7 > > police 8000 1500 1500 conform-action transmit > > exceed-action drop > > ! > > ! > > interface Serial0 > > bandwidth 64000 > > > > ( clockrate on the frame switch is set to 64K ) > > > > ip address 192.168.50.1 255.255.255.0 > > encapsulation frame-relay > > ip ospf priority 100 > > service-policy output 200filter > > no fair-queue > > frame-relay map ip 192.168.50.2 102 broadcast nocompress > > frame-relay map ip 192.168.50.3 103 broadcast nocompress > > frame-relay map ip 192.168.50.4 104 broadcast nocompress > > ! > > > > I'm using extended ping, and setting the packet size to 1500, > > and the ToS > > bit to match the values in the class-maps. > > > > Replies appear to be slow, but nothing is being dropped, as I > > would expect. > > Even when I throw in traffic from the border router just to > > fill up > > bandwidth. > > > > Anyone got some thoughts on "proof of concept" for policing? > > > > Chuck > > -- > > > > www.chuckslongroad.info > > like my web site? > > take the survey! Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=54147&t=54134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OT: rate-limiting proofs [7:54134]
Chuck's Long Road wrote: > > I'm putting in some rack time to review certain QoS features. > Configuration > is not really a problem. MQC makes this really easy :-> > > However, I am attempting to observe results, and I am finding > that I am > unable to make bad things happen, such as packet drops. > > I am pinging from three different routers on a token ring to 3 > other routers > via a 64K frame relay. The router that bridges the token ring > and frame > networks has the policy configured. You would have to exceed 64 Kbps for drops to occur, wouldn't you? Do you have any idea how much bandwidth you're using on the Token Ring side? What does show int show for load? I'm thinking you'll need to do more than ping. The problem with Cisco's ping is that it doesn't let you specify how much time between pings, sometimes called an interval. The timeout value is for unsucessful pings. But what you need is a configurable interval between the sending of pings, successful or not. A real operating system or real ping tool would let you do this. ;-) Ping in the MS-DOS prompt on Windows doesn't have this either, at least not the version I'm using. But ping under UNIX does, although it may not let you set the interval low enough. Some UNIXes have a -f (flood) option that will let you really whip the pings out. And a ping utility would let you do that too. For example, I use iNetTools from WildPackets. Are you trying to consume bandwidth just by using router tools or could you use a host also? Then there are many more options, of course. Hmm, what are some other ways to consume bandwidth by just configuring router options. Gazillions of SAPs? Gazillions of AppleTalk networks with RTMP? Can you FTP or RCP stuff to and from the routers? ___ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com > > class-map match-all pingr6 > match ip precedence 6 > class-map match-all pingr7 > match ip precedence 7 > class-map match-all pingr5 > match ip precedence 5 > ! > policy-map 200filter > class pingr5 > police 8000 1500 1500 conform-action transmit > exceed-action drop > class pingr6 > police 8000 1500 1500 conform-action transmit > exceed-action drop > class pingr7 > police 8000 1500 1500 conform-action transmit > exceed-action drop > ! > ! > interface Serial0 > bandwidth 64000 > > ( clockrate on the frame switch is set to 64K ) > > ip address 192.168.50.1 255.255.255.0 > encapsulation frame-relay > ip ospf priority 100 > service-policy output 200filter > no fair-queue > frame-relay map ip 192.168.50.2 102 broadcast nocompress > frame-relay map ip 192.168.50.3 103 broadcast nocompress > frame-relay map ip 192.168.50.4 104 broadcast nocompress > ! > > I'm using extended ping, and setting the packet size to 1500, > and the ToS > bit to match the values in the class-maps. > > Replies appear to be slow, but nothing is being dropped, as I > would expect. > Even when I throw in traffic from the border router just to > fill up > bandwidth. > > Anyone got some thoughts on "proof of concept" for policing? > > Chuck > -- > > www.chuckslongroad.info > like my web site? > take the survey! > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=54138&t=54134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
OT: rate-limiting proofs [7:54134]
I'm putting in some rack time to review certain QoS features. Configuration is not really a problem. MQC makes this really easy :-> However, I am attempting to observe results, and I am finding that I am unable to make bad things happen, such as packet drops. I am pinging from three different routers on a token ring to 3 other routers via a 64K frame relay. The router that bridges the token ring and frame networks has the policy configured. class-map match-all pingr6 match ip precedence 6 class-map match-all pingr7 match ip precedence 7 class-map match-all pingr5 match ip precedence 5 ! policy-map 200filter class pingr5 police 8000 1500 1500 conform-action transmit exceed-action drop class pingr6 police 8000 1500 1500 conform-action transmit exceed-action drop class pingr7 police 8000 1500 1500 conform-action transmit exceed-action drop ! ! interface Serial0 bandwidth 64000 ( clockrate on the frame switch is set to 64K ) ip address 192.168.50.1 255.255.255.0 encapsulation frame-relay ip ospf priority 100 service-policy output 200filter no fair-queue frame-relay map ip 192.168.50.2 102 broadcast nocompress frame-relay map ip 192.168.50.3 103 broadcast nocompress frame-relay map ip 192.168.50.4 104 broadcast nocompress ! I'm using extended ping, and setting the packet size to 1500, and the ToS bit to match the values in the class-maps. Replies appear to be slow, but nothing is being dropped, as I would expect. Even when I throw in traffic from the border router just to fill up bandwidth. Anyone got some thoughts on "proof of concept" for policing? Chuck -- www.chuckslongroad.info like my web site? take the survey! Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=54134&t=54134 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
