Verio filtering... Would be nice if they at least honored what they said...
http://info.us.bb.verio.net/routing.html Quote: "We do not announce prefixes longer than /24." Then why do I have: 5 /25 2 /26 3 /27 3 /28 21 /29 *sigh* I guess we don't eat our own dogfood... Searching for matching routes, use ^C to quit... Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH S:SUPPRESSED F:FILTERED Prefix Next HopMetric LocPrf Weight Status 1 63.73.183.0/25 129.250.126.97 2 1000 EF AS_PATH: 2914 10910 10910 10910 10910 10910 10910 10910 10910 10910 8012 2 128.241.222.0/28 129.250.126.97 3 1000 EF AS_PATH: 2914 12008 3 168.143.110.0/28 129.250.126.97 3 1000 EF AS_PATH: 2914 12008 4 192.41.162.0/25129.250.126.97 3 1000 EF AS_PATH: 2914 14745 5 198.107.213.8/29 129.250.126.97 3 1000 EF AS_PATH: 2914 11854 11854 11854 11854 11854 11854 11854 6 198.107.213.16/29 129.250.126.97 3 1000 EF AS_PATH: 2914 11853 11853 11853 7 198.107.213.24/29 129.250.126.97 3 1000 EF AS_PATH: 2914 12179 8 198.107.213.32/29 129.250.126.97 3 1000 EF AS_PATH: 2914 13790 9 198.107.213.40/29 129.250.126.97 3 1000 EF AS_PATH: 2914 10912 10912 10912 Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH S:SUPPRESSED F:FILTERED Prefix Next HopMetric LocPrf Weight Status 10 198.107.213.48/29 129.250.126.97 3 1000 EF AS_PATH: 2914 12180 11 198.107.213.56/29 129.250.126.97 2 1000 EF AS_PATH: 2914 10910 10910 10910 10910 10910 10910 10910 10910 10910 12 198.107.213.64/29 129.250.126.97 4 1000 EF AS_PATH: 2914 13789 13789 13789 13789 13789 13 198.107.213.72/29 129.250.126.97 3 1000 EF AS_PATH: 2914 12178 14 198.107.213.80/29 129.250.126.97 3 1000 EF AS_PATH: 2914 6993 6993 6993 15 198.107.213.88/29 129.250.126.97 3 1000 EF AS_PATH: 2914 10911 10911 10911 16 198.107.213.96/29 129.250.126.97 3 1000 EF AS_PATH: 2914 10913 17 198.107.213.104/29 129.250.126.97 3 1000 EF AS_PATH: 2914 13791 13791 13791 13791 13791 13791 18 198.107.213.112/29 129.250.126.97 3 1000 EF AS_PATH: 2914 13792 13792 13792 13792 13792 13792 Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH S:SUPPRESSED F:FILTERED Prefix Next HopMetric LocPrf Weight Status 19 198.107.213.120/29 129.250.126.97 3 1000 EF AS_PATH: 2914 12181 20 198.107.213.144/29 129.250.126.97 3 1000 EF AS_PATH: 2914 14742 14742 14742 21 198.107.213.152/29 129.250.126.97 3 1000 EF AS_PATH: 2914 14636 14636 14636 14636 14636 14636 14636 22 198.107.213.160/29 129.250.126.97 3 1000 EF AS_PATH: 2914 14743 14743 14743 23 198.107.213.168/29 129.250.126.97 3 1000 EF AS_PATH: 2914 14745 24 198.107.213.176/29 129.250.126.97 3 1000 EF AS_PATH: 2914 19024 19024 19024 25 204.27.124.128/25 129.250.126.97 3 1000 EF AS_PATH: 2914 21637 26 204.171.181.32/29 129.250.126.97 3 1000 EF AS_PATH: 2914 16821 16821 16821 16821 27 207.20.149.96/27 129.250.126.97 3 1000 EF AS_PATH: 2914 11189 Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH S:SUPPRESSED F:FILTERED Prefix Next HopMetric LocPrf Weight Status 28 207.20.172.128/26 129.250.126.97 3 1000 EF AS_PATH: 2914 19359 29 207.174.18.128/27 129.250.126.97 3 1000 EF AS_PATH: 2914 13790 3404 19129 30 208.239.6.64/26129.250.126.97 3 1000 EF AS_PATH: 2914 11655 31 208.244.144.128/25 129.250.126.97 4 1000 EF AS_PATH: 2914 25626 32 209.69.100.224/28 129.250.126.97 3 1000 EF AS_PATH: 2914 18776 33 209.69.154.192/27 129.250.126.97 3 1000 EF AS_PATH: 2914 18776 34 210.7.223.0/25 129.250.126.97 3 1000 EF AS_PATH: 2914 9874 3549 4682 9335
/24s run amuck... again
With all the recent talk about filtering, I figured now was a good time to update my list of evil /24 announcers... There are currently over 63k /24s out of 113k total unfiltered announcements (over 55%). http://www.e-gerbil.net/ras/projects/ipaddr/amuck-071902.txt This scan is done from the point of view of Williams (AS7911) transit, a fairly "average" unfiltered view of around 113k routes. It's not perfect, but it's pretty easy to go down the list and verify which ones are really poluting the internet. The reason these don't get picked up on other peoples "cidr scans" is that they have "gaps", so they are not perfectly cidr-able. The reasons for these announcements vary, including obvious incompetence and cable/dsl companies without a "backbone" connecting their various POPs announcing a /24 for each location to a single transit provider. If I had more free time I would extend this analysis past /24s, but since they're such a huge amount of polution it's a good place to start. If someone wanted to do an analysis of routes from a common block with identical attributes, I suspect they would find it a bigger cause of net polution than multihomers punching holes. For quick complaining, the top 10 offenders are: ASNNameReg'd Netblock Prefixes ----- 6595 DoD Dependents Schools - Europe 204.218.0.0/15 236 22927 TELEFONICA DE ARGENTINA 168.226.0.0/16 167 7029 Alltel Information Services 166.102.0.0/16 128 7303 Telecom Argentina Stet-France 200.43.0.0/16127 14654 Wayport 64.134.0.0/16113 16473 Bell South 198.146.0.0/16 111 11492 Cable One 24.116.0.0/16108 18687 MPower Communications 208.57.0.0/1698 7132 Southwestern Bell 207.193.0.0/16 89 1580 Army HQ, 5th Signal Command 144.170.0.0/16 88 -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: verio arrogance
On Thu, Jul 18, 2002 at 11:54:30PM -0400, David Diaz wrote: > Is there any need to keep the routing table to a smaller size. Since > in theory, it creates suboptimal routing. And considering the new > routers out there today should be able to handle it. Considering > verio is using junipers, and they pride themselves on handling a > tremendously large table. Why should we shoot for a 100,000 route > table instead of 500,000 if it does not impact performance? When you are talking about BGP reconvergance when a router crashes (oh wait, they would never crash ;-) or is upgraded it takes a lot longer to advertize 500k routes than 100k routes. Even with a really-fast processor it obviously takes more time to do route lookup in doing best-path computations with 100+ ibgp peers. Then you start to talk about the memory footprint of 500k prefixes, once you start to include received-side communities as well as your new communities you've tagged on. With route-refresh it's not that bad, but with soft-reconfiguration enabled it may cause a bit more memory to be used. > I do understand that the 100,000 might be that actual 'installed best > routes' and that the routers might in fact be dealing with a much > larger route table. That might be an issue. But certainly 100,000- > 500,000 installed routes, is that a problem for large backbones with > high end routers? If you venture a guess and say that most "large" networks originate about 5% of the 100k prefixes must be advertized (see peering discussion about minimum routes to advertize awhile back) that numer of prefixes is increased to 25k prefixes. Then if you prefix-filter your customers, you're talking about 5X increased nvram/config requirements. > My only consideration might be the small multihomed ISPs with 2-3 > providers with full BGP feeds and cisco 4000s (256meg ram). I saw > one last week. I might be concerned at that level. "back in the day when full routes would fit in 64m ram". obviously the smaller providers have a bit more of a challenge as they tend to not have support contracts, and it can be a bit tougher to justify router memory. > I'd love to hear feedback. It would then justify filtering...or not. Think about the "7007" and other cases whereby someone announces a large set of routes they should not be. There have been numerous cases of this in the past and as a long as it's possible to easily leak routes incorrectly due to not filtering customers closely, etc.. it will continue to happen. - jared > > David > > > > > At 21:37 -0400 7/18/02, Phil Rosenthal wrote: > >How is it arrogant? > >I read that as: a customer set up an exploitable FormMail. Verio > >received notice about it. Verio removed the FormMail in question. Verio > >asked to be removed since they corrected the problem. Verio was ignored. > > > >Verio may have some problems with not terminating spammers, and I > >believe this to be the truth -- I buy from verio, and Don't spam, and > >whenever one of my clients spam, they get terminated for it. I receive > >plenty of spam from verio ips, and no matter how much I complain, it > >never gets terminated. This is probably a scenario of asking sales rep > >"If I want to spam, but I pay more per meg -- Is this OK?" and getting > >a positive answer. > > > >That is why the NANAE people don't like verio. But, nonetheless, I > >don't think that putting verio's mailserver on a formmail list is > >accomplishing anything good, since they fixed THAT problem... > > > >--Phil > > > >-Original Message- > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of > >Kai Schlichting > >Sent: Thursday, July 18, 2002 6:37 PM > >To: [EMAIL PROTECTED] > >Cc: Kai Schlichting > >Subject: Re: verio arrogance > > > > > > > >How's THIS for Verio arrogance, going to a whole new level: > > > >http://www.monkeys.com/anti-spam/filtering/verio-demand.ps > > > >Details were on the SPAM-L list Wed, 17 Jul 2002 15:51:05 EDT: Verio > >threatens to sue Ron Guilmette over the IP 208.55.91.59 appearing on his > >FormMail.pl open-proxy/formmail server DNSBL. > > > >And given the ever-increasing number of spammers now hopping onto Verio > >tells me that Verio must be well down the spiral of death (spammers seem > >to be attracted by NSP's going chapter 7/11, or who are getting close), > >or else the dozen-or-so automated messages going to [EMAIL PROTECTED] > >every week complaining about connections (real or attempted) to hosts > >under my control, and originating from their spamming customers would > >have shown any results over time. > > > >I don't need connectivity to 208.55.0.0/16. I really don't, and I have > >not the slightest tolerance for litigious, small-minded, > >panic-lawyer-dialling scum like this. > > > >/etc/mail$ grep 208.55 access.local > >208.55 550 Access for FormMail spam and litigious scum > >denied - Verio in their
RE: verio arrogance
Getting back to the more original thread. Is there any need to keep the routing table to a smaller size. Since in theory, it creates suboptimal routing. And considering the new routers out there today should be able to handle it. Considering verio is using junipers, and they pride themselves on handling a tremendously large table. Why should we shoot for a 100,000 route table instead of 500,000 if it does not impact performance? I do understand that the 100,000 might be that actual 'installed best routes' and that the routers might in fact be dealing with a much larger route table. That might be an issue. But certainly 100,000- 500,000 installed routes, is that a problem for large backbones with high end routers? My only consideration might be the small multihomed ISPs with 2-3 providers with full BGP feeds and cisco 4000s (256meg ram). I saw one last week. I might be concerned at that level. I'd love to hear feedback. It would then justify filtering...or not. David At 21:37 -0400 7/18/02, Phil Rosenthal wrote: >How is it arrogant? >I read that as: a customer set up an exploitable FormMail. Verio >received notice about it. Verio removed the FormMail in question. Verio >asked to be removed since they corrected the problem. Verio was ignored. > >Verio may have some problems with not terminating spammers, and I >believe this to be the truth -- I buy from verio, and Don't spam, and >whenever one of my clients spam, they get terminated for it. I receive >plenty of spam from verio ips, and no matter how much I complain, it >never gets terminated. This is probably a scenario of asking sales rep >"If I want to spam, but I pay more per meg -- Is this OK?" and getting >a positive answer. > >That is why the NANAE people don't like verio. But, nonetheless, I >don't think that putting verio's mailserver on a formmail list is >accomplishing anything good, since they fixed THAT problem... > >--Phil > >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of >Kai Schlichting >Sent: Thursday, July 18, 2002 6:37 PM >To: [EMAIL PROTECTED] >Cc: Kai Schlichting >Subject: Re: verio arrogance > > > >How's THIS for Verio arrogance, going to a whole new level: > >http://www.monkeys.com/anti-spam/filtering/verio-demand.ps > >Details were on the SPAM-L list Wed, 17 Jul 2002 15:51:05 EDT: Verio >threatens to sue Ron Guilmette over the IP 208.55.91.59 appearing on his >FormMail.pl open-proxy/formmail server DNSBL. > >And given the ever-increasing number of spammers now hopping onto Verio >tells me that Verio must be well down the spiral of death (spammers seem >to be attracted by NSP's going chapter 7/11, or who are getting close), >or else the dozen-or-so automated messages going to [EMAIL PROTECTED] >every week complaining about connections (real or attempted) to hosts >under my control, and originating from their spamming customers would >have shown any results over time. > >I don't need connectivity to 208.55.0.0/16. I really don't, and I have >not the slightest tolerance for litigious, small-minded, >panic-lawyer-dialling scum like this. > >/etc/mail$ grep 208.55 access.local >208.55 550 Access for FormMail spam and litigious scum >denied - Verio in their XXX - we block more than just >208.55.91.59 - Spammers must die - see >http://www.monkeys.com/anti-spam/filtering/verio-demand.ps >/etc/mail$ > >PS: I also have zero tolerance for Nadine-type spam-generating, >"single-opt-in", > "87% permission-based" emailers nowadays: 2 bounces or a single mail >to a >never-existing account, and all your /24's are off into gated.conf as >a >next-hop route to 127.0.0.1. And no, they won't get around that by >advertising >/25's. > >Good-bye route-prefix-filtering wars, and welcome to the war on spam, >where Null0'd /28's for filtering 'undesirables' just doesn't cut it any >more. Casualties like 10-15 bystanding rackspace.com customers with a >"Nadine- type" mailer in neighboring IP space be damned: "move your >servers into a different slum, cause da landlord's running down 'da >neighborhood". > >-- >"Just say No" to Spam Kai >Schlichting >New York, Palo Alto, You name it Sophisticated Technical >Peon >Kai's SpamShield is FREE! >http://www.SpamShield.org >| >| | >LeasedLines-FrameRelay-IPLs-ISDN-PPP-Cisco-Consulting-VoiceFax-Data-Muxe >s >WorldWideWebAnything-Intranets-NetAdmin-UnixAdmin-Security-ReallyHardMat >h -- David Diaz [EMAIL PROTECTED] [Email] [EMAIL PROTECTED] [Pager] Smotons (Smart Photons) trump dumb photons
Re: If you thought Y2K was bad, wait until cyber-security hits
It has taken me more than an hour to recover from reading that depressing Probe Research alert. OK I have a question. Can't the ISPs gather here regard this as an invitation to leave the PSTN? If this goes down as suggested it seems to me that if they don't leave the PSTN in SOME fashion they will be strangled by the big telco players in the Soviet style, homeland security, central planning bureaucracy. Will these regs apply to common carriers? But not to information service providers? Is the FCC direction on broadband therefore a good thing for ISPs? Should every ISP that wants to remain independent go wireless and look for a fiber connection to an inter exchange carrier network? As if these ISPs don't avoid the LECs already? What is the feasibility of separating an IP internet from the LEC networks? Is Cogent our friend? or anyone else who buys up IP assets at fire sale prices? Can the Bush Men really be against redundant networks? >Probe Research has a very lucid take on this very topic at > >http://www.proberesearch.com/alerts/networksecurity.htm > >Their point is that, given the current climate, the RBOCs are likely >to be setting the agenda for cyber security. To quote Probe's first >two conclusions: > >"First, the RBOCs will be the focus of developing a telecom national >security plan; > >Second, the RBOCs will use this position to force costs onto all >players. For example, co-location will be viewed as increasing the >risk to telecom, so carriers may be forced to abandon co-location in >favor of smaller nodes and these nodes will have to have remote >backup nodes." > >Cheers, > >Mathew > -- The COOK Report on Internet, 431 Greenway Ave, Ewing, NJ 08618 USA (609) 882-2572 (phone & fax) [EMAIL PROTECTED] Subscription info & prices at http://cookreport.com/subscriptions.shtmlSummary of content for 10 years at http://cookreport.com/past_issues.shtml Here Comes Asset Based Telecom A 120 page - Aug Sept issue available at http://cookreport.com/11.05-6.shtml
RE: verio arrogance
How is it arrogant? I read that as: a customer set up an exploitable FormMail. Verio received notice about it. Verio removed the FormMail in question. Verio asked to be removed since they corrected the problem. Verio was ignored. Verio may have some problems with not terminating spammers, and I believe this to be the truth -- I buy from verio, and Don't spam, and whenever one of my clients spam, they get terminated for it. I receive plenty of spam from verio ips, and no matter how much I complain, it never gets terminated. This is probably a scenario of asking sales rep "If I want to spam, but I pay more per meg -- Is this OK?" and getting a positive answer. That is why the NANAE people don't like verio. But, nonetheless, I don't think that putting verio's mailserver on a formmail list is accomplishing anything good, since they fixed THAT problem... --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Kai Schlichting Sent: Thursday, July 18, 2002 6:37 PM To: [EMAIL PROTECTED] Cc: Kai Schlichting Subject: Re: verio arrogance How's THIS for Verio arrogance, going to a whole new level: http://www.monkeys.com/anti-spam/filtering/verio-demand.ps Details were on the SPAM-L list Wed, 17 Jul 2002 15:51:05 EDT: Verio threatens to sue Ron Guilmette over the IP 208.55.91.59 appearing on his FormMail.pl open-proxy/formmail server DNSBL. And given the ever-increasing number of spammers now hopping onto Verio tells me that Verio must be well down the spiral of death (spammers seem to be attracted by NSP's going chapter 7/11, or who are getting close), or else the dozen-or-so automated messages going to [EMAIL PROTECTED] every week complaining about connections (real or attempted) to hosts under my control, and originating from their spamming customers would have shown any results over time. I don't need connectivity to 208.55.0.0/16. I really don't, and I have not the slightest tolerance for litigious, small-minded, panic-lawyer-dialling scum like this. /etc/mail$ grep 208.55 access.local 208.55 550 Access for FormMail spam and litigious scum denied - Verio in their XXX - we block more than just 208.55.91.59 - Spammers must die - see http://www.monkeys.com/anti-spam/filtering/verio-demand.ps /etc/mail$ PS: I also have zero tolerance for Nadine-type spam-generating, "single-opt-in", "87% permission-based" emailers nowadays: 2 bounces or a single mail to a never-existing account, and all your /24's are off into gated.conf as a next-hop route to 127.0.0.1. And no, they won't get around that by advertising /25's. Good-bye route-prefix-filtering wars, and welcome to the war on spam, where Null0'd /28's for filtering 'undesirables' just doesn't cut it any more. Casualties like 10-15 bystanding rackspace.com customers with a "Nadine- type" mailer in neighboring IP space be damned: "move your servers into a different slum, cause da landlord's running down 'da neighborhood". -- "Just say No" to Spam Kai Schlichting New York, Palo Alto, You name it Sophisticated Technical Peon Kai's SpamShield is FREE! http://www.SpamShield.org | | | LeasedLines-FrameRelay-IPLs-ISDN-PPP-Cisco-Consulting-VoiceFax-Data-Muxe s WorldWideWebAnything-Intranets-NetAdmin-UnixAdmin-Security-ReallyHardMat h
Re: If you thought Y2K was bad, wait until cyber-security hits
Probe Research has a very lucid take on this very topic at http://www.proberesearch.com/alerts/networksecurity.htm Their point is that, given the current climate, the RBOCs are likely to be setting the agenda for cyber security. To quote Probe's first two conclusions: "First, the RBOCs will be the focus of developing a telecom national security plan; Second, the RBOCs will use this position to force costs onto all players. For example, co-location will be viewed as increasing the risk to telecom, so carriers may be forced to abandon co-location in favor of smaller nodes and these nodes will have to have remote backup nodes." Cheers, Mathew At 08:22 PM 7/18/2002 -0400, Sean Donelan wrote: >http://www.eweek.com/article2/0,3959,387377,00.asp > >"All the while maintaining that the government will not set IT security >requirements for the private sector, top federal IT officials today said >they expect such mandates will be imposed on federal agencies and that the >same standards will also be used by industry." > >While standards are great, one-size-fits-all standards aren't. When the >government's cyber-security plan is released in September, will >there be 500 requirements that Internet Service Providers must meet? >Should ISPs be more secure than the post office or the telephone or the >bike messenger? Must Bill's Bait & Sushi Shop ISP Service meet the same >security requirements as the ISP for the White House? > >ISPs come in all sorts of shapes and sizes. Consumers use cordless >phones at home, but the NSA prohibits use of cordless phones in secure >areas. Just because the government issues a security standard doesn't make >it suitable for all purposes. Some people like paying $9.95 for Internet >service from an ISP without a backup generator, and wouldn't want to pay >$29.95 for a "certified" ISP with a backup generator. If the $9.95 ISP >fails, heck they could almost afford two more for the same price as a >single "certified" ISP. Sometimes a hammer is just a hammer, and you >don't need a MIL-SPEC. If the Department of Homeland Security creates a >new security standard for ISPs, what do you think will happen to any ISP >which doesn't meet it? > >The security "Gold Standard" for Microsoft 2000 was written by the >Critical Infrastructure Protection Board, the Center for Internet >Security, the National Security Agency, the General Services >Administration, the National Institute of Standards and Technology, and >the SANS Institute. > >Do you know who is writing the security "Gold Standard" for Internet >Service Providers?
Be glad you're not in the U.K.
And coming soon to the US! >BBC News Online: Sci/Tech >Wednesday, 17 July, 2002, 09:15 GMT 10:15 UK >Switch on for state snooping > >Police forces want to plug in to lots of networks > > >From August net service providers in the UK will be obliged to carry out >surveillance of some customers' web habits on behalf of the police. >Controversial laws passed in 2000 oblige large communications companies >to install technology that allows one in 10,000 of their customers to be >watched. > >The information gathered about what people look at on the web, the >content of e-mail messages and their phone conversations will be passed >to the police or a government monitoring station. > >The demands have been criticised by experts who say the law conflicts >with basic guarantees of privacy and that the government is not doing >enough to help pay for the installation of the surveillance systems. > >Data hoover > >The controversial Regulation of Investigatory Powers Act was passed in >October 2000 and gave law enforcement agencies sweeping powers to snoop >on the electronic lives of citizens. > >" It's the internet equivalent of a telephone tap " >Roland Perry, Linx > >The Act demands that organisations it dubs Communication Service >Providers (CSP) - broadly anyone that helps people keep in touch via the >web, fax machine or phone - install technology that can automatically >monitor what many of their customers are doing. > >It also demands that service providers start monitoring a customer >within 24 hours of being told that the police or other investigation >agencies want to snoop on them. > >The information collected must also be passed on electronically to the >agency which asked for the snooping to start. > >A spokesman for the Home Office said 1 August was the day on which the >new surveillance regime would start, even though the technology to do >the watching are yet to be installed. > >He said only law enforcement agencies would have the power to ask for >the surveillance to start. > >Police would have to get a warrant from the Home Office before they >could ask for surveillance to start, he said, and it would only be used >to gather evidence about serious crimes. > >Data delivery > >Roland Perry, public policy director for the London Internet Exchange >which interconnects the networks of net service companies, said the >government was still working out how best to put the surveillance >systems in place. > >"It's a very long-term project," he said. "The whole thing will be done >on a one-to-one basis with the individual companies concerned." > >" Agencies have to make a judgement whether it's worth making a request >if it costs a few hundred pounds to do it " > >Ian Brown, Foundation for Information Policy Research > >The government is also currently working out what types of information >it wants from CSPs and how it will be delivered. > >"In theory, an interception capability would deliver all the data," said >Mr Perry. "It's the internet equivalent of a telephone tap." > >The government is hoping that its work on automatic surveillance will >become a European standard and be widely adopted. > >Costly communication > >Service providers have asked for help to buy the equipment needed to set >up the permanent interception capability. > >"The Home Office has said it would contribute £20m to this but the net >industry has said it will cost a lot more than that," said Ian Brown, >director of the Foundation for Information Policy Research. > >The Internet Service Providers Association has warned about the >potentially huge costs of installing surveillance equipment to meet the >demands of the RIP Act and the recently passed Anti-Terrorism, Crime and >Security Act. > >A spokesman for the organisation said it was still seeking clarification >over the types of data its members were supposed to be catching, how >long it had to be stored for and who would pay for the storage. > >Mr Brown said one of the few safeguards on the snooping system was the >fact that the agencies asking for the surveillance to be carried out >will be charged to use it. > >"This means agencies have to make a >judgement whether it's worth making a request if it costs a few hundred >pounds to do it," said Mr Brown. > > > Yahoo! Groups Sponsor -~--> >Will You Find True Love? >Will You Meet the One? >Free Love Reading by phone! >http://us.click.yahoo.com/O3jeVD/R_ZEAA/Ey.GAA/qkHolB/TM >-~-> > > > > > >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
If you thought Y2K was bad, wait until cyber-security hits
http://www.eweek.com/article2/0,3959,387377,00.asp "All the while maintaining that the government will not set IT security requirements for the private sector, top federal IT officials today said they expect such mandates will be imposed on federal agencies and that the same standards will also be used by industry." While standards are great, one-size-fits-all standards aren't. When the government's cyber-security plan is released in September, will there be 500 requirements that Internet Service Providers must meet? Should ISPs be more secure than the post office or the telephone or the bike messenger? Must Bill's Bait & Sushi Shop ISP Service meet the same security requirements as the ISP for the White House? ISPs come in all sorts of shapes and sizes. Consumers use cordless phones at home, but the NSA prohibits use of cordless phones in secure areas. Just because the government issues a security standard doesn't make it suitable for all purposes. Some people like paying $9.95 for Internet service from an ISP without a backup generator, and wouldn't want to pay $29.95 for a "certified" ISP with a backup generator. If the $9.95 ISP fails, heck they could almost afford two more for the same price as a single "certified" ISP. Sometimes a hammer is just a hammer, and you don't need a MIL-SPEC. If the Department of Homeland Security creates a new security standard for ISPs, what do you think will happen to any ISP which doesn't meet it? The security "Gold Standard" for Microsoft 2000 was written by the Critical Infrastructure Protection Board, the Center for Internet Security, the National Security Agency, the General Services Administration, the National Institute of Standards and Technology, and the SANS Institute. Do you know who is writing the security "Gold Standard" for Internet Service Providers?
Re: verio arrogance
How's THIS for Verio arrogance, going to a whole new level: http://www.monkeys.com/anti-spam/filtering/verio-demand.ps Details were on the SPAM-L list Wed, 17 Jul 2002 15:51:05 EDT: Verio threatens to sue Ron Guilmette over the IP 208.55.91.59 appearing on his FormMail.pl open-proxy/formmail server DNSBL. And given the ever-increasing number of spammers now hopping onto Verio tells me that Verio must be well down the spiral of death (spammers seem to be attracted by NSP's going chapter 7/11, or who are getting close), or else the dozen-or-so automated messages going to [EMAIL PROTECTED] every week complaining about connections (real or attempted) to hosts under my control, and originating from their spamming customers would have shown any results over time. I don't need connectivity to 208.55.0.0/16. I really don't, and I have not the slightest tolerance for litigious, small-minded, panic-lawyer-dialling scum like this. /etc/mail$ grep 208.55 access.local 208.55 550 Access for FormMail spam and litigious scum denied - Verio in their XXX - we block more than just 208.55.91.59 - Spammers must die - see http://www.monkeys.com/anti-spam/filtering/verio-demand.ps /etc/mail$ PS: I also have zero tolerance for Nadine-type spam-generating, "single-opt-in", "87% permission-based" emailers nowadays: 2 bounces or a single mail to a never-existing account, and all your /24's are off into gated.conf as a next-hop route to 127.0.0.1. And no, they won't get around that by advertising /25's. Good-bye route-prefix-filtering wars, and welcome to the war on spam, where Null0'd /28's for filtering 'undesirables' just doesn't cut it any more. Casualties like 10-15 bystanding rackspace.com customers with a "Nadine- type" mailer in neighboring IP space be damned: "move your servers into a different slum, cause da landlord's running down 'da neighborhood". -- "Just say No" to Spam Kai Schlichting New York, Palo Alto, You name it Sophisticated Technical Peon Kai's SpamShield is FREE! http://www.SpamShield.org | | LeasedLines-FrameRelay-IPLs-ISDN-PPP-Cisco-Consulting-VoiceFax-Data-Muxes WorldWideWebAnything-Intranets-NetAdmin-UnixAdmin-Security-ReallyHardMath
Re: verio arrogance
Daniel Golding wrote: > > RADB is largely meaningless, in terms of authorization or authority to > advertise. However, if you have a properly delegated SWIP entry for the > block, few providers will request LOA. Those who do, should probably be > avoided. Largely? I like to see the SWIP, but it's not always provided. Regardless, I want to see an announcement originating from my customer directly to the owner of the block. De facto authorization. [...] Peter E. Fry
Re: What is a reasonable range for global BGP table size?
On Thursday, July 18, 2002, at 05:25 , Marshall Eubanks wrote: > I still don't see where the excess 20K routes come from. Could these be > internal routes from an iBGP ? The export policy of contributors to route-views collectors is not well-defined. While some participants might be sending a customer or peer view, others are quite likely including all kinds of deaggregated bloat which only has intra-AS application, and that would never normally be seen by a peer AS. Joe
RE: verio arrogance
RADB is largely meaningless, in terms of authorization or authority to advertise. However, if you have a properly delegated SWIP entry for the block, few providers will request LOA. Those who do, should probably be avoided. I still like the idea of using the DNS system for this, since there are already authoritative reverse delegations. (i.e. AS to IP block mapping) - Daniel Golding > > On Thu, 18 Jul 2002, Ralph Doncaster wrote: > > > > > And your suggestion has technical deficiencies as well. I > have a leased > > > line between Toronto and Ottawa, so I want to announce my > Ottawa IPs to my > > > Toronto transit provider as well as an Ottawa transit > provider. And the > > > reverse for the Toronto IPs. My understand is trying to > punch holes in PA > > > space is much more difficult than de-aggregating ARIN PI space. > > > > I can't really see why, as long as the provider has punched the > > appropriate hole for your aggregate in their filters. More specific > > routes always win out. Or am I missing your point? > > If the block isn't assigned to you by ARIN, I've encountered cases where > network operators request an LOA before accepting the announcement, even > if there is an RADB entry for it. As well, if you have PA space and your > upstream allocates you a 66.x for example, then you're back to square one. > > -Ralph > >
Re: What is a reasonable range for global BGP table size?
I still don't see where the excess 20K routes come from. Could these be internal routes from an iBGP ? BTW, we have similar histograms plotted on http://www.multicasttech.com/status/cidr.html and given in http://www.multicasttech.com/status/histogram.cidr.bgp # cidr_histogram Unicast Prefix Size Histogram # cidr_histogram Prefix Size | Number of Prefixes | Number of CIDR Holes | Number of Addresses | followed by relative PER CENTAGE in order # cidr_histogram size # prfx # holes # addr % prfx % holes % addr # cidr_histogram cidr_histogram 1 0 0 00.0 0.00.0 cidr_histogram 2 0 0 00.0 0.00.0 cidr_histogram 3 0 0 00.0 0.00.0 cidr_histogram 4 0 0 00.0 0.00.0 cidr_histogram 5 0 0 00.0 0.00.0 cidr_histogram 6 0 0 00.0 0.00.0 cidr_histogram 7 0 0 00.0 0.00.0 cidr_histogram 8 20 3 3355442800.0 0.0 28.0 cidr_histogram 9 6 1 503316360.0 0.04.2 cidr_histogram 10 7 2 293601140.0 0.02.5 cidr_histogram 11 12 1 251658000.0 0.02.1 cidr_histogram 12 36 12 377486640.0 0.03.2 cidr_histogram 13 87 28 456128820.1 0.03.8 cidr_histogram 14 235 59 616033700.2 0.15.1 cidr_histogram 15 415 102 543940500.4 0.24.5 cidr_histogram 167270 851 4764321806.4 1.4 39.8 cidr_histogram 171452 475 475762321.3 0.84.0 cidr_histogram 182647 846 433631542.3 1.43.6 cidr_histogram 1976722205 628336806.8 3.75.2 cidr_histogram 2074292680 304143266.6 4.52.5 cidr_histogram 2152123146 106637524.6 5.30.9 cidr_histogram 227929533081034387.0 9.00.7 cidr_histogram 239682661949378208.611.20.4 cidr_histogram 24 62823 36537 15957042 55.561.81.3 cidr_histogram 25 54 51 68040.0 0.10.0 cidr_histogram 26 25 23 15500.0 0.00.0 cidr_histogram 27 31 319300.0 0.10.0 cidr_histogram 28 30 284200.0 0.00.0 cidr_histogram 29 16 16 960.0 0.00.0 cidr_histogram 30 79 761580.1 0.10.0 cidr_histogram 32 31 29 310.0 0.00.0 Note that you (or route views) sees 10K more /24 than we do, 3K more /23's, etc. Regards Marshall Jared Mauch wrote: > On Thu, Jul 18, 2002 at 11:11:18AM -0600, Kris Foster wrote: > >>That number is still too high since some people are advertising their /25 to >>/32 prefixes to the route-views box.. >> > > true, but unless you do ingress filtering of your upstream > (which most smaller ASes do not do) your numbers may be > wrong. People also leak internal routes to route-views at > times also i've noticed. > > (still talking about the same route-views snapshot) > > count netmask > % cut -d: -f2 oix.home_as.out | cut -d/ -f2 | sort -n | uniq -c > 25 8 >6 9 >7 10 > 12 11 > 36 12 > 99 13 > 269 14 > 514 15 > 9764 16 > 1537 17 > 2778 18 > 8378 19 > 8131 20 > 6075 21 > 9949 22 > 12258 23 > 73921 24 > 468 25 > 419 26 > 354 27 > 378 28 > 241 29 > 225 30 > 105 32 > > - jared > > >>Kris >> >> >> >>>-Original Message- >>>From: Jared Mauch [mailto:[EMAIL PROTECTED]] >>>Sent: Thursday, July 18, 2002 12:47 PM >>>To: Robert Boyle >>>Cc: [EMAIL PROTECTED] >>>Subject: Re: What is a reasonable range for global BGP table size? >>> >>> >>> >>> I was going off my data analysis of >>>route-views data. >>> >>>wc -l oix.home_as.out >>> 135949 oix.home_as.out >>> >>> this file has prefix:home_asn >>> >>> (where home_asn is the last asn in the as_path. prefixes >>>with inconsistent home_as will appear twice. this may be >>>cause of some >>>of your confusion. eliminating those brings it to 120131 prefixes) >>> >>> - jared >>> >>>On Thu, Jul 18, 2002 at 12:37:09PM -0400, Robert Boyle wrote: >>> At 11:26 AM 7/18/2002 -0400, you wrote: >Hmm. > >We don't filter, and > >112942 network entries and 391859 paths using 25288182 > >>>bytes of memory >>> We don't filter either and... 117800 network entries and 339843 paths using 23660948 >>>bytes of memory >>> "about 135k prefixes last i checked." is not what we see >>>here from any of >>> our upstreams. -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Good will, li
RE: QoS/CoS in the real world?
On Thu, 18 Jul 2002, John Evans wrote: > > I realise this is a US-centric list, however, a significant number of > providers in Europe have deployed Diffserv as a means of supporting (and > selling) differential SLAs. Of these, some have deployed Diffsev at the > edge and some both the edge and core. See Clarence Filsfils presentation at > NANOG 25 for a description of typical core deployments. > > > 2. Hype aside, to what extent do customers actually want this > > Surely end customers want a service with SLAs that will support their > applications, and at low cost? It then becomes a provider cost > consideration as to whether these SLA assurances can most competitively > satisfied with mechanisms such as Diffserv or without. I have to say that the majority of users barely understand how their outlook client works let alone the difference between applications. I'm starting to think theres no demand for these services other than that which the hype says is there. THis is in line with what people said about using qos behind the scenes but customers dont know.. kind of what I thought to begin with STeve > > I conclude either the people doing this are successful and keep > > their secret > > safe or the world is yet to sell largescale QoS across IP. > > or perhaps they are just not on this list. > > cheers > > John > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > > Stephen J. Wilcox > > Sent: 14 July 2002 00:47 > > To: [EMAIL PROTECTED] > > Subject: Re: QoS/CoS in the real world? > > > > > > > > Well, end of the week and the responses dried up pretty quickly, > > I think thats a > > response in itself to my question! > > > > Okay, heres a summary which was requested by a few people: > > > > Other people too are interested in my questions, they dont > > implement QoS in any > > saleable manner and wonder how it can be done and whats actually > > required. > > > > A number of people think QoS was interesting for a while but that > > its never > > either found its true use or is dead. > > > > There are unresolved questions from a customer point of view as > > to what they are > > actually going to get, what difference it will make and how they > > can measure > > their performance and the improvements from QoS. > > > > There is a real demand for guaranteed bandwidth, however this > > tends to be in the > > form of absolute guarantees rather than improvements above "normal" hence > > ATM remaining a popular solution. > > > > There is a requirement to differentiate voice traffic, however this is > > necessarily done by the network anyway in order to offer the > > service, this being > > the case the customer doesnt pay extra or gets to know much about > > how all the > > fancy bits are done. > > > > > > On the face of it this is all negative. Nobody has responded > > saying there are > > genuine requirements for services to be offered to customers. Nor > > has anybody > > responded with any descriptions of implementations. > > > > I conclude either the people doing this are successful and keep > > their secret > > safe or the world is yet to sell largescale QoS across IP. > > > > Steve > > > > > > On Mon, 8 Jul 2002, Stephen J. Wilcox wrote: > > > > > > > > Hi all, > > > I've been looking through the various qos/cos options > > available, my particular > > > area was in how IP (MPLS perhaps) compares and can be a > > substitute for ATM. > > > > > > Well, theres lots of talk and hype out there, from simple IP > > queuing eg cisco > > > priority queuing, rsvp, diffserv, mpls traffic engineering etc > > > > > > But two things are bugging me.. > > > > > > 1. To what extent have providers implemented QoS for their customers > > > > > > 2. Hype aside, to what extent do customers actually want this > > (and by this I > > > dont just mean that they want the latest QoS because its the > > 'latest thing', > > > there has to be a genuine reason for them to want it). And this > > takes me back to > > > my ATM reference where there is a clear major market still out > > there of ATM > > > users and what would it take to migrate them to an IP solution? > > > > > > Also, how are people implementing bandwidth on demand (dynamic > > allocation > > > controlled by the customer) solutions to customers > > > > > > Cheers > > > > > > Steve > > > > > > > > > > > > > > > > > >
Re: verio arrogance
> I can't really see why, as long as the provider has punched the > appropriate hole for your aggregate in their filters. More specific > routes always win out. Or am I missing your point? The point, I think, is the effort involved in using global route announcements to solve your traffic engineering problems. When you use provider-assigned space, you have to coordinate your intent to add entries to the global routing table with the provider who assigned the space and the providers that you want to accept the new routes. When you use provider-independent space, you get to decide to add entries to the global routing table pretty much all by yourself, modulo running afoul of the occasional provider that does not, by default, buy into solving local traffic engineering problems in other people's networks using global routing table entries. Stephen
Re: Multi-collector Netflow/etc
On Wed, 2002-07-17 at 14:07, Pete Kruckenberg wrote: > Any other methods that are working for scaling multiple > collectors without exceeding router limitations or burdening > routers unnecessarily? flow-tools has flow-fanout which does what you are describing for netflow. (replicates arriving flows to many destinations) man flow-fanout http://www.splintered.net/sw/flow-tools/docs/flow-fanout.html flow-tools http://www.splintered.net/sw/flow-tools/ flow-tools seems to be a good bet for handling/munging flow data in general. -joel
Re: What is a reasonable range for global BGP table size?
On Thu, Jul 18, 2002 at 11:11:18AM -0600, Kris Foster wrote: > > That number is still too high since some people are advertising their /25 to > /32 prefixes to the route-views box.. true, but unless you do ingress filtering of your upstream (which most smaller ASes do not do) your numbers may be wrong. People also leak internal routes to route-views at times also i've noticed. (still talking about the same route-views snapshot) count netmask % cut -d: -f2 oix.home_as.out | cut -d/ -f2 | sort -n | uniq -c 25 8 6 9 7 10 12 11 36 12 99 13 269 14 514 15 9764 16 1537 17 2778 18 8378 19 8131 20 6075 21 9949 22 12258 23 73921 24 468 25 419 26 354 27 378 28 241 29 225 30 105 32 - jared > > Kris > > > > -Original Message- > > From: Jared Mauch [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, July 18, 2002 12:47 PM > > To: Robert Boyle > > Cc: [EMAIL PROTECTED] > > Subject: Re: What is a reasonable range for global BGP table size? > > > > > > > > I was going off my data analysis of > > route-views data. > > > > wc -l oix.home_as.out > > 135949 oix.home_as.out > > > > this file has prefix:home_asn > > > > (where home_asn is the last asn in the as_path. prefixes > > with inconsistent home_as will appear twice. this may be > > cause of some > > of your confusion. eliminating those brings it to 120131 prefixes) > > > > - jared > > > > On Thu, Jul 18, 2002 at 12:37:09PM -0400, Robert Boyle wrote: > > > > > > At 11:26 AM 7/18/2002 -0400, you wrote: > > > >Hmm. > > > > > > > >We don't filter, and > > > > > > > >112942 network entries and 391859 paths using 25288182 > > bytes of memory > > > > > > We don't filter either and... > > > > > > 117800 network entries and 339843 paths using 23660948 > > bytes of memory > > > > > > > > > "about 135k prefixes last i checked." is not what we see > > here from any of > > > our upstreams. > > > > > > > > > -Robert > > > > > > > > > > > > > > > Tellurian Networks - The Ultimate Internet Connection > > > http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 > > > "Good will, like a good name, is got by many actions, and > > lost by one." - > > > Francis Jeffrey > > > > -- > > Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] > > clue++; | http://puck.nether.net/~jared/ My statements > > are only mine. > > -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: verio arrogance
> On Thu, 18 Jul 2002, Ralph Doncaster wrote: > > > And your suggestion has technical deficiencies as well. I have a leased > > line between Toronto and Ottawa, so I want to announce my Ottawa IPs to my > > Toronto transit provider as well as an Ottawa transit provider. And the > > reverse for the Toronto IPs. My understand is trying to punch holes in PA > > space is much more difficult than de-aggregating ARIN PI space. > > I can't really see why, as long as the provider has punched the > appropriate hole for your aggregate in their filters. More specific > routes always win out. Or am I missing your point? If the block isn't assigned to you by ARIN, I've encountered cases where network operators request an LOA before accepting the announcement, even if there is an RADB entry for it. As well, if you have PA space and your upstream allocates you a 66.x for example, then you're back to square one. -Ralph
Re: verio arrogance
On Thu, 18 Jul 2002, Ralph Doncaster wrote: > And your suggestion has technical deficiencies as well. I have a leased > line between Toronto and Ottawa, so I want to announce my Ottawa IPs to my > Toronto transit provider as well as an Ottawa transit provider. And the > reverse for the Toronto IPs. My understand is trying to punch holes in PA > space is much more difficult than de-aggregating ARIN PI space. I can't really see why, as long as the provider has punched the appropriate hole for your aggregate in their filters. More specific routes always win out. Or am I missing your point? James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am =
Re: Fiber cut NE USA
On Thu, 18 Jul 2002, Martin Hepworth wrote: > Looks theres a fiber cut in NE USA. It's definitly affecting what's left > of PSI-net's network trans USA. Most other providers' networks appear unaffected. Other than the Internet Traffic Report (which is flaky even on good days) there doesn't seem to be much out of the ordinary on the net today.
Re: Multi second RTT's from Level3 to Shockwave
On Thu, Jul 18, 2002 at 02:54:13PM -0400, Marshall Eubanks wrote: > > I got a complaint about this : > > > weird - I can't pull up Atom Films or Shockwave from any of my computers.. > > > > Homne or office. > > > > Now, let's see - intervideomag.com is > 209.246.228.72, which is assigned to redwire.net, which is part > of Level 3. > > Atom Films.com is 63.251.52.76, which is > assigned to AS 16974, Shockwave.com, which seems to > get access from Internap. > [abysmal RTT from l3 to shockwave] > > What can give such huge RTT's ? > Shockwave get access from l3 (and possibly from uunet, as well, though I think that link was scheduled to be dropped at some point) in addition to internap. I've forwarded this to my still-employed former cow-orkers, who have been fighting this nastiness for nearly a week. -Pete
Re: verio arrogance
> (Apologies if this is flogging a dead horse, but some messages are worth > repeating, if for no other reason than to illustrate the down side of > not understanding the proper rationale for CIDR.) I thought the dead horse was the conclusion that small ISPs should use whatever means the ARIN rules allow in order to get PI space. Having used provider-assigned space for a couple years, I can firmly say it sucks. Even if I had to talk to every tier-1 to get my de-aggregates accepted, it would be MUCH less hastle than having PA IP space. And your suggestion has technical deficiencies as well. I have a leased line between Toronto and Ottawa, so I want to announce my Ottawa IPs to my Toronto transit provider as well as an Ottawa transit provider. And the reverse for the Toronto IPs. My understand is trying to punch holes in PA space is much more difficult than de-aggregating ARIN PI space. -Ralph
Re: looking glass
We have heavily modified a version of the MRLG ( ftp://ftp.enterzone.net/looking-glass/ ) to provide controlled router access to a specific (mostly internal) audience. We have found that allowing people who normally have no router access, to have read-only access to some normally enable-only commands through a Web interface has been invaluable in delegating diagnostics and "peer review". The major benefit of a Web-based interface is that we can control the commands, input parameters, output display, and usability much better than with a command line interface. For example, we allow "show config", but we cover up any security-sensitive information (passwords, SNMP strings, TACACS keys, server IP addresses, etc) in the command output. The control is very flexible, allowing certain users to see only certain things, or be able to execute commands that other users can't, for example. We can embed HTML links in the output to related resources (Web-based help, graphs, related commands, etc). Everything is encrypted via SSH/SSL, and can be tracked for audit and security purposes. To see something similar to what we have done (and where we got the idea from), see the Internet2 Abilene Core Node Router Proxy at http://loadrunner.uits.iu.edu/%7Erouterproxy/abilene/ Source code for the I2 Proxy is available from http://tseg.uits.indiana.edu/dist Pete. On Thu, 18 Jul 2002, Scott Granados wrote: > Date: Thu, 18 Jul 2002 12:00:38 -0700 (PDT) > From: Scott Granados <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: looking glass > > > What are people using for looking glass software. Is it just some simple > perl code which grabs data from the router or is it more complex than > that? > > Thanks > > Scott > >
Re: looking glass
Yet another one.. this one has support for multiple routers ... free under GNU general public license Sush ftp://ftp.enterzone.net/looking-glass/CURRENT/ - Original Message - From: "Scott Granados" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, July 18, 2002 3:00 PM Subject: looking glass > > What are people using for looking glass software. Is it just some simple > perl code which grabs data from the router or is it more complex than > that? > > Thanks > > Scott > >
Re: looking glass
On Thu, 2002-07-18 at 14:00, Scott Granados wrote: > > What are people using for looking glass software. Is it just some simple > perl code which grabs data from the router or is it more complex than > that? The RANCID package includes a decedent of the Digex looking glass code. http://www.shrubbery.net/rancid/ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: looking glass
On Thu, Jul 18, 2002 at 12:00:38PM -0700, Scott Granados mooed: > > What are people using for looking glass software. Is it just some simple > perl code which grabs data from the router or is it more complex than > that? It's just perl. I have a copy of it at http://www.angio.net/rep/lg.tar.gz if you want it. -Dave -- work: [EMAIL PROTECTED] me: [EMAIL PROTECTED] MIT Laboratory for Computer Science http://www.angio.net/
Re: verio arrogance
>> I have one downstream ISP customer that explicitly asked for "full BGP >> routes" to be written into the contract. Why Verio's customer's wouldn't >> want full routes makes no business sense to me. The reasons are related to the law of diminishing returns. -mark
looking glass
What are people using for looking glass software. Is it just some simple perl code which grabs data from the router or is it more complex than that? Thanks Scott
Multi second RTT's from Level3 to Shockwave
I got a complaint about this : > weird - I can't pull up Atom Films or Shockwave from any of my computers.. > > Homne or office. > Now, let's see - intervideomag.com is 209.246.228.72, which is assigned to redwire.net, which is part of Level 3. Atom Films.com is 63.251.52.76, which is assigned to AS 16974, Shockwave.com, which seems to get access from Internap. From here (MCT 16517) [tme@hendrix audience_data]$ ping www.atomfilms.com PING static.shockwave.com (63.251.52.76) from 63.105.122.14 : 56(84) bytes of data. 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=0 ttl=52 time=79.649 msec 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=1 ttl=52 time=58.033 msec 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=2 ttl=52 time=57.193 msec 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=3 ttl=52 time=60.717 msec --- static.shockwave.com ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/mdev = 57.193/63.898/79.649/9.186 ms >From a level3 looking glass, http://www.level3.com/LookingGlass/ , (San Diego) Ping from Level 3 (San Diego) to 63.251.52.76 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=0. time=13. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=1. time=10002. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=2. time=9002. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=3. time=8002. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=4. time=7002. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=5. time=6002. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=6. time=5002. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=7. time=4003. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=8. time=3003. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=9. time=2003. ms 63.251.52.76 PING Statistics 10 packets transmitted, 10 packets received, 0% packet loss round-trip (ms) min/avg/max = 13/5403/10002 Check out those multisecond round trip times! Also from San Francisco Ping from Level 3 (San Francisco) to 63.251.52.76 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=0. time=1. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=1. time=10148. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=2. time=9148. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=3. time=8148. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=4. time=7148. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=5. time=6148. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=6. time=5148. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=7. time=4148. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=8. time=3148. ms 64 bytes from static.shockwave.com (63.251.52.76): icmp_seq=9. time=2148. ms 63.251.52.76 PING Statistics 10 packets transmitted, 10 packets received, 0% packet loss round-trip (ms) min/avg/max = 1/5533/10148 What can give such huge RTT's ? Regards Marshall Eubanks
Re: verio arrogance
> That said, their current policy of refusing to accept de-aggregated > prefixes from peers (while accepting such from paying customers) makes > perfect sense, IMHO. Not arrogant, just a smart & reasonable business > decision. I have one downstream ISP customer that explicitly asked for "full BGP routes" to be written into the contract. Why Verio's customer's wouldn't want full routes makes no business sense to me. However a NANOG list subscriber was kind enough to help me get past Verio's NOC monkeys and get their filters updated to allow my announcements. -Ralph
RE: verio arrogance
Ralph, Welcome to the Internet. This has been the case for years, now. If you don't like it, you have a couple options. 1) You can go on hunger strike and chain yourself to the front door at NTT, demanding a change to the policy. 2) You can lobby Verio's peers to drop peering with them, unless they change their ways. 3) You can pay Verio to accept your routes. 4) You can live with it. May I suggest #4? I'm not a big fan of Verio's filtering policies, but as long as you announce the /20 as an aggregate, you'll be fine. - Daniel Golding > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Ralph Doncaster > Sent: Monday, July 15, 2002 6:37 PM > To: [EMAIL PROTECTED] > Subject: Re: verio arrogance > > > > On Mon, 15 Jul 2002, Richard A Steenbergen wrote: > > > On Mon, Jul 15, 2002 at 05:10:28PM -0400, Ralph Doncaster wrote: > > > Announcing a covering /20 along with the regional more > specifics I have > > > will only serve to increase the size of the routing table for most > > > backbones, and lead to sub optimal routing in some cases since I'm > > > announcing the more specifics due to geographical diversity. > > > > Announce the /20 to your transit providers, and the more specifics with > > no-export. Verio's position is that they don't want to or need to hear > > your /23s unless you are a customer, and for the most part they > are right. > > But I've broken my /20 into a /21 for Ottawa, a /22 for Toronto, a /23 for > Montreal, and a /23 for expansion. I'm currently only getting transit in > Toronto, but will have a second transit provider restored in Ottawa (I was > using GT for a short while). While announcing the the /20 will my network > is reachable for single-homed Verio customers, it won't provide the true > best path that simply accepting the regional more specifics. > > -Ralph >
RE: What is a reasonable range for global BGP table size?
That number is still too high since some people are advertising their /25 to /32 prefixes to the route-views box.. Kris > -Original Message- > From: Jared Mauch [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 18, 2002 12:47 PM > To: Robert Boyle > Cc: [EMAIL PROTECTED] > Subject: Re: What is a reasonable range for global BGP table size? > > > > I was going off my data analysis of > route-views data. > > wc -l oix.home_as.out > 135949 oix.home_as.out > > this file has prefix:home_asn > > (where home_asn is the last asn in the as_path. prefixes > with inconsistent home_as will appear twice. this may be > cause of some > of your confusion. eliminating those brings it to 120131 prefixes) > > - jared > > On Thu, Jul 18, 2002 at 12:37:09PM -0400, Robert Boyle wrote: > > > > At 11:26 AM 7/18/2002 -0400, you wrote: > > >Hmm. > > > > > >We don't filter, and > > > > > >112942 network entries and 391859 paths using 25288182 > bytes of memory > > > > We don't filter either and... > > > > 117800 network entries and 339843 paths using 23660948 > bytes of memory > > > > > > "about 135k prefixes last i checked." is not what we see > here from any of > > our upstreams. > > > > > > -Robert > > > > > > > > > > Tellurian Networks - The Ultimate Internet Connection > > http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 > > "Good will, like a good name, is got by many actions, and > lost by one." - > > Francis Jeffrey > > -- > Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] > clue++; | http://puck.nether.net/~jared/ My statements > are only mine. >
Fiber cut NE USA
Hi Looks theres a fiber cut in NE USA. It's definitly affecting what's left of PSI-net's network trans USA. Anyone got any details? -- Martin Hepworth Senior Systems Administrator Solid State Logic Ltd +44 (0)1865 842300 ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **
Re: What is a reasonable range for global BGP table size?
I was going off my data analysis of route-views data. wc -l oix.home_as.out 135949 oix.home_as.out this file has prefix:home_asn (where home_asn is the last asn in the as_path. prefixes with inconsistent home_as will appear twice. this may be cause of some of your confusion. eliminating those brings it to 120131 prefixes) - jared On Thu, Jul 18, 2002 at 12:37:09PM -0400, Robert Boyle wrote: > > At 11:26 AM 7/18/2002 -0400, you wrote: > >Hmm. > > > >We don't filter, and > > > >112942 network entries and 391859 paths using 25288182 bytes of memory > > We don't filter either and... > > 117800 network entries and 339843 paths using 23660948 bytes of memory > > > "about 135k prefixes last i checked." is not what we see here from any of > our upstreams. > > > -Robert > > > > > Tellurian Networks - The Ultimate Internet Connection > http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 > "Good will, like a good name, is got by many actions, and lost by one." - > Francis Jeffrey -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: What is a reasonable range for global BGP table size?
At 11:26 AM 7/18/2002 -0400, you wrote: >Hmm. > >We don't filter, and > >112942 network entries and 391859 paths using 25288182 bytes of memory We don't filter either and... 117800 network entries and 339843 paths using 23660948 bytes of memory "about 135k prefixes last i checked." is not what we see here from any of our upstreams. -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Good will, like a good name, is got by many actions, and lost by one." - Francis Jeffrey
Re: What is a reasonable range for global BGP table size?
it appears to depend upon which hemisphere you get transit in :) Steve On Thu, 18 Jul 2002, Alex Rubenstein wrote: > > > Hmm. > > We don't filter, and > > 112942 network entries and 391859 paths using 25288182 bytes of memory > > > > On Wed, 17 Jul 2002, Jared Mauch wrote: > > > > > without filtering? > > > > about 135k prefies last i checked. > > > > On Wed, Jul 17, 2002 at 04:38:48PM -0500, Rob Healey wrote: > > > > > > > > > How big is the global BGP table running these days? > > > > > > 100K? 110K? Bigger? > > > > > > -Rob > > > > -- > > Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] > > clue++; | http://puck.nether.net/~jared/ My statements are only mine. > > > > -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- > --Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- > > >
Re: Multi-collector Netflow/etc
> data and this was then fed to the main processing server. However, in > general I think it's pretty hard to make Netflow data scale...ideally you > would be able to pick which fields you wanted exported... The NetFlow v9 format looks like it would support this kind of thing. Whether cisco will actually implement it that way I don't know. Bradley
Re: What is a reasonable range for global BGP table size?
Hmm. We don't filter, and 112942 network entries and 391859 paths using 25288182 bytes of memory On Wed, 17 Jul 2002, Jared Mauch wrote: > > without filtering? > > about 135k prefies last i checked. > > On Wed, Jul 17, 2002 at 04:38:48PM -0500, Rob Healey wrote: > > > > > > How big is the global BGP table running these days? > > > > 100K? 110K? Bigger? > > > > -Rob > > -- > Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] > clue++; | http://puck.nether.net/~jared/ My statements are only mine. > -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
Re: fractional gigabit ethernet links?
one small note, in passing: > In other words..intermittent intergap delay? when PAIX sells what it calls Fractional Gig E, it's just Gig E with rate limiting. nothing special at the link level.
Re: verio arrogance
Brian Wallingford wrote: [...] > That said, their current policy of refusing to accept de-aggregated > prefixes from peers (while accepting such from paying customers) makes > perfect sense, IMHO. Not arrogant, just a smart & reasonable business > decision. Interesting. Looking around, it seems that Verio allocates /24 and larger (all I saw offhand were /24s and /23s) address blocks for customers from the Class C space. Can't fault 'em for consistency. Peter E. Fry
RE: problems with 701
You're leaving 701. BR's are exit points toward a peer. If you go through a BR you are into a peering connection. That connection may be messed up, and sure that's their problem. But you'll get a lot further asking the right question is there a problem with 701-X peering in the south-east. -Original Message- From: Chad Oleary [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 18, 2002 6:05 AM To: [EMAIL PROTECTED] Cc: Bryan Heitman; Christopher L. Morrow Subject: Re: problems with 701 We're starting to see the same issues with uunet, again. Anyone else seeing this? Trying to reach Qwest... traceroute to 63.146.190.1 (63.146.190.1), 30 hops max, 38 byte packets 1 esc-lp2-gw.e-solutionscorp.com (63.118.220.1) 1.167 ms 1.163 ms 1.142 ms 2 500.Serial2-10.GW1.TPA2.ALTER.NET (157.130.149.9) 1.097 ms 1.059 ms 1.044 ms 3 161.at-1-0-0.XL4.ATL1.ALTER.NET (152.63.81.190) 13.839 ms 14.108 ms 16.638 ms 4 0.so-3-1-0.XL2.ATL5.ALTER.NET (152.63.0.238) 14.370 ms 14.587 ms 14.553 ms 5 POS7-0.BR2.ATL5.ALTER.NET (152.63.82.193) 13.928 ms 14.099 ms 14.053 ms 6 * * * ... Thanks, --Chad On Tue, 16 Jul 2002, Christopher L. Morrow wrote: > Date: Tue, 16 Jul 2002 19:45:49 + (GMT) > From: Christopher L. Morrow <[EMAIL PROTECTED]> > To: Bryan Heitman <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: problems with 701 > > > wow.. what are you trying to get to? This looks like it entered 701 on > hop 6 and exited at hop 8 to some other network which sttms to have some > delivery problems of its own. > > > > --Chris > ([EMAIL PROTECTED]) > ### > ## UUNET Technologies, Inc. ## > ## Manager ## > ## Customer Router Security Engineering Team ## > ## (W)703-886-3823 (C)703-338-7319 ## > ### > > On Tue, 16 Jul 2002, Bryan Heitman wrote: > > > > > anyone know what is going on over at uu? > > > > seeing problems all over... > > > > > 3 <10 ms <10 ms <10 ms 216.79.187.254 > > > 4 <10 ms10 ms <10 ms 172.25.57.5 > > > 5 <10 ms10 ms <10 ms 205.152.37.184 > > > 6 <10 ms10 ms10 ms 500.POS2-0.GW11.ATL5.ALTER.NET > > > [157.130.76.97] > > > 710 ms10 ms <10 ms 0.so-2-1-0.XL2.ATL5.ALTER.NET > > > [152.63.85.38] > > > 8 <10 ms10 ms10 ms POS7-0.BR2.ATL5.ALTER.NET [152.63.82.193] > > > 9 *** Request timed out. > > > 10 *** Request timed out. > > > > > > > > Best regards, > > > > > > Bryan Heitman > > Interland, Inc. > > > > >
Re: problems with 701
We're starting to see the same issues with uunet, again. Anyone else seeing this? Trying to reach Qwest... traceroute to 63.146.190.1 (63.146.190.1), 30 hops max, 38 byte packets 1 esc-lp2-gw.e-solutionscorp.com (63.118.220.1) 1.167 ms 1.163 ms 1.142 ms 2 500.Serial2-10.GW1.TPA2.ALTER.NET (157.130.149.9) 1.097 ms 1.059 ms 1.044 ms 3 161.at-1-0-0.XL4.ATL1.ALTER.NET (152.63.81.190) 13.839 ms 14.108 ms 16.638 ms 4 0.so-3-1-0.XL2.ATL5.ALTER.NET (152.63.0.238) 14.370 ms 14.587 ms 14.553 ms 5 POS7-0.BR2.ATL5.ALTER.NET (152.63.82.193) 13.928 ms 14.099 ms 14.053 ms 6 * * * ... Thanks, --Chad On Tue, 16 Jul 2002, Christopher L. Morrow wrote: > Date: Tue, 16 Jul 2002 19:45:49 + (GMT) > From: Christopher L. Morrow <[EMAIL PROTECTED]> > To: Bryan Heitman <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: problems with 701 > > > wow.. what are you trying to get to? This looks like it entered 701 on > hop 6 and exited at hop 8 to some other network which sttms to have some > delivery problems of its own. > > > > --Chris > ([EMAIL PROTECTED]) > ### > ## UUNET Technologies, Inc. ## > ## Manager ## > ## Customer Router Security Engineering Team ## > ## (W)703-886-3823 (C)703-338-7319 ## > ### > > On Tue, 16 Jul 2002, Bryan Heitman wrote: > > > > > anyone know what is going on over at uu? > > > > seeing problems all over... > > > > > 3 <10 ms <10 ms <10 ms 216.79.187.254 > > > 4 <10 ms10 ms <10 ms 172.25.57.5 > > > 5 <10 ms10 ms <10 ms 205.152.37.184 > > > 6 <10 ms10 ms10 ms 500.POS2-0.GW11.ATL5.ALTER.NET > > > [157.130.76.97] > > > 710 ms10 ms <10 ms 0.so-2-1-0.XL2.ATL5.ALTER.NET > > > [152.63.85.38] > > > 8 <10 ms10 ms10 ms POS7-0.BR2.ATL5.ALTER.NET [152.63.82.193] > > > 9 *** Request timed out. > > > 10 *** Request timed out. > > > > > > > > Best regards, > > > > > > Bryan Heitman > > Interland, Inc. > > > > >
Re: Multi-collector Netflow/etc
> Any other methods that are working for scaling multiple > collectors without exceeding router limitations or burdening > routers unnecessarily? I know that we at some point had several machines in the network gathering the data as the volumes simply became to much to process at one single point. We then had some homegrown software that did pre-processing on the data and this was then fed to the main processing server. However, in general I think it's pretty hard to make Netflow data scale...ideally you would be able to pick which fields you wanted exported... If you find some "standard" tool set for this, I think would be interesting though. But I personalyl still think the problem lays with the protocol as such... - kurtis -
Re: verio arrogance
> That said, their current policy of refusing to accept de-aggregated > prefixes from peers (while accepting such from paying customers) makes > perfect sense, IMHO. Not arrogant, just a smart & reasonable business > decision. You could turn this around and ask what reasons there are to not filter the more specifics out from your peers... - kurtis -
