-Oorspronkelijk bericht-
Van: NANOG [mailto:nanog-boun...@nanog.org] Namens Joe Greco
Verzonden: Friday, October 31, 2014 12:02 PM
Aan: Rafael Possamai
CC: keith tokash; nanog@nanog.org
Onderwerp: Re: Industry standard bandwidth guarantee?
...
A silly example would be this: you fill your
Please contact me offline about a misbehaving filter.
signature.asc
Description: OpenPGP digital signature
And if you look at it from the provider's prospective, they have lots of
customers who want 12 gallons of gas worth of driving time, but only
want to pay for 11 gallons (or worse, went to gasspeedtest.net and it
showed their purchased gas only gave them 10 gallons worth of driving time).
That *is* a silly example.
A more proper analogy would be that you buy 12 gallons of gas, but the
station only deposits 11 gallons in your tank because the pumps are operated
by gasoline engines and they feel it is fine to count the number of gallons
pulled out of their tank instead of the
If you're selling to end users, under promise and over deliver. Tell them
20Mbit but provision for 25. That way when they run their speedtest,
they're delighted that they're getting more, instead of being disappointed
and feeling screwed. In practice they will leave it idle most of the time
In the recent past, we've had another provider in our same market
erroneously advertising prefixes for some of our customers.
After we got it cleared up, I noticed that there were some old
route objects in RADB that were entered for that provider years ago by
360. These route objects, in
On Fri, Oct 31, 2014 at 10:34:23AM -0700, Tim Howe wrote:
I've since found a disturbing number of defunct objects that
relate to my customers (and me) in a similar way, and I have mostly
had success in getting them cleared up. If my relatively small
customer base is any indication,
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.
Daily listings are sent to
I have a feeling this issue only occurs with residential customers, and
perhaps small businesses. It is most likely cheaper to over deliver in this
case then to maintain a larger call center and support team to attempt to
explain end users how TCP has limitations. No two large communication
We have been having a problem receiving software releases from our developer.
The releases are typically around 1G in size. The developer’s connection is a
100m metro fiber with TW Telecom, our connection is a 25m Comcast Enterprise
Fiber.
Our traffic graphs show very little utilization of
On Fri, Oct 31, 2014 at 12:39 PM, Jared Mauch ja...@puck.nether.net wrote:
[snip]
People tend to treat things like IRR (eg: RADB, etc) as a
garbage pit you toss things into and never remove from.
So who do we ask about making IRRs expire defunct objects and/or
changing their system
On 31 October 2014 18:32, Zachary Frederick zcfreder...@gmail.com wrote:
We have been having a problem receiving software releases from our
developer. The releases are typically around 1G in size. The developer’s
connection is a 100m metro fiber with TW Telecom, our connection is a 25m
We get this with wireless carriers -- they ask for quote for a 100 Mbps
Ethernet circuit, and then tell us afterwards that it's 100 Mbps of goodput,
so we have to size it to 125 Mbps to cover all their one MPLS and two 802.1Q
tags and to past the RFC 2544 test at 64-byte frames.
Frank
+1 on this exactly what we do, keeps the calls down.
Carlos Alcantar
Race Communications / Race Team Member
1325 Howard Ave. #604, Burlingame, CA. 94010
Phone: +1 415 376 3314 / car...@race.com / http://www.race.com
On 10/31/14, 9:56 AM, Laszlo Hanyecz las...@heliacal.net wrote:
If you're
With a max bandwidth of 25 Mbps and a 40ms RTT, the max is more like 14MB/s
or 1.75 Mbps.
https://www.switch.ch/network/tools/tcp_throughput/index.html?mss=1460rtt=80loss=1e-06bw=25rtt2=35win=64Calculate=Calculate
But that's only if either endpoint is stuck at a 64 KB receive window. A
quick
I apologize I should have said it starts out about 3 meg max and slows to about
400kpbs for most of the transfer.
On Oct 31, 2014, at 3:27 PM, John Neiberger jneiber...@gmail.com wrote:
With a max bandwidth of 25 Mbps and a 40ms RTT, the max is more like 14MB/s
or 1.75 Mbps.
Sounds like a combination of packet loss and small TCP receive windows. If
you can, grab a packet capture and make sure to get the TCP setup. That
should show you what's happening under the hood.
Also, I should mention that I totally hosed the units in my first reply.
:) That's what I get for
Similar to another thread on the list today, I'm troubleshooting a problem
for a customer on Comcast business fiber.
Downloading a file from one of our web servers is very slow (~15KByte/sec).
mtr looks clean in both directions. I added an IP address on the same
server from a different class C
Recommendations:
1) Use iperf in TCP mode to test the performance
2) use iperf in UDP mode to test the performance
This is the best way to quickly triage the issue and determine if
it's actual bandwidth issue or something else.
It's quite common for
Replying off-list as requested.
John
On Fri, Oct 31, 2014 at 1:41 PM, Mark Price mpr...@tqhosting.com wrote:
Similar to another thread on the list today, I'm troubleshooting a problem
for a customer on Comcast business fiber.
Downloading a file from one of our web servers is very slow
On Fri, 31 Oct 2014, Mark Price wrote:
Similar to another thread on the list today, I'm troubleshooting a problem
for a customer on Comcast business fiber.
Downloading a file from one of our web servers is very slow (~15KByte/sec).
mtr looks clean in both directions. I added an IP address on
On Fri, 31 Oct 2014 15:41:43 -0400, Mark Price said:
Similar to another thread on the list today, I'm troubleshooting a problem
for a customer on Comcast business fiber.
Downloading a file from one of our web servers is very slow (~15KByte/sec).
I recently hit a similar problem, tracked it
This report has been generated at Fri Oct 31 21:14:13 2014 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/2.0 for a current version of this report.
Recent Table History
BGP Update Report
Interval: 23-Oct-14 -to- 30-Oct-14 (7 days)
Observation Point: BGP Peering with AS131072
TOP 20 Unstable Origin AS
Rank ASNUpds % Upds/PfxAS-Name
1 - AS23752 201970 4.6%1655.5 -- NPTELECOM-NP-AS Nepal
Telecommunications Corporation,
I don't routinely follow this list, so I'm not sure how much of this is
common knowledge already, but...
http://blogs.cisco.com/security/talos/help-my-ip-address-has-been-hijacked/
Current route announcements for AS201640:
36.0.56.0/21 probable hijack - China
41.92.206.0/23probable
On 2014-10-31 17:20, Ronald F. Guilmette wrote:
P.S. If anybody is able to look up _all_ of the route announcements
that have been made by AS201640 over the past few months, I for one would
definitely like to see those.
Hello again, Ronald.
I don't know for certain that it's all-inclusive,
In message 54542174.30...@ghostnet.de,
Armin Kneip a...@ghostnet.de wrote:
http://bgpupdates.potaroo.net/cgi-bin/generate_as_log?as=201640
http://bgpupdates.potaroo.net/cgi-bin/generate_as_log?as=22
or
http://www.cidr-report.org/cgi-bin/as-report?as=AS201640view=2.0
So who do we ask about making IRRs expire defunct objects
you might start with a rigorous definition of defunct
randy
28 matches
Mail list logo
