|
Limited Port SpeedSo on Cisco fiber gbic's you can't lock port speed. I need to use the fiber gbic's but limit my speed to 100megs/full duplex. How can I do this on my 7301? If we set some type of traffic queue adding 11-15-20% for overhead is fine. I just can't exceed much over 100megs. |
|
|
Use a policy-map / class map to rate limit / police the interfaces. |
|
DarkLogixTexan and Proud Premium Member join:2008-10-23 Baytown, TX |
to wirelessdog
I thought some SFP's couldn't do anything other than gig and thus would just have to be ratelimited. |
|
|
to markysharkey
Any chance you can provide an example? |
|
|
|
to wirelessdog
Your upstream provider should be able to set a egress limit on their port to you. Your upstream can be limited in the following manner:
policy-map WAN_LIMIT class class-default shape average percent 100
interface GigabitEthernet0/0 bandwidth 100000 service-policy output WAN_LIMIT
Buy adjusting the "bandwidth" statement under the interface, you'll be able to limit the throughput of your egress traffic, based upon 100% of the traffic hitting the policy-map. |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ |
to wirelessdog
said by wirelessdog:Any chance you can provide an example? as long as your router supports mqc (the 7301 should). policy-map SHAPE-100M
class class-default
shape peak 102400000
int gi0/0
service-policy SHAPE-100M out
{edit} done from memory on my phone. actual syntax may vary. q. |
|
|
This shapes the output. How can I limit the input if the upstream provider does not know how? |
|
wirelessdog |
to DaSneaky1D
I thought the bandwidth statement was informational only and didn't really have any effect on anything... |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ |
said by wirelessdog:I thought the bandwidth statement was informational only and didn't really have any effect on anything... it doesn't do anything in this case either. it causes the policy map to reference the speed of the link on this circuit -- then perform average shaping to 100% of the links reference bandwidth (which is stated using the 'bandwidth' statement). said by wirelessdog:This shapes the output. How can I limit the input if the upstream provider does not know how? then your provider is incompetent. using port-speeds to limit your aggregate throughput (while it can be done) isn't the best way of doing things. what about when you need a 200meg commit? 300? price per 1gbe port is dirt cheap now and if your carrier was smart -- they'd provision you a 1gbe port and shape you to your purchased rate. then, when your throughput demands increase -- they simply change the shaper on your interface and you're done. unless you're dealing with customers who are only dealing with routine 10meg commits -- there is no reason to use 100m port anymore as you're just going to cause headaches when your customer outgrows your kit. q. |
|
|
said by tubbynet:then your provider is incompetent. using port-speeds to limit your aggregate throughput (while it can be done) isn't the best way of doing things. On this we can agree. That said I need to figure out a workaround for myself. What my upstream provider does as long as it doesn't affect me is what it is. This is what I'm using: policy-map WAN-Egress-100M class class-default shape average 102400000 policy-map VLAN22-Ingress-100M class class-default police cir 102400000 conform-action transmit exceed-action drop policy-map VLAN22-Egress-100M class class-default shape average 102400000 policy-map WAN-Ingress-100M class class-default police cir 102400000 conform-action transmit exceed-action drop |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ 1 edit
1 recommendation |
my spidey-sense is tingling here -- as i dont think this is what you should be doing (i.e. you need to talk with your provider). by applying a strict policer on ingress from wan (or egress to lan) you are effectively limiting the tcp flow mechanism such that *connection oriented* traffic will (kinda) obey your limit. the issue is that any udp traffic ingress doesnt care -- it'll just be dropped. while most udp-oriented apps (streaming audio, video) wont care about the loss -- the issue is that your provider isnt billing on what you receive -- they are billing on what they send (i'm guessing you're in something similar to 95th percentile with burst?). if you have a shit-ton of udp traffic being crammed down your pipe all the time -- good luck dealing with your carrier. in their minds -- they carried it to your door -- you should have to pay for delivery even if you dont accept it; they still had to get it to you. i need to lab this up to test -- but i dont think you'll see any luck with this. tl;dr -- work with the carrier. if they are the cheapest -- you are absolutely getting what you pay for. q. [edited to add -- here's a link on [c-nsp] from a few years back talking about a tangentially related issue and the problems facing therein] |
|
DarkLogixTexan and Proud Premium Member join:2008-10-23 Baytown, TX |
said by tubbynet:95th percentile with burst You hear what google did way back when they were small as kinda a hack around 95th? they were copying their DB's cross-country so to save cost they unplugged the link for 95% of the month then ran it at max speed for 5% because the provider dropped the top 5% for billing and then use the next 5% as though that were the whole month it looked like they used nothing. |
|
TomS_Git-r-done MVM join:2002-07-19 London, UK |
TomS_
MVM
2014-Aug-30 8:22 am
Doesnt quite work like that. Even if they only used the link for 5% of the month time wise, during that time there will still be 5% of traffic peaks above the average that will be discarded, leaving the lower 95% of traffic peaks from which billing can be deduced.
Compressing the amount of time you use a link for is only likely to drive your average consumed rate up as you try to push more through in a shorter period of time.
Methinks that where ever you heard this from is making stuff up or doesnt understand how 95% works. That or the provider had a very broken implementation of 95% billing that they were exploiting, in which case, bravo to them. Cant imagine they would have got away with it for too long though... |
|
|
to tubbynet
Good clarification of the method I suggested |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ |
to DarkLogix
95th percentile billing isnt 95% usage. its 95th percentile of peak speeds.
q. |
|
tubbynet |
i just tested this out in my lab. asr9001 simulating provider edge sending pings -- 2951 simulating customer edge with a service policy. ip access-list extended PINGS
permit icmp host 2.2.2.1 host 2.2.2.2 echo
permit icmp host 2.2.2.1 host 2.2.2.2 echo-reply
class-map match-any MATCH-PINGS
match access-group name PINGS
!
policy-map LIMIT-PINGS
class MATCH-PINGS
police 8000 conform-action transmit exceed-action drop
class class-default
interface GigabitEthernet0/0
ip address 2.2.2.2 255.255.255.252
duplex auto
speed auto
service-policy input LIMIT-PINGS
running the following command on the asr9001 RP/0/RSP0/CPU0:ASR-9001-C#ping ipv4 2.2.2.2 size 250 interval 100 count 1000
gives the following results Sun Aug 31 01:44:17.644 UTC
Type escape sequence to abort.
Sending 1000, 250-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!
!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!
!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!
!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!
!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!
.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!
!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!
!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!
!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.
!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!
!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!
!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!
!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!
!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!
.!!!!!!!!.!!!!!!!!.!
Success rate is 88 percent (889/1000), round-trip min/avg/max = 1/1/66 ms
the results from each of the routers is as follows RP/0/RSP0/CPU0:ASR-9001-C#sh int gi0/0/0/19
Sun Aug 31 01:56:40.138 UTC
GigabitEthernet0/0/0/19 is up, line protocol is up
Interface state transitions: 1
Hardware is GigabitEthernet, address is 10f3.1162.c4ad (bia 10f3.1162.c4ad)
Internet address is 2.2.2.1/30
MTU 1514 bytes, BW 1000000 Kbit (Max: 1000000 Kbit)
reliability 255/255, txload 0/255, rxload 0/255
Encapsulation ARPA,
Full-duplex, 1000Mb/s, link type is force-up
output flow control is off, input flow control is off
loopback not set,
ARP type ARPA, ARP timeout 04:00:00
Last input 00:00:00, output 00:00:18
Last clearing of "show interface" counters never
5 minute input rate 4000 bits/sec, 3 packets/sec
5 minute output rate 5000 bits/sec, 2 packets/sec
3477 packets input, 711349 bytes, 1 total input drops
205 drops for unrecognized upper-level protocol
Received 4 broadcast packets, 1345 multicast packets
0 runts, 0 giants, 0 throttles, 0 parity
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
2444 packets output, 937992 bytes, 0 total output drops
Output 11 broadcast packets, 102 multicast packets
0 output errors, 0 underruns, 0 applique, 0 resets
0 output buffer failures, 0 output buffers swapped out
1 carrier transitions
and from the customer side CE5#sh int gi 0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is PQ3_TSEC, address is bc16.65c9.0160 (bia bc16.65c9.0160)
Internet address is 2.2.2.2/30
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set
Keepalive set (10 sec)
Full Duplex, 1Gbps, media type is RJ45
output flow-control is unsupported, input flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:02, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
80767 packets input, 8270968 bytes, 0 no buffer
Received 73866 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 71656 multicast, 0 pause input
336485 packets output, 29506566 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
69 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
6 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
so from the carrier side -- i'm sending traffic -- you're just dropping it. i'm still billing you for the traffic (if you're on a burst plan). if your carrier is billing you for a certain commit speed -- they should play ball and not try to bust your balls by sending traffic towards you. if they are only charging you for a flat 100m commit -- and not charging for the burst -- don't even police inbound. let them send you traffic for free. either way -- your carrier has to play ball. otherwise -- you're never going to get what you want except for pissed off customers. q. |
|
TomS_Git-r-done MVM join:2002-07-19 London, UK |
TomS_
MVM
2014-Aug-30 2:20 pm
Something is broken, code tags are not formatting properly. |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ |
my original post had a hanging tag. should be fixed now.
q. |
|
|
to tubbynet
said by tubbynet:so from the carrier side -- i'm sending traffic -- you're just dropping it. I agree it is not ideal. However, I don't really care if traffic over 100megs is dropped. My LAN side of the router is running at 100megs so anything over 100megs has issues anyway... |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ |
but if they are billing you for traffic sent -- you are still being charged. thats what i am saying. if they dont shape you, and they bill via sent -- you're being fleeced.
q. |
|
|
Ok, so let me expand on the situation. The upstream provider is a small mom and pop cable company that has grown leaps and bounds over the past few years. They are dual-homed with two gig connections from two tier one providers. That hand me off a port and trust I won't go much over what I am paying for. I'm not comfortable having a gig port with them but that overcame the speed issues I was seeing before. Just trying to do the right thing here and not piss them off. |
|
TomS_Git-r-done MVM join:2002-07-19 London, UK
1 recommendation |
TomS_
MVM
2014-Aug-30 3:49 pm
Asking them to shape towards you is just standard ISP stuff. *EVERYONE* does it. If that pisses them off, I'd argue they are in the wrong business.
If they simply trust that you arent going to go over 100M, dont worry about shaping, and keep an eye on it. When you start nudging your way towards/over 100M, start talking to them about selling you more bandwidth.
If you have that kind of cozy relationship, something like this should also be doable.
But as tubby says, in order to be more strict, they really need to be shaping towards you. Thats the only way to ensure packets are dropped before they hit the wire. |
|
DarkLogixTexan and Proud Premium Member join:2008-10-23 Baytown, TX |
to TomS_
said by TomS_:Doesnt quite work like that. Even if they only used the link for 5% of the month time wise, during that time there will still be 5% of traffic peaks above the average that will be discarded, leaving the lower 95% of traffic peaks from which billing can be deduced.
Compressing the amount of time you use a link for is only likely to drive your average consumed rate up as you try to push more through in a shorter period of time.
Methinks that where ever you heard this from is making stuff up or doesnt understand how 95% works. That or the provider had a very broken implementation of 95% billing that they were exploiting, in which case, bravo to them. Cant imagine they would have got away with it for too long though... Its just what I heard they did some time long ago. in that "hack" there was only any traffic in that 5% and nothing in the 95%. it was mentioned on security now via an e-mail from someone that was at google. |
|
DarkLogix |
to tubbynet
said by tubbynet:95th percentile billing isnt 95% usage. its 95th percentile of peak speeds.
q. The explanation for how it was being used on security now as that the top 5% was dropped and of the 95% the top 5% was used as though it was the whole month rate. |
|
TomS_Git-r-done MVM join:2002-07-19 London, UK |
TomS_
MVM
2014-Aug-30 5:05 pm
Found the reference to this, and it came from Urs Holzel, someone who I'd be inclined to believe on a matter like this.
j.mp/1yjedJo
Starts from paragraph 3 and on to the next page.
Must be my understanding of 95% that is broken then! I'd have thought you would discard data points with a value of 0 so that you were only considering periods of time where there was actually data transfer. Seems not, at least in that case. |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ |
to DarkLogix
said by DarkLogix:The explanation for how it was being used on security now as that the top 5% was dropped and of the 95% the top 5% was used as though it was the whole month rate. interesting. while admittedly -- i've not seen anyone try to game the system in such a fashion -- in working with carriers -- this would really piss me off. high throughput for an uncontrolled 36 hours of any month could potentially skew my traffic profiles -- especially if i'm on a hard commit with my carriers. q. |
|
DarkLogixTexan and Proud Premium Member join:2008-10-23 Baytown, TX |
said by tubbynet:said by DarkLogix:The explanation for how it was being used on security now as that the top 5% was dropped and of the 95% the top 5% was used as though it was the whole month rate. interesting. while admittedly -- i've not seen anyone try to game the system in such a fashion -- in working with carriers -- this would really piss me off. high throughput for an uncontrolled 36 hours of any month could potentially skew my traffic profiles -- especially if i'm on a hard commit with my carriers. q. I would bet that if the carrier caught on they'd ask legal to review the contract to see if they can adjust their method a little (like dropping time that its disconnected or zero use times) |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ |
to TomS_
said by TomS_:But as tubby says, in order to be more strict, they really need to be shaping towards you. Thats the only way to ensure packets are dropped before they hit the wire. bingo -- especially if they use things like netflow telemetry to extract billing info (or will at some point). my fear is that (being a mom/pop shop) -- they are simply using "enterprise kit" in an area that demands s/p level granularity. q. |
|
|
meta
Member
2014-Sep-1 9:33 am
I would bet cash that the mom/pop gear does not support shaping in any meaningful sense, but still should be able to hard police. Not all of us have asr9k's laying around... Also dont forget the high probability that small shops lack the QOS skillset in their techies to effectively/accurately design/deploy/operate/monitor it. |
|
|
said by meta:I would bet cash that the mom/pop gear does not support shaping in any meaningful sense, but still should be able to hard police. I think you probably nailed it. This is why they only offer three speeds on their business fiber - 10megs 100megs and 1gig. To accomplish that I think they are using media converters to copper ports lol |
|