Re: Bogon Filter - Please check for 77/8 78/8 79/8
Florian Lohoff wrote: Hi *, in august IANA handed 77/8 78/8 79/8 to RIPE which started handing out those ranges 2 months ago. We (Telefonica Deutschland AS6805) are seeing a lot of reachability problems most likely caused by not updated bogon filters. For testing purposes 77.181.114.4 aka bogon.mediaways.net is up for icmp/http. Please check and possibly update your filters. Flo (aka [EMAIL PROTECTED]) To facilitate de-bogonising the RIPE NCC advertises some of the prefixes from the newly allocated ranges from our RIS beacons. We do this for a few months before starting allocating them to LIRs. http://www.ris.ripe.net/debogon/debogon.html Andrei Robbachevsky RIPE NCC
RE: Bogon Filter - Please check for 77/8 78/8 79/8
So we're saying that a lawsuit is an intelligent method to force someone else to correct something that you are simply using to avoid the irritation of manually updating things yourself??? That seems to be the epitomy of laziness vs. litigousness. Scott No, but a lawsuit may be an intelligent method to force someone to correct something that other people are using to avoid the irritation of manually updating things themselves. I agree it would be idiotic if someone using the bogon list were to sue the list operator because they didn't like what was on the list and it was harming them. If all other methods fail to get the bogon list updated, which is easier: A) Track down everyone using the bogon list and convince them to switch to manually updating their own list of bogons so that they can reach you. B) Threaten the bogon list operator with a lawsuit for falsely claiming your addresses are bogons and hope they take the simplest path and fix their list. This is a pretty classic case of someone inducing other people to rely on the accuracy of their data and then offering incorrect data (not arguably incorrect, manifestly incorrect and most likely negligently so) which those other people then rely on. It's no different from a credit report with inaccurate information affecting a consumer who did not choose to have his credit tracked by the agency providing the information. We generally recognize third parties have a right to sue to correct negligently demonstrably incorrect information about them when that information harms them. This is not like lists of spam sources where the list is correctly reporting information the spammer would prefer to suppress. This is a case where the list is wrong, and it's harming other people who stupidly relied on it and people who never chose to rely on it. If you set up a service and induce people to use it and rely on it, there definitely should be some minimum standard of quality you should be held to. I think failing to update a bogon list to reflect address space that is no longer a bogon within a week or so is negligence under any standard of care. DS
GBLX issues?
Anyone seeing issues for GBLX around NY? DISCLAIMER: I WOULD HAVE POSTED TO THE OUTAGE LIST BUT THAT WOULD MAKE 100+ MAILING LISTS APOLOGIES TO THE OTP (OFF-TOPIC POLICE) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo echo @infiltrated|sed 's/^/sil/g;s/$/.net/g' http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x1383A743 How a man plays the game shows something of his character - how he loses shows all - Mr. Luckey
RE: Bogon Filter - Please check for 77/8 78/8 79/8
B) Threaten the bogon list operator with a lawsuit for falsely claiming your addresses are bogons and hope they take the simplest path and fix their list. This is a pretty classic case of someone inducing other people to rely on the accuracy of their data and then offering incorrect data (not arguably incorrect, manifestly incorrect and most likely negligently so) which those other people then rely on. It's not just incorrect data. The design of the system used by completewhois is flawed at the core. They only know that certain address ranges are bogons at a certain point in time. If their system only reported this fact along with the date for which it is known to be valid, then they would likely win any lawsuits for incorrect data. The fact is, that you can only know that an address range is a bogon at the point in time which you check it and that it WAS a bogon for some past period. For most bogons, it is not possible to predict the future time period during which it will remain a bogon. Any protocol which does not allow the address range to be presented along with the LAST TIME IT WAS CHECKED is simply not suitable for presenting a bogon list. BGP simply is not suitable for this. HTTP/REST, XML-RPC or LDAP could be used to make a suitable protocol. But even better would be to not have any bogons at all. If IANA and the RIRs would step up to the plate and provide an authoritative data source identifying which address ranges have been issued for use on the Internet then bogon lists would not be needed at all. And if people plug their systems into the RIR data feed, then there would be fewer issues when the RIRs start issuing addresses from a new block. IANA would be the authoritative source for stuff like RFC 1918 address ranges and other non-RIR ranges. One wonders whether it might not be more effective in the long run to sue ICANN/IANA rather than suing completewhois.com. --Michael Dillon P.S. As any lawyer will tell you, it is a good idea to make some attempt at solving your issue outside of the courts. Anyone contemplating a lawsuit against ICANN should probably try emailing them and writing a few letters first. Since they are a somewhat democratic structure, it may be possible to get this fixed without lawsuits.
GBLX issues anyone?
Anyone seeing issues for GBLX around NY? DISCLAIMER: I WOULD HAVE POSTED TO THE OUTAGE LIST BUT THAT WOULD MAKE 100+ MAILING LISTS APOLOGIES TO THE OTP (OFF-TOPIC POLICE) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo echo @infiltrated|sed 's/^/sil/g;s/$/.net/g' http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x1383A743 How a man plays the game shows something of his character - how he loses shows all - Mr. Luckey
Re: GBLX issues?
On Wed, 13 Dec 2006, J. Oquendo wrote: Anyone seeing issues for GBLX around NY? Do you have traceroutes or other useful data to illustrate said broken-ness? jms
RE: Bogon Filter - Please check for 77/8 78/8 79/8
On Wed, 13 Dec 2006 [EMAIL PROTECTED] wrote: It's not just incorrect data. The design of the system used by completewhois is flawed at the core. No more so that other systems that rely on automation with some human involvement but see below as I generally agree with what you meant. They only know that certain address ranges are bogons at a certain point in time. If their system only reported this fact along with the date for which it is known to be valid, then they would likely win any lawsuits for incorrect data. Timestamps are included in every generated file. There is general timestamp when full list was put together (usually daily and that's what almost everyone is using) but also there are different timestamps for each individual list which for semi-static list like IANA allocations, IANA bogons, IANA special-use blocks are updated only when this list is manually updated. The fact is, that you can only know that an address range is a bogon at the point in time which you check it and that it WAS a bogon for some past period. For most bogons, it is not possible to predict the future time period during which it will remain a bogon. That is why system is doing rebuilding on daily basis. Any protocol which does not allow the address range to be presented along with the LAST TIME IT WAS CHECKED is simply not suitable for presenting a bogon list. BGP simply is not suitable for this. HTTP/REST, XML-RPC or LDAP could be used to make a suitable protocol. I know you like LDAP a lot, but its not protocol that have found support in operations community (as opposed to say RSYNC not mentioned above...). But as I've already thought about it before, I'll look into making data about each individual entry available by whois lookups and extended text file with comments (# after each entry) with these comments also see in TEXT DNS lookups. But even better would be to not have any bogons at all. If IANA and the RIRs would step up to the plate and provide an authoritative data source identifying which address ranges have been issued for use on the Internet then bogon lists would not be needed at all. And if people plug their systems into the RIR data feed, then there would be fewer issues when the RIRs start issuing addresses from a new block. IANA would be the authoritative source for stuff like RFC 1918 address ranges and other non-RIR ranges. SIDR will provide authoritative signed data, but it maybe quite some time (my guess at least 10 years) before we see majority of BGP advertised blocks with signed certificates available (and as to ALL doing it, I fear to guess...). And I do agree with you about IANA; not only that but at the first (?) IETF SIDR meeting I even mentioned need for IANA to distribute certificates for non-allocated and special-use blocks. Others weren't very optimistic that they'd step up; in fact put it this way - by the time they may get to it, there may no longer by any unassigned IPv4 blocks left. P.S. I'd be curious if there are people who would like to see daily activebogons list as email report including section about changes from yesterday to today, I don't want to just send something like this to some list I've not been invited to do so but can setup separate list for this on new mail server. This would allow others to check on and discuss potentially wrong entries. If you're interested you should send email to me privately. --- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: GBLX issues?
On 12/13/06, J. Oquendo [EMAIL PROTECTED] wrote: Anyone seeing issues for GBLX around NY? DISCLAIMER: I WOULD HAVE POSTED TO THE OUTAGE LIST BUT THAT WOULD MAKE 100+ MAILING LISTS APOLOGIES TO THE OTP (OFF-TOPIC POLICE) dude, chill. no need to yell. you know, GBLX sells a lot of different stuff - are we talking IP transit, MPLS transport, wavelength, voice? what kind of issues? how is anyone going to know what you're talking about when you're as vague as humanly possible.
Re: GBLX issues?
On Wed, 13 Dec 2006, Aaron Glenn wrote: On 12/13/06, J. Oquendo [EMAIL PROTECTED] wrote: Anyone seeing issues for GBLX around NY? dude, chill. no need to yell. you know, GBLX sells a lot of different stuff - are we talking IP transit, MPLS transport, wavelength, voice? what kind of issues? how is anyone going to know what you're talking about when you're as vague as humanly possible. You're awful at this game. When faced with a totally vague question, lacking context or useful information, it's up to you to supply your own. Start with, always: Yes, vendor is having problems in location. Then, tap your coworkers for assistance: 1: Name a hardware Vendor (the lower the stock value, the better) 2: Name a transport technology (frame relay, sonet, etc) 3: A number between 1 and 10. 4: A number between 8 and 32. 5: A seasonally relevent catastrophic event (snow storm, backhoe, exploding squirrel) Respond: Yes, vendor is having problems in location. Seems 5 hit this morning around 3 am, effecting 2 connections in that location. Vendor is having problems getting backup systems online, because they were idiots and deployed 1 gear without failover. At last check, it'll be at least 4 hours before they get things sorted out. - billn
Re: GBLX issues anyone?
We had some issues out of indy yesterday afternoon and night but cleared up sometime before midnight. Symptom was 250+ms response on first hop into their network. tv - Original Message - From: J. Oquendo [EMAIL PROTECTED] To: nanog@merit.edu Sent: Wednesday, December 13, 2006 7:54 AM Subject: GBLX issues anyone?
Re: GBLX issues?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Saved for future use... Classic. ~ Matt Taber [EMAIL PROTECTED] WMIS Internet http://www.wmis.net 616-281-9647 1-888-482-9647 Accelerate ... It's a Speed Thing PGP: http://www.wmis.net/pgp/0x3077CD7C ~ Bill Nash wrote: On Wed, 13 Dec 2006, Aaron Glenn wrote: On 12/13/06, J. Oquendo [EMAIL PROTECTED] wrote: Anyone seeing issues for GBLX around NY? dude, chill. no need to yell. you know, GBLX sells a lot of different stuff - are we talking IP transit, MPLS transport, wavelength, voice? what kind of issues? how is anyone going to know what you're talking about when you're as vague as humanly possible. You're awful at this game. When faced with a totally vague question, lacking context or useful information, it's up to you to supply your own. Start with, always: Yes, vendor is having problems in location. Then, tap your coworkers for assistance: 1: Name a hardware Vendor (the lower the stock value, the better) 2: Name a transport technology (frame relay, sonet, etc) 3: A number between 1 and 10. 4: A number between 8 and 32. 5: A seasonally relevent catastrophic event (snow storm, backhoe, exploding squirrel) Respond: Yes, vendor is having problems in location. Seems 5 hit this morning around 3 am, effecting 2 connections in that location. Vendor is having problems getting backup systems online, because they were idiots and deployed 1 gear without failover. At last check, it'll be at least 4 hours before they get things sorted out. - billn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFgGoyhqnZajB3zXwRAiM4AKCskORTrF7HRlS6/SxrBcJDbXCHkwCfQVzO gMWtnyvUzWB7F2ra2ICwoGc= =mgHG -END PGP SIGNATURE-
GBLX (or other) issue continuing (?)
Hello folks, I've gotten a couple of calls from people today complaining about a spike in latency when using GBLX paths. I saw a couple of posts asking about potential GBLX issues yesterday. (But they seemed to devolve into mild flaming, and I couldn't glean any useful info from them, except that SOME people seemed to be having SOME kind of problem.) Anyhow, here's a trace someone sent 1 207.244.155.177 (207.244.155.177) 1.152 ms 0.760 ms 0.593 ms 2 208.99.192.133 (208.99.192.133) 2.990 ms 3.208 ms 1.771 ms 3 204.8.32.85 (204.8.32.85) 3.243 ms 1.573 ms 2.444 ms 4 208.99.192.58 (208.99.192.58) 2.705 ms 2.580 ms 2.782 ms 5 ge-0-1-0.ar2.SEA1.gblx.net (64.215.184.161) 1.752 ms 2.782 ms 2.160 ms 6 * * * 7 * * * 8 te-4-1.car4.LosAngeles1.Level3.net (4.68.110.65) 37.129 ms 36.173 ms 36.437 ms 9 * ae-32-56.ebr2.LosAngeles1.Level3.net (4.68.102.190) 48.388 ms * 10 * ae-2.ebr1.SanJose1.Level3.net (4.69.132.9) 43.981 ms 54.608 ms 11 ae-1-100.ebr2.SanJose1.Level3.net (4.69.132.2) 49.057 ms * 48.426 ms 12 ae-3.ebr1.Denver1.Level3.net (4.69.132.58) 99.259 ms * 100.438 ms 13 ae-3.ebr1.Denver1.Level3.net (4.69.132.58) 89.555 ms ae-1-100.ebr2.Denver1.Level3.net (4.69.132.38) 99.875 ms * 14 * ae-1-100.ebr2.Denver1.Level3.net (4.69.132.38) 89.361 ms ae-3.ebr1.Chicago1.Level3.net (4.69.132.62) 89.568 ms15 * * ae-1-100.ebr2.Chicago1.Level3.net (4.69.132.42) 100.631 ms 16 * ae-7-7.car1.Boston1.Level3.net (4.69.132.241) 116.866 ms 120.512 ms 17 ae-11-11.car2.Boston1.Level3.net (4.69.132.246) 118.752 ms 126.690 ms ae-7-7.car1.Boston1.Level3.net (4.69.132.241) 126.614 ms 18 unknown.Level3.net (63.211.176.18) 116.590 ms 116.168 ms 116.375 ms 19 unknown.Level3.net (63.211.176.18) 116.316 ms ge5-1.aggr2.sbo.ma.rcn.net (207.172.15.152) 116.340 ms 120.395 ms One somewhat savvy customer who had the forethought to commit to his memory a general map of the routes to the last host has noticed that things changed over the last 2 hours. He's now jumping from Seattle to LA, to San Jose, to Denver, to Chicago, and then to Boston before finally hitting his destination. Perhaps this isn't even really a GBLX issue, but the customer seems to remember going straight from Seattle to somewhere east before, all via GBLX I presumably. Anyhow, I'm just fishing for any other weirdness that people may have seen, as well as any news people might have heard about fiber cuts, outages, etc. FWIW, the wind in Seattle right now is outrageous. Probably unrelated, but I figured I'd throw it out there Thanks, Rick Kunkel
Re: Bogon Filter - Please check for 77/8 78/8 79/8
[EMAIL PROTECTED] wrote: One wonders whether it might not be more effective in the long run to sue ICANN/IANA rather than suing completewhois.com. Of course, it could be that I used the wrong term. IANAL after all. Perhaps the right term was injunction? Does that qualify as a lawsuit? Unfortunately, people seem to think the legal system is strictly about money. Perhaps it is. However, in the process of people getting money, I've noticed people have solved their initial problem temporarily. besides, it didn't look like it really took all that much to solve the completewhois.com problem. Surely people don't pay their lawyers without first yelling, screaming, and calling everyone and their dog (or posting to NANOG) in the attempt to get what they want first. :) Jack
RE: GBLX issues?
this morning around 3 am, effecting 2 connections in that You mean 'affecting.' -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben Net Access Corporation, 800-NET-ME-36, http://www.nac.net
RE: GBLX issues?
On Wed, 13 Dec 2006, Alex Rubenstein wrote: this morning around 3 am, effecting 2 connections in that You mean 'affecting.' Pobody's nerfect. - billn
SatCom communications alert
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just as an FYI, radio communications, satellites communications, and power grids (including some SCADA systems) could face potential interruptions or damage tomorrow due to some very odd (out of cycle) solar activity. Story here: http://www.msnbc.msn.com/id/16187534/ More: http://www.sec.noaa.gov/ Just a heads-up. They're talking about midday tomorrow (Eastern Time, I suppose)... - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.1 (Build 1557) wj8DBQFFgOTeq1pz9mNUZTMRAnqoAKC9cjZ03Uk0LwFltbFqBf8Uvdu7YQCfYQTS D/PYMcYa7TO/W6HWNmmMZIY= =EvSN -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Curious question on hop identity...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This may be far afield insofar as topic fodder, but I am curious if anyone knows exactly what these two hops [9] [10] below, actually are? [snip] [...] 5 165 ms 161 ms 183 ms 10g-9-1-ur04.sanjose.ca.sfba.comcast.net [68.87. 192.49] 6 155 ms 156 ms 149 ms 10g-7-1-ur03.sanjose.ca.sfba.comcast.net [68.87. 192.41] 7 ** 163 ms 10g-9-1-ar01.sfsutro.ca.sfba.comcast.net [68.87. 192.37] 8 161 ms 157 ms * 68.87.226.130 9 169 ms 185 ms 171 ms 12.116.90.17 10 197 ms 198 ms 196 ms 12.122.114.66 11 157 ms 169 ms 175 ms ggr3-ge110.sffca.ip.att.net [12.122.82.169] 12 145 ms 149 ms 148 ms 192.205.33.82 13 182 ms 196 ms 209 ms ae-2-54.bbr2.SanJose1.Level3.net [4.68.123.97] 14 344 ms 332 ms 339 ms as-0-0.mp2.Stockholm1.Level3.net [4.68.128.70] 15 330 ms 343 ms 390 ms ge-1-1.car2.Stockholm1.Level3.net [4.68.96.226] [...] [snip] I have asked SBC/ATT folks and received no reply at all... Cheers, - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.1 (Build 1557) wj8DBQFFgPw+q1pz9mNUZTMRAiFEAJ9y481aCutAqVuQrLcMPa3iC6SoXwCgigNC ZE+BBNraVc4VMlUKfyzYNJg= =34zg -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Curious question on hop identity...
On Thu, 14 Dec 2006, Fergie wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This may be far afield insofar as topic fodder, but I am curious if anyone knows exactly what these two hops [9] [10] below, actually are? Wouldn't you like to know? -- Alex Pilosov| DSL, Colocation, Hosting Services President | [EMAIL PROTECTED]877-PILOSOFT x601 Pilosoft, Inc. | http://www.pilosoft.com
Re: Curious question on hop identity...
On 2006-12-14-02:24:52, Fergie [EMAIL PROTECTED] wrote: This may be far afield insofar as topic fodder Not in the slightest. To the contrary, it's one of the more on-topic postings I've seen as of late, and I mean that with all sincerity. I am curious if anyone knows exactly what these two hops [9] [10] below, actually are? [...] 8 161 ms 157 ms * 68.87.226.130 9 169 ms 185 ms 171 ms 12.116.90.17 10 197 ms 198 ms 196 ms 12.122.114.66 11 157 ms 169 ms 175 ms ggr3-ge110.sffca.ip.att.net [12.122.82.169] 12 145 ms 149 ms 148 ms 192.205.33.82 13 182 ms 196 ms 209 ms ae-2-54.bbr2.SanJose1.Level3.net If I had to guess, I'd say 9 is a /30 (/31?) on Comcast's transit interface, and 10 is a backbone device of some sort. Suffice it to say, ATT doesn't consider maintaining accurate (or even inaccurate, for that matter) PTR records a priority. Some recent faves include: 6 ggr3-ge00.n54ny.ip.att.net (12.123.0.97) 1.538 ms 1.400 ms 1.422 ms 7 att-gw.dc.aol.com (192.205.32.2) 1.775 ms 1.816 ms 1.847 ms 8 0.ge-5-1-0.XL4.NYC4.ALTER.NET (152.63.3.121) 1.701 ms 1.742 ms 14.988 ms 5 cw-gw.n54ny.ip.att.net (192.205.32.197) 0.648 ms 0.635 ms ggr3-p3122.n54ny.ip.att.net (192.205.33.117) 0.838 ms 6 tbr1-p012204.sl9mo.ip.att.net (12.122.82.22) 1.596 ms 1.759 ms 1.466 ms 4 savvis-gw.cgcil02ck4.ip.att.net (208.175.10.94) [AS 3561] 56 msec 60 msec allegiance-gw.dlstx.ip.att.net (192.205.32.225) [AS 7018] 196 msec 5 tbr1-p014001.cgcil.ip.att.net (12.123.6.34) [AS 7018] 4 ggr2-p310.sffca.ip.att.net (12.123.12.18) [AS 7018] 32 msec 16 msec 20 msec 5 att-gw.ashburn.eli.net (192.205.32.74) [AS 7018] 20 msec 20 msec 20 msec 6 0.so-2-0-0.XL1.SCL2.ALTER.NET (152.63.57.50) [AS 701] 20 msec 16 msec 16 msec -a
