Re: Outbound Route Optimization
On Fri, Jan 23, 2004 at 11:01:14AM -0800, Richard J. Sears wrote: > > In reality, I learned that BGP is simply not up to the task of handling > anything beyond its limited scope - best path routing. In today's world, > we need to look beyond best path as it simply has nothing to do with > best performance, at least not in 40 to 50% of my traffic routing > decisions. You can do that with bodies (if your a purest) or you can > utilize route optimization equipment. In either case, you have to do it. > > I think for the time being, route optimization equipment, and the > companies that utilize them will have an edge over those doing things > the manual way. Regardless of which box I could have chosen, the end > result is that myself and my backbone engineers have far more time on > their hands for other tasks and my customers are much happier than they > were before. BGP is relatively good at determining the best path when you a major carrier with connectivity to "everyone" (i.e. when traffic flows "naturally"), in many locations, and you engineer your network so that you have sufficient capacity to support the traffic flows. However, BGP is relatively BAD at determining the best path when you are the customer of many carriers, some of whom have serious problems on their network that they spend a lot of time and effort trying to hide from you, and when you have a diverse assortment of link speeds. In this setup, traffic does not flow "naturally". I often find myself spending a fair amount of time talking people down from trying to make their network "better" by buying transit from every carrier they can get their hands on. A single flapping session on a single transit can get you dampened for quite a while, making you only as strong as your weakest link. Also, the convergence becomes painfully slow, not to mention flaptacular, as best paths are computed, announced, re-computed, re-announced, re-re-computed, etc (and if you don't believe me watch Internap converge some time). Plus if you are an inbound heavy network, the localpref increase via certain paths (everyone localprefs their own customers above routes they hear from peers/transits) will cause a skew in traffic that prepending may have little to no influence over. Botton line, BGP is most useful when you select paths as naturally as possible, with as few transits are as needed for redundancy, and use equal-sized pipes with sufficient capacity to support the traffic flow (or where you make capacity decisions based on the traffic levels, not the other way around). When you try to force BGP to work with the model you described, it will go kicking and screaming. Now this isn't to say that even the best run carrier doesn't have their off days, and that there is potential benefit from having many different carriers to choose from, but it does almost REQUIRE a different system of path selection to be effective. Unfortunately there are some serious problems to overcome in order for any such system to scale, not the least of which are: * The inability to receive FULL bgp routes from every bgp peer to your optimization box without requiring your transit providers to set up a host of eBGP Multihop sessions (which most refuse to do). This means you will always be stuck assuming that every egress path is a transit and can reach any destination on the Internet until your active or passive probing says otherwise. * The requirement of deaggregation in order to make best path decisions effective. For example, someone's T3 to genuithree gets congested and the best path to their little /24 of the Internet is through another provider. Do you move 4.0.0.0/8? * The constant noise of stupid scripts pinging everything on the Internet. Once upon a time I heard some pretty interesting numbers about the amount of traffic a newly routed /8 with no usage received just in Internet noise from all the scanners, hackers, and worms out there. I don't know if it was true or not (though I'm sure someone on this list has done such and can tell us exactly how much traffic it is), but just looking at the amount of noise much smaller blocks receive leads one to the conclusion that active analysis will not scale to support everyone. etc etc etc. There is certainly room for improvement of traffic engineering in the protocols, but the perl scripts and zebra hacks most people are throwing at the problem currently are far from capable of handling it. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
DRAFT agenda for NANOG 30
Greetings - here's a subject-to-change agenda for Miami: --- NANOG 30 Agenda - 10th Anniversary Meeting ! February 8-10, 2004 Miami, Florida Sunday Tutorials 1:30 - 3:00 p.mCustomer-Triggered Real-Time Black Holes Level: Introductory Chris Morrow, UUNET; Tim Battles, AT&T 1:30 - 3:00 p.m. MPLS-Based Layer 2 VPNs Level: Intermediate Florin Balus and Mike Loomis, Nortel 3:00 - 3:30 p.m. BREAK 3:30 - 5:00 p.m. Provider-Provisioned Virtual Private Networks Level: Introductory Ina Minei, Juniper 3:30 - 5:00 p.m. MPLS Fast Reroute Level: Intermediate/Advanced Joe Soricelli, Juniper Monday, October 20 -- 9:00 a.m. Welcome, Introductions Eric Aupperle, Merit Andy Burnette, Terremark Susan Harris, Merit 9:20 a.m. Implications of Recent Legislation on Provider Operations Diane Sidebottom, Dept. of Homeland Security 9:50 a.m. A Short History of the 'Net Scott Bradner, Harvard Univ. 10:30 a.m.BREAK 10:45 a.m.End-to-end, Spam, and DoS: Threats to the Model That Made the Internet Great Phil Karn, QUALCOMM 11:15 a.m.10 Years of Corporate Change in the NANOG & IP Backbone Community Martin Levy, moderator;John Curran, XO Communication Doug Humphrey 12:00 p.m.LUNCH (on your own) 1:30 p.m. A Decade of Technology Pitfalls and Successes Dino Farinacci, Procket 2:00 p.m. Where Did the NAPs Come From and When Did They Turn Into Exchange Points? Steve Feldman, CNET 2:20 p.m. Anniversary Retrospective: Where We've Been & Where We're Headed Sue Hares, NextHop, Moderator Paul Francis, Cornell Univ. Steve Bellovin, AT&T Research Dino Farinacci, Procket 3:00 p.m. BREAK 4:20 p.m. Research Forum -- - Achievable Comprehensive Delay Reporting from Routers - Synchronising Software Clocks on the Internet Darryl Veitch, Sprintlabs - A Distributed Control Plane Architecture to Support Millisecond Routing Convergence Hormuzd Khosravi, Intel - IETF NETCONF Working Group Update Eliot Lear, Cisco - Nemecis: A Tool to Analyze the IRR Registries Georgos Siganos, UC Riverside - In-Progress Research Designing Support for Troubleshooting Complex Network Problems Barbara Mirel, Univ. of Mich. Monday Evening BOFs & Key Signing - 7:30 - 9:00 p.m. ISP Security and NSP-SEC BOF IV Barry Raveendran Greene, Cisco, moderator 9:00 - 10:30 p.m. Peering BOF VII Bill Norton, Equinix, moderator 9:00 - 10:30 p.m. Troubleshooting the Hardest Network Engineering Problems Barbara Mirel, Univ. of Michigan, moderator 9:00 p.m. PGP Key Signing Party Majdi Abbas, Lattice Networks, moderator Tuesday, October 21 --- 9:00 a.m. Listen and Whisper: Security Mechanisms for BGP L. Subramanian, V. Roth, I. Stoica, S. Shenker, and R.H. Katz, UC Berkeley 9:20 a.m. Making Sense of BGP Tina Wong, Van Jacobson, Cengiz Alaettinoglu, Packet Design 9:50 a.m. Hot Potatoes Heat Up BGP Routing Renata Teixeira, UCSD; Jennifer Rexford, AT&T; Tim Griffen, Intel 10:20 a.m. BREAK 10:40 a.m. MPLS Over Various IP Encapsulations Mark Townsley, Cisco 11:10 a.m. IAB Concerns About Permanent Deployment of Edge-Based Filtering Itojun Hagino, IETF Internet Architecture Board 11:25 a.m. Regional Internet Registries Statistics and Activities Ray Plazk, ARIN 11:45 a.m. How to Kill Worms and Viruses with Policy Pontifications Scott Bradner, Harvard 12:00 p.m. LUNCH (on your own) 1:30 p.m. Real-time Global Routing Metrics Jim Cowie, Andy T. Ogielski, B.J. Premore, Eric A. Smith, & Todd Underwood, Renesys 1:50 p.m. Root Cause Analysis of Internet Routing Dynamics Matthew C. Caesar, L. Subramanian, Randy H. Katz, UC Berkeley 2:10 p.m. Airborne Contagion: Effects of a Worm on Wireless Networking Christopher Chin, UC Berkeley 2:30 p.m. Life on a University Network: An Arc
Re: Outbound Route Optimization
I have been on a personal crusade for the last 8 months to address this very issue! We identified the exact same issues and questions as we grew from a single backbone to 7 backbones, each of various sizes ranging from gig connections to DS3s. In total I have almost 3GB of total available capacity, but two small DS3 links make routing decisions very interesting :-) It was becoming a nightmare for my engineers to manage the BGP for all of these backbones in such a way that dealt with both the business case as well as the performance case. In the end, it was becoming a customer service problem when we had spikes that saturated some of our smaller links and left our larger links untouched. BGP simply did not care about my capacity issues. In our specific setting, we are an ISP that buys all of our connectivity, and has spent a tremendous amount of time searching for total connectivity as opposed to total capacity. While most of our bandwidth per mb costs the same, our commit levels with our different carriers are different and required constant vigilance to maintain the levels we needed to see without overloading any particular link. We have no private peering at all. After some very unfortunate dealings with a bandwidth provider in the "performance based routing" business, I decided to do it on my own. Its important to note that in my world, my mandate was simple - get us the best possible performance from our network as you can possibly get. Worry about cost after performance. We house some large VoIP, Gaming and E-Commerce farms and cost was the lowest concern on our plate - keeping the customers happy was the primary concern. I started out by going from 2 backbones to buying backbone bandwidth from a total of 7 carriers, spreading those out among Cisco 7507s and Juniper M20s and basically relying on BGP and my engineering staff to monitor and manage those resources. In the end I discovered that it was a huge job to keep all of those balls in the air while not upsetting some of our larger customers, I spent months researching and talking to friends that drive some of the largest networks in the world. In the end, it was very clear to see that BGP was not up to the task of dealing with my network requirements. Best path simply did not equate to best performance and BGP had no provisions for determining saturation on my links. My engineers and I spent months talking to vendor after vendor about their products, doing research and trying to find the closest thing to a 'silver bullet' that we could find. An engineer friend of mine at Google turned me onto RouteScience and we put them into the mix of vendors we were testing. Our needs were simple - 100% performance based routing until we came within 15% max utilization on any given backbone, then next best performance path. In my world, cost based routing was the last thing we needed to deal with. We enlisted the help of several of our larger data center customers in a kind of blind trial of the various manufacturers as well as utilized KeyNote locations around the world for testing. After four months of testing and evaluation, we choose the RouteScience box. In my mind, the question about utilizing route optimization boxes is moot. Until we build into BGP (or some other method) the ability to sense latency and capacity issues, optimize bandwidth allocation based on our preferences, and maintain service level agreements by keeping our traffic heading down the best performance path automatically, we have to employ and dedicate an increasing number of engineers to these tasks. Route Optimization equipment plays a critical part in keeping my customers happy and myself and my other expensive engineers focused on other tasks more closely related to the bottom line. No smoke, no mirrors, no BS - these are real world numbers from our network. For me the proof was in the performance. After four months of baseline reporting, we were seeing an average performance increase (measure in decrease in latency) of 40 to 50% between the routes my pathcontrol box is selecting and standard BGP routes. My backbones include carriers such as Level3, UUNet, Qwest, XO, Verio - decent backbones with major connectivity. In reality, I learned that BGP is simply not up to the task of handling anything beyond its limited scope - best path routing. In today's world, we need to look beyond best path as it simply has nothing to do with best performance, at least not in 40 to 50% of my traffic routing decisions. You can do that with bodies (if your a purest) or you can utilize route optimization equipment. In either case, you have to do it. I think for the time being, route optimization equipment, and the companies that utilize them will have an edge over those doing things the manual way. Regardless of which box I could have chosen, the end result is that myself and my backbone engineers have far more time on their hands for other tasks and my customers are much happier tha
Re: network mapping and data viz.
A useful set of references and links can be found here: http://www.cybergeography.org/mapping.html - Original Message - From: Chris Horry <[EMAIL PROTECTED]> Date: Friday, January 23, 2004 11:42 am Subject: Re: network mapping and data viz. > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jamie Reid wrote: > | I have been looking for a tool that will visualize traceroute > data in > | a graph. Skitter looks ideal, but its availability is quite limited. > | > | I have tried Netmap (netmap.sourceforge.net) and have been > | mucking about with Graphviz (graphviz.org) in general. > | However, the problem of building a map from traceroute data > | (with graphviz anyway) is sorting out the unique paths. Technically > | possible, but I don't want to re-invent the wheel if I don't > have to. > | > | Tulip (tulip-software.org) is a framework that something like this > | could be written in, as is any other viz tool (opendx.org, etc...) > | The tools from Opte (opte.org) aren't available yet. > | > | Is there a tool that you are currently using to represent large > | traceroute graphs that is available under a gpl/bsd/open license? > | Even something based on Dot or Neato? > > You might want to try VisualRoute, www.visualroute.com. > > Chris > > - -- > Chris Horry "Winter is the season in which people > [EMAIL PROTECTED]try to keep the house as warm as it was > PGP: DSA/2B4C654E it was in the summer, when they complained > Amateur Radio: KG4TSM about the heat" --Author Unknown > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.4 (MingW32) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFAEU7mnAAeGCtMZU4RAp+eAJ974r5L20XoIeJAr/FakiyAhuYzxACff9pZ > 2v8ZJOy1g8c0kBF8+8gwwUI= > =43qW > -END PGP SIGNATURE- > >
Physical Layer Switches / Smart Optical Cross-Connect Panels
Hey Folks, I'm looking for physical layer switch that will allow me to remotely configure how two ports are cross-connected. The two main benefits would be that a site only has to be wired once and there is also a potential for a simplified disaster recovery plan (i.e. one of my boxes melts down, and I need to bring a standby online without dispatching a tech). If I could have the perfect box, it would: - Handle fiber (serial connections, ala DS3, would be a bonus) - Be protocol agnostic. I want to switch GigE and OC fiber cross-connects. I don't want GigE / POS inter-networking. - Be completely passive. If the power fails, all connections will remain active. I suppose this implies some sort of mechanical switching mechanism. - Text based CLI mandatory. Web GUI optional. - DC powered - Did I mention cheap? After Googling around this morning, it was unable to find anything that completely fits the bill. I was only able to come up with 3 vendors that come close to fitting the bill, each with their own set of pros and cons: RAM Electronics (http://www.ramelectronics.net/apcon/patchpanels.htm) MEMX (http://www.memx.com/cross%20connect.htm) MRV (http://www.mrv.com/product/MRV-FD-SFPMCC/) Anyone have experience with any of these vendors? Are there other vendors I should be looking at? Off-list replies from sales-droids welcome. (An invitation for punishment, I'm sure ;) Thanks! Brad -- +1-408-434-2048 [EMAIL PROTECTED]
Re: network mapping and data viz.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jamie Reid wrote: | I have been looking for a tool that will visualize traceroute data in | a graph. Skitter looks ideal, but its availability is quite limited. | | I have tried Netmap (netmap.sourceforge.net) and have been | mucking about with Graphviz (graphviz.org) in general. | However, the problem of building a map from traceroute data | (with graphviz anyway) is sorting out the unique paths. Technically | possible, but I don't want to re-invent the wheel if I don't have to. | | Tulip (tulip-software.org) is a framework that something like this | could be written in, as is any other viz tool (opendx.org, etc...) | The tools from Opte (opte.org) aren't available yet. | | Is there a tool that you are currently using to represent large | traceroute graphs that is available under a gpl/bsd/open license? | Even something based on Dot or Neato? You might want to try VisualRoute, www.visualroute.com. Chris - -- Chris Horry "Winter is the season in which people [EMAIL PROTECTED]try to keep the house as warm as it was PGP: DSA/2B4C654E it was in the summer, when they complained Amateur Radio: KG4TSM about the heat" --Author Unknown -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAEU7mnAAeGCtMZU4RAp+eAJ974r5L20XoIeJAr/FakiyAhuYzxACff9pZ 2v8ZJOy1g8c0kBF8+8gwwUI= =43qW -END PGP SIGNATURE-
Re: network mapping and data viz.
On Fri, 23 Jan 2004, Jamie Reid wrote: > I have been looking for a tool that will visualize traceroute data in > a graph. Skitter looks ideal, but its availability is quite limited. > Is there a tool that you are currently using to represent large > traceroute graphs that is available under a gpl/bsd/open license? > Even something based on Dot or Neato? For the RIS, we use dot, see: http://www.ris.ripe.net/cgi-bin/risas.cgi?as=&action=Search&startDay=20040123&startHour=00&startMin=00&startSec=00&endDay=20040123&endHour=14&endMin=7&endSec=35&rrcb=all&peer=all&type=U&outype=plot&sortby=stime&arrow=east&rank=100&plotsize=A4&.cgifields=type for an example, or select your own AS and graphical output in http://www.ris.ripe.net/cgi-bin/risas.cgi It is based on dot, plus about 2 pages of perl to pull the data from a DB. The nice thing about dot is that it does most of the work for you, including merging common parts of the paths and minimizing the number of crossing lines. Henk -- Henk Uijterwaal Email: [EMAIL PROTECTED] RIPE Network Coordination CentreWWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB AmsterdamFax: +31.20.5354445 The NetherlandsThe Netherlands Mobile: +31.6.55861746 -- Sir, it's not that we cannot help you, it's that we don't want to help you. (Former) Sales rep at *** inc.
Re: What's the best way to wiretap a network?
In article <[EMAIL PROTECTED]>, Kurt Erik Lindqvist <[EMAIL PROTECTED]> writes (Although I now what the NA...stands for I have to ask) Plenty of NANOs will have bits of network in the EU (or indeed within the remit of the Cybercrime Convention which the USA has signed but not ratified). So the EU part is only the tapping requirement? The charging scheme is local? Or did I miss all of this? EU law tends to say things about privacy, human rights, and so on. It outlaws wiretaps, but then has exemptions to allow individual states to pass wiretap laws if they feel there's a law enforcement need. Nothing about cost recovery. The Cybercrime Convention (a Treaty of the Council of Europe - which is not the EU - and not a law in its own right) has an article (#21) *requiring* ratifying states [1] to implement wiretapping, but is also silent on the cost recovery issue, which would be a matter for the individual state's legislature. [1] Only 4 relatively minor states so far, so the Treaty isn't even in force yet: http://conventions.coe.int/Treaty/EN/searchsig.asp?NT=185&CM=&DF= -- Roland Perry
network mapping and data viz.
I have been looking for a tool that will visualize traceroute data in a graph. Skitter looks ideal, but its availability is quite limited. I have tried Netmap (netmap.sourceforge.net) and have been mucking about with Graphviz (graphviz.org) in general. However, the problem of building a map from traceroute data (with graphviz anyway) is sorting out the unique paths. Technically possible, but I don't want to re-invent the wheel if I don't have to. Tulip (tulip-software.org) is a framework that something like this could be written in, as is any other viz tool (opendx.org, etc...) The tools from Opte (opte.org) aren't available yet. Is there a tool that you are currently using to represent large traceroute graphs that is available under a gpl/bsd/open license? Even something based on Dot or Neato? Thanks, -- Jamie.Reid, CISSP, [EMAIL PROTECTED] Senior Security Specialist, Information Protection Centre Corporate Security, MBS 416 327 2324 I have been looking for a tool that will visualize traceroute data in a graph. Skitter looks ideal, but its availability is quite limited. I have tried Netmap (netmap.sourceforge.net) and have been mucking about with Graphviz (graphviz.org) in general. However, the problem of building a map from traceroute data (with graphviz anyway) is sorting out the unique paths. Technically possible, but I don't want to re-invent the wheel if I don't have to. Tulip (tulip-software.org) is a framework that something like this could be written in, as is any other viz tool (opendx.org, etc...) The tools from Opte (opte.org) aren't available yet. Is there a tool that you are currently using to represent large traceroute graphs that is available under a gpl/bsd/open license? Even something based on Dot or Neato? Thanks, --Jamie.Reid, CISSP, mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]Senior Security Specialist, Information Protection Centre Corporate Security, MBS 416 327 2324
Re: sniffer/promisc detector
Ruben van der Leij wrote: +++ Alexei Roudnev [22/01/04 09:05 -0800]: My results vary from 15 minuts to 1 hour. Mine too. So nmap sucks if you want to quickly identify daemons running on strange ports. No big deal. This discussion wasn't about nmap to start with. Point of interest: Dan Kaminsky's scanrand (part of Paketto Keiretsu - www.doxpara.com, which seems to be down right now, but the Google cache works) is a very fast bulk scanner: "During an authorized test inside a multinational corporation's class B, scanrand detected 8300 web servers across 65,536 addresses. Time elapsed: approximately 4 seconds." http://www.pantek.com/library/general/lists/newsfeed.osdn.com/osdn-developer-txt-mm/msg1.html http://www.doxpara.com/ - down at present but Paketto is widely mirrored. There was also a "scan the entire Internet" project a few years back which used BASS, a bulk scanner. (grep the report for 'they're hre' for a tale of uber hacking that makes the hair stand up on the back of my neck even today...) BASS: http://www.securityfocus.com/data/tools/network/bass-1.0.7.tar.gz Report: http://www.viacorp.com/auditing.html \a The information contained in this message or any of its attachments may be privileged and confidential and intended for the exclusive use of the intended recipient. If you are not the intended recipient any disclosure, reproduction, distribution or other dissemination or use of this communications is strictly prohibited. The views expressed in this e-mail are those of the individual and not necessarily of MIS Corporate Defence Solutions Ltd. Any prices quoted are only valid if followed up by a formal written quote. If you have received this transmission in error, please contact our Security Manager on +44 (01622) 723410. This email is intended for the recipient only and contains confidential information, some or all of which may be legally privileged. If you are not the intended recipient, you must not use, save, disclose, distribute, copy, print or rely on this email or any information contained within it. Please notify the sender by return and delete it from your computer. Thank you.
The Cidr Report
This report has been generated at Fri Jan 23 21:47:51 2004 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
16-01-04129605 90929
17-01-04129642 90924
18-01-04129749 90922
19-01-04129759 90881
20-01-04129614 90911
21-01-04129657 91008
22-01-04129839 91002
23-01-04129825 91008
AS Summary
16434 Number of ASes in routing system
6593 Number of ASes announcing only one prefix
1379 Largest number of prefixes announced by an AS
AS701 : ALTERNET-AS UUNET Technologies, Inc.
73394432 Largest address span announced by an AS (/32s)
AS568 : SUMNET-AS DISO-UNRRA
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 23Jan04 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 129829910503877929.9% All ASes
AS4323 690 209 48169.7% TW-COMM Time Warner
Communications, Inc.
AS6197 696 267 42961.6% BATI-ATL BellSouth Network
Solutions, Inc
AS701 1379 956 42330.7% ALTERNET-AS UUNET
Technologies, Inc.
AS7018 1365 943 42230.9% ATT-INTERNET4 AT&T WorldNet
Services
AS7843 510 122 38876.1% ADELPHIA-AS Adelphia Corp.
AS27364 382 33 34991.4% ACS-INTERNET Armstrong Cable
Services
AS6198 590 250 34057.6% BATI-MIA BellSouth Network
Solutions, Inc
AS4134 657 332 32549.5% CHINANET-BACKBONE
No.31,Jin-rong Street
AS22909 331 26 30592.1% DNEO-OSP1 Comcast Cable
Communications, Inc.
AS22773 332 32 30090.4% CCINET-2 Cox Communications
Inc. Atlanta
AS1239 952 668 28429.8% SPRINTLINK Sprint
AS4355 382 99 28374.1% ERMS-EARTHLNK EARTHLINK, INC
AS9583 296 19 27793.6% SATYAMNET-AS Satyam Infoway
Ltd.,
AS1221 908 649 25928.5% ASN-TELSTRA Telstra Pty Ltd
AS17676 293 42 25185.7% GIGAINFRA Softbank BB Corp.
AS6347 329 82 24775.1% DIAMOND SAVVIS Communications
Corporation
AS25844 243 16 22793.4% SKADDEN1 Skadden, Arps, Slate,
Meagher & Flom LLP
AS209724 507 21730.0% ASN-QWEST Qwest
AS6140 345 129 21662.6% IMPSAT-USA ImpSat
AS6478 260 44 21683.1% ATT-INTERNET3 AT&T WorldNet
Services
AS14654 2113 20898.6% WAYPORT Wayport
AS11305 236 42 19482.2% INTERLAND-NET1 Interland
Incorporated
AS2386 418 229 18945.2% INS-AS AT&T Data
Communications Services
AS20115 599 415 18430.7% CHARTER-NET-HKY-NC Charter
Communications
AS4519 199 17 18291.5% MAAS Maas Communications
AS6327 205 28 17786.3% SHAW Shaw Communications Inc.
AS9929 199 30 16984.9% CNCNET-CN China Netcom Corp.
AS15270 208 39 16981.2% AS-PAETEC-NET PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS2048 249 84 16566.3% LANET-1 State of Louisiana
AS5668 322 159 16350.6% AS-5668 CenturyTel Internet
Holdings, Inc.
Total 14510 6471 803955.4% Top 30 total
Possible Bogus Routes
24.138.80.0/20 AS11260 ANDARA-HSI Andara High Speed Internet c/o Halifax
Cable Ltd.
64.62.126.0/23 AS25700 SWIFTDESK SWIFTDESK VENTURE
66.41.192.0/18 AS13367
Re: sniffer/promisc detector
>Mine too. So nmap sucks if you want to quickly identify daemons running on >strange ports. No big deal. This discussion wasn't about nmap to start with. >The point of the discussion was wether it made sense to run services on >non-standard ports to deter cr4x0rs. And I feel it doesn't. Actually, the point of the discussion was whether security through obscurity (A.K.A. camouflage techniques) is a legitimate tool in the security arsenal. >As long as a sshd yells "SSH-1.99" at you the moment you connect to it's >port there's no hiding sshd. Like I said, ... camouflage ... It doesn't stop with port numbers. And if you do camouflage the real SSH and run a honeypot on port 22 that looks like SSH, where do you think the haxors will put their attention first? >A well-tuned iptables or equivalent, on the other hand, might hide the >presence of daemons completely for anyone except the designated users. How >is that for obscurity? Great idea. The whole point of camouflage and obscurity techniques is to confuse observers/attackers and this fits the bill. I agree that security through obscurity should always be backed up with real hardening where possible, but I also believe that multiple techniques working in synergy is best. --Michael Dillon
Re: AT&T carrying rfc1918 on the as7018 backbone?
On Fri, 23 Jan 2004, Tomas Lund wrote: > On Thu, 22 Jan 2004, Brett Watson wrote: > > > I was just having a hard time believing AT&T was leaking 10/8 and that > > any other large provider was accepting it so wanted to verify. > > Wasn't it established that they did infact not leak it but just routed it > inside their own network? This is not true. I am attached to 7018 and we saw 10/X routes. We are not AT&T. bye, ken emery
