Re: Hotmail blackholing certain IP ranges ?
Jeroen Wunnink wrote: Does anyone have a clue why hotmail is appearantly blocking certain IP ranges ? I provided a new server for a customer in his own IP subnet which is a part of a /20 we announce, but for some reason all mail sent to @hotmail.com addresses disappears. He has another server in a /24 we announce which is still part of another network and that works like a charm. None of our subnets are blacklisted in any spamfilter I can find, so i'm a bit puzzeled on what's up here. If any hotmail netadmin is reading this list, can you please check if 81.26.212.0/26 is blocked in any way (It's part of 81.26.208.0/20 originating from AS39556) According to the mailserver logs all the mail is properly accepted by the hotmail relays, never to be seen again after that. hotmail reportedly installed some new spam control lately. many ISPs and ESPs are reporting problems similar to what you describe (my employer is having such deliverability problems, for one.) SPF records, signing up for the MSN/Hotmail feedback loop, and opening a ticket with hotmail support are all things you can do. effectiveness is not guaranteed, and it's taking hotmail 3-4 days to respond to new tickets, they appear to be swamped. richard
Re: Cable-Tying with Waxed Twine
Confession time - I'm over 50 At 09:41 p.m. 24/01/2007 -0700, you wrote: As for plastic ties (TyRap is the brand name for the Thomas Betts version) they may be easy to use, but they do have several functional drawbacks, including: 1) difficulty in maintaining consistent tension from tie to tie, and as a correlary it is comparatively easy to overtighten one, risking compression-related damage to the underlying cabling, or as mentioned above, increasing crosstalk when using twisted-pair cables You can buy a cable-tie gun from Panduit, along with ties on a bandolier. They are used in appliance manufacture for making up wiring looms, instead of lacing them. The tension is programmable .You may also remember that in cars, the wiring harness was in a cloth jacket.. 2) can harden and/or become brittle over time, eventually failing under stress H'mm - you buy various grades of cable-tie. I have a lot of personal experience with a black Ty-Rap. Its black with a stainless-steel tag. The black makes it UV-stable and I get nervous if we don't have a few thousand in stock. I carry a few hundred in my van... White ties aren't UV stable and so are indoor rated only. Of course I live in a country where the weather report gives a UV rating each day, due to the Ozone depletion making a hole right above us - due to CFCs in aerosol can's. Thanks guysand girls. Get Joe Abley to tell you about CityLink over a few beers. But basically, its a 20Km metro fiber network suspended off the trolley bus wires. I built the fist 200 odd buildings, before we got staff. The fiber is attached to a synthetic rope (kevlar) which is the catenary wire, by a TyRap ty25 (from memory), every 300 mm. The way we work was my van pulled the trailer with the fiber drum, Ryan and Glenn were in the cherry-picker, moving from pole to pole. I was on the ground cable tying like mad. Ryan then pulled the cable up, tensioned it, made it fast,and we moved on. Been doing it since 1996. These days we use self supporting fiber, so run much faster, no cable ties until we overlay 3) typical background vibration causes them to tend to chafe the sheaths of the wiring that the ties are in direct contact with, over a period of years. buy the ones with stainless tags - they last for years. The cheap plastic ones are toys Lacing is a lot slower than using platic ties, and doing it is rough on your fingers. If you're lucky you know a data tech who can show you how to do it properly, it's really not something that you can just describe in writing. Depending upon the specific need, contact points may also have pieces of fish paper laced to them before the wiring is laid out and laced into place. Not unusual to see this when DC power cables are being secured. H'mmm - the DC cables I'm used to are the size of your arm - per polarity.we don't lace them, just bury them. But sorry - I'm old and been around. I worked in a power utility for 14 years. BTW Broadband over Power - we call ripple control. It turns on the street lights, load control etc. Been doing it for years and its not hard to go both ways. Zellweger in Uster Switzerland used to make the cool stuff. I have photos somewhere. We also inject DC into the AC network, but thats another beer or two. First you have to work out why the utilities use AC.. Rich
Re: Network end users to pull down 2 gigabytes a day, continuously?
At 09:50 a.m. 15/01/2007 -0500, Gian Constantine wrote: The problem with this all (or mostly) VoD model is the entrenched culture. In countries outside of the U.S. with smaller channel lineups, an all VoD model might be easier to migrate to over time. In the U.S., where we have 200+ channel lineups, consumers have become accustomed to the massive variety and instant gratification of a linear lineup. If you leave it to the customer to choose their programs, and then wait for them to arrive and be viewed, the instant gratification aspect is lost. This is important to consumers here. While I do not think an all or mostly VoD model will work for consumers in U.S. in the near term (next 5 years), it may work in the long term (7-10 years). There are so many obstacles in the way from a business side of things, though. I don't see many obstacles for content and neither do other broadcasters. The broadcast world is changing. Late last year ABC or NBC (sorry brain fade) announced the lay off of 700 News staff, saying news is no longer king. Instead they are moving to a strategy similar to that of the BBC. ie lots of on-demand content on the Internet. Rich
Re: Network end users to pull down 2 gigabytes a day, continuously?
At 08:40 p.m. 9/01/2007 -0500, Gian Constantine wrote: It would not be any easier. The negotiations are very complex. The issue is not one of infrastructure capex. It is one of jockeying between content providers (big media conglomerates) and the video service providers (cable companies). We're seeing a degree of co-operation in this area. Its being driven by the market. - see below. snip On Jan 9, 2007, at 7:57 PM, Bora Akyol wrote: An additional point to consider is that it takes a lot of effort and to get a channel allocated to your content in a cable network. This is much easier when TV is being distributed over the Internet. The other bigger driver, is that for most broadcasters (both TV and Radio), advertising revenues are flat, *except* in the on-line area. So they are chasing on-line growth like crazy. Typically on-line revenues now make up around 25% of income. So broadcasters are reacting and developing quite large systems for delivering content both new and old. We're seeing these as a mixture of live streams, on-demand streams, on-demand downloads and torrents. Basically, anything that works and is reliable and can be scaled. (we already do geographic distribution and anycast routing). And the broadcasters won't pay flash transit charges. They are doing this stuff from within existing budgets. They will put servers in different countries if it makes financial sense. We have servers in the USA, and their biggest load is non-peering NZ based ISPs. And broadcasters aren't the only source of large content. My estimate is that they are only 25% of the source. Somewhere last year I heard John Chambers say that many corporates are seeing 500% growth in LAN traffic - fueled by video. We do outside webcasting - to give you an idea of traffic, when we get a fiber connex, we allow for 6GBytes per day between an encoder and the server network - per programme. We often produce several different programmes from a site in different languages etc. Each one is 6GB. If we don't have fiber, it scales down to about 2GB per programme. (on fiber we crank out a full 2Mbps Standard Def stream, on satellite we only get 2Mbps per link). I have a chart by my phone that gives the minute/hour/day/month traffic impact of a whole range of streams and refer to it every day. Oh - we can do 1080i on demand and can and do produce content in that format. They're 8Mbps streams. Not many viewers tho :-) We're close to being able to webcast it live. We currently handle 50+ radio stations and 12 TV stations, handling around 1.5 to 2million players a month, in a country with a population of 4million. But then my stats could be lying.. Rich (long time lurker)
Re: Network end users to pull down 2 gigabytes a day, continuously?
At 08:58 a.m. 10/01/2007 -0500, Gian Constantine wrote: All H.264? no - H.264 is only the free stuff. Pretty well its all WindowsMedia - because of the DRM capabilities. The rights holders are insisting on that. No DRM = no content. (from the big content houses) The advantage of WM DRM is that smaller players can add DRM to their content quite easily and these folks want to be able to control that space. Even when they are part of an International conglomerate, each country subsidiary seems to get non-DRM'ed material and repackage it (ie add DRM). I understand this is how folks like Sony dish out the rights - on a country basis, so each subsidiary gets to define the business rights (ie play rights) in their own country space. WM DRM has all of this well defined. Rich
Re: New router feature - icmp error source-interface [was: icmp rpf]
On Mon, Sep 25, 2006 at 09:22:34AM -0400, Patrick W. Gilmore wrote: On Sep 25, 2006, at 9:06 AM, Ian Mason wrote: ICMP packets will, by design, originate from the incoming interface used by the packet that triggers the ICMP packet. Thus giving an interface an address is implicitly giving that interface the ability to source packets with that address to potential anywhere in the Internet. If you don't legitimately announce address space then sourcing packets with addresses in that space is (one definition of) spoofing. Who thinks it would be a good idea to have a knob such that ICMP error messages are always source from a certain IP address on a router? You know I was just having this discussion with someone else a couple days ago. It turns out, much to my surprise, that the RFC actually calls for the ICMP error-message packet (as you said, the things that aren't ping etc which require a specific source-address) to originate from the OUTGOING interface used to return the ICMP message to the original sender. After much googling, I can't find any document where this has ever been officially updated either. The defacto industry standard on the other hand has been to use the primary address of the inbound interface, which serves exactly one function: it makes traceroute work. The hack that people use to simulate this functionality normally is: ip address the.fake.ip.here 255.255.255.252 ip address the.real.ip.here 255.255.255.252 secondary (FYI side note the Juniper equivilent is... confusing or non-working, hard to tell which. The tag primary is defined as the source address for local broadcast/multicast, preferred is defined as the source when you have multiple IPs within a subnet. Neither one should work for what we're talking about according to the docs, but if you actually try it... sometimes it works, sometimes it won't, and sometimes the behavior is different if you include only one but not the other :P). This works well for simple external-facing interfaces, things that speak BGP for example, but can confuse things like OSPF etc when you use secondaries on internal interfaces. FWIW I've been asking for more people to implement exactly what you're talking about for years (specifically setting ONLY the ICMP error source interface without risk of screwing up the interface in other ways). You can debate over exactly how to do it (global or per interface, icmp source-interface lo99 vs icmp source-ip 1.2.3.4, etc), but I agree wholeheatedly it should be done. It should be really simple too! (Unless, of course, I get 726384 you are off-topic replies, in which case I withdraw the suggestion.) Please stop talking about networking on NANOG, you're confusing people. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: New router feature - icmp error source-interface [was: icmp rpf]
On Mon, Sep 25, 2006 at 04:33:18PM -0700, David Temkin wrote: C and J both already have a similar feature, however I'm not sure whether or not they apply to ICMP. They both support PBR for locally originated packets - which, should include if the thought process is correct, ICMP. Perhaps someone with some time to waste can verify this in a lab. http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1828/products _configuration_guide_chapter09186a00800ca590.html#5406 The actual path taken for the ICMP generated by the router does not matter, we're just talking about the source address selected by the router. The only reasons that the source address (which reveals a real IP address on a router) matters at all for ICMP error responses are: * So traceroute works (current industry standard behavior is to use the ingress interface IP so you see the forward path in traceroute, not the reverse path, which may be asymmetric. * So your replies don't get thwacked by people doing uRPF strict (i.e. they must come from announced IPs or people doing strict strict with no exception filtering capabilities will block the traceroute responses). * Optionally, allowing naive tools like MTR to ping the IP they discover via traceroute, lest weenies flood your noc with I'm pinging 10lolz! emails. Revealing your interface IPs carries all kinds of DoS/security risks with it, since there are a great many routers out there without good control plane policing functionality (and even some of those that have it, don't really have it :P). Since there is really no legitimate need for people from the outside world to ever communicate with your real interface IPs at all (with the exception of some rate limited ICMP echo/reply due to aforementioned mtr weenies), having the option to hide those real addresses completely in ICMP source address selection is a very good thing for enhancing network security. As I said you can accomplish part of this hack with primary/secondary IPs on interfaces. You can also accomplish some level of filtering by numbering your interfaces out of common blocks which are filtered at your various borders/edges. It's still a pain in the !(*#*, especially if you number your links out of any regional blocks to cut down on asymmetric routing confusion, or have any number of peers who provide /30s from their own IP space. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: New router feature - icmp error source-interface [was: icmp rpf]
On Mon, Sep 25, 2006 at 08:45:49PM -0400, John Curran wrote: At 9:22 AM -0400 9/25/06, Patrick W. Gilmore wrote: Who thinks it would be a good idea to have a knob such that ICMP error messages are always source from a certain IP address on a router? It certainly would beat the alternative of no response at all, but one would hope it wouldn't become common practice since it reduces the information returned (e.g. during a traceroute, you'd lose the sometimes useful information from in-addr about what particular interface was involved). Personally I'd hope that if it was implemented, it would support mapping on a per-interface basis (especially for NSP use). That should in theory lead to even more accurate information, since each network would be capable of easily renumbering without impact, and managing their own DNS for every interface. Currently a great many PTRs are out of date because IP blocks supplied by peers, exchange points, or transit providers, are too much of a pain to keep updated when interfaces move etc. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: New router feature - icmp error source-interface [was: icmp rpf]
On Tue, Sep 26, 2006 at 02:51:21AM +, Fergie wrote: So, I'm wondering: What happens when you have a traceroute tool that shows you MPLS-lableled hops, too? :-) http://momo.lcs.mit.edu/traceroute/index.php The best (?) of both worls, but I digress... That doesn't show any more or less data about the path, just some extra info about the label that is effectively useless to end users. If TTL decrement is not enabled, all of the IP hops are hidden by the tunnel, which is the point Chris was making. But that said, I personally think Cisco MPLS with TTL decrement enabled but returning the the same rtt as the penultimate hop for every IP hop inside the LSP has caused far more harm to every NOC ticket queue on the planet than just hiding the damn things. While we're asking for silly features, I can name a LOT of people who would pay good money for a dedicated ICMP generating processor on Cisco that doesn't spike every time BGP scanner runs. Silencing end users who have figured out how to work traceroute (or worse MTR) is worth its weight in gold. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: tech support being flooded due to IE 0day
On Thu, Sep 21, 2006 at 08:06:13PM -0500, Gadi Evron wrote: Hi guys, several ISP's are experiencing a flood of calls from customers who get failed installations of the recent IE 0day - VML - (vgx.dll). If you are getting such floods too, this is why. This is currently discussed on the botnets@ list, as raised by Cox, and I figured I will float it out here. No patch is currently available from Microsoft, workaround are available. Ok I'll admit I've been reading less and less of this godforsaken list with each passing day, but at what point did we change the name to North American Network Tech Support Operators Group? Was the memo distributed via HTML e-mail only or something? Maybe it was redacted from the archives so I didn't see it... Seriously Gadi, what *possible* relevence could this have to network operations? -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: tech support being flooded due to IE 0day
On Fri, Sep 22, 2006 at 12:11:33AM -0400, Jared Mauch wrote: Does it impact the network operation? Eg, does it adversely affect the network? (say, like Beagle did.) I was thinking sql-slammer, massive flood causing signifcant amount of network infrastructure to go down. (people on low speed links with large blocks of address space were DoS'ed off the network). I don't think of drive-by browser/desktop infection as a networking issue, more of an end-host issue. Even more to the point, a lot of people with network infrastructure that couldn't handle random destination traffic were affected. Such impact is precisely the kind of thing that should be discussed on NANOG, both from an operational how do we deal with this and a design what you should know about your gear when it doesn't have a prepopulated table in its fast path perspective. A web browser crapping out has nothing to do with networks, or network operations. I'm not aware of any network of any consequence where the people who run, design, or build the infrastructure have any relationship to end user tech support call centers. I'm sure there are many fines places where this particular issue is great on-topic discussion, but since as Gadi said it not only has nothing to do with BGP but nothing to do with networks at all, this just isn't it. To the people who say we throw in the towel and just say Gadi will never stop posting off-topic crap, so why bother trying to correct him?, I'd suggest that this is a self-defeating attitude. Not only because Gadi could actually be posting useful stuff if set on the right path as to what is appropriate and what is not, but because 10,000 other people are going to be reading that post and thinking that this is appropriate subject matter. One off-topic post you can delete, but an entire list which has been co-opted by off-topic material can not be fixed. Unless we're ready to admit that NANOG is completely and totally worthless as a forum for discussing network operations, people NEED to step up and take responsibility for the self policing that we're all supposed to be doing in srh's absence. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Removal of my brain
[EMAIL PROTECTED] wrote: Hrmm How many of you realize who Bill Manning is ? While you are at it, go flame Vinton Cerf... I am sure he will learn from you, too..
Re: Removal of my brain
/signalnoise That said, I admit I probably hesitate a bit longer before flaming Dr. Cerf. :) If you've ever met them both, you would understand why. I have, on more than one occasion. My old address was @onecall.net Perhaps you saw our cars in the Indy 500 ? Vint does present a smaller target most days. :) Well, there *is* the Atkins diet. ;-) C-ya. /noisesignal? --bill -- TTFN, patrick
Re: Kremen's Buddy?
On Tue, Sep 12, 2006 at 06:55:11PM -0400, Joe Abley wrote: I find the references to alleged, inherent difficulties with the ARIN resource assignment process increasingly tedious. Even if the templates were impossible to decipher, this isn't the forum to discuss them. In my opinion, you do the argument in favour of open trading of addresses as commodities a rank disservice by linking it to this kind of FUD. Ever notice the only folks happy with the status quo are the few who have already have an intimate knowledge of the ARIN allocation process, and/or have the right political connections to resolve the issues that come up when dealing with them? Try looking at it from an outsider's point of view instead. If you're new to dealing with ARIN, it is not uncommon to find the process is absolutely baffling, frustrating, slow, expensive, and requiring intrusive disclosure just shy of an anal cavity probe. In any kind of free market system, competition would have bitchslapped the current ARIN way of doing things a long, long time ago. Personally I find the single most compelling reason to move to IPv6 to be the removal of any justification for ARIN's continued existance in its current form. Somehow I suspect the only folks who wouldn't welcome this are the ones who benefit from the one thing ARIN is actually good at doing, namely paying for frequent business class travel and accomodations to exotic locations around the world under the pretense of meetings. Hrm guess I had better offer dinner in St Louis is on me for whichever one of my friends on the ARIN travel plan complains about this post first. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: [OT] Connexion {Was: Re: [routing-wg]BGP Update Report}
On Sun, Sep 10, 2006 at 12:24:52PM -0400, Steven M. Bellovin wrote: On Sun, 10 Sep 2006 09:08:56 -0500, Netfortius [EMAIL PROTECTED] wrote: Just wondering this, myself. I travel fairly frequently between US and Europe, and Lufthansa was recently my choice, exclusively because of this service. Perhaps with the interdiction of computing devices on board (have not travelled since the UK incident, so I am not sure if the new rules of flying naked affect all flights?!?) there won't - obviously - be much of a need for an Internet connection ... The main issue, from what I read, is that too few airlines followed suit. In particular, most American airlines were far too strapped financially to invest in the necessary equipment. Duh. Did you ever read the numbers for Connexion? They managed to design a system which cost the airlines up to $1mil per plane to install, and only generated $80k/yr/plane total revenue (thats Boeing revenue not airline revenue). They had an opex of something like $150mil/yr on total revenue of $11mil/yr. Obviously there is no such thing as an FAA certified $50 Linksys WRT54G, but it never fails to amaze me how people are utterly shocked when reality catches up with their wild, unchecked, and stupid spending. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: TCP receive window set to 0; DoS or not?
On Thu, Sep 07, 2006 at 11:28:47PM -0700, Jim Shankland wrote: Richard A Steenbergen [EMAIL PROTECTED] writes: Advertising a window of 0 is a perfectly valid way of telling the other side that you are temporarily out of resoruces, and would like them to stop sending you data Except that that's not what's going on here. This message appears when the TCP peer shrinks the window, withdrawing a previously granted permission to send bytes -- a protocol violation. For example, you're free to tell me (with your window advertisement) that you're authorizing me to send you 32K bytes, and then, after I've sent you 32K bytes, to close the window until you're ready to accept more. You're not free to tell me it's OK to send 32K bytes, then change your mind and advertise a window size of 0 after I've sent you only 16K bytes. Ok, looking at the error condition in further detail I do believe that you're righ. So, per RFC1122: 4.2.2.16 Managing the Window: RFC-793 Section 3.7, page 41 A TCP receiver SHOULD NOT shrink the window, i.e., move the right window edge to the left. However, a sending TCP MUST be robust against window shrinking, which may cause the useable window (see Section 4.2.3.4) to become negative. It is a warning message generated by a SHOULD NOT violation, during the MUST be robust against this behavior section of code. Looking at other such messages in the Linux kernel which are wrapped in #ifdef TCP_DEBUG, they all appear to be equally esoteric and probably not worth mentioning to the end user. However it looks like TCP_DEBUG is enabled by default (don't ask me why), which when combined with a relatively inane message using alarm provoking words, serves only to confuse. :) To address the DoS question, I don't see how this protocol violation enables a DoS attack. More likely, it's simply somebody's buggy TCP stack misbehaving. That somebody is unlikely to be Windows, MacOS, FreeBSD, or Linux. My money is on some flavor of $50 NAT/home router box. Did a little poking into this condition on other platforms as well, and as previously mentioned it does appear to be fairly contained to mobile devices (not sure which ones though). I guess if you have a small portable device with limited memory, this may be an issue. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: TCP receive window set to 0; DoS or not?
On Thu, Sep 07, 2006 at 03:04:58PM -0700, [EMAIL PROTECTED] wrote:
I've been seeing some systems that stop serving pages, and I also see
the Linux Treason Uncloaked! kernel messages that indicate a remote
system reduced its rcv win from 1 to 0... is there a non-malicious
explanation for this, aside from a remote host running out of socket
buffers? Seems to happen too often for that to be the case, and
my googling has shown that it may be outside of spec. Certainly
the warning is clear enough...
I've seen this, quite a bit, on some heavy traffic web clusters. Some
impolite web browsers will shrink the TCP window to kill the socket
connection instead of a proper fin/reset.
Advertising a window of 0 is a perfectly valid way of telling the other
side that you are temporarily out of resoruces, and would like them to
stop sending you data. This can be caused by any number of things, from a
completely bogged down box, to an application which isn't read()ing off
its socket buffer (thus for all intents and purposes the kernel is out of
resources to buffer any more data for that socket). It doesn't kill the
TCP session, it just throttles it back. The sender then goes into problem
the zero window mode, waiting for this condition to go away. It is
described in RFC 1122 section 4.2.2.17:
Probing of zero (offered) windows MUST be supported.
A TCP MAY keep its offered receive window closed
indefinitely. As long as the receiving TCP continues to
send acknowledgments in response to the probe segments, the
sending TCP MUST allow the connection to stay open.
etc etc etc
Looking at the Linux code which calls the error message (tcp_timer.c
tcp_retransmit_timer()), the condition which triggers it is:
if (!tp-snd_wnd !sock_flag(sk, SOCK_DEAD)
!((1 sk-sk_state) (TCPF_SYN_SENT | TCPF_SYN_RECV))) {
/* Receiver dastardly shrinks window. Our retransmits
* become zero probes, but we should not timeout this
* connection. If the socket is an orphan, time it out,
* we cannot allow such beasts to hang infinitely.
*/
It looks like it is just detecting this condition and changing its
behavior in accordance with the RFC. Since the actual print of the message
is wrapped in #ifdef TCP_DEBUG, it probably isn't intended to be displayed
to end users at all. As for the cute Treason Uncloaked message, thats
what you get for running an OS written by/for 14 year olds. :)
Or at least thats make 15 minute take on it, having not touched Linux
(gleefully) in many, many years.
--
Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: NNTP feed.
On Wed, Sep 06, 2006 at 04:29:54AM +0200, Daniel Roesen wrote: If folks would end abusing NNTP for file distribution via flooding, the matter would quickly be resolved. Am i naive? There is a reason Usenet hasn't gone the way of Gopher, and I assure you it isn't because of the the copious spam, net kooks, and trolls. There is a certain type of content that people want, and I'll give you one guess what that is... If you don't carry that content, you'll probably be doing more traffic in backscatter on the IP space then you will in NNTP. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Is it my imagination or are countless operations impacted today with mysql meltdowns
On Sun, Aug 27, 2006 at 08:04:01AM +0930, Mark Smith wrote: On Sat, 26 Aug 2006 12:48:39 -0700 (PDT) Henry Linneweh [EMAIL PROTECTED] wrote: Every where I go that uses MySql is hozed and I can not access the pages -Henry There seems to have been a big fault over there that is effecting us here in .AU. According to our local upstream it's a GLX fault, and by it's duration, it seems to have been a big one - I was told about it more than 12 hours ago. Examples of sites customers are having trouble accessing are : I think you're referring to an issue of blackholed packets between GX (3549) and Singtel (7473) in LA, for packets going to Optus (4804) (which for some reason appear to not be announced to normal Singtel peers). I don't think this was GX's fault actually, but I'm not sure if the issue extended beyond 3549-7473. At any rate this has nothing to do with MySQL faults or off-topic posts, and it is venturing dangerously close to actually talking about routing issues. We'd best change the subject to spam or botnets or something, before somebody gets the wrong idea about this list. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: ams-ix - worth using?
On Thu, Aug 24, 2006 at 11:33:17PM +0200, Gunther Stammwitz wrote: Costs for leased lines from the states to either Linx, Ams-Ix or DE-Cix are all more or less the same. You should chose the ixp from you can benefit most. DE-Cix has done a lot in the past few months to attract more members from eastern Europe. Because of its position just in the middle of Europe you should have the best coverage to western as well as eastern Europe. A short comparison: Exchange / Traffic on public exchange vlan / Number of members LINX: ~ 77 Gbps / 210 members AMS-IX: ???* Gbps / 244 members DE-CIX: 51 Gbps / 184 members * = the webpage says about 110 Gbps but as far as I know a lot of Dutch isps are carrying some sort of mirror-traffic over the ams-ix because of legal monitoring reasons (correct me if I'm wrong) Without getting in the middle of the eternal contest over who is better, LINX or AMS-IX (each has its own advantages and disadvantages), the AMS-IX website says 165Gbps, the LINX website says 95Gbps (actual publicly switched traffic), and the DECIX website says 71Gbps. Some portion of the AMS-IX traffic seems to be Dutch-specific content that stays in the country, but there is plenty of global traffic there too. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: AW: ams-ix - worth using?
On Fri, Aug 25, 2006 at 06:56:56AM +0300, Hank Nussbacher wrote: On Thu, 24 Aug 2006, Gunther Stammwitz wrote: Exchange / Traffic on public exchange vlan / Number of members LINX: ~ 77 Gbps / 210 members AMS-IX: ???* Gbps / 244 members DE-CIX: 51 Gbps / 184 members I'm curious if any US based IXs exceed 100Gbps. Or has Amsterdam and London become the center of the Internet universe? Not everyone publishes their traffic stats, some pseudo-publically, and some not at all. The total for every Equinix Exchange in the US (thats Ashburn, New York Metro, Chicago, Dallas, San Jose, and Los Angeles) combined is currently only 93Gbps peak (a huge upsurge since they launched a 10GE product several months back, it was at 40Gbps before that). Equinix is pretty much the vast majority of interesting public peering in the US today, with the closest runners-up being PAIX Palo Alto (numbers unpublished, but speculation is around 35Gbps), followed by NYIIX (16Gbps). It is probably safe to speculate that AMSIX is as large or larger than all of the public peering in the US combined. Why the difference? Well for starters, the US exchange points are typically priced at 3-6x the equivilent sized port at LINX AMSIX DECIX etc, so it just doesn't make economic sense for most US networks to peer publically. Also, US exchange points are almost all run by commercial facility operators who use the ix's to promote colocation and crossconnects in their facilities, vs the European exchange points who are colocation facility neutral. The US IX operators are not motivated to promote as many people as possible on the exchanges, since this just means increased costs of operating the switches with no new colo and reduced crossconnect revenue. They're satisfied with keeping the exchanges priced at a premium, as an entry level point for new users and low speed peer aggregator for bigger networks, and then making everyone else use private peering. Thus the vast majority of peering in the US happens via private interconnection instead of via public peering. Of course this is a self feeding cycle too, because of the low cost and ease of entry there are hundreds of networks of every ilk peering at the European exchanges, which means there are far more open-peering people compared to the US exchanges. This makes it very attractive for even US based companies to get started peering with a pseudowire to Europe, compared with going to a US exchange. Also, not that it matters (because the absurdly high pricing has kept new customer turnup at an absolute minimum), but most of the facilities where the US exchange points are run from are currently sold out, particularly to new customers. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Wikipedia/Cogent
So, lets kick this Friday off right... I don't suppose anybody has noticed that Wikipedia is being blackholed by Cogent, and that it seems to be intentional? :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Wikipedia/Cogent
On Fri, Aug 18, 2006 at 09:09:59PM +, Christopher L. Morrow wrote: On Fri, 18 Aug 2006, Geoffrey Pan wrote: This space has been assigned to the same location, facility for years. same location/facility doesn't mean that that place/people/thing still has authority to route the PA block... Like say the decided to stop having Cogent as a provider? or stopped payments to Cogent? or some other sort of snafu... Cogent seems to think that they terminated a relationship with said company (one of what looks like many different hostway names at any rate), and gave them several months to renumber out of the IP allocation. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Cox leaking 128.0.0.0/1
Seeing as this has been going on for over 2h30m, no one can seem to get ahold of any live bodies who can fix it, and the emails about it to the noc contacts have gone unanswered, I'm reduced to trying the old public embarassment approach... Would Cox please stop announcing 128.0.0.0/1. Thanks. route-views.oregon-ix.netsh ip bgp 128.0.0.1 BGP routing table entry for 128.0.0.0/1, version 471808 Paths: (14 available, best #14, table Default-IP-Routing-Table) Not advertised to any peer 852 22773 154.11.11.113 from 154.11.11.113 (154.11.11.113) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 852 22773 154.11.98.225 from 154.11.98.225 (154.11.98.225) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 3277 6820 3267 3343 174 174 174 22773 194.85.4.55 from 194.85.4.55 (194.85.4.55) Origin IGP, localpref 100, valid, external Community: 3277:6820 3277:65361 3277:65364 2493 3602 812 22773 206.186.255.223 from 206.186.255.223 (206.186.255.223) Origin IGP, localpref 100, valid, external Community: 812:2 3602:65011 3602:65535 7500 2516 22773 202.249.2.86 from 202.249.2.86 (203.178.133.115) Origin IGP, localpref 100, valid, external 6539 22773 216.18.63.137 from 216.18.63.137 (216.18.63.137) Origin IGP, localpref 100, valid, external 11608 3491 22773 207.246.129.13 from 207.246.129.13 (207.246.129.15) Origin IGP, localpref 100, valid, external Community: 3491:2000 3491:2007 3491:22773 11608:1004 11608:5504 22773:130 22773:60101 22773:64002 22773:64100 22773:64101 7660 2516 22773 203.181.248.233 from 203.181.248.233 (203.181.248.13) Origin IGP, localpref 100, valid, external 1221 4637 22773 203.62.252.26 from 203.62.252.26 (203.62.252.26) Origin IGP, localpref 100, valid, external 1103 1273 22773 193.0.0.56 from 193.0.0.56 (193.0.0.56) Origin IGP, localpref 100, valid, external 8001 22773 209.123.12.51 from 209.123.12.51 (209.123.12.51) Origin IGP, localpref 100, valid, external Community: 8001:3000 8001:3023 8001:6008 22773:130 22773:60101 22773:64002 22773:64100 22773:64101 12956 22773 213.140.32.146 from 213.140.32.146 (213.140.32.146) Origin IGP, localpref 100, valid, external Community: 12956:18500 12956:28200 12956:28201 22773:130 22773:60101 22773:64002 22773:64100 22773:64101 5650 22773 74.40.7.35 from 74.40.7.35 (207.173.112.63) Origin IGP, metric 0, localpref 100, valid, external 5650 22773 74.40.7.36 from 74.40.7.36 (74.40.0.11) Origin IGP, metric 0, localpref 100, valid, external, best Oh and if you are on this list (and therefore accepting that prefix), you may need better filters. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: i am not a list moderator, but i do have a request
On Thu, Aug 17, 2006 at 02:48:01PM -0500, Gadi Evron wrote: Paul, apparently, we are in disagreement! :) Botnets are an operational issue affecting most of every large carrier to momspops service provider here. I believe a lot of the information about botnets, which is not that complex, is behind held in secret for no reason, and I release it when possible. ... This is probably one of the more active and interesting discussions in the past year which are ON-TOPIC. If this is all we have to talk about and it is on-topic, then NANOG has failed, and we need a new list where people can actually discuss network operations. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: GTSM - Do you use it?
On Thu, Aug 17, 2006 at 05:14:57PM -0700, Merike Kaeo wrote: I don't think that's a fair assumption. A few providers I talked to for a security current practiced document I am writing said they were deploying it between BGP peers and I recently asked for more clarification from some individuals to ensure I had correct info with respect to vendors. There is some support in some J boxes and also support in C boxes. I didn't get specific detail how it was deployed, just that is was. Juniper only suports GTSM on Gibson-based architectues (which is T640, T320, M320, and M120 today). Cisco only supports GTSM in a meaningful way on IOS XR on CRS-1. All IOS based platforms still check MD5 before TTL, and only do TTL checks in software, making it worthless for anything other than deploying it on sessions today and maybe making it do something useful tomorrow. I think XR on GSR support is limited too, but nobody runs that in production anyways. :) And no, nobody seriously deploys GTSM today in any kind of scale. AFAIK no other vendors support it yet either, so requiring it on sessions is a non-starter. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Captchas was Re: ISP wants to stop outgoing web based spam
On Wed, Aug 16, 2006 at 09:21:06AM +0100, Simon Waters wrote:
The reason people use image recognition is it is something (most) humans find
very easy, but requires considerable investment of effort (or resource for
self training) to teach computers, and readily permits of variations ('click
the kitten' being a good example).
How many CAPTCHA tests can a human making minimum wage complete in an
hour? Ask the post office people who input handwritten zipcodes.
A tougher question might be, what does any of this have to do with NANOG?
--
Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: AS 8437 announced a quarter of the net for half of an hour
On Mon, Aug 14, 2006 at 01:36:36PM -0600, Josh Karlin wrote: Greetings, Today (Aug 14th 2006) AS 8437 announced 63 /8 nets from 14:30 to 15:00 UTC. I don't believe that this is normal, but please correct me if I am wrong. Note they're all unallocated blocks, so probably someone's attempt at bogon filtering got leaked inadvertently. Since they're all unallocated blocks, it shouldn't have done any harm, and anyone with reasonably intelligent routing policies should have blocked those routes anyways. :P And may there be a special circle of hell reserved for the weenies who do stupid unnecessary shit that breaks more than it fixes in the name of security. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: SORBS Contact
On Sun, Aug 13, 2006 at 09:11:58PM -0700, David Schwartz wrote: Your argument is similar to a mall that claims they can shoot people who don't buy anything. After all, their only obligation is to those who pay them. But of course neither you nor they can do that. By setting up a network and connecting it to the Internet, you know that you will sometimes carry packets that are neither from nor to someone with whom you have a contract. Those are not your packets, and you have no contract with their owners, but you handle them in the ordinary course of your business, so you have a variety of tort obligations to them. Whatever you're smoking, you've really gotta share some with the rest of us. :P I guarantee you that there is not a single packet that I will route which is neither from nor to someone I have a contract with. If you want to give away free service to people without contracts that is your right, but I sure as hell don't have to. The same would be the case if I used FedEx to return something of yours to you. If they destroyed your property, you would have a claim against them even though you didn't pay them for anything. Packets are not property, there is no intrinsic value in returning them to sender. Plus I guarantee you if you drop off a package with Fedex and don't pay for it (thus entering into a contract with them for services), they will eventually throw it in the trash rather than deliver it. Of course, you can protect your own network. Just as FedEx can destroy a bomb if someone tries to ship it through them. But you cannot do whatever you want with your packets unless they really are your packets. The only thing you probably CAN'T do is take someone else's packets that were sent to you (either under contract or not) and sniff or alter them for the purpose of doing something Bad (tm) with the data (probably because said bad activity is already convered under some existing law, e.g. no extorting people, no impersonating others, etc). -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Unique BGP Regular Communities
On Fri, Aug 11, 2006 at 04:03:57AM +, John Smith wrote: Hi, When the providers choose communities do they follow the syntax AS_NUM:X, where X is some number to ensure uniqueness of their particular community? The reason i ask this is because if operators are doing this then they need not worry that the community being used by them would not be used by anybody anywhere in the world. I am wondering if it can _ever_ happen that i get to recieve a BGP UPDATE carrying a community number that i use inside my AS? Is this possible? And if Yes, then what scenario? Communities can be used in any damned way you feel like, they're just numbers that people add to routes to convey extra information, and they can be squashed or added, and propagated or not proagated between networks, as any particular network sees fit. Some people are partial to only using their own ASN in the first half (and thus arbitrary codes in the second half), but personally I'm not. For example, if I was AS1234 and I wanted my customers to be able to tell me to preend once to my peer AS5678, I would rather they be able to send 5678:1 rather than have to know to look up my communities reference webpage and find an arbitrary mapping like 1234:65123 for the behavior they want. Why? Two reasons. First, there is a logical difference between communities you accept (to do some specific action), and communities you advertise (to inform others about the routes in some way). It probably isn't terribly neighborly of you to send routes to AS5678 using 5678: because you felt like it (though if they have any common sense whatsoever they're filtering their own reserved community space on the routes they receive from you), but it may make perfect sense for you to pass on some information about the route (such as geographic area you learned it from, the type of relationship (customer, peer, transit), etc) using 1234: space. I'm a fan of making this information available to everyone on the Internet who wants it (since you never know, it may come in handy to some network you've never heard of 7 hops away from you), and if they don't they're welcome to filter it. For routes you are receiving, it is generally harmless to step on other peoples 5678: space, take whatever action you're going to take, and then delete those communities at export time. Second, I'm still waiting for a widely available policy language which lets you do useful things, such as reference variables which change at run time depending upon the session they're applied again. Picture a policy language where you can say match $remoteasn:1 to do a specific prepend to a specific neighbor, without needing to write a specific policy for that neighbor beforehand. Once vendors get their acts together and implement this (so far the only one I know of to do it is Cisco under IOS XR), using powerful and complex policies to manage your network will be much, much easier. But the short answer to your cryptic question is yes anyone can send you anything at any time, and if you don't want them to do so, filter appropriately on your border. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Abovenet fibre cut
On Fri, Jul 28, 2006 at 08:51:35AM -0700, Jeremy Chadwick wrote: Has anyone heard of a fibre cut affecting Abovenet customers (particularly those utilising MPLS), possibly centralised around the east coast? I've managed to confirm with the Abovenet NOC that there is a cut which is likely the reason we're seeing increased latency between California and Virginia, and Arizona and Virginia, but have no other details about the problem, nor the location of the cut. Kingwood TX (outside Houston), no ETR. It's affecting GBLX too. That is a major link in the southern crosscountry path for a lot of folks and the closest detour is probably going to be up through Dallas, Chicago, and New York. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Hot weather and power outages continue
On Mon, Jul 24, 2006 at 02:22:26AM -0400, Sean Donelan wrote: Due to the hot weather in many parts of the US, there have been various power outages. Some large outages have been caused by severe storms, but mostly the heat has just overloaded power distribution equipment. The good news so far is the Net has shown very few disruptions due to the heat and some multi-day power outages. The major ISP access providers have been indicating about average numbers of outages in their networks, i.e. even during normal times, there are usually a few tens of thousands of lines down nationwide. I'm surprised nobody said anything about the (apparently regional) utility outage in NoVA on Saturday. Equinix Ashburn was running on generator for several hours, but apparently the SAVVIS facility down the road a few miles in Sterling (old Exodus facility) didn't fare so well. The latest story I heard was that they lost 14 out of 16 chillers and customers had to send techs in in shifts because it reached over 130F inside. Come on Sean, this very few disruptions stuff is below your usual standards. The least you can do to help us pass the time in this damn heat is to recount a few good stories about routers you could scramble eggs on. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: SBC Lost of connectivty to Canada?
On Mon, Jul 24, 2006 at 01:04:47PM -0400, Elijah Savage wrote: On our SBC peering links we lost connectivty to our Canadian customers for about 20 minutes. I have escalated this up through SBC but was wondering if anyone on the list as any knowledge of what may have caused the outage. Our Canadian customers come in through different Canadian providers so from my perspective it wasn't just one AS or prefix that was lost it was many. Yes its part of a new homeland security policy of discrimination against our moose loving brothers to the north. All packets will now be stopped at the border and inspected by DHS. :) Actually they just leaked some routes this morning, and blew out max prefixes to most peers. Pretty typical as far as accidental leaks go, those folks with sensible filtering and running routers which trip on max prefixes accepted not prefixes received probably weren't even affected. Another day on the internet. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: SBC Lost of connectivty to Canada?
On Mon, Jul 24, 2006 at 09:43:19PM -0400, [EMAIL PROTECTED] wrote: On Mon, 24 Jul 2006 13:18:42 EDT, Richard A Steenbergen said: Actually they just leaked some routes this morning, and blew out max prefixes to most peers. Pretty typical as far as accidental leaks go, those folks with sensible filtering and running routers which trip on max prefixes accepted not prefixes received probably weren't even affected. Another day on the internet. If I didn't know better, I'd say you were implying that your best bet for a survivable design is to plan as if your peers listened to Randy Bush on network design? Not sure what you're referencing there. If Randy said something to the effect of all peers will screw up and leak something to you eventually, no matter how large or generally well run, so plan accordingly, I would agree with it though. I was suggesting that if even if you don't have the ability to fully prefix or as-path filter every peer (which, face it, most of us with large numbers of interesting peers don't have), you can still filter the really obvious stuff and prevent a large amount of the impact from common fat finger events. I can't tell you the number of problems that are prevented by applying a simple set of as-path filters matching large networks you know you should never hear from your peers (or most of your peers). Something simple like: deny _209_ deny _701_ deny _1239_ deny _1299_ deny _1668_ deny _3320_ deny _3356_ deny _3549_ deny _3561_ deny _5511_ deny _6453_ deny _7018_ Catches a huge amount of stupid stuff, especially when the event isn't a full blown leak which trips max prefixes, but is an isolated set of prefixes leaked by someone not directly connected to you. On a Cisco, the leaked 7018 routes from 7132 this morning would have been gone splash harmlessly with such a filter, and sessions wouldn't even trip max prefixes and bounce. Unfortunately Juniper has a bit of a backwards take on the use of prefix limits. They believe that the reason to have a prefix limit is to protect a router against memory exhaustion (for example, someone sending you a few million routes that you are rejecting filling up your adj rib in), rather than as a policy tool (shutting down a wildly broken session that is sending you stuff it shouldn't). Juniper applies the max prefixs to routes received from a session rather than routes accepted, so even if the routes are filtered the prefix limit will still trip and shut down the session. This is particularly bad if for example you have a customer session which is fully prefix list filtered, and the customer accidentally leaks you a table. In reality, both types of limits are probabaly a good idea. I've talked to a lot of people from a lot of companies who say they have requested Juniper add a seperate accepted-prefixes limit (or more likely, convert the existing limits to accepted-prefixes, and add a new received-prefixes knob), but so far it hasn't been implemented. If you are a Juniper customer who is reading this and you think having prefix limits which only count accepted prefixes is a good idea, please use this as an opportunity to submit an enhancement request so we can get this behavior improved. Feel free to throw in a request for outbound prefix limits as a last ditch safety net too. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Deaggregation Disease
On Fri, Jul 21, 2006 at 01:59:35PM -0400, Jon Lewis wrote: As we push closer to the ipv4 route table limits of cisco's 6500/7600 series (with anything less than Sup720-3bxl), I suspect lots of networks are going to be forced to start doing some sort of filtering of routes beyond just refusing 24-bit networks or cisco's going to sell a lot more Sup720-3bxl's, FAN2 trays, and power supplies in the next year or two. It should be noted that the sup720-3a/3b tcam allocations (cef maximum-routes) only gives 190k of the 256k theoretical max to IPv6 routes by default. Anyone running a sup720 non-3bxl who has not manually adjusted those cef maximum-routes is either blowing up or about to blow up any day now, depending on how many internal routes they have and how much filtering their upstreams are doing. Of course this isn't a new problem, many of us are still running old Foundry ironcore boxes with 700+ day uptimes and software so old it came with 120k or 140k default maximum routes. Similiarly, cam aggregation on such platforms (without enough cam to hold even close to enough routes for a full table) is nothing new either. Cisco could easily implement cam aggregation where they do not install a cef route entry if there is a covering less-specific route pointing to the same nexthop(s). It is hardly rocket science, and could extend the life of a 256k route tcam platform for many years to come. But clearly Cisco would rather just sell 3bxl's. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
MCI - Toronto Routing Issues
Is anyone aware of routing problems within MCI/WC/UUNET? link shows packets going out, but nothing coming back -rd- -- Richard Danielli
Re: MCI - Toronto Routing Issues
Thanks to Christopher for his time in working on this with me Chris, if you are ever in Toronto, I owe you a beer... -rd- Christopher L. Morrow wrote: On Fri, 7 Jul 2006, Richard Danielli wrote: someone here has found out that BCE - who owns the last mile is at fault.. bummer it's nice to see folks get help when they ask... thanks for your time and concern on this.. no problem, it's what they pay me for, sorta :) -rd- Christopher L. Morrow wrote: -- Richard Danielli President - eSubnet 416.203.5253 http://www.eSubnet.com
Re: key change for TCP-MD5
On Sat, Jun 24, 2006 at 02:51:57AM -0700, Barry Greene (bgreene) wrote: At the same time, you are not going to find the SP core swapping out their equipment for hardware with crypto chips. SPs do not seem to want to pay for this sort of addition. So even new equipment is not getting hardware crypto that can be used. As with everything else, it needs to actually add useful features that makes a SP's life easier, not just be another vector for an extra line item and a higher total on the router invoice. So a BGP IPSEC option has to work with what hardware we've got deployed today - not wishing the community would just upgrade. SPs don't see any tangile benefit in BGP IPSEC (and legitimately so), so this will clearly not be a driving factor for them. I guarantee you if you solve a real problem (like say authenticating and managing authorized prefix announcements) and make it faster/better because the router has hardware crypto available, folks will actually start buying new RPs/etc. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: key change for TCP-MD5
On Fri, Jun 23, 2006 at 04:43:29PM -0400, Todd Underwood wrote: On Fri, Jun 23, 2006 at 11:49:33AM -0700, Barry Greene (bgreene) wrote: Yes Jared - our software does the TTL after the MD5, but the hardware implementations does the check in hardware before the packet gets punted to the receive path. That is exactly where you need to do the classification to minimize DOS on a router - as close to the point where the optical-electrical-airwaves convert to a IP packet as possible. i'm not that bright, so maybe i'm missing something, but i've heard this claim from cisco people before and never understood it. just to clarify: you're saying that doing the (expensive) md5 check before the (almost free) ttl check makes sense because that *minimizes* the DOS vectors against a router? can someone walk me through the logic here using small words? i am obviously not able to follow this due to my distance from the optical-electrical-airwaves. As I parsed Barry's post, he was saying that Cisco currently does the wrong thing today, but that some day when they actually support doing the check in hardware, that will be the right place to do it. (aka duh :P) Obviously in a perfect world, you don't want to do the expensive MD5 check anywhere sooner than the last possible moment before you declare the data valid and add it to the socket buffer. I assume that the reason they can't do the check sooner in software is they lack a mechanism to tell the IP or even TCP input code we want to discard these packets if they are less than TTL x. They probably can't make that decision until the packet gets validated by TCP and makes it all the way to BGP code. But, they should still be able to do all of the TCP layer checks which don't require outside information, such as matching the segment to a proper TCB by ip/port/seq #, before doing the MD5 calculation. This makes DoS against MD5 where you don't know the full L4 port #'s and the seq # pretty impossible on its own, without needing to involve the TTL hack. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: key change for TCP-MD5
On Fri, Jun 23, 2006 at 05:01:00PM -0400, Richard A Steenbergen wrote: Obviously in a perfect world, you don't want to do the expensive MD5 check anywhere sooner than the last possible moment before you declare the data valid and add it to the socket buffer. I assume that the reason they can't do the check sooner in software is they lack a mechanism to tell the IP or even TCP input code we want to discard these packets if they are less than TTL x. They probably can't make that decision until the packet gets validated by TCP and makes it all the way to BGP code. Actually I take that back, it should be easy enough to configure a minimum TTL requirement on the TCB through a socket interface. Obviously they're doing something to pass the IP TTL data outside of its normal in_input() function (or whatever passes for such on IOS), so if you've got that data avilable in the tcp_input() code you should be able to do the check after you find your TCB but before the MD5 check, yes? Since there hasn't been an IOS source code leak in a while, does someone from Cisco who actually knows how this is implemented want to comment so we can stop guessing? :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: key change for TCP-MD5
On Wed, Jun 21, 2006 at 05:55:21PM -0700, Randy Bush wrote: when low-hanging fruit is unavailable, or when they see a really cool way to exploit the higher fruit, it would be prudent to have done something about it. who cares about openly recursive dns servers? there are easier ways to crack the host. oops! There is a fine line between being dilligent about security, and wasting your time trying to solve problems that don't exist, which I think has been crossed in the discussion. Not to venture too far away from facts and into the realm of cute soundbites and quotable one-liners about lions and fruit, but let me propose what I think is a good one: If the bad guys have copies of your MD5 passwords, then you have way bigger problems than the bad guys having copies of your MD5 passwords. I have yet to hear a reasonable counter-argument to this. If there is one out there that had not yet been made then by all means now is the time to make it. Otherwise, you would really be better served by devoting your time and energy into solving real problems. If you're running low on real problems to solve, I would be happy to send you some of mine. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: key change for TCP-MD5
On Tue, Jun 20, 2006 at 05:06:27PM -0400, Ross Callon wrote: DoS against routers is of course a major concern. Using encryption has the potential of making DoS worse, in the sense that the amount of processing that a bogus packet can cause is increased by the amount of processing needed to check the authentication. If the router needs to check multiple keys in the keychain before declaring the segment as invalid, then this multiplies the effect of the DOS by the number of keys that need to be checked. I'd still like someone to explain why we're wasting man hours, CPU time, filling up our router logs, and potentially making DoS easier, for an attack that doesn't exist. After that, I'd like them to explain why we need to devote more resources to protecting against the attack that already doesn't exist, and that is already protected against just fine even if it were to exist. Of course any not completely insane implementation should be checking for a valid TCP window range (or an existing TCB for that matter) before wasting CPU time on an MD5 calculation. It's just not possible in reality for any sufficiently large number of packets to get through those check to then be affected by an MD5 DoS (unless of course you're peering with 7018, and the NSA has an extra copy of your packets laying around). We already collectively wasted our time deploying MD5 passwords over a big scare that turned out to be nothing more than someone cracking open the manual and rediscovering how stuff worked all along. Why don't we spend our time going forward solving actual issues like filtering/announcement authentication, and stop trying to solve the non-existant problems. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Interesting new spam technique - getting a lot more popular.
On 6/14/06, Florian Weimer [EMAIL PROTECTED] wrote: There are universal subscriber gateways that simply override all network configuration on the host, but they aren't marketed at datacenters AFAIK. After all, who would think that a datacenter needs a network security policy similar to that of a hotel offering Internet access in its rooms? That's the way we are using now... works very well... With a subscriber management equipment, you can put each customer in their own vlan. Each vlan is bound to a subscriber which has its ip addresses. When more addresses are requested, just add some to the subscriber. Thanks, Richard
Re: Interesting new spam technique - getting a lot more popular.
On Wed, Jun 14, 2006 at 04:46:31AM +, Christopher L. Morrow wrote: is it really that hard to make your foudry/extreme/cisco l3 switch vlan and subnet??? Is this a education thing or a laziness thing? Is this perhaps covered in a 'bcp' (not even an official IETF thing, just a hosters bible sort of thing) ? Simple: Subnets are hard, customers are stupid, and ARIN is not exactly a hosters best friend. When a hosting customer asks for 5 IPs today and 25 IPs tomorrow, it is infinitely easier for the hosting folks to just slap them into /24s and say ok uhm you are now .69-.94 than to try and explain subnets, cidr, reserving IP space in cidr sized blocks etc to the customer. Hosters are also generally under-equipped in the paperwork and detailed documentation department, so they tend to run their IP allocations into the ground while attempting to explain their need for more space. CIDR allocations are wasteful to them, especially when a customer needs to expand from 30 IPs to 35 IPs and crosses a new boundry. Incase you've never seen hoster configs, they generally look a little something like this: ip address 1.1.1.1 255.255.255.0 ip address 1.1.2.1 255.255.255.0 secondary ip address 1.1.3.1 255.255.255.0 secondary ip address 1.1.4.1 255.255.255.0 secondary ip address 1.1.5.1 255.255.255.0 secondary ... Anything else is quite honestly beyond 99% of hosters out there, they're still blissfully calling these things class c's. I've seen some truly godawful thins configured by hosters, like chains of 3548s all linking back to a single router interface in ways you can't even imagine. If you made it dirt simple for them they would probably be doing something better (I usually point folks who ask to pvlans, then take the opportunity to make a hasty retreat while they are distracted), but otherwise they don't see the benefit in it. Why bother configuring your router better when you can just send your $5/hr monkey over with a redhat cd and have them reinstall, right? :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Interesting new spam technique - getting a lot more popular.
On Wed, Jun 14, 2006 at 07:03:10PM -0400, Matt Buford wrote: As a hoster with many customers on large shared VLANs perhaps I can add a bit... Note that if you're reading this list, you have already identified yourself as a non-typical hoster. Go read WHT or GFY for 10 minutes for an example of typical hosters, and if you're not a drooling idiot in need of a brain transplant afterwards consider yourself lucky. :) And don't forget, there are hundreds of hosting networks like the ones I described, a lot of whom are in the 1 - 30Gbps traffic range, with absolutely no clue how to do better. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Telia network degredation / POC
On Wed, May 31, 2006 at 06:48:06PM -0700, Jeremy Chadwick wrote: Does anyone have a contact number/POC of any sort for Telia that's within the United States? Jared's NOC list only contains a contact number in Sweden. It seems their network has been falling apart both within Sweden and the US since the raid on TPB (ThePirateBay.org) earlier today. Sure, it's probably kiddies as usual, but this is pretty major. Can anyone confirm/deny? Host Loss% Snt Rcv Last Avg Best Wrst StDev 1. gige-g6-0-19.gsr12012.fmt. 0.0% 119 1190.3 0.3 0.2 0.6 0.1 2. pos1-0.gsr12416.fmt.he.net 0.0% 119 119 51.5 19.6 0.4 266.9 50.7 3. pos10-0.gsr12416.sjc2.he.n 0.8% 119 1181.1 11.2 0.9 199.1 36.4 4. sjo-bb1-pos5-2-0.telia.net 19.3% 119961.0 5.2 0.9 145.5 18.3 Notice how your loss starts at the border between Hurricane Electric and Telia? HE is a customer of Telia. You should be contacting your provider (HE) to resolve the issue, not Telia. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Fwd: 41/8 announcement
william(at)elan.net wrote: On Wed, 24 May 2006, Richard Mikisa wrote: Well, the noise helped some. We now have connectivity to fastweb net. How was that achieved if their users still are within 41/8 locally? Can't be sure what they did, but I received an e-mail asking me to check on my connectivity to them and well, it worked. From e-mails received, turns out they have known about this for awhile now but just didn't want to foot the cost of re-numbering. They claim they the clean up work is on-going. -- Richard
Fwd: 41/8 announcement
This came in from someone in Italy.. -- Forwarded message -- From: * Date: May 24, 2006 11:15 AM Subject: Re: 41/8 announcement To: [EMAIL PROTECTED] Turns out the folks at fastweb (Italy) NAT there adsl clients but instead of using the rfc1918 space like most people, they use unassigned global /8s. Well 41/8 is one of there NATted allocations for Turin. No amount of emails will get them to respond, calling isn't any better as I get only Italian speaking people at the other end. Any ideas out there? Yes: you lose, sorry. :-) Many of their networking people are less than clueful, and I fear that they are not going to renumber a whole city just to let their customers communicate with a few African networks... Let me know if you need more information. (Feel free to repost this if needed, but please remove my name.) -- ciao, *** -- cheers Richard
Re: Fwd: 41/8 announcement
Well, the noise helped some. We now have connectivity to fastweb net. On 5/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: so how many ISPs will shun fastweb for hijacking address space? (please do -NOT- respond, its a retorical question...) --bill On Wed, May 24, 2006 at 11:37:12AM +0300, Richard Mikisa wrote: This came in from someone in Italy.. -- Forwarded message -- From: * Date: May 24, 2006 11:15 AM Subject: Re: 41/8 announcement To: [EMAIL PROTECTED] Turns out the folks at fastweb (Italy) NAT there adsl clients but instead of using the rfc1918 space like most people, they use unassigned global /8s. Well 41/8 is one of there NATted allocations for Turin. No amount of emails will get them to respond, calling isn't any better as I get only Italian speaking people at the other end. Any ideas out there? Yes: you lose, sorry. :-) Many of their networking people are less than clueful, and I fear that they are not going to renumber a whole city just to let their customers communicate with a few African networks... Let me know if you need more information. (Feel free to repost this if needed, but please remove my name.) -- ciao, *** -- cheers Richard -- cheers Richard
Re: private ip addresses from ISP
On Mon, May 22, 2006 at 04:30:37PM -0400, Andrew Kirch wrote: 3) You are seeing packets with source IPs inside private space arriving at your interface from your ISP? ... Sorry to dig this up from last week but I have to strongly disagree with point #3. From RFC 1918 Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. The ISP shouldn't be leaving anything to the end-user, these packets should be dropped as a matter of course, along with any routing advertisements for RFC 1918 space(From #1). ISP's who leak 1918 space into my network piss me off, and get irate phone calls for their trouble. The section you quoted from RFC1918 specifically addresses routes, not packets. If you're receiving RFC1918 *routes* from anyone, you need to thwack them over the head with a cluebat a couple of times until the cluey filling oozes out. If you're receiving RFC1918 sourced packets, for the most part you really shouldn't care. There are semi-legitimate reasons for packets with those sources addresses to float around the Internet, and they don't hurt anything. If you really can't stand seeing an RFC1918 sourced packet over the Internet it is more of a personality problem than a networking problem, so a good shrink is probably going to be more useful than a good firewall. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: private ip addresses from ISP
On Tue, May 23, 2006 at 12:23:54PM -0400, Patrick W. Gilmore wrote: I know it was late when you wrote that, RAS, but from the _very_first_sentence_: Er yeah I meant to say it says nothing about filtering 1918 packets. Please read BCP38 again. (For the first time? :) Clearly allowing anyone to inject large quantities of spoofed packets into the Internet is Bad (tm), no one is arguing that. First of all note that I was talking about how you deal with packets you receive, not packets you send. Hate to bust out the old be conservative in what you send and liberal in what you receive line, but in this case it is true. There are legitimate uses for RFC1918 sourced packets (as has been pointed out many times, for example, ICMP responses from people who want/need their routers to not source packets from publicly routed space). Filtering every last 1918 sourced packet you receive because it might have a DoS is like filtering all ICMP because people can ping flood. If you want to rate limit it, that is reasonable. If you want to restrict it to ICMP responses only, that is also reasonable. If on the other hand you are determined to filter every 1918 sourced packets between AS boundries (including ttl exceed, mtu exceed, and dest unreachable) because an RFC told you you should, you are actually doing your customers a disservice. If you are an end-user network or don't transit other people's packets and you want to do yourself a disservice then by all means filter 1918 sourced packets until you are blue in the face. If on the other hand you do handle other people's packets, I would encourage you to fully consider the ramifications before you go out and apply those filters. This is why k00ks who can only cite RFC's instead of think for themselves and large networks tend to be a bad mix. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
AS9132 filtering my traffic (41.220.0.0/20)
Hi all, Anyone from AS9132 - Broadnet mediascape communications AG, Hamburg on this list? Please get back offline. Seems like you are blocking all traffic from 41.220.0.0/20 - AS29032. All attempts for help via email and phone have failed. -- Richard
AS12874 - FASTWEB
Anyone from FASTWEB please get back to me offline. -- Richard
Re: Anyone got numbers on peering vs transit?
On Fri, May 05, 2006 at 10:11:31AM +0300, Aleksi Suhonen wrote: I forgot to stress that I'm particularly interested in the ratio between private and public peering. The answer is, it depends. In any given region, prevailing market conditions (the price of transit, etc), the costs of ix ports, the costs of colo and fiber xconns, the geographic distribution of peers, and the attitudes towards public and private peering are all going to have a huge impact. For example, public peering in Europe is FAR more pervasive than it is in the US. Obvious reasons for this include: European IX's US IX's * Largely run by non-profits* Largely run by for-profits * Largely un-associated with colos * Largely run by colo operators * Early adopters of new tech like 10GE * Significantly lagging on new tech * IX ports are generally very cheap * Same ports usually cost 3-8x more * Larger numbers of smaller peers * Smaller numbers of larger peers * Lots of language specific content * Lots of globally targetted content Obviously market economics drive public peering much more in Europe than in the US. To put it into perspective, the amount of traffic exchange by a single large IX (such as AMS-IX) is roughly equal to all of the IX's in the US combined. That same amount of traffic is roughly 1/2 (or less) of the the traffic exchanged by a single large network (such as Cogent, Level3, ATT, ATDN, etc) via private peering. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Tier 2 - Lease?
On Tue, May 02, 2006 at 10:38:22PM -0700, Robert Sherrard wrote: What make a provider a tier 2, versus a tier 1 provider... Is it possible to determine who a tier 2 (i.e. Cogent) leases fiber from? It has absolutely nothing to do with fiber. http://en.wikipedia.org/wiki/Tier_1_carrier As of this exact moment that I'm posting, that article is actually reasonably accurate. Of course I'm sure in 5 minutes 100 people will be updating it to include their favorite not-really-a-tier-1 carrier. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Google AdSense Crash
On Sat, Apr 22, 2006 at 04:58:21PM -0400, Daniel Golding wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of william(at)elan.net On Sat, 22 Apr 2006, John Palmer (NANOG Acct) wrote: Google Adsense has been down for several hours now. This is the interface that partners use to manage their advertising settings. And this is reported on nanog because...? Because this is the Internet's most profitable advertising service and ISP's will get complaints if their customers (esp. business customers) can't reach it, even on the weekend. Outage reports are operational, unlike many threads. More, please. Not sure I'd agree with that one. If there was an actual networking issue and you couldn't reach Google, I'd buy that it is at least in the right ballpark of on-topic for nanog (though if past history is any guide, it would just be 20 me too posts with no useful information about WHY it was broken or how to go about fixing it). But if you can get the website to load, and Google's servers just don't want to run that particular application, I can't see how it possibly has any bearing to NANOG. Layers people. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Determine difference between 2 BGP feeds
On Tue, Apr 18, 2006 at 04:28:40PM -0400, Scott Tuc Ellentuch at T-B-O-H wrote:
On Tue, 18 Apr 2006, Scott Tuc Ellentuch at T-B-O-H wrote:
Is there a utility that I can use that will pull the
routes off each router (Foundry preferred), and then compare
them as best it can to see why there is such a difference?
I can understand a handful of routes over what CIDR says,
but a minimum of 3K more?
Is one of them as4323?
Actually, no. I wasn't wanting to name names to
protect the innocent... BUT
ROUTER1:
Neighbor Address AS# State Time Rt:Accepted Filtered Sent ToSend
64.200.58.69 7911 ESTAB 4d21h57m182287 04 0
ROUTER2:
Neighbor Address AS# State Time Rt:Accepted Filtered Sent ToSend
69.28.152.229 22822 ESTAB 18d16h51m186379 04 0
This is actually fairly common. There are a lot of folks out there who
announce more specifics to one network but not another, or who apply no
export or limited export community tags in various places. Also, every
network has a different filter policy of what they will and won't accept.
FWIW my exported to bgp speaking customers count at this moment is
182525. I wouldn't get concerned about it unless the network with more
prefixes is doing something absurdly stupid like sending you internal /30s
and such (which, well, a lot of people do :P). It could also be something
like peers agreeing to traffic engineer by sending each other more
specifics w/meds, though if they were smart they would be doing that with
no-export so as to not make your TE job more difficult. If you really want
to compare the differences, try something like:
telnet yourrouter | tee outputfile
term length 0
sh ip bgp nei x.x.x.x received-routes
quit
Followed by 30 secs with awk(1), cut(1), diff(1), etc. For floundry,
something dirt simple like grep / | awk '{ print $2 }' should do the
trick.
--
Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Open Letter to D-Link about their NTP vandalism
On Wed, Apr 12, 2006 at 01:32:26PM -0500, Stephen Sprunk wrote: On the plus side, after seeing D-Link's (lack of) reaction to this, I'll bet none of us will buy another of their products again. If it was legal to sell whatever you people are smoking that makes you think dlink gives a flying crap about you as customers, I'd be a very rich man. What part of mass consumer product isn't clear here, 99.9% of their target market doesn't know NTP is, and doesn't care. I am absolutely appalled by the number of slashdot warriors here, ready to launch a crusade of spreading misinformation to the media in hopes of obtaining a large monetary payout or otherwise causing dlink, in the name of doing the right thing, and without any consideration or understanding of the facts at hand. You know why dlink can't just come forward and say woops we're sorry, we didn't see that you wanted this used for DIX members only, our bad? Because they have to contend with people who will take that apology and then use it in court as an admission of guilt, and seek many tens of thousands of dollars or more in non-existent damages. I think we all know that dlink was wrong. They should have double-checked the list of NTP servers they included in their default shipping firmware to make certain that the owners were ok with having their services used publically, there is no question about this. However, just because they made this mistake, it is not an excuse for everyone involved to start cashing in like they hit the lottery. Imagine that you get rear ended in traffic by an inattentive driver, and they dent your bumper. Yes it is their fault, yes they made a mistake and they should be responsible for it, but it is not okay for you to start screaming whiplash as soon as you see that you got hit by a Mercedes. It also doesn't mean that you are going to get a new car instead of them paying to have your bumper fixed. If anyone else is going to carry this as a story, please act responsibly and do a little fact checking. We're talking about 37 packets/sec, less than a dialup worth of bandwidth, and any number of technical solutions which could completely mitigate that traffic without ANY additional expenses. Also, IANAL, but I think that refusing to take reasonable action to mitigate the damages because you feel the other party is at fault and should be 100% responsible is probably a good way to hurt any kind of case you might actually have against them too. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: XO Peering
Does anyone know what is going on with XO and their peering? My XO circuit is taking weird paths to other carriers, and internethealthreport.com shows elevated latency on all of their links. Latency looks fine - Network availability is pretty pathetic. I can route out our XO pipe fine, although there isn't a whole lot on it. I can't make mtr do anything funky that would indicate a problem with XO so I could open a ticket. Does anyone else miss the good old days when nanog readers/attendees knew why pinging the routers you saw in a traceroute directly was not an accurate measurement of anything? How about when people used diagnostic tools that told you more than oh crap 91ms from *somewhere* on xo to *somewhere* on xo, omgrotfwtflolz the square is red and I'm pinging 10 quick post to nanog!? Anyone? I think maybe we should all take a moment to hang our heads in shame. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Open Letter to D-Link about their NTP vandalism
On Fri, Apr 07, 2006 at 12:52:29PM -0700, Etaoin Shrdlu wrote: Well, this is at least marginally on topic, and I think it deserves a wider audience. It is written by Poul-Henning Kamp (the affected party). Please read it. http://people.freebsd.org/~phk/dlink/ *sigh* Yes yes everyone loves a good large stupid company screws the little guy by sticking their small/free service into a commercial product story, but unfortunately none of these solutions are very pragmatic. If I hosted an NTP server and dlink put it in a default query list of a default firmware, and then I asked them to pay my Equinix bill for the next 5 years, I would fully expect them to provide a nice little ascii diagram of exactly where I could stick it. Its just NTP, I can't imagine that it is *really* enough traffic to care all that much. There are probably a hundred people on this list who could donate free transit for this and not give it a second thought (hell if I had a pop anywhere close to .dk I would donate a gigabit solely to end this nanog thread before it turns into a bunch of self-righteous whining). There are probably an equal number of people who could donate hardware for this, either for filtering or for the IX (if they REALLY don't have the resources to handle it without charging, which I highly doubt). I'm sure you could probably pick out the dlink queries with sufficient packet inspection too, which I'm also sure you can achieve with a FreeBSD box and a couple hours of spare time. :) Seriously now, there are a million viable solutions here, ranging from mild inconvenience to attempting to screw dlink for being dumbasses, all of which are free. Point the A record else where and have people who care change to a new record, it's not worth $62k. Oh and one more thing, if the goal was restricting the traffic to only people who participated at this IX (as per the description), please add this to the list of reasons why announcing your IX subnet over the global internet is a BAD IDEA! -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Open Letter to D-Link about their NTP vandalism
Ok let me answer two at once here: On Fri, Apr 07, 2006 at 06:57:50PM -0400, Steven M. Bellovin wrote: Did you read the posting? His ISP is charging him. He's also put in a fair amount of time trying to get this resolved. As for transit -- NTP works much better with short RTTs, which is precisely why it's good to have a server in Denmark. Actually, no. Incase it wasn't clear, the IP (192.38.7.240) is out of an IX subnet for the DIX. Even if you didn't know this particular block, looking at the reverse DNS for nearby IPs makes it painfully obvious. See: http://www.peeringdb.com/dns-scan/192-38-7-0-24.txt The real issue here is that DIX used a /24 from an aggregate block which is announced in BGP (198.38.0.0/17) for their IX space, thus making it reachable from anywhere on the Internet. Incase anyone didn't know this before, now you do, this is a Bad Idea (tm). The prices phk mentions appear to be the cost of a DIX port. According to their website: A connection at the DIX with 10 or 100 Mbit/s ethernet has a yearly fee of DKK 27.000. A connection at the DIX with 1000 Mbit/s Ethernet costs a yearly fee of DKK 38.700. According to the service description, this NTP server was intended to be used only by DIX connected networks. If the /24 had been pulled from a direct /24 allocation or EP.net space, this would never be a problem, because the /24 for the IX shouldn't be propagated globally. In this particular case they could filter packets coming in via AS1835's border links, but since the block is announced globally already this may create further problems from people who don't know they need to carry the /24 and propagate it to their customers. Personally I'm not sure what to be more appalled by, that DIX would want to charge him for something that is clearly a service which benefits only them and which they should probably be paying HIM for (and which wouldn't cost them a dime if not for their poorly implemented architecture), or that a consultant charged $5000 to track this down. Both concepts are actually more repulsive to me than dlink picking 25 publicly accessable nameservers. On Sat, Apr 08, 2006 at 01:30:31AM +0100, Per Gregers Bilse wrote: I know phk personally (give or take a little, we're from the same country, and have both participated vigorously in the same UNIX user group [yes, there have been such entities]); for those who are unaware of his credentials, let me cut and paste the following from the FreeBSD GBDE manual page: Yes thank you everyone knows who phk is (or at least I hope they do), that is the only reason anyone is giving this a second glance, the reason it made it to slashdot, etc. However, that doesn't change the facts here. This is a non-issue, and there are many many easy ways to fix it. I'm perfectly ok with calling out dlink for their stupidity, but I think expecting them (or phk) to pay $62k or more for this is ridiculous. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
some funky bgp communities
Holy crap I'm about to make an on-topic nanog post (IPs changed to protect the guilty)... Anyone else out there seeing issues with some funky communities in the global table around oh say: Apr 3 00:29:33.457 UTC: %BGP-6-BIGCHUNK: Big chunk pool request (252) for community. Replenishing with malloc Apparently it seems to be smoking a few Foundry's out there. The only thing I've seen logged is: bgp_read_v4_message: NOTIFICATION received from x.x.x.x (External AS x): code 3 (Update Message Error) subcode 4 (attribute flags error), Data: d0 08 01 00 04 d7 So, dusting off my rarely used bgp parsing skills for a second... 0d == attribute flags, including extended length 08 == attribute type communities 0x04d7 == 1239 Based on a lead from some other folks who noticed that this particular issue went away when they stopped accepting routes from AS5400, I noticed: * 62.3.160.0/19 (7 entries, 1 announced) Nexthop: x.x.x.x AS path: 5400 5588 8246 8364 I () Communities: 1239:100 1239:110 5400:49 5400:2004 5400:2005 5400:2014 5400:2016 5400:2023 5400:2027 5400:2029 5400:2032 5400:2033 5400:2034 5400:2044 5400:2045 5400:2048 5400:2061 5400:2103 5400:2106 5400:2109 5400:2110 5400:2112 5400:2116 5400:2117 5400:2121 5400:2123 5400:2124 5400:2128 5400:2130 5400:2133 5400:2145 5400:2151 5400:2169 5400:2174 5400:2500 5588:1001 5588:2048 5588:3003 5588:21016 8246:2 8246:31 8246:1050 Anybody else seeing this issue? Just a generic Foundry/extended length bug being set off by as5400 getting a little community happy? -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: ATT: 15 Mbps Internet connections irrelevant
On Sat, Apr 01, 2006 at 08:34:36AM +0200, Mikael Abrahamsson wrote: http://arstechnica.com/news.ars/post/20060331-6498.html In the foreseeable future, having a 15 Mbps Internet capability is irrelevant because the backbone doesn't transport at those speeds, he told the conference attendees. Stephenson said that ATT's field tests have shown no discernable difference between ATT's 1.5 Mbps service and Comcast's 6 Mbps because the problem is not in the last mile but in the backbone. No the problem is at ATT's congested peering edge. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: UDP Badness [Was: Re: How to measure network qualityperformance for voipgameservers (udp packetloss, delay, jitter,...)]
On Fri, Mar 10, 2006 at 11:52:40AM +, tony sarendal wrote: Does traceroute really do that ? Even for ICMP. Think about it. Hint: the return packets your traceroute produces, do they have the same return path for every hop ? Think Internet, think large providers with many peerings. On behalf of every network operator on the planet, I would like to take this opportunity to encourage every person who implements a traceroute or traceroute like program to ALWAYS DISPLAY THE SOURCE ADDRESS IN THE OUTPUT OF THE [EMAIL PROTECTED] Very few things in life suck more than asymmetric paths + wannabe network engineers armed with a noc phone number list and traceroute, mtr, or those wonderful visual traceroute programs that they insist on taking 6MB bmp screenshots of and sticking into word documents so they can email that as an attachment. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: UDP Badness [Was: Re: How to measure network qualityperformance for voipgameservers (udp packetloss, delay, jitter,...)]
On Fri, Mar 10, 2006 at 11:43:59AM -0800, Matt Ghali wrote: On Fri, 10 Mar 2006, Bill Nash wrote: You will not learn hatred until that MMO you host implements a 'Report network problem' button that does a traceroute, and automatically emails it and a canned message to your NOC mailbox. Ultima Online did this, back in my nocling days. Like monkeys expecting a reward, those little bastards pounded on that button until the lag stopped. That's hilarious- I just finished emailing ras offlist about the same tool. It also (somehow) allowed them to send their blather to [EMAIL PROTECTED] http://matt.snark.net/crap/idiot/idiot5.txt Not to try and troubleshoot your 5 year old ticket or anything, but their ingress traceroute shows what looks like Baltimore to San Francisco to mae-west to a sjc based server (probably someone honoring meds :P), and the outbound traceroute used to troubleshoot it coming out of VA and going over mae-east. Nothing in that traceroute proves that AboveNet was or was not having issues at mae west. While the output from traceroute is simple, obtaining meaningful data from it about what is actually wrong requires an operator with expertise and years of experience. Jumping to conclusions about what is or isn't wrong based on traceroute is probably one of the largest failings of noc people in general. But thanks for reminding us of the crappy crappy networking that went on 5 years ago. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Cogent Outage
On Thu, Mar 02, 2006 at 06:41:04PM -0500, David Coulson wrote: Apparently Cogent had a fiber cut between Santa Clara and Houston which is screwing their network up pretty nicely (I'm seeing 60m of latency between two routers in Chicago). You mean WCG had a fiber cut, just west of Houston. Santa Clara is completely and totally unrelated as a destination, on anyone's network. This affects far more than Cogent though. Their internal ticket # is 387128. Is this the second or third this year for them? Higher. You can't hold longhaul fiber cuts against Cogent directly though. Stuff happens. You CAN hold it against them when a single metro cut takes out half of a longhaul crosscountry ring though, or when two simultanious cuts segment the network into east and west sides of the country. Thats just bad planning. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Exchange Points
On Fri, Feb 17, 2006 at 08:46:34PM -0600, sjk wrote: We're a small facilities based ISP in Chicago and I am looking for a public exchange point for peering. I have been told, by someone at SBC, that the public NAP here is no longer accepting connections and is essentially going to shut down over time. Has anyone else heard this? Are there other exchange options - other then to haul transport to multiple net operators? It's freaking 2006 here, please let AADS die a slow and horrible death. The only serious IX currently operating in Chicago is at Equinix, and is Ethernet only. Whether they have power or space for you is another matter. If you're confused by any of this, you probably shouldn't be peering, especially given the price of transit. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: ASNumber Extension for Firefox available
On Mon, 13 Feb 2006 14:44:13 +0100 Andre Oppermann [EMAIL PROTECTED] wrote: Another thing I want to do is to show the number of RBL (Spamhaus, etc) listed IPs per AS. That sounds useful. As would be the possibility to block access to sites that are so listed (in the same way that software installation by unauthorised sites is blocked until specifically enabled) Contacting those RBLs is rather difficult and any help to discuss this directly with the RBL administrators is appreciated. That's certainly not been my experience and if you are still having problems I suggest you write to me and I'll forward the request. Richard Cox
Re: Yahoo, Google, Microsoft contact?
On Fri, Feb 03, 2006 at 04:36:56PM +, Christopher L. Morrow wrote: actually, working for a largish company, I'd say one aspect not recognized is the scale on their side of the problem... [EMAIL PROTECTED]|uu|vzb gets (on a bad month) 800k messages, on a 'good' month only 400k ... how many do yahoo/google/msn get? How many do their role accounts get for hostmaster/postmaster/routing/peering ?? Expecting that you can send an email and get a response 'quickly' is just no reasonable unless you expect just an auto-ack from their ticketting system. The heart of this problem, like so many other problems before it, is that most people are dumber than dirt itself. When people are posting to NANOG for a contact, they're saying hey I'm a network engineer who knows what he's talking about, looking for a way to directly contact another network engineer to quickly resolve a problem without having to stay on hold and explain the situation to 20 people who wouldn't understand it anyways for the next 4 hours. Well at least thats how it started, then everyone who reads NANOG started using the same system for their my traceroute is broken complaints and now we're flooded with them. The reality is that the vast vast majority of issues people take it upon themselves to contact a network over are non-existant, the people doing the contacting are remarkably stupid, and more often than not they're the kind of people who are going to be abusive(*) and threatening about it. I know from my own personal experience the ratio of bogus to legit calls regarding security/hacking is around 10:1 on a good day. If there was a number that anyone could call to speak to a clueful person at Yahoo, said clueful person would quit on the second day after the 500th call threatening to sue him because he's hacking a computer on port 80. Until someone invents a universally recognized system where you can call and say Hi I'm CCIE #12345, I'm certified to know what I'm talking about and I have an actual network issue, please transfer me to someone with clue, we're going to continue to see the problem of letting the legit calls through while seperating out the calls from J. Random Crackmonkey who is sniffing the ajax. And from the customer perspective, if you don't want to sit on the phone going through the have you tried rebooting your router script when you call to complain that BGP on an OC48 is down, try buying from a smaller company who focuses on providing service to clueful networks and who doesn't need call screeners for its customers. (*) My all-time personal favorite (not at all work safe) is: http://www.e-gerbil.net/ras/this-man-hates-spam -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Yahoo, Google, Microsoft contact?
On Fri, 03 Feb 2006 12:42:04 -0500 Martin Hannigan [EMAIL PROTECTED] wrote: I'd like to see evidence that there is a problem. For example, don't see why these worm lists couldn't have just gone to the abuse address. Of course that's the right answer. IN THEORY. The practice is rather different, and that's WHY the need for some direct contact exists. I followed through with two large UK ISPs, who had both had the list of worm IPs sent to their official abuse address. In neither case had the mail been read or passed on. A copy to their security specialists was appreciated, and resulted in much hurried activity. No, I'm not going to identify who they were; there probably would have been many more ISPs in that position if I'd looked further. the customer is shifting the cost of support off of their own provider and on to the rest of us which is inherently not fair. s/customer/provider/ - if the provider wasn't doing that, the customer quite likely WOULD have gone directly to them. I think it's ok to post these things to NANOG as long as there's more information than just who they are looking for. If it's too private to tell all of us, then don't use our list as a directory service. True. Nevertheless there is a need for some directory system, so that appropriate people can contact key security etc people in other network entities, without giving NANOG a full-disclosure on the situation ... -- Richard Cox
Re: Anyone heard of INOC-DBA?
On Fri, Feb 03, 2006 at 02:34:16PM -0500, Sean Donelan wrote: On Fri, 3 Feb 2006, Richard A Steenbergen wrote: Until someone invents a universally recognized system where you can call and say Hi I'm CCIE #12345, I'm certified to know what I'm talking about and I have an actual network issue, please transfer me to someone with clue, we're going to continue to see the problem of letting the legit calls through while seperating out the calls from J. Random Crackmonkey How about INOC-DBA, which is supposed to have a clue threshold you obtained an ASN by some means in order to have a dial-by-asn phone. With all due respect to the INOC-DBA project, which is actually somewhat interesting (from a I want to play with free IP phones too perspective if nothing else), it isn't a workable solution to operational contacts yet. Among other reasons, it seems that the vast majority of the users are just people playing around with it at their desk in the office, never expecting it to ring for anything serious. It might be more interesting if people actually set up 1234*NOC extensions, but puck.nether.net seems like a far more effective choice. The INOC-DBA system so far doesn't seem to integrate particularly will with existing NOC phones or systems that are not IP based, and you really have to go out of your way to get it to forward to multiple people like say an engineer on duty. And then of course there is that whole using the IP network to contact someone about an IP network issue thing that doesn't seem terribly well thought out... Admittedly I haven't looked at the INOC-DBA stuff in a while, there could have been some massive advancement that I'm not aware of, but I suspect that the situation is still more work needed. Existing phone systems, call centers, and engineers with cellphones, seems to be a much safer bet right now. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Yahoo, Google, Microsoft contact?
On Fri, Feb 03, 2006 at 08:55:04PM +0100, Per Heldal wrote: On Fri, 3 Feb 2006 14:10:26 -0500, Richard A Steenbergen [snip] The heart of this problem, like so many other problems before it, is that most people are dumber than dirt itself. So ... responsible prociders should only serve customers with some minimum IQ? As said elsewhere in the thread; the responsible thing to do is to scale operations properly. You have to find other ways to deal with people's stipidity than to ignore them completely. No one gets ignored, they just get met with an army of equally stupid minimum wage phone drones who read the have you tried rebooting your router script, and the two sides slug it out in a no holds bared battle of the braindead until one side gives up. Usually though, the script is smarter than the caller, or they wouldn't be using them. This is why people with actual issues don't get noticed as quickly as they should among the sea of false issues. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: 74/8 75/8 76/8
On Wed, Feb 01, 2006 at 03:36:31PM -0500, Martin Hannigan wrote: 74/8, 75/8, and 76/8 These /20's out of ASN 3 Cymru Testing: 74.63.0.0/20 75.127.0.0/20 76.191.0.0/20 ...should be withdrawn now. Allocation out of 74/8 happened on 12/20/2005 and 76/8 1/19/2006. Operationally, the testing should stop prior to allocations from the block, regardless of size. I think it's a binary question, they're either in production or not, and if they are, there should be no intrusive testing. It looks like they were given real ARIN allocations for those test prefixes, so its not like those blocks are going to assigned to some random network who goes to use them and finds out there is a Cymru announcement on their space. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: So -- what did happen to Panix?
On Mon, Jan 30, 2006 at 09:48:13AM +, [EMAIL PROTECTED] wrote: Wouldn't a well-operated network of IRRs used by 95% of network operators be able to meet all three of your requirements? We have such a database (used by Verio and others), but the Panix incident happened anyway due to bit rot. We've got to find a way to fix the layer 8 problems before we can make improvements at layer 3. If an IRR suffers from bit-rot, then I don't consider it to be well-operated and therefore it cannot be considered to be part of a well-operated network of IRRs. The point is that the tools exist. The failing is in how those tools are managed. In other words this is an operational problem on both the scale of a single IRR and on the scale of the IRR system. Is this what you mean by a layer 8 problem? Take it up with the people putting data into the system, not the IRR operators. Anyone who is behind an IRR-based provider (like Verio) has motivation to put data into the system (hey look I do this and now routing works), but there is no motivation to take stale data OUT of the system. I can't even begin to count the number of networks I know who theoretically use IRR who don't even know HOW to remove data, let alone make any active attempt to do so when a customer leaves or a route is returned. Combine this with the idiots who run around proxy registering routes for other people based on everything they see in the table (gee theres a good idea, define filters for what is allowed in the table based on what we see people trying to put into the table, brilliant!) and you quickly see how IRR data becomes stale and eventually worthless. I'll save the rest of my rant for the presentation on the subject in Dallas. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: I never realized so many trains derailed until my Internet kept going out
On Sun, Jan 29, 2006 at 06:37:47AM -0500, Sean Donelan wrote: http://www.thedenverchannel.com/technology/6490915/detail.html It was the third multi-day outage experienced by Comcast Western Slope customers. The two previous also came as a result of train derailments. One Aspen Comcast customer told the Aspen Times that he learned a lot about train derailments as result of his service interruptions. I never realized so many trains derailed until my Internet kept going out, said Michael McVoy. You know, I was wondering when someone was going to mention this one. Personally I think the massive almost-3-day outage on the Qwest and GX longhaul on this path (which of course is a critical link in the northern path crosscountry fiber routes) was a LITTLE more important, but I guess this is better than nothing. Before a few Comcast people bitched about their cable modems, the only coverage of this story was about the ~100 skiers who had to take a bus back to Denver. From what I saw the actual outage was caused by the railroad crews doing cleanup, not the initial derailment. They also took their sweet time removing the cars, and didn't let splicing crews into the tunnel for days. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Strange issue involving sampling
On Wed, Jan 18, 2006 at 03:09:50PM -0500, Peering wrote: First, apologies if this isn't the right place, but I was hoping to hit a lot of networking folks in one shot and this seemed like the likely venue. This sounds like a Juniper-specific issue, so the appropriate place is probably going to be http://puck.nether.net/juniper-nsp/. I have this problem where a customer of mine has issues getting to secure websites (https sites like Charles Schwab's). It doesn't happen all the time, maybe once a month or so. We went to Juniper with the issue (we're using M-20s as our edge routers) and they couldn't figure it out, but one of our engineers found that the config pasted below (with proprietary info removed) fixed the problem. The only problem is that even with this config, we have to restart the sampling daemon every month or so because the problem will come back. Understandably, the customer would prefer to have a more permanent solution. You have to restart the sampling daemon to forward packets to SSL based websites? Wha? Are you sure you didn't accidentally install a Crackpipe Services PIC in that router? :) Anyone have an idea why this one customer on my entire network would have this issue? Supposedly the customer had Cisco come out and look at their network and they couldn't find any reason for it either. [snip] Nothing in that config would cause or cure the problem you've described, unless the config it replaced was from destination-port 443; then reject;. I suspect your problem lies elsewhere, which is why Juniper and Cisco both said there were no problems. :) But if there really is something going on with the Juniper, re-post this to juniper-nsp (with more details about the failure behavior) and I'm sure someone will give it their best shot to figure out what your problem is. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: GoDaddy.com shuts down entire data center?
On Tue, Jan 17, 2006 at 02:09:21AM -0500, Patrick W. Gilmore wrote: On Jan 17, 2006, at 1:32 AM, Jim Popovitch wrote: I want to say, from an outsider's perspective, that I whole heartily applaud GoDaddy on the actions they took [...] There seems to be a wide split on this topic. I was wondering if people would privately tell me yes or no on a few questions so I can understand the issue better. 1) Do you think it is acceptable to cause any collateral damage to innocent bystanders if it will stop network abuse? 2) If yes, do you still think it is acceptable to take down 100s of innocent bystanders because one customer of a provider is misbehaving? 3) If yes, do you still think it is acceptable if the misbehaving customer is not intentionally misbehaving - i.e. they've been hacked? 3) If yes, do you still think it is acceptable if the collateral damage (taking out 100s of innocent businesses) doesn't actually stop the spam run / DoS attack / etc.? I don't think anyone (well ok, anyone sane, I know we have a few nutjobs on this list :P) thinks that arbitrarily blocking service to hundreds or thousands of users because someone is unknowingly hacked is an appropriate way to address network abuse. I really have no idea how aggressive GoDaddy is with enforcing their AUP, as I don't personally use their services, but based on what I know about the affected customer and what I can read from the affected whiner's website I'm certainly not going to jump to the conclusion that GoDaddy is running around like a hopped up abuse desk worker on a power trip, shutting off service to random innocent people because they feel like it. The question at hand is, at what point does a registrar providing services have an ethical or moral obligation to step in and do something when they do encounter an excessive level of abuse by someone using their services? At what point does ARIN revoke the allocation of a blatant and persistant spammer who is violating the law without being stopped? I think the answer is that clearly this isn't something they want to be doing on a regular basis, any more than an ISP wants to be responsible for filtering every packet that goes through their routers looking for warez and kiddie porn, yet I have seen them do it in certain rare and severe cases of unrelenting abuse. Maybe it is a judgement call, maybe it isn't. Bottom line, dealing with abuse is an ass job, and I certainly wouldn't want it. Some days you're doing a good thing because you shut down a spammer, some days you're doing a bad thing because you shut down innocent services along with it (and some days you're just fending off stop hax0ring me on port 80 or I'll sue you and call the CIA e-mails). I highly suspect that GoDaddy doesn't involve itself in these kinds of issues lightly, which means that in all likelihood the level of abuse was severe, with no communication from the person they suspended service to. I for one have never heard of anyone I know having their GoDaddy service suspended for this kind of thing. Unless someone has some actual facts that GoDaddy is engaging in this kind of activity, I'm inclined to give them the benefit of the doubt. This means, at least for now lumping them in the respecting them for taking a stand regarding the abuse of their service category, rather than the wackjob conspiracy theorist power-crazed zealot category we all know and love. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: GoDaddy.com shuts down entire data center?
On Sun, Jan 15, 2006 at 03:32:02PM -0800, Matt Ghali wrote: On Sun, 15 Jan 2006, Elijah Savage wrote: Any validatity to this and if so I am suprised that our team has got no calls on not be able to get to certain websites. http://webhostingtalk.com/showthread.php?t=477562 I for one applaud godaddy's response. If more piddling Hosting Providers with Datacenters got turned off when they started spewing abusive traffic, the net would be a much nicer place. Whoever the heck nectartech is, I guess they might act a little more responsibly in the future. Or, more probably, they'll just change to another DNS registrar who doesn't care as much about abuse. FYI, Nectartech is a small hosting shop out of 55 S Market in San Jose. I wouldn't describe them as a datacenter, since I don't think they own or operate any facilities. Perhaps if they ever managed to find the command to make two routers talk to each other and be redundant (a real quote from what has been loosely described as their network admin, I'm not kidding, you can't make stuff like this up :P), their next step might be to find the command to make dns servers talk to each other and be redundant. Reality check time, what we have here is a small hosting shop with a long history of shady customers. I doubt GoDaddy nukes nameservers on a whim, my money is that there was a lot of abuse which went on for a long time without getting any response. Its amazing how quickly some people who don't respond or address abuse issues at all when you're asking nicely will appear and take care of things once you turn them off. The rest is just some random blowhard web hosting customer who gets off on being an ass and blaming everyone but himself and his choice in hosting companies. Hardly an uncommon sight. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: workhorse of the future...
On Tue, Jan 10, 2006 at 10:39:59PM +, [EMAIL PROTECTED] wrote: first it was the vitalinks, then the bridge gear, then proteon, then cisco AGS, then 7600VXR, then 7301s looking to find the next-gen workhorse ... looking for 4-6yr life expectancy. pointers(private are ok) are appreciated - as well as -why- you think the suggested boxen are likely candidates. You know if I didn't know better, I would think this was a troll. :) Everyone's workhorses are different, depending on what kind of work you want to do with them. The 7200VXR (which is what I assume you meant) and 7301 are the last great mostly cpu based routers out there, which is why they have lasted as long and become as widely used as they have. Any time you have a CPU based solution it is going to be easier to add new features quickly, and handle a wide variety of tasks. Personally I couldn't find a use for either one in my network on a dare, but that is because I care about capacity not high touch services or L2TP termination. It is pretty hard to predict what box is going to be the it thing for the next 5 years, though I certainly agree that anyone interested in making smart purchases needs to be concerned about the viability of the product over exactly that kind of timeframe. For my needs, the Juniper M160 has been the workhorse for the past 3-5 years, though its time is rapidly coming to an end. The weapon of choice for L3 ethernet aggregation is certainly now the 6500/7600 SUP720 based platforms, and will probably see a good 5 years worth of use and deployment. Folks like Foundry, Extreme, and Force10 have all come out with interesting nextgen boxes at L2, but I think they've already lost the L3 war to Cisco before firing a single shot. I'm not entirely certain that the next 5 years has been ironed out in the carrier space yet. There is still plenty of opportunity for Juniper to be dethroned if they follow through with some of the disturbing trends they've been setting (and from all indications, we won't be seeing anything new or even close to revolutionary for at least 2 years). The point has been made that this pattern of becoming complacent re: innovation and cost effectiveness until you get your ass handed to you by a competetive product is the natural cycle of things, and we may very well be near another turning point in the market like what happened when Juniper first hit the scene. The CRS1 hasn't made significant headway into the market yet either though, most likely due to its lack of any low-end or non-40Gbps cards as an upgrade path for existing GSR users. I wouldn't be surprised to see the 7206VXR and 7301 still in use 5 years from now though, some roles just aren't that demanding traffic-wise, and are better served by a CPU based solution. I couldn't tell you if there are plans for a bigger beefier CPU-based router (not my area of concern really), but in that space I think the 7300 may be a safe bet for the near future. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: live chat with other nanog'ers
On Thu, Dec 29, 2005 at 04:18:02PM -0800, Kyle Lutze wrote: I've been watching the list, saw some posts, but nothing definite has been done, is there another place besides efnet where competent people are joining to chat on topic? Otherwise I would love to see people on freenode or oftc I think that a few people here may be under some misconceptions about #nanog on efnet. There are actually many very experienced network operators who hang out there, including frequent nanog attendees and presenters (along with the usual collection of random twits that you'll find anywhere in life, but what are you going to do). However, I believe you will find that most people are there to unwind, not to discuss networking or to answer questions about routers. As such, nanog list readers who wander in expecting on topic conversation or advice about configuring their 2600, rather than general chatter about cell phones and cars, are probably going to be disappointed by the reception they receive. Realistically, most networking issues have already been talked about to death, and most people just don't have anything new to contribute. As far as alternatives go, I think you may find that channels like #ciscohelp on efnet are more in line with what people here are expecting in the way of on topic conversation. Of course you are always welcome to start your own channel on any of a wide variety of networks, as others have already done in the past, but these tend to come and go with some frequency. Having said all that, by all means if #nanog on efnet doesn't fit your tastes, no one is twisting anyone's arm to be there. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: live chat with other nanog'ers
On Thu, Dec 29, 2005 at 07:51:31PM -0800, Kyle Lutze wrote: My problem with #nanog on efnet is not that there is off topic chatter with people unwinding, its when you go in their to ask a question (such as I had forgotten what AS stood for and asked really fast) and you get crap answers, for example: AppleBoy` question on some keyterms used on the list, what is an AS? xkev what is an AS? TestACL typo for ASS xkev ashkie, anal suppressor xkev alk;hr xkev .. AS: anal suppressor and it basically went on like that. So, new chan, perhaps with only decent people in it. Like I said, #nanog is not an appropriate place for absurdly novice questions. The people you mention above are regular nanog attendees and experienced network operators (actually, very experienced), and you are not only wasting their time you are intruding on their conversation by coming to that channel to ask silly questions. That is not intended to be mean, that is simply the way it is. It sounds like what you are really looking for is a channel that is geared towards helping the less experienced without giving sarcastic answers, in which case I stand by the recommendation of #ciscohelp. If in doubt, #nanog is probably not the place for you. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Compromised machines liable for damage?
On Wed, Dec 28, 2005 at 11:17:11PM -0500, Barry Shein wrote: To beat a dead horse just a little harder the problem I have is when a certain company kept distributing software with security flaws specifically because they're profiting from those flaws. For example, graphics libraries which accept binary code chunks to be executed in kernel mode without limits for support of quick screen updates in games considered of marketing importance. Blaming it on the games vendors seems inadequate, particularly over several years and releases of each. That's just pure economics and, hence, profiting on others' serious pain. And yet, I'd bet $10 that: * They know this. * They are just implementing what their customers demand. * They accept that allowing direct access in order to obtain performance at the experience of security is a necessary model in a wide variety of situations, particularly gaming. * They don't give a flying crap what a bunch of perceived whining kooks on NANOG think about that tradeoff. God knows, I wouldn't. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Infected list
On Sun, 25 Dec 2005 13:33:44 -0600 (CST) Rob Thomas [EMAIL PROTECTED] wrote: Here is Barrett's list, including and sorted by ASN. And even that won't be sufficient for many networks to take action. A lot of people provide lists of the IPs that spam/attack/etc them, but do not provide the actual time. Since many consumer networks are running DHCP, they will have no way to know which of their many customers using the claimed IP on the day in question was actually an attacker, and so they will almost certainly ignore such a report. To get action, lists of compromised (etc) systems NEED to include: Date/Time (preferably UTC), exact IP (as hostnames can have multiple A-records) and AS number. -- Richard
Re: Destructive botnet originating from Japan
On Sun, Dec 25, 2005 at 02:06:38AM -0600, Gadi Evron wrote: It is difficult to hear something important that one invested much in is doing harm, but that is the only conclusion I and others can come up with after years of study, and NSP-SEC, as amazing as it has been, has been of a negative impact other than to cause a community to form and act together. Which is amazing by itself and which is why I believe it can do so much more.. even if it is relatively young it has proven itself time and time again... I am straying from the subject here. Could have told you that a long time ago. NSP-SEC became useless the day it became so bogged down in its own self-aggrandizing paranoia that no one could possibly be bothered to actually tell anyone outside of the secret handshake club about security issues they've spotted. On the other hand, if you ARE going to sit around pissing and moaning about botnets you are too sekure to tell anyone else about, thus assuring they never get fixed, at least it's nice to do it in one secret place so I don't have to hear it. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Level3 Blackhole Community
On Wed, Dec 14, 2005 at 05:50:30PM -0700, Erich Borchert wrote: Does anyone know if Level3 supports a BGP black hole community from their customers, .e.g., 3356:666 ? I spoke with someone in their NOC but they lacked clue. According to whois -h whois.radb.net AS3356 | grep remarks ... remarks: remarks:prefix type communities remarks: remarks:3356:123 - Customer route remarks:3356:666 - Peer route ... 3356:666 (aka route of satan?) is applied to any peer route. I've been told the community you're looking for is 3356:, and not as widely speculated, 3356:174. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: www.google.com latency/packet loss/very slow thru savvis
On Tue, Dec 13, 2005 at 03:46:43PM -0600, Erik Sundberg wrote: hey is any one seeing a slow google to day... packet loss 22 hops... visual traceroute show that it goes from chicago to los angeles to singapore to italy to amsterdam and then finally to google in sunnyvale ca. ...yadayadayada... 8 singapore-telecommunications-ltd.LosAngelesEquinix.savvis.net (208.174.196.6) 64.209 ms 62.281 ms 62.374 ms 9 laxeq-cr1.ge-3-0-0.ix.singtel.com (203.208.182.45) 62.767 ms ge-0-3-0.laxeq-cr1.ix.singtel.com (203.208.168.221) 62.958 ms 62.604 ms MPLS Label=126512 CoS=0 TTL=1 S=1 10 so-3-3-2.sngc3-cr1.ix.singtel.com (203.208.154.25) 227.841 ms 225.874 ms 226.254 ms MPLS Label=100288 CoS=0 TTL=1 S=1 11 ge-1-0-0.sngc3-ar2.ix.singtel.com (203.208.172.158) 232.373 ms ge-0-0-0.sngc3-ar2.ix.singtel.com (203.208.172.166) 232.503 ms 239.240 ms 12 203.208.147.238 (203.208.147.238) 424.056 ms * 429.784 ms 13 pal6-pakistan-telecom-1-pk.pal.seabone.net (195.22.197.193) 477.452 ms 478.886 ms * 14 amsix-ams2-racc1.ams.seabone.net (195.22.213.221) 483.282 ms 491.266 ms 480.559 ms 15 core1.ams.net.google.com (195.69.144.247) 448.393 ms 442.054 ms 435.464 ms You'd be better off with an AS-PATH, but just follow the chain... Savvis - Singtel - Pakistan Telecom - Seabone - Google. Where I'm from, we call that a routing leak. Doesn't take too much work to guess where either. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: www.google.com latency/packet loss/very slow thru savvis
On Tue, Dec 13, 2005 at 05:02:42PM -0500, Richard A Steenbergen wrote: You'd be better off with an AS-PATH, but just follow the chain... Savvis - Singtel - Pakistan Telecom - Seabone - Google. Where I'm from, we call that a routing leak. Doesn't take too much work to guess where either. :) Oh and FYI it is still going on, though the route just changed 4 mins ago: [BGP/170] 00:04:21, localpref 200 AS path: 7473 17557 17557 17557 17557 5400 15169 I Singtel - Pakistan Telecom - British Telecom - Google. AS17557 is leaking its BGP table, and AS7473 is not filtering its customer. Bad network, bad. No cookie. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Juniper DNS cache
On Fri, Dec 09, 2005 at 05:42:17PM -0500, Peering wrote: Dumb question...anyone know how to clear the DNS cache on a Juniper M-20? I looked all through the JUNOS documentation on their website and looked through all the available commands and couldn't find anything. Juniper does not operate as a caching nameserver, therefore it has no DNS cache. It will send new queries to its configured nameservers every time, so if something isn't updating, it is the nameservers you are using. This question would probably be better suited for the Juniper-NSP mailing list (http://puck.nether.net/juniper-nsp/) too. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Sat, 03 Dec 2005 00:45:05 + W.D.McKinney [EMAIL PROTECTED] wrote: It's a simple switch in the GUI of Barracuda Networks to turn of this annoyance. More operator error than Barracuda's fault, IMHO. Not if a software upgrade from Barracuda can cause the current configuration to be silently reverted to Barracuda's defaults ... -- Richard
Re: BGP Security and PKI Hierarchies
On Tue, Nov 29, 2005 at 10:21:53AM +, [EMAIL PROTECTED] wrote: It's hard to imagine an organization who can afford to run a network using BGP to announce a class C block and not be able to afford $1250 per year. Sounds like a failure of imagination to me. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: the future of the net
On Wed, Nov 16, 2005 at 04:42:41PM -0800, Randy Bush wrote: http://www.linuxjournal.com/article/8673 Hrmmm... The future of the net? You mean, will crazy people continue to post crazy rants about things they clearly don't fully understand? All signs point to yes. You can just call me Netstradamus. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: [Latest draft of Internet regulation bill]
On 13 Nov 2005 00:56 UTC, Leo Bicknell [EMAIL PROTECTED] wrote: The sad thing is, these are not things with a precise definition. You can invision defining Long Distance before there were cell phones, and it might not have included them. Of course, I think if you stop anyone on the street and ask if they can call a cell phone using their long distance service they would stare at you blankly with a of course, why wouldn't you kind of response. Not at all. In many parts of the world Long Distance still does not include cellphones. Even calls from the USA to Europe or Australasia (over the cheaper networks) will not complete at all if a cellphone number range is dialled. On other networks there is a price uplift. (It didn't used to be like that in the olden days, though!) -- Richard Cox
Re: Peering VLANs and MAC addresses
On Wed, Nov 09, 2005 at 11:59:38PM -, Chris Roberts wrote: I think the 'connect only routers' adage is probably a good conservative motto to stick to. There are situations where connecting switches and hybrids to IXPs is certainly more efficient and better suited, but only if you know what you're doing or have a good reason for it. As I understand it, most IXPs are pretty well protected against guff coming from switches these days anyway, but it still doesn't make sense in my mind to have a free for all on what people can connect. At least this adage might make someone who might not be experienced in what they're doing think twice and ask someone who knows better before doing it (as indeed it seems to have done in this case). There is no technical reason why you can't hook up as many switches as you need, is there any real difference between a L3 switch and a L3 router (except for its internal architecture and maybe a couple of 0's at the end of the price :P). There are only good products, and bad products, smart people, and stupid people. Stupid people running bad products will find a way to leak stupid stuff to the IX and screw things up royally, regardless of the type of product connected. Smart people running good products USUALLY won't, no matter how many layer 2 and 3 switches stand between a router and an IX port. Of course I think part of the qualification for being considered a smart person involves being able to connect switches to IX's without blowing anything up, so those results might be a little biased. Only connecting routers is really just attempting to mitigate the effects of stupid people by forcing them to run configurations so simple even a monkey could pull it off. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: classful routes redux
On Wed, Nov 02, 2005 at 04:14:31PM -0800, Bill Woodcock wrote: On Wed, 2 Nov 2005, Fred Baker wrote: While I think /32, /48, /56, and /64 are reasonable prefix lengths for what they are proposed for, I have this feeling of early fossilization when it doesn't necessarily make sense. Yeah, that's what seems important to me here... I mean, I've lived through the whole classful thing once... I'm still not clear why there are people who want to do it again. Well to be fair, classful routing actually did have a few advantages. Longest prefix match lookups have historically always been very difficult, so difficult that it held back the speed of routers for years. We've only recently been able to get a handle on the problem in hardware. Also, some of the original motivations behind CIDR starts to go out the window when you have enough IP space that you can hand out huge chunks ahead of immediate need. Who cares about efficient utilization or but I only need a /35 and you gave me a whole /32, I'm wasting so much space when there is not a space shortage. Just allocate enough space that you will never need to upgrade, you'll be doing more good than trying to predict or restrict your usage and creating more routing entries later when you need more space. Of course none of this is a compelling argument for classful routing. We've pretty much got the longest prefix match thing covered at this point, and claims that we need to scale bgp to support 2^128 routes so that everyone can multihome their refrigerators are a load of crap. Also, just because 2^128 is a big number does not mean that all IPv6 space is infinite, and there is no reason to get short-sighted. If we're really going to end up in a situation where a /64 is a host, then a /48 is the equivilent of a /16 on IPv4. That is a decent sized chunk for small users, but hardly infinite. If you are a larger provider with a /32 and you have to hand out /48s to everyone, it is like only having a /16 yourself. Imagine a large cable company who had to give an IP to every customer and trying to get it all done in a single /16. Suddenly all this massive space seems to be running low. /56s and the like as allocations seem like a really bad and short-sighted idea, unless we're talking about it for nothing more than business-class end-user service like a /27 on a business grade DSL circuit today. I'm still not seeing any reason that everything can't work itself out through existing means. Make the preferred allocation size from RIRs /32, to be given out to large networks or anyone with an ASN who asks for one. Make the preferred reallocation size for enterprises /48, and make it the smallest block which can be announced in BGP (with the expectation that /32s will be the primary announcement). Make the preferred assignment for end-users (cable modems and such) /64, and use the remaining 64 bits as a giant waste of time but one that makes certain we won't have to deal with NAT ever again. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: classful routes redux
On Thu, Nov 03, 2005 at 03:29:35PM -0500, Todd Vierling wrote: On Thu, 3 Nov 2005, Stephen J. Wilcox wrote: well, /56 /48 /32 seem to have resonance but are not special in any way Well, they are somewhat special. All of them are on eight-bit boundaries. The importance of this comes in when deciding how to lay out a routing table in a gate array or memory-based table. A routing table capable of handling a flat 2^128 addressing space goes beyond the realm of known physics -- and flat 2^64 comes close, at least for a while (consider semiconductor atomic weights, and the fact that 1 mole is approximately 2^79 atoms). That's quite a stretch, but should give a hint as to why flat addressing does not work for every model. Come on now, a lot of new routing gear made today can just barely handle 2^18 routes, and even the high end stuff tops out at 2^20. We're nowhere near handling 2^32 routes even for IPv4, nor should we be, so lets not start the whole but ipv6 has more space therefore routes will increase to 7873289439872361837492837493874982347932847329874293874 nonsense again. Removing the extreme restrictions on IP space allocation by being able to allocate chunks so large that you would RARELY need to go back for a second block would immediate reduce the size of the routing table. Let me state the stats again for the record: Total ASes present in the Internet Routing Table: 20761 Origin-only ASes present in the Internet Routing Table: 18044 Origin ASes announcing only one prefix:8555 Transit ASes present in the Internet Routing Table:2717 There are just not that many distinct BGP speaking networks out there, nor will there ever be. NOW is the time to make certain that IPv6 deployments makes sense in practice and not just in theory, so we don't work ourselves into exactly the same mess that we did in IPv4. Lets stop trying to solve theoretical scaling problems which will never happen at the expense of creating problems which actually DO exist, and apply a little bit of common sense. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: cogent+ Level(3) are ok now
On Wed, Nov 02, 2005 at 08:22:20AM -0600, Pete Templin wrote: Time out here. John set the stage: cold potato addressed the long haul (or at least that's the assumption in place when I hopped on board). If NetA and NetB are honoring MED (or other appropriate knob), NetA-NetB traffic has already arrived at the closest mutual peering point in the A-B direction. The rest of the infrastructure would be the responsibility of NetB to get the traffic to CustomerPortXYZ, no? How could CustomerXY get any closer to NetA without cutting NetB out of the middle, and if NetB is out of the middle, why should CustomerXY pay NetB anything? You're forgetting that MEDs suck. When used on real complex production networks, they almost always degrade the quality of the routing. Yes with enough time and energy (or a small enough network) you *can* beat perfect MEDs out of the system (and your customers). You can selectively deaggregate the hell out of your network, then you can zero out all the known aggregate blocks and regions that are in the middle of two MED-speaking interconnection points, and get your customers to tag aggregate blocks announced in multiple locations so that you can zero out those MEDs. With enough time and energy anything is possible, the point is that most folks don't consider it to be worth the time, let alone the customer anger when it degrades your traffic. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: SBC/ATT + Verizon/MCI Peering Restrictions
On Wed, Nov 02, 2005 at 03:04:52AM -1000, Randy Bush wrote: the two year window is far too low given the sbc ceo's recent public statements on the use of his wires by google and the like. Come on, you didn't see that coming? I'd wager money that right now, somewhere at SBC, there are two executives in a board room with arms interlocked at the elbow, skipping merrily in a circle with giant grins on their faces, chanting: o/~ We're gonna be a tier 1 o/~ o/~ We're gonna be a tier 1 o/~ -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Using BGP to force inbound and outbound routing through particular routes
On Wed, Nov 02, 2005 at 03:35:07PM -0600, John Dupuy wrote: There is nothing about a cable modem that would normally prevent a BGP session. Nor do all the intermediate routers need to support BGP (multi-hop BGP). However, direct connections are preferred. Your _real_ challenge is convincing Roadrunner's NOC staff to program one of their backbone routers to do a BGP session with a cable modem sub. Or, for that matter, getting them to even route a non-roadrunner IP block to a cable modem sub. Instead you might try borrowing a bunch of old 2500s and setting up a test lab that isn't connected to actual net. Best of luck on your CCIE. A) No cable company in their right mind is going to speak BGP to a $29.95/mo residential customer, period. B) The answer to his question about I don't know if what I'm doing will violate the AUP or not is, when in doubt the answer is YES. No sane comapny is going to let this guy near bgp with a 10ft pole after that statement, but then again no sane people read nanog any more I suspect. C) If this guy actually had a CCIE, I would encourage Cisco to quickly implement a SWAT team responsible for reposessing the CCIE medals of anyone caught using the words Class C for a /24 out of 66. space. D) Please do not feed the trolls. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Using BGP to force inbound and outbound routing through particular routes
On Wed, Nov 02, 2005 at 03:21:15PM -0800, Joe McGuckin wrote: RAS, I have to admit that I'm guilty of using the phrase class C more or less interchangably with /24 - I suspect a lot of us still do that... Well, on behalf of the entire networking community, I hereby ask you to stop it. :) It's just a bad habit, and while you may know exactly what it means and doesn't mean, it does nothing but confuse new people about how and why classless routing works. It is absolutely absurd that so many people still teach classful routing FIRST to new students in this day and age, and then approach classless routing like it is something new and different which should be considered as an afterthought. Just remember, the people you confuse today are the ones who are going to be announcing their legacy erm class B allocations as /24s tomorrow, because they don't know any better. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: cogent+ Level(3) are ok now
. These networks face constant attrition from more competetive providers, and quickly realize that access to their single homed customers is one of their only bargining chips left to make people pay a higher price. Yes these are financially trying times for everyone, content and access networks alike. Everyone wants to take action to generate additional revenue, or to strike out at networks who are perceived as offering prices which are too low based on dumping of push heavy traffic and unfair cost burdons. Unfortunately in the rush to do that, many networks are actually creating exactly the situation they want to avoid. How much business do you think has been lost to Cogent giving away free or super-low-cost inbound in order to prop up its ratios? How much revenue has been generated by depeering Cogent because of ratio imbalances? The numbers speak for themselves, regardless of who does or doesn't pay a higher amount to deliver the traffic. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
