Re: The Cidr Report
Hello Stephen, any thoughts on how to fix it? back to the smallest allocation per /8 that the RIRs have published and make it part of the MoU at the larger NAPs/exchange points. at the large end i'm still without an explanation as to why large networks require so many prefixes - none of them seem to comment? Commercial reasons? The traffic goes to the 32x/24 instead of the /19. Not to mention the BGP customer may go to another provider. You end up in discussions (if you get that chance at all) with your sales group and look like a dogmatic fool as other companies do this. Saving the world works best if the pain is no one's fault - at least not my fault ;-) Regards, Marc -- Marc Binderberger[EMAIL PROTECTED]
Re: why upload with adsl is faster than 100M ethernet ?
Hi Joe, divide et impera :-) Put a (FTP-)server in _your_ network to get an idea if the problem is with the edge device (or somewhere in your network) or on the WAN to Japan. The PING may not tell you much about short-term queue problems in a device. As Mikael Abrahamsson wrote use a sniffer (Ethereal, tcpdump, ...) and search for retransmissions, i.e. some breaks in a monotonic increasing sequence number sequence or such. We had a similar issue when E1 customers had been fine but customers on the same router with 10Mbit/s and above complained. Took us some memory/queue fine-tuning of the 7500 box to get it right, traffic on the higher speed link probably was more bursty and this flooded some buffers then. On Oct 15, 2004, at 10:14 Uhr, Joe Shen wrote: Hi, the network path is: |-(ADSL)\ customer/ --Edge_router---...---Japan Server \-(100Methernet)-/ So, from edge_router to Japan server the path is identical. Regards, Marc -- Marc Binderberger[EMAIL PROTECTED]
Re: why upload with adsl is faster than 100M ethernet ?
On Oct 15, 2004, at 14:24 Uhr, Alex Bligh wrote: I can't remember what the tool is now, but there used to be a tool which worked like ping but sent a udp stream at a given rate per second and told you about packet drops, iperf? (works for both, tcp and udp) Regards, Marc -- Marc Binderberger[EMAIL PROTECTED]
Re: CCO/cisco.com issues.
Charles, Let's add a very important line: Then They Came for the OC-3 or smaller connections and I did not speak out because I run fat OC-12 - OC-48 pipes which doesn't help you much today. I've seen attacks of around a Gbit/s bandwidth. So a OC-48 is already in danger. The OC-12 is useless. And _of course_ the top providers have OC-192 everywhere ... . It's my guess that the top providers that ignore cries for help because they can sink the traffic (and bill for it) and get complains from customers because the Internet access doesn't work as promised. Ignoring this in a competitive market is no option. A least not for a longer time. What is underestimated is the difficulty to detect an attack and the details of it. Fortunately tools like Arbor or Riverhead exist meanwhile but even then it's often reactive for smaller customers. From my impression top providers spent the money for such tools although there is no direct/obvious revenue impact (read: gain). I would name this a responsible behavior for commercial companies. I hope we don't have to wait until that time comes around to figure out how to cooperate. There is cooperation. Maybe not that much on list like NANOG but Hank mentioned already a non-public list which succeeded in building the trust to cooperate with other providers. Without the risk to see your issues on news.com the next day. Just because it doesn't appear on NANOG doesn't mean nobody takes care :-) Regards, Marc -- Marc Binderberger[EMAIL PROTECTED]Powered by *BSD ;-)
Re: MPLS ICMP Extensions
As far as I remember we have seen labels from other providers, until they turned on the traceroute hide. And there was no LDP coupling between them and us so ... . That was with Cisco in both networks. The question is if these information cause any problem for you - despite curious customers asking ;-) The labels seem to be allocated from a start value - usually 20, 1024, 4096 or such, depending on your system, OS version - in an incremental order, so guessing labels isn't that difficult. If your network accepts labels although it shouldn't then the extra information in ICMP doesn't really make things worse anymore. Marc On Thursday, August 14, 2003, at 08:39 PM, Leo Bicknell wrote: In a message written on Thu, Aug 14, 2003 at 01:21:28PM -0500, Mike Bernico wrote: Maybe I'm wrong, but I thought that the extended MPLS info only showed up when the trace was started on a PE or P router. Is that right? I did the traceroute from a router with _NO_ mpls commands turned on, and it's on a network that uses _NO_ mpls today. Basically from reading the draft if the router that generates the ICMP unreachable received the packet with an MPLS label, it adds the MPLS info to the returned data. As long as your traceroute can parse/show it (so far I've only confirmed Juniper can do it), it will be displayed to the world. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org mime-attachment -- Marc Binderberger[EMAIL PROTECTED]Powered by *BSD ;-)
