dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
1382
wirelessdog
join:2008-07-15
Queen Anne, MD

wirelessdog

Member

Limited Port Speed

So 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.
markysharkey
Premium Member
join:2012-12-20
united kingd

markysharkey

Premium Member

Use a policy-map / class map to rate limit / police the interfaces.

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix to wirelessdog

Premium Member

to wirelessdog
I thought some SFP's couldn't do anything other than gig and thus would just have to be ratelimited.
wirelessdog
join:2008-07-15
Queen Anne, MD

wirelessdog to markysharkey

Member

to markysharkey
Any chance you can provide an example?

DaSneaky1D
what's up
MVM
join:2001-03-29
The Lou

DaSneaky1D to wirelessdog

MVM

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.

tubbynet
reminds me of the danse russe
MVM
join:2008-01-16
Gilbert, AZ

tubbynet to wirelessdog

MVM

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.
wirelessdog
join:2008-07-15
Queen Anne, MD

wirelessdog

Member

This shapes the output. How can I limit the input if the upstream provider does not know how?
wirelessdog

wirelessdog to DaSneaky1D

Member

to DaSneaky1D
I thought the bandwidth statement was informational only and didn't really have any effect on anything...

tubbynet
reminds me of the danse russe
MVM
join:2008-01-16
Gilbert, AZ

tubbynet

MVM

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.
wirelessdog
join:2008-07-15
Queen Anne, MD

wirelessdog

Member

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

tubbynet
reminds me of the danse russe
MVM
join:2008-01-16
Gilbert, AZ

1 edit

1 recommendation

tubbynet

MVM

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]

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix

Premium Member

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

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...

DaSneaky1D
what's up
MVM
join:2001-03-29
The Lou

DaSneaky1D to tubbynet

MVM

to tubbynet
Good clarification of the method I suggested

tubbynet
reminds me of the danse russe
MVM
join:2008-01-16
Gilbert, AZ

tubbynet to DarkLogix

MVM

to DarkLogix
95th percentile billing isnt 95% usage. its 95th percentile of peak speeds.

q.
tubbynet

tubbynet

MVM

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

Something is broken, code tags are not formatting properly.

tubbynet
reminds me of the danse russe
MVM
join:2008-01-16
Gilbert, AZ

tubbynet

MVM

my original post had a hanging tag.
should be fixed now.

q.
wirelessdog
join:2008-07-15
Queen Anne, MD

wirelessdog to tubbynet

Member

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...

tubbynet
reminds me of the danse russe
MVM
join:2008-01-16
Gilbert, AZ

tubbynet

MVM

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.
wirelessdog
join:2008-07-15
Queen Anne, MD

wirelessdog

Member

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

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.

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix to TomS_

Premium Member

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

DarkLogix to tubbynet

Premium Member

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

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.

tubbynet
reminds me of the danse russe
MVM
join:2008-01-16
Gilbert, AZ

tubbynet to DarkLogix

MVM

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.

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix

Premium Member

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)

tubbynet
reminds me of the danse russe
MVM
join:2008-01-16
Gilbert, AZ

tubbynet to TomS_

MVM

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
join:2004-12-27
00000

meta

Member

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.
wirelessdog
join:2008-07-15
Queen Anne, MD

wirelessdog

Member

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