> Yes, and no.
>
> If you are a given a limited resource (in this case, a physical port that
> can process no more than 1gbps for example) and your efficiency in
> transferring data over that port is not 100%, the provider itself is not to
> blame. Each and every protocol has limitations, and in t
-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 you
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).
Con
>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
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
anyw
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, t
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 bgp-st...@lists.ap
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
busines
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 our
On Fri, Oct 31, 2014 at 12:39 PM, Jared Mauch 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 design to ensure that
On 31 October 2014 18:32, Zachary Frederick 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
> Comcast Enterprise Fibe
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
-Origin
+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" wrote:
>If you're selling to end us
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=1460&rtt=80&loss=1e-06&bw=25&rtt2=35&win=64&Calculate=Calculate
But that's only if either endpoint is stuck at a 64 KB receive window. A
quic
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 wrote:
>
> 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/n
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 hu
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 o
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 variou
Replying off-list as requested.
John
On Fri, Oct 31, 2014 at 1:41 PM, 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
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 t
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
Date
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, Intern
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 h
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 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=AS201640&view=2.0
>http://www.cidr-report.org/cg
> So who do we ask about making IRRs expire defunct objects
you might start with a rigorous definition of defunct
randy
Hit a strange route issue earlier transiting Level3 network to GTT - Packet
Loss & High Latency - caused some interruptions in critical traffic flow.
Between Level3 hop 4.68.63.158 and GTT 144.136.105.226 - had a 20ms latency
increase and packet loss. After about 1+ hours the route had shifted and
While it's not a thorough list of all announcements, here are nightly
snapshots courtesy of http://bgp.he.net
AS201640: http://pastebin.com/nvuVbnpn
AS22: http://pastebin.com/1JZnWadD
--
Rob Mosher
Senior Network and Software Engineer
Hurricane Electric / AS6939
On 10/31/2014 11:57 PM, Ron
31 matches
Mail list logo
