Re: why use IPv6, was: Lazy network operators
Renumbering is much easier. I like this one. Now this is a funny one about IPv6. How is renumbering *any* easier than IPv4? Yes you have autoconf based on route advertisements/solicits on the client end from the routers, but how is that any different than IPv4+DHCP? Is it perhaps b/c IPv6 uses classful styled numbering scheme? (i.e. you have /64 to end sites, where you simply s/old:old:old:old/new:new:new:new/ ) There is also a doc about renumbering in IPv6 http://ietfreport.isoc.org/idref/draft-baker-ipv6-renumber-procedure/ I guess it is easier to renumbering in IPv6, but even in IPv4, a proper set of procedures and well-done planning can make renumbering process way less painful than anticipated. Multihoming can be done the same way many people do it for IPv4: take addresses from one ISP and announce them to both. Obviously your /48 will be filtered, but as long as you make sure it isn't filtered between your two ISPs, you're still reachable when the link to either fails. However, this means renumbering when switching to another primary ISP. Not much fun, despite the fact that renumbering is much easier in IPv6. ??? How is this any different than bungled up peering with the 2nd provider with half-way transit? If my /48 is filtered from GRT, but at least both of my upstreams see it, I don't see it as multihoming. I see it as Broken multihoming. Another issue... How is IPv6 going to solve aggregation problem is something still being worked on. Making TLA spaces requirement for multihoming, like in RFC2772 is helping a lot in aggregation at the GRT, but that is definately a sledgehammer. honestly, in my sole belief, IPv6 surely integrates many of the more recent makeshift additions of IPv4, right into the protocol itself, which is a very good thing. But still, doesn't have enough real-world justification for most enterprises to plan for immediate protocol upgrade to v6, especially when multihoming issues are still not cleared, and most of improvements are already done in IPv4 with add-on's. -J -- James JunTowardEX Technologies, Inc. Technical LeadNetwork Design, Consulting, IT Outsourcing [EMAIL PROTECTED] Boston-based Colocation Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
welcome to 2004. ISL is a thing of the past. let us move on. ./end_flamebait.sh -J (who realized Cisco no longer supports ISL on 2950 and some other newer box) On Mon, Jan 26, 2004 at 11:09:07PM -0800, Alexei Roudnev wrote: So what? Is is a sugnificant drawback? I do not think so. Both ISL and 802.1q require special interface cards (with extended frame size), and I do not see any reason, why 26 bytes vs 4 bytes makes big difference. /May be, the only pro for 802.1q tagging is it's possible implementation on the old interface cards, which did not allowed extra 30 bytes but allowed extra 4 bytes/. I am no saying that ISL is better tha 802.1q, but 802.1q is not much better than ISL, and (in some cases) is even worst. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 26, 2004 9:10 AM Subject: Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs? ISL _DOES NOT CHANGE_ packet size. An 802.1q tag adds 4 bytes to the Ethernet frame. ISL encapsulation adds 30 bytes to the Ethernet frame. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: Nachi/Welchia Aftermath
more generally... if you want routing, buy a router. amen. imho there can't be a better routing equipment than a real router :) -J i have a hybrid switer that i'm very happy with. at my house, that is. (the idea of using one in commerce or production gives me cold shivers.) -- Paul Vixie -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: Nachi/Welchia Aftermath
ok so.. please note that, that was rather a foolish statement of mine :) for more constructive thought, i agree with ras' comments. -J On Wed, Jan 21, 2004 at 12:11:43PM -0500, [EMAIL PROTECTED] wrote: more generally... if you want routing, buy a router. amen. imho there can't be a better routing equipment than a real router :) -J i have a hybrid switer that i'm very happy with. at my house, that is. (the idea of using one in commerce or production gives me cold shivers.) -- Paul Vixie -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: sniffer/promisc detector
PS. Sniffer... there are not any way to detect sniffer in the non-switched network, and there is not much use for sniffer in switched network, if this network is configured properly and is watched for the unusial events. depends on brand and model of switch $ portinstall dsniff $ man macof -J (and yes, the thread topic is about ways for _watching_ the unusual events aka sniffing) The real smart ones - professionals - won't attack unless there's a chance of a serious payback. This excludes most businesses, and makes anything but a well-known script-based attack a very remote possibility. that's just not so. ask me about it in person and i might tell you stories. For most other people a trivial packet-filtering firewall, lack of Windoze, and a switch instead of a hub will do just fine. this part, i agree with. -- Paul Vixie -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: Nachi/Welchia Aftermath
lesson learned: stop using /makeshift/ layer3 switches (without naming vendor) to run L3 core -J On Tue, Jan 20, 2004 at 02:22:52PM -0800, Brent Van Dussen wrote: Well folks, since the middle of August I've been tracking the spread and subsequent efforts by our community to stop the nachia/welchia infection that took down so many networks. Sadly, by my estimations, only about 20-30% of infected hosts were cleaned. After Jan 1, 2004 it appears that the thousands, (millions?) of remaining infected hosts were rebooted and the worm removed itself. Network traffic has finally returned to normal. What kind of effects did everyone see from this devastating worm and what lessons did we learn for preventing network downtime in the future? -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: Nachi/Welchia Aftermath
yes in concur.. prefix based ones (like FIB) are fine. unfortunately some models from some vendors (tisk tisk) who use slow process path to reprogram the CAM per flow can be quite painful during situations like random dest. dos attacks and worms.. add the E vendor to your list too.. we had summit48i that loved the worm traffic -J On Tue, Jan 20, 2004 at 10:16:03PM -0200, Rubens Kuhl Jr. wrote: Not all L3-switches are flow-based; prefix-based ones should do just fine. Can people add/correct this initial list ? Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A) Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600 with Sup2(A), Sup3(A/BXL) Rubens - Original Message - From: [EMAIL PROTECTED] To: Brent Van Dussen [EMAIL PROTECTED] Cc: NANOG [EMAIL PROTECTED] Sent: Tuesday, January 20, 2004 9:46 PM Subject: Re: Nachi/Welchia Aftermath lesson learned: stop using /makeshift/ layer3 switches (without naming vendor) to run L3 core -J On Tue, Jan 20, 2004 at 02:22:52PM -0800, Brent Van Dussen wrote: Well folks, since the middle of August I've been tracking the spread and subsequent efforts by our community to stop the nachia/welchia infection that took down so many networks. Sadly, by my estimations, only about 20-30% of infected hosts were cleaned. After Jan 1, 2004 it appears that the thousands, (millions?) of remaining infected hosts were rebooted and the worm removed itself. Network traffic has finally returned to normal. What kind of effects did everyone see from this devastating worm and what lessons did we learn for preventing network downtime in the future? -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: sniffer/promisc detector
I think I'll pass this onto zen of Rob T. :) i think he said something along the lines of security industry is here for my amusement in the last nanog. so yea.. let's install bunch of honeypots and hope all those stupid hackers will get caught like the mouse. by the time you think your enemy is less capable than you, you've already lost the war. -J On Sat, Jan 17, 2004 at 02:31:06AM -0800, Alexei Roudnev wrote: The best anty-sniffer is HoneyPot (it is a method, not a tool). Create so many false information (and track it's usage) that hackers will be catched before they do something really wrong. Who do not know - look onto the standard, cage like, mouse - trap with a piece of cheese inside. -:) - Original Message - From: Rubens Kuhl Jr. [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 16, 2004 3:18 PM Subject: Re: sniffer/promisc detector That is a battle that was lost at its beginning: the Ethernet 802.1d paradigm of don't know where to send the packet, send it to all ports, forget where to send packets every minute is the weak point. There are some common mistakes that sniffing kits do, that can be used to detect them (I think antisniff implements them all), but a better approach is to make to promisc mode of no gain unless the attacker compromises the switch also. In Cisco-world, the solution is called Private VLANs. Nortel/Bay used to have ports that could belong to more than one VLAN, probably every other swith vendor has its own non-IEEE 802 compliant way of making a switched network more secure. Rubens - Original Message - From: Gerald [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 16, 2004 8:35 PM Subject: sniffer/promisc detector Subject says it all. Someone asked the other day here for sniffers. Any progress or suggestions for programs that detect cards in promisc mode or sniffing traffic? Gerald -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: PC Routers (was Re: /24s run amuck)
almost all times I hear people saying there is problem with Zebra or Quagga, more than half of all times it is problem with their OS, not the daemon. On Wed, Jan 14, 2004 at 05:00:06PM -0700, james wrote: : Be real carfull with Zebra, I got stung big time !!! What I run is actually Quagga, despite saying Zebra. Would you share your experiences ? James Edwards Routing and Security [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965 -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: PC Routers (was Re: /24s run amuck)
... and we care because? the router is a black box. if the output is not what is expected, it matters not why. though understandable, it is still not acceptable. /imho and you blame zebra ? if an equipment / vendor you have on your network is not acceptable, do what is acceptable such as (get another vendor|debug the problem|call the support) etc paul -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: PC Routers (was Re: /24s run amuck)
no, i blame the solution. if fans in my switch keep dying, i blame the manufacturer of the switch for picking an unreliable fan manufactuer, not the manufacturer of the fan alone. wrong. more than half of all problems i hear, the _fan_ is the OS or the implementation by user, not zebra/quagga. if an equipment / vendor you have on your network is not acceptable, do what is acceptable such as (get another vendor|debug the problem|call the support) etc yes. i handle this by not using zebra/(.*)OS boxes for tasks that are better handled by something else. paul -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: PC Routers (was Re: /24s run amuck)
OSPF and ISIS, etc redistribution is a Zebra/etc function and I am told it is pretty good at these functions. multilink PPP? With spanning tree on multiple VLANs? With peer groups? Most of these are OS functions, but I believe they support peer groups in the later editions of the software. We extensively and heavily utilize peer-groups all over at the edge of our IPv6 testbed network, which is mainly powered by Quagga (Some zebra), and a couple C's and J's. We absolutely had no problem running peer-groups with Quagga in both v6 and v4 as of date. Remember that Zebra/Quagga is not a _solution_. It is a userland component you build into an OS or a platform, to BUILD a solution. With SNMP? OS function. Works. How does the host deal with 802.1q trunks? With Channel interfaces? With hot-swapping a line card? With TCP MD5? Hotswapping is a chassis function. The rest are OS functions. These are the questions I ask myself when I pick a routing platform. Cheap is of no use to me if it does not do what I need. Of course, but you may not need all of these functions on your low-medium end, or you'll want to pick your alternate platform as thoughtfully as you'd pick a large-capital item. Deepak Jain AiNET -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: /24s run amuck
The only way I can see to do anything about this is for upstreams to educate their customers and others to pressure their peers. Educating customers... educating peers... I think enough had been tried and that is just too much work for the most people with little effect. The problem is the _upstreams_ are the general source of deaggs. If upstreams have policies in place with well organized autonomous filtering system and routing policy, theirs customers will most likely end up being having to justify deaggregation or else get filtered. -J Two primary reasons are given, one is for traffic engineering purposes to either control the ingress of traffic or to allow a network to function with critical links down and the other is to allow blocks to be dropped to mitigate the effects of a DDoS, I dont believe either justify the deaggregation of large aggregates into Nx/24s and that a large driver is to make your network look larger than it is... Steve On Sat, 10 Jan 2004, Richard A Steenbergen wrote: Ok, I realized I haven't done one of these since 2001, so it's time for an updated list of /24 polluters. With /24s accounting for over 50% (more than 71k) of the announcements on the Internet, it seems reasonable to try and take a look at why there are so many. One of the patterns which quickly becomes evident is the announcing of almost all of a larger block, but with enough gaps that traditional scripts which look for CIDR aggregation can miss it. For example, someone who owns a /16 and announces it as 250 /24s might not show up in other CIDR aggregation scripts because of the missing 5 /24s, or if 1 of the /24s has a different AS Path. So, solely for the purpose of looking for this pattern, I have written a script which counts the number of /24s announced within a /16 (an admittedly arbitrary range, but one which happens to work) with a consistant AS Path, and sorts by the highest count. This of course doesn't mean for certain that the netblock listed doesn't have a good reason for their deaggregation, but odds are they don't or could otherwise take steps to limit announcement to the general internet (for example a cable modem provider with 250 individual routes /24s but only a single upstream provider, who could announce a /16 globally and use no-export on the more specifics). This is done from the point of view of a Global Crossing (AS3549) transit feed, so things may look slightly different fromy our corner of the Internet. You have been warned. A summary of the top 250 netblocks by count: http://www.e-gerbil.net/ras/projects/ipaddr/24summary Detailed list of the netblocks and AS Path by count: http://www.e-gerbil.net/ras/projects/ipaddr/24dump A sorted list of the origin ASs contributing the /24s in the above lists: http://www.e-gerbil.net/ras/projects/ipaddr/24asn If you are on the list or know someone who is, please encourage them to take steps to clean up their act. You may now return to your regularly scheduled complaining about Verisign. -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: example.com/net/org DNS records
A) They don't own example.com and, Who says they don't? RFC never says IANA can or cannot own. B) this is the crux of the issue. IANA was not granted special privileges by RFC2606 nor do they have any more claim to these domains than Verisign does to unregistered domains or expired domains. The RFC never stated IANA cannot register these domains. It says IANA will _reserve_ the domains. Bottomline, as long as IANA holds the domain, stating its reserved, RFC is complied. http://www.example.com says: You have reached this web page by typing example.com, example.net, or example.org into your web browser. These domain names are reserved for use in documentation and are not available for registration. See RFC 2606, Section 3. Good enough. I find it fully compliant to the RFC. Example.dom was placed in the pubic domain by a public and open RFC process. It seems that IANA has violated this process and in so doing exceeded the authority vested in them by their contract with DARPA (and the DOC?). Is that contract available in public domain? If so, have you read it? I clearly understand your frustration but let's not make assumptions. If UCE happens to contain a forged sender of roble.com, would you consider that even remotely useful in a filter? Yes. Roble manages several email gateways for companies other than ourselves and we've found that rejecting invalid domains and senders is an indispensable component of spam filtering. Not only is it effective it is also 100% false-positive proof (so far). OK, bingo. This is a simple issue to fix. Configure your spam filter to reject spams sourced from example.* This is not hard, and much more productive and quickest to do on your mail server(s). -J -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: Stopping ip range scans
[.. SNIP ..] The problem is these are random scans, the traffic is going to ips that are not used and never were. They're clearly a random sequential scans. In this particular case, null-routing your aggregate is your friend. Or get a sink hole and suck down all the !traffic to it. Please, it's the internet. Port scans are nothing out of the ordinary. -James -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: Request for submissions: messy cabling and other broken things
Now that you've educated the world about messy cabling jobs that should _not_ be done, perhaps you or someone else should now post _CLEAN_ cabling jobs that everyone should follow examples of :-) Thanks for the good pictures btw. Some of them are actually funny hehe On Mon, Dec 15, 2003 at 03:12:20PM -0800, Eric Kuhnke wrote: Sometimes illustrating the way a job should *not* be done is a powerful educational tool. I have collected a gallery of messy and ridiculous cabling jobs: http://gallery.colofinder.net/shameful-cabling my favorite (not horrible, but funny): http://gallery.colofinder.net/shameful-cabling/cables Anonymous submissions can be sent to [EMAIL PROTECTED] , equipment labels and faces will be blurred if requested. -- James Jun (formerly Haesu) Network Operations TowardEX Technologies, Inc. Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
ARIN, where art thou?
Does any one know if ARIN just went down? I am trying from different locations and its not connecting.. traceroute dies after arin-gw.customer.alter.net Thanks, -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN
Re: ARIN, where art thou?
It looks like they are back up now. I think it was short outage. Sorry to those who got distracted by the false alarm here.. -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN On Wed, Nov 12, 2003 at 08:01:11PM -0600, Chris Adams wrote: Once upon a time, Haesu [EMAIL PROTECTED] said: I am trying from different locations and its not connecting.. traceroute dies after arin-gw.customer.alter.net whois.arin.net and www.arin.net are working from here. It appears they block traceroute. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: paging Motorola - please evacuate your ninja bots from route-views.oregon-ix.net
Uhm... I think those ninja bots are in frozen-state. They probably logged off but their session may have been locked up in router vty. May be its time for route-views to go another reboot? -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN On Mon, Nov 10, 2003 at 01:58:39PM -0500, Kai Schlichting wrote: Paging Motorola. Please leave some system resources for the rest of us and LOG OFF when you're done. Thank you. bye,Kai sonet:~$ date Mon Nov 10 13:56:46 EST 2003 sonet:~$ telnet route-views.oregon-ix.net [] route-views.oregon-ix.netwho Line User Host(s) Idle Location 2 vty 0idle 1w3d gate01.mot.com 3 vty 1idle 1w3d gate02.mot.com 4 vty 2idle 1w3d 203.135.29.11 5 vty 3idle 1w2d www.sohoskyway.net 6 vty 4idle 1w3d mippet.ci.com.au 7 vty 5idle 1w2d a65-124-16-8.svc.towardex.com 8 vty 6idle 1w2d gate01.mot.com 9 vty 7idle 1w2d gate02.mot.com 10 vty 8idle 1w3d 216.140.58.174 11 vty 9idle 1w3d host1.tla.com 12 vty 10 idle 1w3d gate01.mot.com 13 vty 11 idle 1w2d gate02.mot.com 14 vty 12 idle 1w3d gate01.mot.com 15 vty 13 idle 1w2d gate01.mot.com 16 vty 14 idle2d19h gate02.mot.com 17 vty 15 idle 1w1d gate02.mot.com 18 vty 16 idle 1w1d gate01.mot.com 19 vty 17 idle 1w1d gate02.mot.com 20 vty 18 idle 1w1d gate01.mot.com 21 vty 19 idle 1w0d gate02.mot.com 22 vty 20 idle 1w0d gate02.mot.com 23 vty 21 idle4d10h 203.130.226.203 24 vty 22 idle5d23h gate02.mot.com 25 vty 23 idle 1w0d Blackberry.rt.ru 26 vty 24 idle 1w0d gate01.mot.com 27 vty 25 idle 1w0d gate02.mot.com 28 vty 26 idle 1w0d gate02.mot.com 29 vty 27 idle 1w0d gate01.mot.com 30 vty 28 idle6d12h gate01.mot.com 31 vty 29 idle3d18h gate02.mot.com 32 vty 30 idle3d20h office.gill.force.vcn.com 33 vty 31 idle4d16h gate02.mot.com 34 vty 32 idle6d17h gate02.mot.com 35 vty 33 idle2d13h gate02.mot.com 36 vty 34 idle5d13h 203.130.226.203 37 vty 35 idle4d22h gate01.mot.com 38 vty 36 idle2d03h phlox.cs.wisc.edu 39 vty 37 idle4d23h a207-99-126-144.svc.towardex.com 40 vty 38 idle3d15h gate01.mot.com 41 vty 39 idle3d14h gate02.mot.com 42 vty 40 idle3d06h gate02.mot.com 43 vty 41 idle4d05h gate02.mot.com 44 vty 42 idle3d17h mail-out.hk.reach.com 45 vty 43 idle3d12h gate02.mot.com 46 vty 44 idle2d15h gate02.mot.com * 47 vty 45 idle 00:00:00 sonet.conti.nu 48 vty 46 idle2d14h gate02.mot.com 49 vty 47 idle2d22h gate02.mot.com 50 vty 48 idle1d07h gate02.mot.com 51 vty 49 idle2d01h gate02.mot.com 52 vty 50 idle2d09h gate02.mot.com 53 vty 51 idle 00:00:14 ip-157-14.newcomamericas.net 54 vty 52 idle 00:04:10 office.gill.force.vcn.com 55 vty 53 idle 11:10:41 gate02.mot.com 56 vty 54 idle 00:00:34 gateway.panamsat.com 57 vty 55 idle 16:11:06 gate01.mot.com 58 vty 56
Re: Anybody using GBICs?
On Tue, Oct 28, 2003 at 09:48:01AM -0800, [EMAIL PROTECTED] wrote: I'm looking into doing some research that will make use of GBICs(Gigabit Interface Converters), interesting info too: http://www.nanog.org/mtg-0310/wodelet.html but I need to know how many of you are using GBICs in your networks? If you are using them, where do they fit into your topology? Anyone who runs a provider network pretty much? heh.. We use them on all core routers and colo switch uplinks.. -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN
Re: Anybody using GBICs?
I'm just curious as to what kind of question it is... apologies if I sound rude to you.. but... What difference does this question make from following: I am doing a research about GigE connectivity. How many people use Gigabit PCI NIC's in their servers, and where in your systems division do you use them the most?? GigE is gives you.. 1 gigabit of connectivity. So.. anything that requires more than 100baseTX bandwidth, and with shorter distance, anyone would use GE whether its customer, peering, backbone, workstation, or even home computer, whatever works. Ethernet is all about Al Cheapo port cost at fast speeds ;-) -Hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN On Tue, Oct 28, 2003 at 01:36:26PM -0800, [EMAIL PROTECTED] wrote: To be more clear, I'm specifically referring to Gigabit Ethernet Converters and not SFPs for POS or SONET. So, to reprhase, where in your network topology, are you using Gigabit Ethernet, specifically GE interfaces using GBICS? Are you using GE primarily for customer connections, server connections, peering points etc. ? Thanks to all who have already replied privately. -Lance- -Original Message- From: Haesu [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 10:54 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Anybody using GBICs? On Tue, Oct 28, 2003 at 09:48:01AM -0800, [EMAIL PROTECTED] wrote: I'm looking into doing some research that will make use of GBICs(Gigabit Interface Converters), interesting info too: http://www.nanog.org/mtg-0310/wodelet.html but I need to know how many of you are using GBICs in your networks? If you are using them, where do they fit into your topology? Anyone who runs a provider network pretty much? heh.. We use them on all core routers and colo switch uplinks.. -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN
Re: /8 blocks allocation statistcs and current use data
Btw, out of curiosity.. What would be the point of registering an AS number for route server? If these hijacked blocks are supposed to be 'bogons', why not use private AS like what Rob is doing? Wouldn't you rather not want these 'bogons' to reappear on the net? Using private AS would be able to easily detect that if someone misconfigures his router. Just curious to ask.. that's all.. -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN On Fri, Oct 17, 2003 at 04:20:13PM -0700, [EMAIL PROTECTED] wrote: As some noticed what is shown today for statistics does not show as announced ip blocks that are announced as entire /8 (3/8 for example). These are processed separately as exceptions and it'll be easier to wait until all scripts are run in order so tomorrow statistics page will be back to normal. On Fri, 17 Oct 2003 [EMAIL PROTECTED] wrote: Try this in about one hour actually, I just noticed blue parts of graphs are missing since I rerun data collection twice today (yes, known bug, but I usually do not run collection manually and then its not a problem) On Fri, 17 Oct 2003 [EMAIL PROTECTED] wrote: As by-product of bogons project I just posted about, we also got some interesting statistics on how much ip space is allocated and used in each /8 block. This is all available in nice graphical format at: http://www.completewhois.com/statistics/ip_statistics.htm The data above is updated every day and I'm also entering this all into rrd database and once I have enough samples rrd graphs of how much this statistics change will also be made available (but before such graphs provide really good view there must be year worth of samples or more...)
Re: Extreme BlackDiamond
Don't mean to get off-topic... but speaking the Extremes.. Has anyone here had luck with doing some BGP stuff with Sumit 48i? Thanks, -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN
Re: Frustrating loss of connectivity...
Hi, have you tried the return path traceroute... Like, run traceroute _From_ the server behind dsl and back to you? Having traceroutes done either way may be helpful often times b/c sometimes problems do rise on asymetric routing situation where provider is doing bgp with x no. of providers. Please feel free to reply to me off list. I understand your frustration to get this out to bunch of engineers, but this may be clasifed as off-topic.. Thanks, -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN On Mon, Oct 13, 2003 at 10:33:26AM -0500, Robert A. Hayden wrote: Hey all, I apologize for posting this here, especially for what is essentially an end-user broadband issue, but I'm looking at what appears to be a link a few hops upstream from me that has been flapping frequently and I can't get our provider to look into it. I am located in Madison, WI, and I have my mail/server machine geek.net co-located in Minneapolis on a business-class DSL line (1.5m/384k). For the past couple of months, I'll lose connectivity for about 5 minutes several times a day. We attempted to open a case with the DSL provider (covad), but they were only interested in addressing last-mile issues and we got nowhere. Same applied when addressing it from my broadband end, since the disconnect is 3 providers upstream. In any case, any thoughts on where I should go with this? I could try Level3, but I suspect they'll blow me off since I'm not a direct customer. It's getting quite frustrating as I'm trying to move a few hundred mb back and forth over the VPN and with that one link flapping it's become almost impossible. Traceroute examples included below. I left real IPs here since they are all easily determined anyways: -- TRACE #1: From my home connection to Geek.NET when it's BROKEN, note where it breaks. C:\tracert 66.166.71.243 Tracing route to geek.net [66.166.71.243] over a maximum of 30 hops: 124 ms10 ms29 ms 10.44.64.1 211 ms10 ms11 ms 172.18.98.98 319 ms22 ms43 ms 172.18.97.58 416 ms14 ms15 ms 12.125.143.113 558 ms34 ms47 ms gbr2-a90s19.cgcil.ip.att.net [12.123.5.78] 616 ms17 ms16 ms tbr1-p013602.cgcil.ip.att.net [12.122.11.37] 731 ms28 ms14 ms ggr2-p310.cgcil.ip.att.net [12.123.6.65] 816 ms 105 ms16 ms so-1-1-0.edge1.Chicago1.Level3.net [209.0.227.77] 921 ms21 ms33 ms so-2-1-0.bbr2.Chicago1.level3.net [209.244.8.13] 1032 ms19 ms14 ms pos9-0.core1.Chicago1.level3.net [209.247.10.170] 1120 ms31 ms48 ms gige6-2.ipcolo2.Chicago1.Level3.net [209.244.8.30] 1264 ms29 ms36 ms unknown.Level3.net [209.247.226.26] 13 *** Request timed out. 14 *** Request timed out. .. 30 *** Request timed out. Trace complete. -- TRACE #2: Same trace, but this time when it's working. C:\tracert 66.166.71.243 Tracing route to geek.net [66.166.71.243] over a maximum of 30 hops: 121 ms16 ms15 ms 10.44.64.1 210 ms22 ms11 ms 172.18.98.98 310 ms15 ms11 ms 172.18.97.58 413 ms37 ms14 ms 12.125.143.113 515 ms18 ms18 ms gbr2-a90s19.cgcil.ip.att.net [12.123.5.78] 626 ms15 ms19 ms tbr1-p013602.cgcil.ip.att.net [12.122.11.37] 736 ms39 ms14 ms ggr2-p310.cgcil.ip.att.net [12.123.6.65] 834 ms14 ms37 ms so-1-1-0.edge1.Chicago1.Level3.net [209.0.227.77] 917 ms14 ms14 ms so-2-1-0.bbr2.Chicago1.level3.net [209.244.8.13] 1017 ms13 ms14 ms pos9-0.core1.Chicago1.level3.net [209.247.10.170] 1118 ms15 ms16 ms gige6-2.ipcolo2.Chicago1.Level3.net [209.244.8.30] 1224 ms27 ms25 ms unknown.Level3.net [209.247.226.26] 1330 ms17 ms23 ms 192.168.5.66 1449 ms52 ms 102 ms 172.18.57.242 1591 ms40 ms39 ms geek.net [66.166.71.243] Trace complete. --- Trace #3: Final trace, from Geek.NET back to my home broadband host (my home IP changed to 10.0.0.1 for this example). traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 38 byte packets 1 r-66-166-71-241.CHCGILGM.covad.net (66.166.71.241) 1.050 ms 0.938 ms 0.891 ms 2 172.31.255.253 (172.31.255.253) 24.068 ms 26.558 ms 26.169 ms 3 192.168.5.65 (192.168.5.65) 22.466 ms 23.301 ms 22.528 ms 4 gigabitethernet8-0-131.ipcolo1.Chicago1.Level3.net (209.247.34.177) 23.638 ms 23.263 ms 22.539 ms 5 gige5-1.core1.Chicago1.Level3.net (209.244.8.17) 22.243 ms 23.256 ms 22.528 ms 6 so-4-0
Re: Frustrating loss of connectivity...
Doh! silly me... I didn't read the whole email in the first time.. Sorry about useless post :( -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN On Mon, Oct 13, 2003 at 12:23:05PM -0400, Haesu wrote: Hi, have you tried the return path traceroute... Like, run traceroute _From_ the server behind dsl and back to you? Having traceroutes done either way may be helpful often times b/c sometimes problems do rise on asymetric routing situation where provider is doing bgp with x no. of providers. Please feel free to reply to me off list. I understand your frustration to get this out to bunch of engineers, but this may be clasifed as off-topic.. Thanks, -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN On Mon, Oct 13, 2003 at 10:33:26AM -0500, Robert A. Hayden wrote: Hey all, I apologize for posting this here, especially for what is essentially an end-user broadband issue, but I'm looking at what appears to be a link a few hops upstream from me that has been flapping frequently and I can't get our provider to look into it. I am located in Madison, WI, and I have my mail/server machine geek.net co-located in Minneapolis on a business-class DSL line (1.5m/384k). For the past couple of months, I'll lose connectivity for about 5 minutes several times a day. We attempted to open a case with the DSL provider (covad), but they were only interested in addressing last-mile issues and we got nowhere. Same applied when addressing it from my broadband end, since the disconnect is 3 providers upstream. In any case, any thoughts on where I should go with this? I could try Level3, but I suspect they'll blow me off since I'm not a direct customer. It's getting quite frustrating as I'm trying to move a few hundred mb back and forth over the VPN and with that one link flapping it's become almost impossible. Traceroute examples included below. I left real IPs here since they are all easily determined anyways: -- TRACE #1: From my home connection to Geek.NET when it's BROKEN, note where it breaks. C:\tracert 66.166.71.243 Tracing route to geek.net [66.166.71.243] over a maximum of 30 hops: 124 ms10 ms29 ms 10.44.64.1 211 ms10 ms11 ms 172.18.98.98 319 ms22 ms43 ms 172.18.97.58 416 ms14 ms15 ms 12.125.143.113 558 ms34 ms47 ms gbr2-a90s19.cgcil.ip.att.net [12.123.5.78] 616 ms17 ms16 ms tbr1-p013602.cgcil.ip.att.net [12.122.11.37] 731 ms28 ms14 ms ggr2-p310.cgcil.ip.att.net [12.123.6.65] 816 ms 105 ms16 ms so-1-1-0.edge1.Chicago1.Level3.net [209.0.227.77] 921 ms21 ms33 ms so-2-1-0.bbr2.Chicago1.level3.net [209.244.8.13] 1032 ms19 ms14 ms pos9-0.core1.Chicago1.level3.net [209.247.10.170] 1120 ms31 ms48 ms gige6-2.ipcolo2.Chicago1.Level3.net [209.244.8.30] 1264 ms29 ms36 ms unknown.Level3.net [209.247.226.26] 13 *** Request timed out. 14 *** Request timed out. .. 30 *** Request timed out. Trace complete. -- TRACE #2: Same trace, but this time when it's working. C:\tracert 66.166.71.243 Tracing route to geek.net [66.166.71.243] over a maximum of 30 hops: 121 ms16 ms15 ms 10.44.64.1 210 ms22 ms11 ms 172.18.98.98 310 ms15 ms11 ms 172.18.97.58 413 ms37 ms14 ms 12.125.143.113 515 ms18 ms18 ms gbr2-a90s19.cgcil.ip.att.net [12.123.5.78] 626 ms15 ms19 ms tbr1-p013602.cgcil.ip.att.net [12.122.11.37] 736 ms39 ms14 ms ggr2-p310.cgcil.ip.att.net [12.123.6.65] 834 ms14 ms37 ms so-1-1-0.edge1.Chicago1.Level3.net [209.0.227.77] 917 ms14 ms14 ms so-2-1-0.bbr2.Chicago1.level3.net [209.244.8.13] 1017 ms13 ms14 ms pos9-0.core1.Chicago1.level3.net [209.247.10.170] 1118 ms15 ms16 ms gige6-2.ipcolo2.Chicago1.Level3.net [209.244.8.30] 1224 ms27 ms25 ms unknown.Level3.net [209.247.226.26] 1330 ms17 ms23 ms 192.168.5.66 1449 ms52 ms 102 ms 172.18.57.242 1591 ms40 ms39 ms geek.net [66.166.71.243] Trace complete. --- Trace #3: Final trace, from Geek.NET back to my home broadband host (my home IP changed
Re: BellSouth prefix deaggregation (was: as6198 aggregation event)
Yup, Looks like they've started getting things a bit organized since sunday night/ monday early dawn. From my network's pt of view, you can see the sudden slight sink in announcements transited thru UUNET which is where bellsouth's prefixes come from on my end: http://www.twdx.net/bgp/graph-1w.png -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN On Mon, Oct 13, 2003 at 11:15:38AM +, James Cowie wrote: On Sun, Oct 12, 2003 at 01:18:59AM -0400, Terry Baranski wrote: More on this - Two of BellSouth's AS's (6197 6198) have combined to inject around 1,000 deaggregated prefixes into the global routing tables over the last few weeks (in addition to their usual load of ~600+ for a total of ~1,600). Kudos to BellSouth for taking first steps to clean this up overnight -- about 1100 of the prefixes left the table between about 01:45 and 03:45 GMT. Very nice deflation. Next topic: multiple origin ASNs .. -- James Cowie Renesys Corporation [EMAIL PROTECTED] 603-464-5799 voice 603-464-6014 fax
Re: BellSouth prefix deaggregation (was: as6198 aggregation event)
IMHO, I think we should create a route-set obj like call it... RS-DEAGGREGATES and list all the major irresponsible providers's specific /24's in it... So some ASes who wish to not accept deaggregated specifics using RPSL can update their AS import policy to not import RS-DEAGGREGATES... Just my humble opinion.. Comments/critics welcome :) -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN On Sun, Oct 12, 2003 at 11:26:49AM -0400, Jared Mauch wrote: On Sun, Oct 12, 2003 at 01:02:57PM +, Stephen J. Wilcox wrote: Can anyone from BellSouth comment? What if a few other major ISPs were to add a thousand or so deaggregated routes in a few weeks time? Would there be a greater impact? one word - irresponsible This clearly stands out to me as a reason to keep and use prefix filtering on peers to reduce the amount of junk in the routing tables. If bellsouth needs to leak more specifics for load balancing purposes, fine, just make sure those routes don't leave your upstreams networks and waste router memory for the rest of us that don't need to see it. - Jared (Note: The above numbers are based on data from cidr-report.org. Some other looking glasses were also checked to see if cidr-report.org's view of these AS's is consistent with the Internet as a whole. This appears to be the case, but corrections are welcome.) -Terry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Terry Baranski Sent: Sunday, October 05, 2003 3:01 PM To: 'James Cowie'; [EMAIL PROTECTED] Subject: RE: as6198 aggregation event James Cowie wrote: On Friday, we noted with some interest the appearance of more than six hundred deaggregated /24s into the global routing tables. More unusually, they're still in there this morning. AS6198 (BellSouth Miami) seems to have been patiently injecting them over the course of several hours, between about 04:00 GMT and 08:00 GMT on Friday morning (3 Oct 2003). If you look at the 09/19 and 09/26 CIDR Reports, BellSouth Atlanta (AS6197) did something similar during this time period -- they added about 350 deaggregated prefixes, most if not all /24's. Usually when we see deaggregations, they hit quickly and they disappear quickly; nice sharp vertical jumps in the table size. This event lasted for hours and, more importantly, the prefixes haven't come back out again, an unusual pattern for a single-origin change that effectively expanded global tables by half a percent. That AS6197's additions are still present isn't encouraging. -Terry -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: BellSouth prefix deaggregation (was: as6198 aggregation event)
The idea is to not filter just /24's. The idea is to work with people who run cidr-report.org (may be.. or other people who are willing to coop), and find an ASNs who advertise a lots of irresponsible deaggregates. As you can see, cidr-report only shows deaggregation for the prefixes that an AS _specifically_ _originates_. It does not show /24's out of downstream ASes, so it is safe. Basically there would need to be some sort of monitoring process to review the cidr-report regularly to keep a close watch on irresponsible providers, and generate route-set filter against them until they aggregate themselves. -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN On Sun, Oct 12, 2003 at 03:07:46PM -0400, McBurnett, Jim wrote: IMHO, I think we should create a route-set obj like call it... RS-DEAGGREGATES and list all the major irresponsible providers's specific /24's in it... CASE: Business has a /24 from X provider in order to multihome. That /24 is de-aggregated from a /19, with this policy that /24 may not be routed. possible exception: When 2002-3 get passed by ARIN, this could even take on new meaning. ARIN says they will use a single /8 for the handing out of /22-/24 for multihoming end users. will you then filter those /24's also? Also: What happens when that /24 for Business Y noted above is dual routed by ISP A and ISP B, and ISP A's upstream filters but ISP B's does not? Will there be asymmetric routing? Finally: Can anyone from BellSouth, explain the end goal of the de-aggregation? I suspect with 40 + ASs they may be rebuilding their network with a recently announced list of new IP services and DSL growth as asked for under the Federal government Rural DSL regulations... (I'm not trying to defend them, just giving some possibilities) So some ASes who wish to not accept deaggregated specifics using RPSL can update their AS import policy to not import RS-DEAGGREGATES... Just my humble opinion.. Comments/critics welcome :) -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN On Sun, Oct 12, 2003 at 11:26:49AM -0400, Jared Mauch wrote: On Sun, Oct 12, 2003 at 01:02:57PM +, Stephen J. Wilcox wrote: Can anyone from BellSouth comment? What if a few other major ISPs were to add a thousand or so deaggregated routes in a few weeks time? Would there be a greater impact? one word - irresponsible This clearly stands out to me as a reason to keep and use prefix filtering on peers to reduce the amount of junk in the routing tables. If bellsouth needs to leak more specifics for load balancing purposes, fine, just make sure those routes don't leave your upstreams networks and waste router memory for the rest of us that don't need to see it. - Jared (Note: The above numbers are based on data from cidr-report.org. Some other looking glasses were also checked to see if cidr-report.org's view of these AS's is consistent with the Internet as a whole. This appears to be the case, but corrections are welcome.) -Terry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Terry Baranski Sent: Sunday, October 05, 2003 3:01 PM To: 'James Cowie'; [EMAIL PROTECTED] Subject: RE: as6198 aggregation event James Cowie wrote: On Friday, we noted with some interest the appearance of more than six hundred deaggregated /24s into the global routing tables. More unusually, they're still in there this morning. AS6198 (BellSouth Miami) seems to have been patiently injecting them over the course of several hours, between about 04:00 GMT and 08:00 GMT on Friday morning (3 Oct 2003). If you look at the 09/19 and 09/26 CIDR Reports, BellSouth Atlanta (AS6197) did something similar during this time period -- they added about 350 deaggregated prefixes, most if not all /24's. Usually when we see deaggregations, they hit quickly and they disappear quickly; nice sharp vertical jumps in the table size. This event lasted for hours and, more importantly, the prefixes haven't come back out again, an unusual pattern for a single-origin change that effectively expanded global tables by half a percent. That AS6197's additions
Re: edge interface bits
On Fri, Oct 10, 2003 at 04:55:44PM +0300, Petri Helenius wrote: Does anyone know, either on the east coast US, London, Stockholm, Copenhagen, Amsterdam or Helsinki transit providers which would allow edge/handoff interface control to different traffic classes using BGP communities? (for example to announce DDoS destinations Null communities suporting organizations: GBLX, UUNET, NLAYER, et al Others who can also do null routing over bgp community, please come forward. One of my customers may be interested in doing business w/ you ;-) and/or sources with different community which would drop the precedence of those packets to a lower level and thus de-prioritize them and allow legitimate traffic to have better performance) I have not seen any QoS policy propagation over BGP (qppb i think is what they call it?) stuff in provider environment yet.. I dunno if qppb is even the right thing for this, but I think it is. But then again, considering most providers don't even support null community, this is like asking too much ;-) And qppb would be something new and it would put more strain on router as it has to rate limit stuff now.. -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN Pete
Re: BGP and OSPF
major snip (Method 1) One way to is to assume that R1 redistributes the route 1.1/16 into OSPF, which will then propagate it as a type 4 LSA. Then R0 and R4 can build a forwarding table (using OSPF) and set a forwarding entry to 1.1/16. This method is what is described in Huitema's book Routing in the Internet. Now I understand that this is not done in practice (I am right ?) since it forces OSPF to carry all the IP prefixes seen by BGP, which in that case might be all prefixes in the world. No. Don't.. Please. I've seen enough networks that break with IGP-BGP redists. (Method 2) An alternative is to have recursive table lookup in forwarding entries at all border routers (R1 to R4). R4 writes that the destination address 1.1/16 is to be sent to NEXT-HOP = 3.3.3.1. R4 learns this over I-BGP from R1. The data packet with destination address in 1.1/16 uses loose source routing inside AS559 and is sent to the link R1-RA. The job of OSPF is only to propagate how to route to all addresses in AS559 (including 3.3.3.1) and there is no redistribution of BGP into OSPF. Border routers need to update the forwarding tables using their RIB learnt from BGP. This is the way to do it. Recursive route lookup++ What you can even do is to reduce your IGP table entries: 1) Have all of your 'edge'/'border' routers set next-hop-self on their IBGP peering to core routers. This will eliminate the need for 'DMZ' or '/30 pointopoint (whatever u wanna call it)' routes to exist in IGP tables. Smaller IGP = Faster convergence = more stability = more SLA guarantee = more revenue :) 2) Have your edge/border routers become route reflector clients and the R0 or the routers sitting at the core would act as route reflectors. This way you don't have to keep adding up IBGP peers all over your network as you add more routers at your edge. Now source routing is obsolete in IPv4, does any one use it ? Not that I know of... At least not me. (Method 3) Same as method 2, but IP in IP encapsulation is used instead of loose source routing. Seems heavy weight for a high speed backbone. Yikes. (Method 4) Same as method 2, but Tag Switching (or MPLS) is used instead of loose source routing. Are we talking about IGP vs. EGP or are we talking about MPLS vs. other transport mechanisms? Can any one help me understand what is done in practice among Methods 1 to 4, or any other one that I missed ? Method 2. Please for the love of god, don't even try Method 1, that's quite bad. -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN
Qwest bgp communities
Hi, Anyone here know if Qwest operates a route server like GBLX, HE, ATT, that also shows AS209's communities? It would be useful for some bgp troubleshooting.. There is one peer in route-views.oregon-ix.net that shows 209 routes, but unfortunately, that particular peer strips off all 209's communities. I am trying to troubleshoot a problem where 209:70 set on a prefix doesn't seem to work/propagate, etc et al. Or does anyone know of any route-servers run by a Qwest customer/peer that receives communities? I know that http://stat.qwest.net has looking glass but it doesn't let you run any bgp commands; just ping and traceroute :-( If you can assist, please reply to me off-list. Thank you very much for your time, -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN
Re: DoS Attacks
rant style=moaning and useless context=naive I really don't give a ^H^H^H^H!H * !X *!X about what timeframe abuse departments operate. I just want more upstreams (or specifically my upstreams) to have a community that I can announce a /32 to null. /rant -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN On Wed, Oct 08, 2003 at 07:19:39PM -0400, Alan Spicer wrote: Due to the efficiency of our upstream provider's abuse department, opening efficiently at 8 am and closing just as efficiently at 5 pm (because we all know network abuse only occurs between 8 and 5), the ISP wasn't going to be of much help with an attack that started at 6:30pm localtime. Andrew D Kirch Security Admin - Summit Open Source Development Group http://www.sosdg.org * A lot of Abuse Departments are going to close at around 5pm, because the advanced staff that would know how to deal with such things goes home around that time. But most of them should have an escalation procedure, which means that there is someone(s) over the staff in the NOC or Call (Support) Center which can be called if necessary. You should insist or demand the issue be escalated if it warrants this. If they won't escalate it ask for the phone number of the supervisor... If they escalate it and you don't get a call back in 30-60 minutes ... call again (repeat until you get a call back). Be prepared to justify why you have had your issue escalated complete with emailable detailed information. Even if the guy that calls you back (semi-technical manager type) doesn't have the proper clue, chances are he has someone else on call that does. If they don't have this escalation capability ... (IMHO) get a different ISP. --- Alan Spicer ([EMAIL PROTECTED]) http://aspicer.homelinux.net/ Systems and Network Administration, and Telecommunications (954) 977-5245 The wonderful thing about the Internet is that you're connected to everyone else. The terrible thing about the Internet is that you're connected to everyone else. -- Vincent Cerf (Father of the Internet) Customer: The Internet is running too slow. Could you reboot it please? Customer: So that'll get me connected to the Internet, right? Tech Support: Yeah. Customer: And that's the latest version of the Internet, right? Tech Support: Uhh...uh...uh...yeah.
[nanog@Overkill.EnterZone.Net: Extensions to RFC1998 - WAS: Re: DoS Attacks]
Forwarding to NANOG on behalf of Mr. Fraizer. Please don't shoot the messenger for any arguable/discussions. -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN - Forwarded message from John Fraizer [EMAIL PROTECTED] - X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Date: Wed, 8 Oct 2003 21:58:26 -0400 (EDT) From: John Fraizer [EMAIL PROTECTED] To: Haesu [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Extensions to RFC1998 - WAS: Re: DoS Attacks In-Reply-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=-2.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) On Wed, 8 Oct 2003, Haesu wrote: H? What did I miss? When did RFC1998 get updated to include Null community? Feel free to let me know if they updated RFC on that lately.. b/c I havent checked it in a while. As far as I know, my upstreams are fully RFC1998 compliant and I use them well. -hc Note: please echo this to the list. I don't have post access. Ahem... Sue...Ahem... The RFC itself hasn't been updated to include a Null community but if you think about it, providing a NULL community is fully within the concept of allowing customers to influence routing policy with the use of community strings. For example: ! router bgp 65534 neighbor a.a.a.a remote-as 65530 neighbor a.a.a.a description Customer AS65530 neighbor a.a.a.a prefix-list AS-65530 in neighbor a.a.a.a route-map CUSTOMERS in ! ip prefix-list AS-65530 seq 5 permit x.x.x.x/y le 32 ! ip community-list standard POISON permit 65534:666 ! route-map CUSTOMERS permit 10 match community POISON set local-preference 500 set ip next-hop [ip address of your sink-hole] ! Of course, the rest of the route-map CUSTOMERS is going to need to do some sanity checks on the announcements you accept from the customers OTHER than blackhole requests. In our case, we pass them through a prefix-list match that includes: ip prefix-list CUSTOMERS seq 10 deny 0.0.0.0/0 ge 25 As you can see, we're doing a prefix-list check against the announcements that the customer sends us in the neighbor statement. Each customer gets their own prefix-list that covers the networks that we have LOA to accept from that customer. (Keeps boneheads from blackholing OTHER people!) The first stanza in the CUSTOMERS route-map checks for the POISON community. Any prefix that the customer sends us that includes this community will be routed to our sink-hole. The rest of the stanzas in the CUSTOMERS route-map look for other communities from the customer. One stanza looks to see if the customer is requesting us to pass their announcements of our address space on as de-aggregated announcements. If we don't see that community, they're aggregated. Other stanzas in the route-map are pretty cut and dry RFC1998. Our customers can do the following: Community Action - 13944:0 Don't announce to any peer 13944:1 Don't announce to PEERS 13944:2 Don't announce to TRANSIT 13944:3 Don't announce to CUSTOMERS 13944:20Announce specific from EnterZone aggregate for customers who are running on our IPs. 13944:90Set preference to 90 13944:100 Set preference to 100 13944:110 Set preference to 110 13944:120 Set preference to 120 13944:666 Poison a Route 13944:NNN0 don't announce to Peer NNN 13944:NNN1 prepend once towards Peer NNN 13944:NNN2 prepend twice towards Peer NNN 13944:NNN3 prepend thrice towards Peer NNN Any time I do any consulting on another network, I recommend that they at MINIMUM implement the Poisoned Route ability. It is not terribly difficult to do as you can see above. -- John Fraizer EnterZone, Inc (13944+$|13944+_14813+$|13944+_17266+$) PGP Key = 6C5903C4 Fingerprint = 2AA6 6614 1B5E EDD2 38AD C417 3E61 F975 6C59 03C4 - End forwarded message -
Re: DoS Attacks
First of all, have your tools ready so that whenever DoS pounds on you, you can immediately activate them and they will give you an overview of the DoS attack such as size of the attack, source/dest (random or one/two or spoofed?), et al. Then you need to contact your upstream first to hve them deal with it, and yes I understand, most SDSL providers do not like to cooperate. Considering it takes me 1 hour of buerocracy to get an ACL put up during a DoS to my current providers, getting an ACL activated by SDSL team is.psh utterly hopeless unless you have people connections :( If you can't afford T1/T3 type of circuits where you can at least call up your upstream (doesnt matter how long it takes them to put up the ACL, the point is, will they?), then I hate to say... I don't think there is much you can do :-( -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN On Wed, Oct 08, 2003 at 12:03:19AM -0400, Brian Bruns wrote: - Original Message - From: Mark Radabaugh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 11:56 PM Subject: Re: DoS Attacks I think I would follow two avenues next time - the direct approach with FSU (or wherever the traffic is coming from) as well as with your DSL provider. Your upstream should be able to assist in at least keeping the traffic off of your dedicated line. Whether your DSL provider has the resources to sink the traffic may be another matter -- but they are at least in a position to help you and (since you are paying them) have an interest in dealing with you. I hate to say this, but Ameritech/SBC is utterly useless in matters like this. I mean, at one point their redback was being nailed, and they didn't seem to care one bit. After 5pm, everyone with a clue seems to leave, and we are left with useless low level help desk techs. Our DSL service isn't bad - in fact it rarely goes down. The problem is that when we need their help with something out of our league, they are completely useless. Anyone know of a contact number for SBC/Ameritech that would be useful in a case like this? -- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.2mbit.com ICQ: 8077511
Re: VeriSign Capitulates
VeriSign said the claims are overblown. There is no data to indicate the core operation of the domain name system or the stability of the Internet has been adversely affected, VeriSign's Galvin said. LOL. VeriSign, woudl you like a copy of all the spams I got b/c your RevenueFinder (sitefinder) broke my spam filters? -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN watta bunch of goobers! scott On Fri, 3 Oct 2003, Tim Wilde wrote: : : http://www.washingtonpost.com/wp-dyn/articles/A40241-2003Oct3.html : : And they act like they're the victims. Amazing. : : Without so much as a hearing, ICANN today formally asked us to shut down : the Site Finder service, said VeriSign spokesman Tom Galvin. We will : accede to their request while we explore all of our options. : : How about a public outcry? Did you miss that part? You don't deserve a : hearing. : : Of course, they haven't removed the wildcard yet: : : dig is-it-gone-yet.com. @a.gtld-servers.net. +short : 64.94.110.11 : : -- : Tim Wilde : [EMAIL PROTECTED] : Systems Administrator : Dynamic DNS Network Services : http://www.dyndns.org/ :
Re: Does anyone think it was a good thing ? (was Re: VeriSign Capitulates
On Fri, Oct 03, 2003 at 04:23:29PM -0400, Mike Tancsa wrote: OK, so was ANYONE on NANOG happy with a) Verisign's site finder Unfair competition, more confusions, broke a lot of stuff, etc, etc , beneficial to nobody b) How they launched it Here... let's change the way DNS works.. That's right, overnight. -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN Speak up on or off list. ---Mike At 04:14 PM 03/10/2003, George Bakos wrote: On Fri, 3 Oct 2003 09:59:49 -1000 (HST) Scott Weeks [EMAIL PROTECTED] wrote: VeriSign also angered the close-knit group of engineers and scientists who are familiar with the technology underpinning the Internet. They say that Site Finder undermines the worldwide Domain Name System, causing e-mail systems, spam-blocking technology and other applications to malfunction. VeriSign said the claims are overblown. There is no data to indicate the core operation of the domain name system or the stability of the Internet has been adversely affected, VeriSign's Galvin said. watta bunch of goobers! Would those goobers be Versign, or the close-knit group of engineers and scientists? g scott
Re: ICMP Blocking Woes
rant Providers blocking all ICMP = ignorant I can't possibly stand any ISP's blocking _ALL_ ICMP (alas it is happening now, I already know 5 ISP's around my area who's doing this as I speak) for any reasons. If you want to *cough*cough*mitigate*/cough*/cough* impact of so-called BLASTER, please please please for the love of god, just block echo/echo replies. Not to mention blocking icmp will not help stop the propagation of the worm. /rant -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 174 Fax: (978)263-0033 | POC: HAESU-ARIN On Mon, Sep 29, 2003 at 09:43:14AM -0700, CA Windon wrote: Dear NANOG-ers, I work for an information security company that is dependant upon ICMP for network mapping purposes (read: traceroute). On or about August 18, we were told, our upstream provider began blocking ICMP packets at its border in the Chicago NAP in an effort to cut down on the propagation of 'MSBlast'. This has effected our ability to accurately map our customers networks. We've been in contact with an engineer in this provider's NOC who is either unable or unwilling to remove this ACL for our block of IPs. Currently, we've been given two options. (1) Deal with the effect of the ACL until 'MSBlast' traffic subsides, or (2) they are willing to reroute our traffic out of the Chicago NAP to a border router that, they claim, does not have the same ACL. The problem with option 2 is that they would force us to renumber. This is a problem for us, as it would impact our customers as well. What options can I take to my management that would cause the least impact to the services we provide while not causing undue work for our clients. Also, what other options could I suggest to my upstream provider? TIA, C. Windon __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Re: what happened to ARIN tonight ?
I am seeing the same. ARIN is completely off the air box02rsm-en01.twdx.net sh ip bgp 192.149.252.16 % Network not in table -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 174 Fax: (978)263-0033 | POC: HAESU-ARIN On Sun, Sep 28, 2003 at 09:45:41PM -0400, Mike Tancsa wrote: What AS path are you taking to get there ? From the oregon-ix, every peer listed there (57 of them) shows it flapping to various degrees BGP routing table entry for 192.149.252.0/24, version 1277910 Paths: (57 available, best #48, table Default-IP-Routing-Table) Not advertised to any peer 15290 701 7046, (suppressed due to dampening) 216.191.65.126 from 216.191.65.126 (216.191.65.126) Origin IGP, localpref 100, valid, external Dampinfo: penalty 3275, flapped 7 times in 00:18:34, reuse in 00:09:59 6939 3356 701 7046, (suppressed due to dampening) 216.218.252.152 from 216.218.252.152 (216.218.252.152) Origin IGP, localpref 100, valid, external Dampinfo: penalty 3182, flapped 7 times in 00:18:16, reuse in 00:09:29 15290 701 7046, (suppressed due to dampening) 216.191.65.118 from 216.191.65.118 (216.191.65.118) Origin IGP, localpref 100, valid, external Dampinfo: penalty 3260, flapped 7 times in 00:18:34, reuse in 00:09:59 6395 1239 701 7046 (history entry) 216.140.2.59 from 216.140.2.59 (216.140.2.59) Origin IGP, metric 5346, localpref 100, external Community: 6395:1 6395:1004 Dampinfo: penalty 7476, flapped 18 times in 00:18:19 7911 701 7046 (history entry) 64.200.199.4 from 64.200.199.4 (64.200.199.4) Origin IGP, localpref 100, external Community: 7911:999 7911:7303 Dampinfo: penalty 3507, flapped 8 times in 00:18:38 6079 3356 701 7046, (suppressed due to dampening) 207.172.6.227 from 207.172.6.227 (207.172.6.227) Origin IGP, metric 0, localpref 100, valid, external Dampinfo: penalty 2420, flapped 5 times in 00:18:04, reuse in 00:03:29 At 09:38 PM 28/09/2003, Brian Bruns wrote: works fine for me. -- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.2mbit.com ICQ: 8077511 - Original Message - From: Mike Tancsa [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, September 28, 2003 9:29 PM Subject: what happened to ARIN tonight ? The Oregon route server seems to indicate they are off the air. Not that I care to look at fee schedules tonight, but the whois server for in-addr.arpa is toast as a result :-( ---Mike BGP routing table entry for 192.149.252.0/24, version 1277910 Paths: (57 available, best #48, table Default-IP-Routing-Table) Flag: 0x8A0 Not advertised to any peer 15290 7018 701 7046 (history entry) 216.191.65.126 from 216.191.65.126 (216.191.65.126) Origin IGP, localpref 100, external Dampinfo: penalty 1407, flapped 2 times in 00:02:01 6939 7911 701 7046 (history entry) 216.218.252.152 from 216.218.252.152 (216.218.252.152) Origin IGP, localpref 100, external Dampinfo: penalty 1408, flapped 2 times in 00:01:42 15290 7018 701 7046 (history entry) 216.191.65.118 from 216.191.65.118 (216.191.65.118) Origin IGP, localpref 100, external Dampinfo: penalty 1407, flapped 2 times in 00:02:00 6395 1239 701 7046 (history entry) 216.140.2.59 from 216.140.2.59 (216.140.2.59) Origin IGP, metric 5657, localpref 100, external Community: 6395:1 6395:1007 Dampinfo: penalty 2796, flapped 4 times in 00:01:46 Mike Tancsa,tel +1 519 651 3400 Sentex Communications, [EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: what happened to ARIN tonight ?
Looks like they are back on the air route-views-v4.lab.occaid.org sh ip bgp 192.149.252.16 BGP routing table entry for 192.149.252.0/24 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 27552 209 701 7046 65.116.132.129 from 65.116.132.129 (65.116.132.129) Origin IGP, localpref 100, valid, external, best Last update: Sun Sep 28 22:31:14 2003 64513 64512 64646 30071 3557 701 7046 65.126.230.245 from 65.126.230.245 (65.126.230.145) Origin IGP, localpref 100, valid, external Last update: Sun Sep 28 22:34:53 2003 -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 174 Fax: (978)263-0033 | POC: HAESU-ARIN On Sun, Sep 28, 2003 at 10:26:00PM -0400, Robert Boyle wrote: At 10:07 PM 9/28/2003, you wrote: I am seeing the same. ARIN is completely off the air box02rsm-en01.twdx.net sh ip bgp 192.149.252.16 % Network not in table I see them via a UUNet announcement through Veroxity and Sprint transit, but I don't see it via any other peer or transit provider. Are they multi-homed? R core1-nwtnj#sho ip bgp 192.149.252.16 BGP routing table entry for 192.149.252.0/24, version 3225401 Paths: (2 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 14985 701 7046 216.182.0.65 (metric 311040) from 216.182.0.65 (216.182.0.65) Origin IGP, localpref 100, valid, internal, best 1239 701 7046 144.228.242.224 from 144.228.242.224 (144.228.242.224) Origin IGP, localpref 90, valid, external Dampinfo: penalty 706, flapped 4 times in 00:58:57 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: Inevitable Consequences--Verisign
I am not surprised at all. If VeriSign took their efforts and time to show us some purported recommendations to abide to their new service, they better at least deal with DoS pretty fast before more people get uptight. -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 174 Fax: (978)263-0033 | POC: HAESU-ARIN On Wed, Sep 24, 2003 at 11:54:59AM -0500, Declan McCullagh wrote: Repeated (though informal) testing over the last 90 minutes showed that at one point, about one-third of attempted HTTP connections to sitefinder took over one minute to complete or, in a few cases, failed entirely. Now only about one of every 5 or 10 connections is displaying that behavior. -Declan On Wed, Sep 24, 2003 at 05:22:49PM +0300, Petri Helenius wrote: Curt Akin wrote: This morning, more often than not, nonexistent domain name access via http is returning timeouts. Overload? DoS? It appears, for whatever reason, that Verisign's scheme is not impervious to the inevitable consequences of arrogant behavior. The service seems to have experienced about 30 minute downtime about an hour ago. On average, the redirect servers has responded in less than four seconds in the last 36 hours. This performance is far from what any commercial enterprise should provide. Performance seems to be worst from 9 UTC to 22 UTC, with best hours to access yourreallyreallynonexistentdomain.com are 1 to 6 UTC. Pete
Re: bind 9.2.3rc3 successful
I am using bind 9.2.2-p2 on our resolver name servers so far.. And I have no problems to report at this time, it's been running smooth so far; mail queues started clearing out nice and clean. -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 174 Fax: (978)263-0033 | POC: HAESU-ARIN On Tue, Sep 23, 2003 at 02:35:48AM -0400, William Allen Simpson wrote: Thought I'd mention that I helped setup BIND 9.2.3rc3 on a yellowdog linux powercomputing machine tonight. It worked. And the mail queues began clearing out. Just for an oddball success report. Are others having similar luck? What needs to be done to make this a standard feature set? Is somebody working on an RFC? -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: Verisign Responds
start quote All indications are that users, important members of the internet community we all serve, are benefiting from the improved web navigation offered by Site Finder end quote The Americans are comitting suicide! :: american bomb falls in the background :: -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 174 Fax: (978)263-0033 | POC: HAESU-ARIN On Mon, Sep 22, 2003 at 09:36:38PM -0400, Mike Tancsa wrote: Even better, This reminds me of the Iraqi Information minister and his lunatic counterfactual arguments All indications indeed! ---Mike At 09:23 PM 22/09/2003, Leo Bicknell wrote: http://www.icann.org/correspondence/lewis-to-twomey-21sep03.htm I quote: ] As to your call for us to suspend the service, I would respectfully ] suggest that it would be premature to decide on any course of action ] until we first have had an opportunity to collect and review the ] available data. One would think it would be equally premature to roll out the service without first asking the appropriate people for their opinion first, starting with ICANN. Looks like the lawsuits are going to be the ones to settle this dispute...anyone think there's a chance of ICANN pulling .COM and .NET from Verisign due to breach of contract? I think it's highly unlikely. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: ICANN asks VeriSign to pull redirect service
It's been about 2 days since ICANN requested Verisign to stop breaking. http://www.icann.org/announcements/advisory-19sep03.htm Recognizing the concerns about the wildcard service, ICANN has called upon VeriSign to voluntarily suspend the service until the various reviews now underway are completed. -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 174 Fax: (978)263-0033 | POC: HAESU-ARIN On Sun, Sep 21, 2003 at 10:42:37PM -0400, Eric Germann wrote: http://msnbc-cnet.com.com/2100-1024_3-5079768.html?part=msnbc-cnettag=alert form=feedsubj=cnetnews The agency that oversees Internet domain names has asked VeriSign to voluntarily suspend a new service that redirects Web surfers to its own site when they seek to access unassigned Web addresses, rather than return an error message. == Eric GermannCCTec [EMAIL PROTECTED] Van Wert OH 45891 http://www.cctec.comPh: 419 968 2640 Fax: 603 825 5893 The fact that there are actually ways of knowing and characterizing the extent of one?s ignorance, while still remaining ignorant, may ultimately be more interesting and useful to people than Yarkovsky -- Jon Giorgini of NASA?s Jet Propulsion Laboratory
Re: VeriSign responds to complaints via press release
omg. So VeriSign is requiring all network operations, or the whole internet to pretty much redo their network per their Recommendations to allow sitefinder? That is an aggravated assault. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Wed, Sep 17, 2003 at 07:40:56PM -0400, Jeff Wasilko wrote: - Forwarded message from Dave Farber [EMAIL PROTECTED] - If this was Microsoft issuing a statement like this we would really go through the roof. Since when in the Internet do we talk with technical people AFTER the fact and AFTER the disruption. In other words BULL. Can we sue them for email disruption? Dave Delivered-To: [EMAIL PROTECTED] Date: Wed, 17 Sep 2003 19:27:49 -0400 From: Wingfield, Nick [EMAIL PROTECTED] Subject: VeriSign update To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Dave, In case it's of interest to IP... Nick =WSJ: VeriSign Responds To Complaints About New Service Dow Jones News Service via Dow Jones By Nick Wingfield Of THE WALL STREET JOURNAL SAN FRANCISCO (Dow Jones)--VeriSign Inc. (VRSN), responding to an outpouring of complaints about a new service that exploits the typing errors users make when surfing the Web, said it plans to work with technologists to remedy disruptions the service has caused to some Internet applications like e-mail. At the same time, the VeriSign service triggered a huge increase in the amount of traffic flowing to the Mountain View, Calif., company's Web site, a portion of which may be the result of a hacker attack against the company, VeriSign said. (This story and related background material are available on the Journal's Web site, WSJ.com.) VeriSign on Monday introduced the service, dubbed Site Finder, which steers users who attempt to reach nonexistent Web addresses to a site operated by VeriSign. The company is able to take control of the traffic because it operates the master list, or registry, for all Internet addresses ending in .com and .net. VeriSign said it designed Site Finder as a navigational aid for Web users. It also receives revenue from the additional traffic through relationships with Overture Services Inc. (OVER) and Yahoo Inc.'s (YHOO) Inktomi, which guide users to Web sites. The new VeriSign service infuriated many network operators, though, who say it has disrupted the functioning of e-mail and other applications. Among the complaints about the VeriSign service is that it hurts the ability of Internet service providers to block spam sent from Internet addresses that don't exist - a common technique normally used to stem the flow of junk e-mail. Internet service providers and software groups have developed patches that prevent the VeriSign service from working on their networks. In a statement Tuesday, VeriSign said it would release technical information on its Web site that would help network operators adapt their software so they could block unwanted e-mail again. In the course of implementation, various users asked us to modify the service to accommodate anti-spam applications, the company said in the statement. Because VeriSign strongly supports appropriate technical measures designed to reduce unwanted spam, we are reaching out to users and the community to make appropriate adjustments to the service. We remain committed to ensuring that Site Finder improves Web navigation and the user experience, VeriSign added. Despite the controversy, VeriSign's efforts to nab control of typo-prone Internet users appears to be having a sizable impact on the volumes of users visiting its site. Traffic to the company's Web site on Tuesday skyrocketed to about 1.3 million visitors from an average of about 100,000 visitors on the previous four Tuesdays, according to measurement firm ComScore Networks Inc. Some of that may have been due to malicious - not typo - traffic. A VeriSign spokesman said the company experienced a denial of service attack on its Web site on Tuesday, in which hackers use computers to bombard Web sites with traffic in hopes of overloading them. The attack appeared to subside by Wednesday, the spokesman said. A ComScore spokesman said it's very unlikely that a denial of service attack on VeriSign had a significant impact on the ComScore traffic figures.
Re: Route failures to behosting.com
Also accessible no problem from Qwest and Nlayer. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Wed, Sep 17, 2003 at 09:35:54PM -0400, Henry Yen wrote: On Wed, Sep 17, 2003 at 09:29:57AM -0400, Brian Bruns wrote: Attempts to access behosting.com were successful from several different locations, which included ameritech and sprint. I'm not going to include traceroutes here (if you would like them, I can email them to you privately). What ISPs are you using to try and get to them? behosting.com/www.behosting.com (aka 216.121.96.160) also accessible without problem from sprint and uunet. - Original Message - From: Lou Katz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 9:23 PM Subject: Route failures to behosting.com I am unable to reach them via several different ISPs. It looks to my naive eyes like routes to them have vanished. Can anyone shed any light on this? -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York
Re: Route failures to behosting.com
Looks like whomever holds the name server 208.56.139.155 etc is not announcing that route. So now, can we end this thread now? I think enough people replied already. [23:49:[EMAIL PROTECTED]:~]$ traceroute 208.56.139.155 traceroute to 208.56.139.155 (208.56.139.155), 30 hops max, 40 byte packets 1 box02ce3-ed01-v305.twdx.net (65.124.16.1) 0.485 ms 0.545 ms 0.513 ms 2 box02jp5-cr01-g0-0.twdx.net (65.116.132.33) 0.19 ms 0.29 ms 0.145 ms 3 box02c75-br01-p3-0.twdx.net (65.116.132.1) 0.996 ms 1.005 ms 0.942 ms 4 box02c75-br01-p3-0.twdx.net (65.116.132.1) 0.916 ms !N * * 5 box02c75-br01-p3-0.twdx.net (65.116.132.1) 0.918 ms !N * 0.813 ms !N box02zbr-en02 sh ip bgp 208.56.139.155 % Network not in table [EMAIL PROTECTED]:~]$ whois 208.56.139.155 OrgName:Alabanza, Inc. OrgID: ALAB Address:10 E. Baltimore St. Suite 1300 City: Baltimore StateProv: MD PostalCode: 21244 Country:US [23:52:[EMAIL PROTECTED]:~]$ whois -h whois.radb.net 208.56.139.155 % No entries found for the selected source(s). -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Wed, Sep 17, 2003 at 10:09:45PM -0400, Roy Bentley wrote: At 09:35 PM 9/17/2003 -0400, Henry Yen wrote: On Wed, Sep 17, 2003 at 09:29:57AM -0400, Brian Bruns wrote: Attempts to access behosting.com were successful from several different locations, which included ameritech and sprint. I'm not going to include traceroutes here (if you would like them, I can email them to you privately). What ISPs are you using to try and get to them? behosting.com/www.behosting.com (aka 216.121.96.160) also accessible without problem from sprint and uunet. No problems from qwest or cw. - Original Message - From: Lou Katz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 9:23 PM Subject: Route failures to behosting.com I am unable to reach them via several different ISPs. It looks to my naive eyes like routes to them have vanished. Can anyone shed any light on this? -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York
Re: What *are* they smoking?
Just noticed this: verisign is redirecting queries for dorkslayers.com's old RBL, even though dorkslayers.com is a registered and active domain. It just has no name servers. I must ask the subject again. What in the name of censored *are* they smoking? Who exclusively gave them the right to own the 'net and decide which domain points to where? Completely unacceptable. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Tue, Sep 16, 2003 at 10:37:35AM -0500, Marius Strom wrote: So it seems they're doing this to billing-active domains as well. On Tue, 16 Sep 2003, Sabri Berisha wrote: On Tue, Sep 16, 2003 at 12:56:57AM +0200, Niels Bakker wrote: A wildcard A record in the net TLD. $ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 $ host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com Simply inject a route for 64.94.110.11/32 in your favorite IGP, route it to a box and alias it on eth0. Put up a 404 not found and let Verisign rot in hell until such time as they regain their consiousness. -- Sabri Berisha I route, therefore you are Wij doen niet aan default gateways - anonymous engineer bij een DSL klant. -- /- Marius Strom | Always carry a short length of fibre-optic cable. Professional Geek | If you get lost, then you can drop it on the System/Network Admin | ground, wait 10 minutes, and ask the backhoe http://www.marius.org/ | operator how to get back to civilization. \-| Alan Frame |--
Re: blocking AS30060
I am already filtering _30060_ and I currently see no problems. Of course... seeing that email bounces may pile up, I should start routing that /24 to a box on our network pretty quick... -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Tue, Sep 16, 2003 at 01:04:18PM -0400, William Allen Simpson wrote: Mark Vevers wrote: On Tuesday 16 Sep 2003 6:41 am, John Brown wrote: we've burned a AS for this, ICK Yup - and 2 /24's #show ip bgp regexp _30060$ Network Next HopMetric LocPrf Weight Path *i12.158.80.0/24 xxx.xxx.xxx.xxx 305100 0 1239 7018 26134 30060 ? *i64.94.110.0/24 xxx.xxx.xxx.xxx 305100 0 1239 7018 26134 30060 ? based on the ASNAME, its seems a nice little route-map /dev/null will be real easy. As long as they keep prefixs used in this really dumb idea for this idea. If you have a full table (i.e. no default) just drop inbound routes with a AS path _30060$ Are there any adverse side effects, that anybody can think of? -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: Delivery Status Notification (Failure)
I'm seeing the same... -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Tue, Sep 16, 2003 at 03:51:00PM -0700, Michel Py wrote: Mee too. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Damm Sent: Tuesday, September 16, 2003 3:17 PM To: [EMAIL PROTECTED] Subject: FW: Delivery Status Notification (Failure) Is anyone else seeing a sort of mail loop issue at ml.com? I'm getting odd bounces to list postings as well as a few duplicates of list mail. -Mike --- Michael Damm, MIS Department, Irwin Research Development V: 509.457.5080 x298 F: 509.577.0301 E: [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 2:46 PM To: [EMAIL PROTECTED] Subject: Delivery Status Notification (Failure) This is an automatically generated Delivery Status Notification. Unable to deliver message to the following recipients, because the message was forwarded more than the maximum allowed times. This could indicate a mail loop. [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Change to .com/.net behavior
You mean you have been studying a way for more people to buy domain through you. I also am modifying BIND to convert your wildcard #$%^^% to NXDOMAIN. Between the domains that I have with you and all the problems we've had with it each time you 'change' your web interface, I've already made my decision to avoid VeriSign/NetworkSolutions for rest of my life. Before I figure out this BIND thing, for now.. box02jp5-cr01.twdx.net# set routing-options static route 64.94.110.11/32 discard; -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Mon, Sep 15, 2003 at 07:24:29PM -0400, Matt Larson wrote: Today VeriSign is adding a wildcard A record to the .com and .net zones. The wildcard record in the .net zone was activated from 10:45AM EDT to 13:30PM EDT. The wildcard record in the .com zone is being added now. We have prepared a white paper describing VeriSign's wildcard implementation, which is available here: http://www.verisign.com/resources/gd/sitefinder/implementation.pdf By way of background, over the course of last year, VeriSign has been engaged in various aspects of web navigation work and study. These activities were prompted by analysis of the IAB's recommendations regarding IDN navigation and discussions within the Council of European National Top-Level Domain Registries (CENTR) prompted by DNS wildcard testing in the .biz and .us top-level domains. Understanding that some registries have already implemented wildcards and that others may in the future, we believe that it would be helpful to have a set of guidelines for registries and would like to make them publicly available for that purpose. Accordingly, we drafted a white paper describing guidelines for the use of DNS wildcards in top-level domain zones. This document, which may be of interest to the NANOG community, is available here: http://www.verisign.com/resources/gd/sitefinder/bestpractices.pdf Matt -- Matt Larson [EMAIL PROTECTED] VeriSign Naming and Directory Services
Re: zebra server redundancy
Depends on your OS. zebra will get realtime notification on Linux with netlink, and on *bsd with routing socket. And then there are times when netlink communication dies and causes a bgp prefix to get 'stuck' as kernel route :( hahah Never had problems with socket/ioctl though. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 Looks like an expect script telneting to the ospfd and removing the network statement from the router ospf section is the best way, or is there some more elegant mechanism people use? Thanks Vtysh is somewhat simpler than telnetting. Alex Pilosov| DSL, Colocation, Hosting Services President | [EMAIL PROTECTED](800) 710-7031 Pilosoft, Inc. | http://www.pilosoft.com
Re: FW: Qwest Dial Access Network Labor Day Week Schedule
/me counts number of sales people on NANOG list.. Oh gee, time for those reseller people to expect more emails with sales inquiries. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Tue, Aug 26, 2003 at 02:25:01PM -0700, Scott Granados wrote: And now look, all the plaintext e-mail addresses are posted to a mailing list. Which is archived on the web! Nice!
Re: Lazy Engineers and Viable Excuses
Hey, You ARE correct. If everyone employs IRR and put explicit filters everywhere, it'd be the perfect world.. I don't consider this as lazy. I'd rather consider it as efficiency. Managing a filter list on one or a few route-servers rather than an AS with hundred edge routers is so much time saving and less humanerror-prone. IRR is great, and it should be used to maximum extent as possible. I've seen people filtering accordingly to IRR properly, and also seen people creating their own manageable applications that work beatifully on *nix boxes. Announcing filtering list over BGP inside an AS would be efficient management to an extent however... -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Mon, Aug 25, 2003 at 04:22:24PM -0600, Danny McPherson wrote: Again... If folks were to implement explicit prefix filtering *everywhere* it wouldn't be necessary to filter only bogons and other miscellany explicitly. Something of this sort would only lower the lazy bar (is it possible?) for the clueless and/or lazy (those which Rob's list currently accommodates, which is better than nothing, BUT.. -- no offense Rob, I'm pretty sure our beliefs are aligned here :-). If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or... Then we can worry about IRR infrastructure hardening and accuracy and derive explicit data plane filters from the output, as well as other tangible benefits. Is it really that hard? -danny
Re: Lazy Engineers and Viable Excuses
That is true, although distributed route-servers that serve specific region may be easier dealing with emergencies (i.e. local POP(s) having emergency situation etc) -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Tue, Aug 26, 2003 at 12:36:09PM -0400, Edward Lewis wrote: At 19:08 -0400 8/25/03, Haesu wrote: Managing a filter list on one or a few route-servers rather than an AS with hundred edge routers is so much time saving and less humanerror-prone. But balance that with keep the path from filter list to route-server short too - because if you need to adjust a filter list in response to a network (or utility) emergency, you want to make sure the data is available. (Based on experience with a project researching DDOS response. We relied on certificates distributed by a DNS server. When the flood was released, accessing DNS became impossible - the security system drowned in the flood.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena.
Re: Lazy Engineers and Viable Excuses
Somewhere in the growth curve along which a customer increases in both size and credibility, I think there is a case for migrating them from prefix filtering to as-path filtering with a prefix limit. While not preventing any possibility of an illegitimate announcement, it does prevent a 7007 type incident along with scalability. a.k.a. the need for some type of automated filtering that scales -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867
exchangecolo 200paul san francisco issues?
Is anyone aware of any problems/issues with 200 paul ave SFO? -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867
bgp route-map
Hi all, Wondering if anyone would know whether such feature in IOS exists or not... Most of the time, people use route-maps on bgp neighbors or peer-groups to set an attribute,etc on a prefix that is being announced OUTbound or INbound. However: On prefixes being announced to me INBOUND, is there a feature to set in route-map so that it checks whether the advertised prefix is already existing in local RIB? Like for example, I am one of the users who receive bogon advertisements from Rob's route-server. Now, when I receive prefixes either from my upstream AS or my customers doing bgp with me, I can setup a route-map on the neighbor so that it compares the prefix being announced by neighborAS with existing Rob's bogon prefix in the RIB with bogon route-server community 65333:888. If the prefix being announced gets a match with existing prefix with 65333:888 already in the router, the route-map would cause a DENY. Thus, making Rob's bogon announcement from his route-server, a bogon route filtering list for me to use on my customers/peers.. If you are not understanding what I am saying, feel free to yell at me to clear up.. This would make it much easier to create dynamic bgp-based route filtering list in my opinion... I am not here to discuss the feasibility of whether doing or inventing this dynamic method of filtering bgp routes; I am rather asking this question to see if anyone is doing something similar to this as it may be useful. Thanks! -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867
Re: bgp route-map
Yes, I've tried that too.. But what I am thinking of doing is, using a route-map/bgp-announcement based version of building 'prefix-list' or 'distribute-list' to decide whether to accept route or not.. But as you said, I don't think that is possible heh.. Thanks! -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Mon, Aug 25, 2003 at 02:57:57PM -0400, [EMAIL PROTECTED] wrote: I don't think what you are suggesting is directly possible, although I can think of something that accomplishes the same thing, and only requires extra configuration on the peering session with the route server. For prefixes recieved from the bogon route server, apply a route map that will (1) send traffic to a Null0 bit sink and (2) set the local preference for these routes to a value suitably large so that the same prefixes learned from other peers never get used. -w On Mon, 25 Aug 2003 14:39:59 -0400, Haesu wrote Hi all, Wondering if anyone would know whether such feature in IOS exists or not... Most of the time, people use route-maps on bgp neighbors or peer- groups to set an attribute,etc on a prefix that is being announced OUTbound or INbound. However: On prefixes being announced to me INBOUND, is there a feature to set in route-map so that it checks whether the advertised prefix is already existing in local RIB? Like for example, I am one of the users who receive bogon advertisements from Rob's route-server. Now, when I receive prefixes either from my upstream AS or my customers doing bgp with me, I can setup a route-map on the neighbor so that it compares the prefix being announced by neighborAS with existing Rob's bogon prefix in the RIB with bogon route-server community 65333:888. If the prefix being announced gets a match with existing prefix with 65333:888 already in the router, the route-map would cause a DENY. Thus, making Rob's bogon announcement from his route-server, a bogon route filtering list for me to use on my customers/peers.. If you are not understanding what I am saying, feel free to yell at me to clear up.. This would make it much easier to create dynamic bgp-based route filtering list in my opinion... I am not here to discuss the feasibility of whether doing or inventing this dynamic method of filtering bgp routes; I am rather asking this question to see if anyone is doing something similar to this as it may be useful. Thanks! -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867
Re: bgp route-map
Of course; since there isn't a feature, let's propose another idea: an option to enable le 24 or le 32/whatever to cover specific announcements. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Mon, Aug 25, 2003 at 03:30:01PM -0400, Matt Levine wrote: On Monday, August 25, 2003, at 3:00 PM, Haesu wrote: Yes, I've tried that too.. But what I am thinking of doing is, using a route-map/bgp-announcement based version of building 'prefix-list' or 'distribute-list' to decide whether to accept route or not.. But as you said, I don't think that is possible heh.. Except that what you are proposing would allow your customer to announce 2 /16's just fine from within one of rob's bogon /8's, as the 2 /16's wouldn't be in your rib. Thanks! -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Mon, Aug 25, 2003 at 02:57:57PM -0400, [EMAIL PROTECTED] wrote: I don't think what you are suggesting is directly possible, although I can think of something that accomplishes the same thing, and only requires extra configuration on the peering session with the route server. For prefixes recieved from the bogon route server, apply a route map that will (1) send traffic to a Null0 bit sink and (2) set the local preference for these routes to a value suitably large so that the same prefixes learned from other peers never get used. -w On Mon, 25 Aug 2003 14:39:59 -0400, Haesu wrote Hi all, Wondering if anyone would know whether such feature in IOS exists or not... Most of the time, people use route-maps on bgp neighbors or peer- groups to set an attribute,etc on a prefix that is being announced OUTbound or INbound. However: On prefixes being announced to me INBOUND, is there a feature to set in route-map so that it checks whether the advertised prefix is already existing in local RIB? Like for example, I am one of the users who receive bogon advertisements from Rob's route-server. Now, when I receive prefixes either from my upstream AS or my customers doing bgp with me, I can setup a route-map on the neighbor so that it compares the prefix being announced by neighborAS with existing Rob's bogon prefix in the RIB with bogon route-server community 65333:888. If the prefix being announced gets a match with existing prefix with 65333:888 already in the router, the route-map would cause a DENY. Thus, making Rob's bogon announcement from his route-server, a bogon route filtering list for me to use on my customers/peers.. If you are not understanding what I am saying, feel free to yell at me to clear up.. This would make it much easier to create dynamic bgp-based route filtering list in my opinion... I am not here to discuss the feasibility of whether doing or inventing this dynamic method of filtering bgp routes; I am rather asking this question to see if anyone is doing something similar to this as it may be useful. Thanks! -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 -- Matt Levine [EMAIL PROTECTED] The Trouble with doing anything right the first time is that nobody appreciates how difficult it was. -BIX
Re: Route Programming (was Re: bgp route-map)
Hello,
The reason for me to come up with this idea/question was so that IRR information
can be used on a seperate box acting as a Prefix-list server, which would be
basically a route server that distributes prefixes that should be filtered on
inbound announcements..
It would be great for integration with RPSL perhaps; RtConfig already does it,
but need something that's distributed/dynamic/automated; publishing filtering
information over BGP sounds interesting to me..
-hc
--
Sincerely,
Haesu C.
TowardEX Technologies, Inc.
WWW: http://www.towardex.com
E-mail: [EMAIL PROTECTED]
Cell: (978) 394-2867
On Mon, Aug 25, 2003 at 04:02:22PM -0400, Leo Bicknell wrote:
This reminds me of something I've wanted to bring up to the community
for a long time. I'd like to see a route programming language that
gets implemented in a multi-vendor way. No, I'm not talking about like
RPSL, but rather, let me give some examples:
1) Pull out session details via variables:
route-statement foo {
if ($route has community(1234:$session{'asn'})) {
set_asprepend($route, 1234 1234)
}
}
2) Check for the route in other routing tables:
route-statement bar {
if ($route in ospf) {
set_localpref($route, 10)
}
if ($route in bgp $route has communty(1234:666))
drop($route)
}
set_localpref($route, 100)
}
3) Scan other route tables:
route-statement baz {
if ($route supernet-in bgp) {
drop($route);
}
}
4) Other weird stuff:
route-statement hack {
if ($route = 1.2.3.0/24) {
announce_route(1.2.3.10/32, 192.168.1.1)
}
}
Basically all the data on the box would be made available via global
variables (eg, session IP, session ASN, bgp version, etc), and all
dynamic data would have interfaces (eg scan other routing tables,
acl's, etc). You'd write a function which would get passed a
route object, and act on it. Functions could further pass that
route on calling other functions (allowing you to create common
policy).
Sadly, while I can think of many cool things you could do, I know
little about how to really design a languge. I also have no idea
how bad other people want this, how hard it would be to get vendors
to implement, etc. Feel free to add your support, or call me a
crackpot.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: Force Majeure
Yes in a way that whole part of a continent fell apart for 24+ hours. But definately kudos to all those providers and colos who stayed up with a generator system that actually works than having marketing value :) -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Mon, Aug 25, 2003 at 04:46:37PM -0400, Brian Cashman wrote: In the opinion of folks on this list, did the recent power failure in the northeast (started 8/14 and lasted several days in some places) constitute a force majeure event? Thanks, Brian Cashman Merit
Re: Hijacked email
Yup, seeing same. Spoofing to quite a few of our addresses and sending worms to everyone.. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Wed, Aug 20, 2003 at 07:36:23AM -0500, [EMAIL PROTECTED] wrote: Anyone seeing hijacked email addresses with this Sobig-F worm? I did some research and I know I didn't send anything to Investec Bank of Johannesburg,ZA. On top of that, I definitely did not send a worm. Thoughts? Jack -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 20, 2003 4:11 AM To: Parks, Jack W Cc: [EMAIL PROTECTED] Subject: MailMarshal has detected a Virus in your message Investec content scanning has stopped the following message: Message: BB002e9963.0001.mml From:[EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Thank you! Because it believes the message contains a virus. The virus scanning software used was: Sophos AntiVirus (SAVI2 Interface) Virus name: W32/Sobig-F Please clean the file and resend it. Rule: Inbound Messages : Block Virus
Re: MPLS ICMP Extensions
It would be cool to update the NANOG Traceroute with MPLS extensions. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Mon, Aug 18, 2003 at 12:26:34AM +0200, Jesper Skriver wrote: On Thu, Aug 14, 2003 at 01:40:01PM -0400, Leo Bicknell wrote: I wanted to get some other opinions on some new features that have appeared in recent code from the popular vendors. It appears there is a new draft, a copy of which can be found at http://www.watersprings.org/links/mlr/id/draft-ietf-mpls-icmp-01.txt that allows MPLS enabled boxes to return some additonal information in a traceroute packet. That's all well and good, and I can see how that might be amazingly useful to someone running an MPLS network, however, it seems to expose data much further than the local network. Here's a random example from a traceroute I recently performed (on a Juniper): traceroute wcg.net [snip] 11 hrndva1wcx3-oc48.wcg.net (64.200.95.117) 91.935 ms 102.652 ms 92.960 ms MPLS Label=13198 CoS=0 TTL=1 S=1 12 hrndva1wcx2-oc48.wcg.net (64.200.95.77) 92.593 ms 92.785 ms 93.119 ms MPLS Label=12676 CoS=0 TTL=1 S=1 13 nycmny2wcx2-oc48.wcg.net (64.200.240.45) 93.273 ms 93.121 ms 93.067 ms MPLS Label=12632 CoS=0 TTL=1 S=1 14 nycmny2wcx3-oc48.wcg.net (64.200.87.78) 104.755 ms 91.949 ms 92.169 ms MPLS Label=12672 CoS=0 TTL=1 S=1 15 chcgil1wcx3-oc48.wcg.net (64.200.240.37) 92.021 ms 91.737 ms 91.684 ms MPLS Label=12592 CoS=0 TTL=1 S=1 16 chcgil1wcx3-pos5-0.wcg.net (64.200.210.114) 175.907 ms 278.144 ms 203.763 ms MPLS Label=12695 CoS=0 TTL=1 S=1 17 chcgil1wcx2-oc48.wcg.net (64.200.103.73) 93.286 ms 93.230 ms 93.593 ms MPLS Label=13506 CoS=0 TTL=1 S=1 18 stlsmo3wcf1-atm.wcg.net (64.200.210.158) 92.780 ms 92.344 ms 92.596 ms If anyone is interested I have a patch for LBL traceroute to display this information too. Download ftp://ftp.ee.lbl.gov/traceroute.tar.gz, patch in http://e.wheel.dk/~jesper/traceroute.diff, and you will have [EMAIL PROTECTED]:/home/jesper traceroute wcg.net traceroute to wcg.net (64.200.241.26), 30 hops max, 40 byte packets 1 217.79.98.25.adsl.griffin.net.uk (217.79.98.25) 0.895 ms 0.836 ms 0.751 ms 2 217.79.96.209 (217.79.96.209) 21.557 ms 18.431 ms 19.075 ms 3 f0-0.core1.tchx.lon.uk.griffin.com (217.79.96.1) 19.768 ms 19.094 ms 19.285 ms 4 lndnuk1icx1.wcg.net (195.66.224.105) 18.824 ms 20.206 ms 19.800 ms 5 nycmny2wcx2-pos15-3.wcg.net (64.200.87.61) 126.360 ms 127.665 ms 127.702 ms MPLS Label=12632 CoS=0 TTL=1 S=1 6 nycmny2wcx3-oc48.wcg.net (64.200.87.74) 125.205 ms 126.923 ms 125.993 ms MPLS Label=12672 CoS=0 TTL=1 S=1 7 chcgil1wcx3-oc48.wcg.net (64.200.240.37) 126.425 ms 126.212 ms 126.220 ms MPLS Label=12592 CoS=0 TTL=1 S=1 8 brvwil1wcxa-pos9-0.wcg.net (64.200.103.193) 126.920 ms 127.660 ms 127.462 ms MPLS Label=12604 CoS=0 TTL=1 S=1 9 64.200.236.14 (64.200.236.14) 129.886 ms 125.499 ms 126.715 ms MPLS Label=13506 CoS=0 TTL=1 S=1 10 stlsmo3wcf1-atm.wcg.net (64.200.210.158) 126.080 ms 124.598 ms 125.235 ms 11 stl-clust01.wcg.net (64.200.241.26) 126.723 ms 124.544 ms 124.736 ms /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.
Re: Weird attack or traffic (Was Re: The impending DDoS storm)
It kinda looks like the virus or whatever it is, is spoofing source IP. Now I am seeing lots of spoofed packets trying to egress out of our network. We are filtering egress traffic so obviously its being dropped at edge of course... Just cleared access-list counter about a minute or so ago and this: box02c75-br01#sh ip acces 180 | in deny deny ip any any log-input (17268883 matches) box02c75-br01# -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Fri, Aug 15, 2003 at 01:04:38AM -0400, Haesu wrote: Is anyone else seeing backscatters on your network about windowsupdate.com's IP? Someone who transits through 65.123.21.137 router is sending out lots of packets to 204.79.188.11 (windowsupdate.com) in which its not currently advertised to internet as we speak. Not to mention, packets seem to be source-spoofed to 65.124.16.0/21 (our block), causing backscatter from 65.123.21.137 to our network... Any ideas/or anyone seeing similar effect? Is someone who is administrative to Qwest Communications WASH01-WAN-65-123-21 (NET-65-123-21-0-1) aware of this may be? It looks like a Qwest customer CPE router to me but I dunno.. See below for traffic snapshot.. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 k00:50:22.807370 65.123.21.137 65.124.23.125: icmp: net 204.79.188.11 unreachable 00:50:22.891672 65.123.21.137 65.124.22.48: icmp: net 204.79.188.11 unreachable 00:50:22.979997 65.123.21.137 65.124.22.98: icmp: net 204.79.188.11 unreachable 00:50:23.047340 65.123.21.137 65.124.22.21: icmp: net 204.79.188.11 unreachable 00:50:23.133616 65.123.21.137 65.124.22.72: icmp: net 204.79.188.11 unreachable 00:50:23.520405 65.123.21.137 65.124.23.107: icmp: net 204.79.188.11 unreachable 00:50:23.745844 65.123.21.137 65.124.22.3: icmp: net 204.79.188.11 unreachable 00:50:23.829309 65.123.21.137 65.124.22.54: icmp: net 204.79.188.11 unreachable 00:50:24.493650 65.123.21.137 65.124.23.113: icmp: net 204.79.188.11 unreachable 00:50:24.530074 65.123.21.137 65.124.23.35: icmp: net 204.79.188.11 unreachable 00:50:24.618082 65.123.21.137 65.124.23.86: icmp: net 204.79.188.11 unreachable 00:47:50.611529 65.123.21.137 65.124.18.100: icmp: net 204.79.188.11 unreachable 00:47:50.649962 65.123.21.137 65.124.17.151: icmp: net 204.79.188.11 unreachable 00:47:50.711865 65.123.21.137 65.124.17.124: icmp: net 204.79.188.11 unreachable 00:47:50.756960 65.123.21.137 65.124.17.47: icmp: net 204.79.188.11 unreachable 00:47:50.826367 65.123.21.137 65.124.20.8: icmp: net 204.79.188.11 unreachable 00:47:52.355967 65.123.21.137 65.124.22.126: icmp: net 204.79.188.11 unreachable 00:47:52.587141 65.123.21.137 65.124.20.46: icmp: net 204.79.188.11 unreachable 00:47:53.865460 65.123.21.137 65.124.22.87: icmp: net 204.79.188.11 unreachable 00:48:05.250757 65.123.21.137 65.124.16.1: icmp: net 204.79.188.11 unreachable 00:48:05.713640 65.123.21.137 65.124.17.86: icmp: net 204.79.188.11 unreachable 00:48:05.841169 65.123.21.137 65.124.17.60: icmp: net 204.79.188.11 unreachable 00:48:06.013042 65.123.21.137 65.124.16.33: icmp: net 204.79.188.11 unreachable 00:48:06.549540 65.123.21.137 65.124.17.41: icmp: net 204.79.188.11 unreachable 00:48:06.803847 65.123.21.137 65.124.17.92: icmp: net 204.79.188.11 unreachable 00:48:06.981930 65.123.21.137 65.124.17.15: icmp: net 204.79.188.11 unreachable 00:48:07.26 65.123.21.137 65.124.18.100: icmp: net 204.79.188.11 unreachable 00:48:07.343120 65.123.21.137 65.124.18.74: icmp: net 204.79.188.11 unreachable 00:48:07.486285 65.123.21.137 65.124.17.47: icmp: net 204.79.188.11 unreachable 00:48:07.569901 65.123.21.137 65.124.20.8: icmp: net 204.79.188.11 unreachable 00:48:08.117407 65.123.21.137 65.124.18.106: icmp: net 204.79.188.11 unreachable 00:48:08.356732 65.123.21.137 65.124.20.41: icmp: net 204.79.188.11 unreachable 00:48:08.637485 65.123.21.137 65.124.20.14: icmp: net 204.79.188.11 unreachable 00:48:08.944750 65.123.21.137 65.124.22.126: icmp: net 204.79.188.11 unreachable 00:48:08.946623 65.123.21.137 65.124.22.49: icmp: net 204.79.188.11 unreachable
Re: East Coast outage?
And if we extrapolate that lesson to IP networks it implies that any medium to large sized organization should do their own BGP peering and multihome to 3 or more upstream network providers. On the other hand, if you understand why electrical networks shed load and develop their cascading failures, you might see some parallels between load and the propagation of BGP announcements which are worrying. Makes remember the days of AS7007... AS numbers are very much like power grids.. Perhaps we should start working on a hierarchical routing system in which the concept of a global routing table cannot develop. Perhaps announcements and withdraws should have a TTL so that they never propogate very far from their source AS? And how would global uniqueness and reachability of a route be done? Dampening to some extent quite helps a lot.. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 --Michael Dillon
Weird attack or traffic (Was Re: The impending DDoS storm)
Is anyone else seeing backscatters on your network about windowsupdate.com's IP? Someone who transits through 65.123.21.137 router is sending out lots of packets to 204.79.188.11 (windowsupdate.com) in which its not currently advertised to internet as we speak. Not to mention, packets seem to be source-spoofed to 65.124.16.0/21 (our block), causing backscatter from 65.123.21.137 to our network... Any ideas/or anyone seeing similar effect? Is someone who is administrative to Qwest Communications WASH01-WAN-65-123-21 (NET-65-123-21-0-1) aware of this may be? It looks like a Qwest customer CPE router to me but I dunno.. See below for traffic snapshot.. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 k00:50:22.807370 65.123.21.137 65.124.23.125: icmp: net 204.79.188.11 unreachable 00:50:22.891672 65.123.21.137 65.124.22.48: icmp: net 204.79.188.11 unreachable 00:50:22.979997 65.123.21.137 65.124.22.98: icmp: net 204.79.188.11 unreachable 00:50:23.047340 65.123.21.137 65.124.22.21: icmp: net 204.79.188.11 unreachable 00:50:23.133616 65.123.21.137 65.124.22.72: icmp: net 204.79.188.11 unreachable 00:50:23.520405 65.123.21.137 65.124.23.107: icmp: net 204.79.188.11 unreachable 00:50:23.745844 65.123.21.137 65.124.22.3: icmp: net 204.79.188.11 unreachable 00:50:23.829309 65.123.21.137 65.124.22.54: icmp: net 204.79.188.11 unreachable 00:50:24.493650 65.123.21.137 65.124.23.113: icmp: net 204.79.188.11 unreachable 00:50:24.530074 65.123.21.137 65.124.23.35: icmp: net 204.79.188.11 unreachable 00:50:24.618082 65.123.21.137 65.124.23.86: icmp: net 204.79.188.11 unreachable 00:47:50.611529 65.123.21.137 65.124.18.100: icmp: net 204.79.188.11 unreachable 00:47:50.649962 65.123.21.137 65.124.17.151: icmp: net 204.79.188.11 unreachable 00:47:50.711865 65.123.21.137 65.124.17.124: icmp: net 204.79.188.11 unreachable 00:47:50.756960 65.123.21.137 65.124.17.47: icmp: net 204.79.188.11 unreachable 00:47:50.826367 65.123.21.137 65.124.20.8: icmp: net 204.79.188.11 unreachable 00:47:52.355967 65.123.21.137 65.124.22.126: icmp: net 204.79.188.11 unreachable 00:47:52.587141 65.123.21.137 65.124.20.46: icmp: net 204.79.188.11 unreachable 00:47:53.865460 65.123.21.137 65.124.22.87: icmp: net 204.79.188.11 unreachable 00:48:05.250757 65.123.21.137 65.124.16.1: icmp: net 204.79.188.11 unreachable 00:48:05.713640 65.123.21.137 65.124.17.86: icmp: net 204.79.188.11 unreachable 00:48:05.841169 65.123.21.137 65.124.17.60: icmp: net 204.79.188.11 unreachable 00:48:06.013042 65.123.21.137 65.124.16.33: icmp: net 204.79.188.11 unreachable 00:48:06.549540 65.123.21.137 65.124.17.41: icmp: net 204.79.188.11 unreachable 00:48:06.803847 65.123.21.137 65.124.17.92: icmp: net 204.79.188.11 unreachable 00:48:06.981930 65.123.21.137 65.124.17.15: icmp: net 204.79.188.11 unreachable 00:48:07.26 65.123.21.137 65.124.18.100: icmp: net 204.79.188.11 unreachable 00:48:07.343120 65.123.21.137 65.124.18.74: icmp: net 204.79.188.11 unreachable 00:48:07.486285 65.123.21.137 65.124.17.47: icmp: net 204.79.188.11 unreachable 00:48:07.569901 65.123.21.137 65.124.20.8: icmp: net 204.79.188.11 unreachable 00:48:08.117407 65.123.21.137 65.124.18.106: icmp: net 204.79.188.11 unreachable 00:48:08.356732 65.123.21.137 65.124.20.41: icmp: net 204.79.188.11 unreachable 00:48:08.637485 65.123.21.137 65.124.20.14: icmp: net 204.79.188.11 unreachable 00:48:08.944750 65.123.21.137 65.124.22.126: icmp: net 204.79.188.11 unreachable 00:48:08.946623 65.123.21.137 65.124.22.49: icmp: net 204.79.188.11 unreachable
Re: rfc1918 ignorant (fwd)
Hmm this could affect routing protocols which use the primary address.. I haven't tried doing that with igp protocols.. But with BGP, it works does manage to bind itself to the working address. (Or if you are sourcing update to loopback, that would be fine too) Right but this one benefit doesnt make right the wrongs! I guess one thing you could do (if you really wanted to implement hacks) is to use the rfc1918 space on your routers and then nat them to a global ip at your borders.. achieves all your goals anyhow (not that i'd recommend it ;) The thing is... some people want to hide the IP of the interface that faces their transit on the border router, as most /30 demarcation subnet is assigned from the transit. And since they would run either bgp or static route between the transit and their border router, it shouldn't break routing.. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867
Re: rfc1918 ignorant
Interesting. Did any of you note last month or so that Sprint US came out with a notice that they are no longer going to router /30 ptp subnets unless the customer specifically asks for it? Could that be why 10.x.y.z is showing up here? No. :) 12 sla-bbtech-2-0.sprintlink.net (203.222.37.106) 114.207 ms 114.295 ms 114.340 ms In this example, bbtech (the one shown in example traceroute below) uses 1918 as transit space on their network. Looks cute though with so many 1918 hops (heh, not that i recommend it!) -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 Sprint??? you out there? -Original Message- From: Haesu [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 12:53 PM To: Vinny Abello; [EMAIL PROTECTED] Subject: Re: rfc1918 ignorant Heh, check this out. traceroute to 219.168.64.121 (219.168.64.121), 64 hops max, 44 byte packets 1 216.93.161.1 (216.93.161.1) 0.532 ms 0.518 ms 0.405 ms 2 66.7.159.33 (66.7.159.33) 0.796 ms 0.667 ms 0.543 ms 3 gigabitethernet8-0-513.ipcolo1.SanFrancisco1.Level3.net (63.211.150.225) 0.541 ms 0.478 ms 0.834 ms 4 gigabitethernet4-1.core1.SanFrancisco1.Level3.net (209.244.14.197) 0.547 ms 0.486 ms 0.530 ms 5 so-4-0-0.mp2.SanFrancisco1.Level3.net (209.247.10.233) 0.741 ms 0.729 ms 0.731 ms 6 so-2-0-0.mp2.SanJose1.Level3.net (64.159.0.218) 1.677 ms 1.510 ms 1.549 ms 7 unknown.Level3.net (64.159.2.102) 1.864 ms 1.851 ms 1.875 ms 8 sl-bb20-sj.sprintlink.net (209.245.146.142) 3.110 ms 3.831 ms 3.321 ms 9 sl-bb22-sj-14-0.sprintlink.net (144.232.3.165) 7.127 ms 3.290 ms 3.331 ms 10 sl-bb20-tok-13-1.sprintlink.net (144.232.20.188) 113.739 ms 113.731 ms 113.874 ms 11 sl-gw10-tok-15-0.sprintlink.net (203.222.36.42) 114.400 ms 114.051 ms 114.067 ms 12 sla-bbtech-2-0.sprintlink.net (203.222.37.106) 114.207 ms 114.295 ms 114.340 ms 13 10.9.17.10 (10.9.17.10) 101.595 ms 101.580 ms 101.771 ms 14 10.0.13.2 (10.0.13.2) 119.025 ms 118.765 ms 118.833 ms 15 10.4.10.2 (10.4.10.2) 134.809 ms 134.536 ms 134.668 ms 16 10.3.10.130 (10.3.10.130) 134.526 ms 135.004 ms 135.701 ms 17 10.10.0.25 (10.10.0.25) 135.291 ms 134.899 ms 135.293 ms 18 10.10.0.3 (10.10.0.3) 122.515 ms 122.210 ms 121.779 ms 19 10.10.0.11 (10.10.0.11) 135.643 ms 135.144 ms 135.438 ms 20 10.10.3.4 (10.10.3.4) 121.721 ms 121.872 ms 122.603 ms 21 10.10.3.36 (10.10.3.36) 135.069 ms 134.956 ms 135.330 ms 22 10.10.3.107 (10.10.3.107) 121.906 ms 122.708 ms 122.076 ms 23 YahooBB219168064121.bbtec.net (219.168.64.121) 147.137 ms 146.039 ms 147.453 ms -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Wed, Jul 23, 2003 at 09:07:51AM -0400, Vinny Abello wrote: Heh... Check out Comcast. A large part of their network uses rfc1918: 216 ms 9 ms10 ms 10.110.168.1 315 ms10 ms11 ms 172.30.116.17 410 ms13 ms10 ms 172.30.116.50 514 ms12 ms26 ms 172.30.112.123 610 ms14 ms23 ms 172.30.110.105 At 08:48 AM 7/23/2003, you wrote: Is there a site to report networks/isps that still leak rfc1918 space? By leaking I not only mean don't filter, but actually _use_ in their network? If someone is keeping a list, feel free to add ServerBeach.com. All traceroutes to servers housed there, pass by 10.10.10.3. traceroute to www.serverbeach.com ... 20. 64-132-228-70.gen.twtelecom.net 21. 10.10.10.3 22. 66.139.72.12 Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN There are 10 kinds of people in the world. Those who understand binary and those that don't.
Re: rfc1918 ignorant
Heh, check this out. traceroute to 219.168.64.121 (219.168.64.121), 64 hops max, 44 byte packets 1 216.93.161.1 (216.93.161.1) 0.532 ms 0.518 ms 0.405 ms 2 66.7.159.33 (66.7.159.33) 0.796 ms 0.667 ms 0.543 ms 3 gigabitethernet8-0-513.ipcolo1.SanFrancisco1.Level3.net (63.211.150.225) 0.541 ms 0.478 ms 0.834 ms 4 gigabitethernet4-1.core1.SanFrancisco1.Level3.net (209.244.14.197) 0.547 ms 0.486 ms 0.530 ms 5 so-4-0-0.mp2.SanFrancisco1.Level3.net (209.247.10.233) 0.741 ms 0.729 ms 0.731 ms 6 so-2-0-0.mp2.SanJose1.Level3.net (64.159.0.218) 1.677 ms 1.510 ms 1.549 ms 7 unknown.Level3.net (64.159.2.102) 1.864 ms 1.851 ms 1.875 ms 8 sl-bb20-sj.sprintlink.net (209.245.146.142) 3.110 ms 3.831 ms 3.321 ms 9 sl-bb22-sj-14-0.sprintlink.net (144.232.3.165) 7.127 ms 3.290 ms 3.331 ms 10 sl-bb20-tok-13-1.sprintlink.net (144.232.20.188) 113.739 ms 113.731 ms 113.874 ms 11 sl-gw10-tok-15-0.sprintlink.net (203.222.36.42) 114.400 ms 114.051 ms 114.067 ms 12 sla-bbtech-2-0.sprintlink.net (203.222.37.106) 114.207 ms 114.295 ms 114.340 ms 13 10.9.17.10 (10.9.17.10) 101.595 ms 101.580 ms 101.771 ms 14 10.0.13.2 (10.0.13.2) 119.025 ms 118.765 ms 118.833 ms 15 10.4.10.2 (10.4.10.2) 134.809 ms 134.536 ms 134.668 ms 16 10.3.10.130 (10.3.10.130) 134.526 ms 135.004 ms 135.701 ms 17 10.10.0.25 (10.10.0.25) 135.291 ms 134.899 ms 135.293 ms 18 10.10.0.3 (10.10.0.3) 122.515 ms 122.210 ms 121.779 ms 19 10.10.0.11 (10.10.0.11) 135.643 ms 135.144 ms 135.438 ms 20 10.10.3.4 (10.10.3.4) 121.721 ms 121.872 ms 122.603 ms 21 10.10.3.36 (10.10.3.36) 135.069 ms 134.956 ms 135.330 ms 22 10.10.3.107 (10.10.3.107) 121.906 ms 122.708 ms 122.076 ms 23 YahooBB219168064121.bbtec.net (219.168.64.121) 147.137 ms 146.039 ms 147.453 ms -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Wed, Jul 23, 2003 at 09:07:51AM -0400, Vinny Abello wrote: Heh... Check out Comcast. A large part of their network uses rfc1918: 216 ms 9 ms10 ms 10.110.168.1 315 ms10 ms11 ms 172.30.116.17 410 ms13 ms10 ms 172.30.116.50 514 ms12 ms26 ms 172.30.112.123 610 ms14 ms23 ms 172.30.110.105 At 08:48 AM 7/23/2003, you wrote: Is there a site to report networks/isps that still leak rfc1918 space? By leaking I not only mean don't filter, but actually _use_ in their network? If someone is keeping a list, feel free to add ServerBeach.com. All traceroutes to servers housed there, pass by 10.10.10.3. traceroute to www.serverbeach.com ... 20. 64-132-228-70.gen.twtelecom.net 21. 10.10.10.3 22. 66.139.72.12 Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN There are 10 kinds of people in the world. Those who understand binary and those that don't.
Re: rfc1918 ignorant (fwd)
Well, if uBR showing RFC1918 address out on the traceroute is an issue, why not just reverse the way its configured? Put RFC1918 as secondary, and put the routable addr as primary. Either way, it should work w/o issues, right? I know quite a few people who purposely put a non-routable IP (whether it be 1918 or RIR-registered block) as primary on their interface, and use routable IP as secondary. Their reason for doing this is to somewhat hide their router's real interface IP from showing up in traceroute.. Well, it wouldn't completely 'hide' it, but to a certain level of degree, it probably does... -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Wed, Jul 23, 2003 at 07:21:25PM -0400, Jeff Wasilko wrote: On Wed, Jul 23, 2003 at 06:03:13PM -0400, Daniel Senie wrote: At 02:11 PM 7/23/2003, Dave Temkin wrote: 2003 7:07 AM:] Comcast and many others seem to blithely ignore this for convenience sake. (It's not like they need a huge amount of space to give private addresses to these links.) ARIN required cable operators to use RFC 1918 space for the management agents of the bridge cable modems that have been rolled out to the millions of residential cable modem customers. Doing so obviously requires a 1918 address on the cable router, but Cisco's implementation requires that address to be the primary interface address. There is also a publicly routable secondary which in fact is the gateway address to the customer, but isn't the address returned in a traceroute. Cisco has by far the lead in market share of the first gen Docsis cable modem router market so any trace to a cable modem customer is going to show this. When MediaOne (remember them?) deployed the cable modems here (LanCity stuff, originally), traceroutes did NOT show the 10/8 address from the router at the head end. ATT bought MediaOne, and now we've got Comcast. The service quality has stayed low, and the price has jumped quite a bit, and somewhere along the line a change happened and the 10/8 address of the router did start showing up. Now it's possible the router in the head end got changed and that was the cause. I really don't know. That's exactly what happened. The Lancity equipment were bridges, so you never saw them in traceroutes. The head-end bridges were aggregated into switches which were connected to routers. The Cisco uBR is a router, so you see the cable interface (which is typically rfc1918 space) showing up in traceroutes from the CPE out. Note that you don't see it on traceroutes towards the CPE since you see the 'internet facing' interface on the uBR. -j
Re: Why can't I default Originate?
After you applied default-originate to peer-group, have you done soft-clear of your bgp session? It usually takes a little while for changes in config to propagate, unless you force an update using soft clear... -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Tue, Jul 08, 2003 at 12:43:35PM -0700, Vandy Hamidi wrote: Platform: Cisco 7206VXR SW: Version 12.2(15)T2 router#sh run | b bgp router bgp 65011 no synchronization bgp log-neighbor-changes bgp confederation identifier 12345 bgp confederation peers 65001 65021 bgp deterministic-med bgp dampening network 1.2.3.0 mask 255.255.255.0 neighbor Confed-Peer-Group peer-group neighbor Confed-Peer-Group update-source FastEthernet1/1 neighbor Confed-Peer-Group next-hop-self neighbor Confed-Peer-Group version 4 neighbor Confed-Peer-Group soft-reconfiguration inbound neighbor Confed-Peer-Group filter-list 2 in neighbor Confed-Peer-Group filter-list 1 out neighbor 10.1.2.75 remote-as 65001 neighbor 10.1.2.75 peer-group Confed-Peer-Group neighbor 10.1.2.75 password 7 05211F2C105211F2C1666B neighbor 10.1.2.76 remote-as 65001 neighbor 10.1.2.76 peer-group Confed-Peer-Group neighbor 10.1.2.76 password 7 05211F2C105211F2C1666B no auto-summary router#conf t Enter configuration commands, one per line. End with CNTL/Z. router(config)#router bgp 65011 router(config-router)#neighbor 10.1.2.75 default-originate % Invalid command for a peer-group member router(config-router)# According to Cisco: All members of a peer group must share identical outbound announcement policies (such as distribute-list, filter-list, and route-map), except for default-originate, which is handled on a per-peer basis even for peer group members. I've also tried to apply to the peer group. The command is accepted, but no default origination of 0/0 is advertised to the peer(s). Thanks in advanced for any help, -=Vandy=-
Re: Why can't I default Originate?
Well, the idea of peer-group is to.. as what the name sugests 'group' the peers into a single and simple configuration.. Default route origination to a peer although may be specific to a neighbor like in your situation, is still a configuration for peering neighbor; hence making it possible to be grouped into peer-group commands. But.. whether or not default-originate goes in seperate peer config or peer-group config I guess is debatable. In application for my network, I find default-originate feature under peer-group useful; as I originate default route to some aggregation switches in route-reflector client peer group. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Tue, Jul 08, 2003 at 02:09:30PM -0700, Vandy Hamidi wrote: Thanks HC, Two things. I was told this was not a topic for this list. Sorry about that. Since I've already posted, I think I should post what the problem was. Problem=I'm stupid. I wasn't looking in the right place for what I was advertising. I ran: router#sh ip bgp nei 10.99.200.75 adv BGP table version is 43, local router ID is 10.1.80.44 Status codes: s suppressed, d damped, h history, * valid, best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Originating default network 0.0.0.0 Network Next HopMetric LocPrf Weight Path * 1.2.3.0/24 1.2.3.3 0 32768 i router# I was looking for the network, but not the line that stated: Originating default network 0.0.0.0 So it was advertising and I've verified it on the remote peers (which I should have done first!). Still doesn't answer why CISCO says you apply default orig to the peer, not the peer group (which we've proven is backwards). It shouldn't be this way since you may want to use the peer group as a template for multiple customers, but they may not all want 0/0 sent to them. ALSO I didn't need to have 0/0 in my local routing table nor did I need to add the BGP command Synchronization. According to CISCO (which is actually accurate), it will originate default UNCONDITIONALLY, which it does. I'm still concerned about applying the command to the peer vs. the peer group issue. Sorry about having posted this to Nanog, I'll filter my future questions more carefully. Thanks for everyone who answered! -=Vandy=- -Original Message- From: Haesu [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 2:04 PM To: [EMAIL PROTECTED] Subject: Re: Why can't I default Originate? After you applied default-originate to peer-group, have you done soft-clear of your bgp session? It usually takes a little while for changes in config to propagate, unless you force an update using soft clear... -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Tue, Jul 08, 2003 at 12:43:35PM -0700, Vandy Hamidi wrote: Platform: Cisco 7206VXR SW: Version 12.2(15)T2 router#sh run | b bgp router bgp 65011 no synchronization bgp log-neighbor-changes bgp confederation identifier 12345 bgp confederation peers 65001 65021 bgp deterministic-med bgp dampening network 1.2.3.0 mask 255.255.255.0 neighbor Confed-Peer-Group peer-group neighbor Confed-Peer-Group update-source FastEthernet1/1 neighbor Confed-Peer-Group next-hop-self neighbor Confed-Peer-Group version 4 neighbor Confed-Peer-Group soft-reconfiguration inbound neighbor Confed-Peer-Group filter-list 2 in neighbor Confed-Peer-Group filter-list 1 out neighbor 10.1.2.75 remote-as 65001 neighbor 10.1.2.75 peer-group Confed-Peer-Group neighbor 10.1.2.75 password 7 05211F2C105211F2C1666B neighbor 10.1.2.76 remote-as 65001 neighbor 10.1.2.76 peer-group Confed-Peer-Group neighbor 10.1.2.76 password 7 05211F2C105211F2C1666B no auto-summary router#conf t Enter configuration commands, one per line. End with CNTL/Z. router(config)#router bgp 65011 router(config-router)#neighbor 10.1.2.75 default-originate % Invalid command for a peer-group member router(config-router)# According to Cisco: All members of a peer group must share identical outbound announcement policies (such as distribute-list, filter-list, and route-map), except for default-originate, which is handled on a per-peer basis even for peer group members. I've also tried to apply to the peer group. The command is accepted, but no default origination of 0/0 is advertised to the peer(s). Thanks in advanced for any help, -=Vandy=-
Re: The Cidr Report
/19 AS5750 FLEXNET-HAWAII FlexNet Inc. 206.167.57.0/24 AS376 RISQ-AS Reseau Interordinateurs Scientique Quebecois (RISQ) 206.191.64.0/18 AS15290 ATTCA-15290 ATT Canada Telecom Services Company 206.251.69.0/24 AS27429 TIL Telesat International Ltd. 207.47.39.0/24 AS816 UUNET-AS4 UUNET Technologies, Inc. 207.92.0.0/14AS2551 ICG ICG NetAhead, Inc. 207.162.192.0/19 AS4589 EASYNET Easynet Group Plc 207.231.96.0/19 AS11194 NUNETPA NuNet Inc 208.65.232.0/23 AS701 ALTERNET-AS UUNET Technologies, Inc. 208.81.187.0/24 AS19194 JOVITA Sentris Network LLC 208.104.103.0/24 AS1239 SPRINTLINK Sprint 209.104.198.0/24 AS6137 SISNA SISNA, Inc. 209.104.199.0/24 AS6137 SISNA SISNA, Inc. 209.104.218.0/24 AS6137 SISNA SISNA, Inc. 209.104.219.0/24 AS6137 SISNA SISNA, Inc. 209.104.252.0/22 AS12030 PACIFIC-ONLINE-PON Pacific Online Services 209.108.0.0/14 AS2551 ICG ICG NetAhead, Inc. 209.151.128.0/19 AS816 UUNET-AS4 UUNET Technologies, Inc. 209.160.73.0/24 AS13415 LUMIX Lumix Communications, Inc. 209.160.209.0/24 AS13415 LUMIX Lumix Communications, Inc. 209.169.219.0/24 AS189 GENUITY-AS189 Genuity 209.169.223.0/24 AS189 GENUITY-AS189 Genuity 209.172.0.0/18 AS7770 TRITON Triton Technologies, Inc. 209.213.32.0/19 AS10629 INTERPAC Inter-Pacific Network Services 209.213.50.0/24 AS10629 INTERPAC Inter-Pacific Network Services 209.213.51.0/24 AS10629 INTERPAC Inter-Pacific Network Services 209.213.55.0/24 AS10629 INTERPAC Inter-Pacific Network Services 209.213.56.0/24 AS10629 INTERPAC Inter-Pacific Network Services 209.213.160.0/19 AS4355 ERMS-EARTHLNK EARTHLINK, INC 209.222.137.0/24 AS27429 TIL Telesat International Ltd. 209.240.96.0/19 AS10815 KCNET KCnet, Inc. 209.251.0.0/19 AS11036 SISCOM SISCOM, Inc 209.251.64.0/19 AS10266 NETWAY-AS MDC, Inc. 210.4.20.0/22AS10095 AS10095 Segmentation Fault 210.4.60.0/24AS10095 AS10095 Segmentation Fault 210.4.61.0/24AS10095 AS10095 Segmentation Fault 211.27.156.0/24 AS9768 PUBNET1-AS KT 216.18.224.0/21 AS11458 IMBRIS IMBRIS, INC. 216.18.224.0/22 AS11458 IMBRIS IMBRIS, INC. 216.18.228.0/22 AS11458 IMBRIS IMBRIS, INC. 216.47.32.0/19 AS11304 SPLUS Solutions Plus Inc. 216.96.128.0/18 AS7018 ATT-INTERNET4 ATT WorldNet Services 216.115.178.0/24 AS11676 ACSBPS Affiliated Computing Services Business ProcessSolutions 216.115.179.0/24 AS11676 ACSBPS Affiliated Computing Services Business ProcessSolutions 216.115.182.0/24 AS11676 ACSBPS Affiliated Computing Services Business ProcessSolutions 216.115.183.0/24 AS11676 ACSBPS Affiliated Computing Services Business ProcessSolutions 216.115.184.0/23 AS11676 ACSBPS Affiliated Computing Services Business ProcessSolutions 216.115.186.0/23 AS11676 ACSBPS Affiliated Computing Services Business ProcessSolutions 216.115.186.0/24 AS11676 ACSBPS Affiliated Computing Services Business ProcessSolutions 216.115.189.0/24 AS11676 ACSBPS Affiliated Computing Services Business ProcessSolutions 216.115.190.0/24 AS11676 ACSBPS Affiliated Computing Services Business ProcessSolutions 216.115.191.0/24 AS11676 ACSBPS Affiliated Computing Services Business ProcessSolutions 216.153.0.0/17 AS6203 ISDN-NET ISDN-Net Inc. 216.211.177.0/24 AS14473 KNET KNet, Inc. 216.226.108.0/22 AS3602 SPRINT-CA-AS Sprint Canada Inc. Please see http://www.cidr-report.org for the full report Copies of this report are mailed to: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867
Re: Best Practices for Loopback addressing (Core routers VPN CPE)
However, considering that these loopbacks are only used for routing protocols (OSPF,BGP, LDP) and for network management (SNMP, telnet, ...) and that these addresses don't need to visible from public Internet (not seen in traceroute, not seen on Internet BGP announces ...) I am considering to use private RFC1918 for a new Backbone deployment. Or, you could use a seperate class C or whatever fits yoru backbone for loopbacks and router interfaces.. Just don't advertise that block. That way you use non-rfc1918 on the backbone, and yet outside people cannot get to it since you dont advertise it to the world... It's just me but i am against using rfc1918 on any part of a backbone. -hc N.B. : Assumption is that e-BGP sessions with Internet peers are done on public interface IP, not on loopback IP. Is there some specific case I am missing where public loopback IP is required, and therefore private adressing would break something (maybe some Carrier-to-Carrier scenario ?) . I also plan to use RFC1918 addresses for Internet CPE routers loopbacks. 2) Loopback on CPE routers of the MPLS VPN customers. For this case, the issue is to assign the adresses in a global range for all the CPE of all the VPN customers. In fact, all these loopback will need to be part of the Network Management VPN for supervision needs. Using RFC 1918 addresses might create trouble as there is a very high chance that the VPN customers are already using 1918 addresses, this might generate addresses conflicts. Addresses unicity among all the customers is required due to the Network Management VPN common to all the customers. Using public address guarantee unicity, but will create issues with public registries, considering that these addresses are used for internal needs. I am considering to use the 198.18.0.0/15 defined in RFC 2544 and listed in RFC 3330 as reserved for lab testing. I suppose that no VPN customer uses this prefix for its internal IP addressing, and as these addresses don't need to be announced on Internet. Do you suggest to use an other prefix than 198.18.0.0/15 for this purpose ? If you consider your adressing policy as touchy topic in terms of security, don't hesitate to reply in private ... Regards, -- Sincerely, Haesu C. TowardEX Technologies, Inc WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867
Re: Re 7/8 - was Re: 69/8 revisited
Seems like 7/8 was allocated to dept. of defense for quite a bit of time.. OrgName:DoD Network Information Center OrgID: DNIC Address:7990 Science Applications Ct Address:M/S CV 50 City: Vienna StateProv: VA PostalCode: 22183-7000 Country:US NetRange: 7.0.0.0 - 7.255.255.255 CIDR: 7.0.0.0/8 NetName:DISANET7 NetHandle: NET-7-0-0-0-1 Parent: NetType:Direct Allocation Comment:Defense Information Systems Agency Comment:DISA /D3 Comment:11440 Isaac Newton Square Comment:Reston, VA 22090-5087 US RegDate:1997-11-24 Updated:1998-09-26 TechHandle: MIL-HSTMST-ARIN TechName: Network DoD, Network TechPhone: +1-703-676-1051 TechEmail: [EMAIL PROTECTED] OrgTechHandle: MIL-HSTMST-ARIN OrgTechName: Network DoD, Network OrgTechPhone: +1-703-676-1051 OrgTechEmail: [EMAIL PROTECTED] On Fri, 28 Mar 2003, John Palmer wrote: Speaking of that, has 7/8 been allocated? Doesn't show it on IANA's list but I saw several routes come in (7.1/16 comes to mind) a few days ago. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 28, 2003 12:36 Subject: 69/8 revisited I've setup a little web site with the results of my ping sweep to attempt to locate as many networks as possible with outdated bogon filters. http://69box.atlantic.net/ If you can't reach that, fix your network...or use the alternative non-69/8 hostname http://not69box.atlantic.net/ Number of IP's currently known to have 69/8 filter issues: 683 Number of /24 networks's currently known to have 69/8 filter issues: 511 Check out the site and see if you recognize any of the IPs. You can test/remove IPs if they've become reachable, or test/add IPs if they have 69/8 filter issues. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Using Policy Routing to stop DoS attacks
I dunno how you want to implement this; but as far as I know, the way most people generally do policy routing on cisco thru routemap is they define the source IP's via access-list... Does that make a huge difference than regular access lists? I dunno... I've kinda tested it in the lab with two 7206's and CPU load seems to be about the same when done with regular access-list and done with policy routing.. But, I don't have the true real data to back up my claims.. -hc On Tue, 25 Mar 2003, Christian Liendo wrote: Looking for advice. I am sorry if this was discussed before, but I cannot seem to find this. I want to use source routing as a way to stop a DoS rather than use access-lists. In other words, lets say I know the source IP (range of IPs) of an attack and they do not change. If the destination stays the same I can easily null route the destination, but what if the destination constantly changes. So I have to work based on the source IP. Depending on the router and the code, if I implement an access-list then the CPU utilization shoots through the roof. What I would like to try and do is use source routing to route that traffic to null. I figured it would be easier on the router than an access-list. Has anyone else tried this successfully on ciscos and junipers? Is it easier on the CPU than access-lists? Is there a link I cannot find on cisco or google? Thanks Christian Liendo
Re: Using Policy Routing to stop DoS attacks
uRPF will certainly save a bit of CPU cycles than access-lists or policy routing.. it would be intertesting to know any kind of 'common practice' ways people use to fool the router so that it will think such offensive source IP's are hitting uRPF. i am not really sure what kind of traffic we are talking about, but if its around 100Mbits/sec or so bandwidth, TurboACL should do it just fine (around ~20% or lower CPU usage on a 7206VXR with NPE-G1) -hc On Tue, 25 Mar 2003, John Kristoff wrote: On Tue, 25 Mar 2003 09:06:01 -0500 Christian Liendo [EMAIL PROTECTED] wrote: I am sorry if this was discussed before, but I cannot seem to find this. I want to use source routing as a way to stop a DoS rather than use access-lists. If you fooled the router into thinking that the reverse path for the source is on another another interface and then used strict unicast RPF checking, that may accomplish what you want without using ACLs. I don't know what impact it would have on your CPU however, you'll have to investigate or provide more details. Note, depending on the platform and configuration, filters/ACLs may have an insignficant impact on the CPU. If they don't, don't forget to complain to your vendor. :-) John
Re: Using Policy Routing to stop DoS attacks
i am not really sure what kind of traffic we are talking about, but if its around 100Mbits/sec or so bandwidth, TurboACL should do it just fine (around ~20% or lower CPU usage on a 7206VXR with NPE-G1) most likely the pps would kill the 5500 long before the bps :( especially if you want to route/acl it. yea you're right.. for that 100Mbits/sec bps i mentioned, the pps at that rate was around 20,000 pps inbound as well as 18,000 pps outbound. -hc -hc On Tue, 25 Mar 2003, John Kristoff wrote: On Tue, 25 Mar 2003 09:06:01 -0500 Christian Liendo [EMAIL PROTECTED] wrote: I am sorry if this was discussed before, but I cannot seem to find this. I want to use source routing as a way to stop a DoS rather than use access-lists. If you fooled the router into thinking that the reverse path for the source is on another another interface and then used strict unicast RPF checking, that may accomplish what you want without using ACLs. I don't know what impact it would have on your CPU however, you'll have to investigate or provide more details. Note, depending on the platform and configuration, filters/ACLs may have an insignficant impact on the CPU. If they don't, don't forget to complain to your vendor. :-) John
Re: cw to att? issue?
www.traceroute.org should have some but that site hasn't been updated in ages.. These are *some* that I know including oregon: route-views.oregon-ix.net route-views2.oregon-ix.net route-server.gt.ca route-server.ip.att.net route-server.cw.net route-server.bbnplanet.net hope it helps.. -hc On Wed, 12 Mar 2003, Scott Granados wrote: Is there a good plac for a listing of the publically available route-servers? I only knew of the oregon one. Thanks - Original Message - From: Richard A Steenbergen [EMAIL PROTECTED] To: Scott Granados [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 5:35 PM Subject: Re: cw to att? issue? On Wed, Mar 12, 2003 at 02:19:58PM -0800, Scott Granados wrote: It actually looked like it was farther in the att network, after cw's peer the next hop after cw's peer. I just tried the trace again and it seems better. Cw seems to be handing off to att at a different point in santaclara now not sanfrancisco which seemed to help. Again though it looked like att was the issue because cw looked fine up tntil one hop after cw ended. route-server.ip.att.net When in doubt, try looking at the reverse path. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RE: 69/8...this sucks -- Centralizing filtering..
Since most service providers should be thinking about a sink hole network for security auditing (and backscatter), why not have ONE place where you advertise all unreachable, or better yet -- a default (ie everything NOT learned through BGP peers), and just forward the packets to a bit bucket.. Which is better than an access list since, now we are forwarding packets instead of sending them to a CPU to increase router load. I don't think ARIN can help the situation. ISPs just need to remove the access lists from each router in the network and centralize them. I totally agree with you. However, as always, centralized systems, while ease management and scalability, everything becomes a trust issue and a single point of failure or source of problems... May be, this could be a subscription based type of service, something like RADB, where everyone subscribes into a central filtering list that is managed by a seperate organization? I really like the Rob's bogon route-server setup. -hc Regards, mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 -Original Message- From: E.B. Dreger [mailto:[EMAIL PROTECTED] Sent: March 10, 2003 10:17 AM To: [EMAIL PROTECTED] Subject: Re: 69/8...this sucks Date: Mon, 10 Mar 2003 09:46:33 + From: Michael.Dillon I have suggested that ARIN should set up an LDAP server to publish the delegation of all their IP address space updated Not bad, but will the lazy ISPs set up an LDAP server to track changes they aren't tracking now? Will those with erroneous filters magically change simply because of LDAP? I still contend the answer is is a boot to the head that screams to them, Update your freaking filters! Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked.
RE: 69/8...this sucks -- Centralizing filtering..
Perhaps I should have been more clear on what I was saying.. Sorry about that.. What I really meant by single pt. of failure was... problems of losing the filtering list if the central system is down... Granted, this would not cause any network issues.. -hc On Mon, 10 Mar 2003, Mark Segal wrote: -Original Message- From: Haesu [mailto:[EMAIL PROTECTED] I totally agree with you. However, as always, centralized systems, while ease management and scalability, everything becomes a trust issue and a single point of failure or source of problems... Single point of failure? Not sure I agree with you.. What happens if your sink hole disapears? Your filtering goes out.. O no.. Please not that. Hardley think that is even a reason for a noc to page you... :). Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570
RE: 69/8...this sucks
That's a non-solution that will never happen. How many networks are going to trust joe somebody to inject null routes into their backbone? Will UUNet/Sprint/CW/Level3/etc. trust me or Rob to tell them what's a bogon and what's not? I really doubt it. They might have an easier time trusting their local RIR, but I wouldn't be surprised if they didn't. Well... I am pretty sure Tier1 backbones are up-to-date on the bogon filters :-) As we've already discussed, it's really the smaller networks with outdated bogons or with admins who don't know what they are doing.. Several people pointed that out earlier. Botched / outdated firewall configs may be a bigger problem than BGP filters. For a glimpse at why, see http://groups.google.com/groups?q=69.0.0.0%2F8ie=UTF-8oe=UTF-8hl=enbtnG=Google+Search Yup.. I know some writers watch nanog for potential stories. Wake up guys, this should be one...if not for the news value ARIN gives out unusable IPs, future of the Net in question, then at least for the public service value of getting the word out that bogon filters need to be maintained and kept up to date or they do more harm than good. No kidding.. I think we are just going around the circle/preaching to the choir on the same topic here.. Is this like what... 3rd time we are discussing this whole 69/8 issue :-D? Really, someone needs to get out this 69/8 issue on the press.. Just a thought.. heh -hc -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 69.0.0.0/8 - Please update your filters
Somebody with one of these new cursed allocations ought to setup a system with two IPs (one from the new block, one from an older established block) and do reachability tests to various parts of the net, and then automate sending a notice of bogus filters to those ASNs reachable from the old IP, but not from the new one. And how quickly would those ASN's respond to or even comprehend the bogon-filter update notices? If those ASN's are competent and quick-responsive ones, we should not even be having these prroblems to begin with. -hc If I end up with some of this space, I'll be doing this. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 69.0.0.0/8 - Please update your filters
If the alternative is getting space, giving it to customers, and explaining why they can't reach X, Y, and Z on their connection to us, but they can on other internet connections, we're going to at least have to try. True, but we'd have to try something that would be effective... Imagine how many of those incompetent ASN's still have _outdated_ technical contact email and phone numbers.. I like the idea of moving the gtld servers into such space. That way, the networks that are at fault will break, and they'll be well motivated to fix their filters. I think this is the way to go. It will break the ASN's who do not properly have updated filters. The only thing to be careful is a type of consequence where some of _your_ customers may attempt to get to one of the broken ASN's. DNS issue at the broken ASN's may cause few minor-to-medium oddities that may cause more phone calls on your end. -hc -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Cisco 7507, erratic behaviour
I've seen that before. It's usually okay to just leave it running unless you really have a need to show the running-config at this hour. If I were you, I would wait and reboot the whole thing at like 4 in the morning when not many people are online. -hc On Fri, 7 Feb 2003, Drew Weaver wrote: Howdy, Im having a little difficulty with a 7507, when I do sh run it just returns a newline and doesn't show me any the running-configuration. My privelege level is 15, and this worked yesterday. I also did wr term, same thing.. New line.. Nothing.. My start-config hasn't been modified, and show start works great. Everything is working Ok in the router, however I am concerned for obvious reasons. ;-)
Re: Level3 routing issues?
http://noc.ilan.net.il/stats/ILAN-CPU/new-gp-cpu.html Was it not known that under certain conditions the router would flatline? What percautionary measures were put into place in such an event to limit the damage? scheduler allocate -hc
Re: Is there a line of defense against Distributed Reflective attacks?
I guess the question of all this is may be... what could be done to perhaps... to minimize the impact of DoS attacks pointed at a victim host? Getting everyone to take security more seriously will most likely never going to happen.. :( -hc On Fri, 17 Jan 2003, Clayton Fiske wrote: On Fri, Jan 17, 2003 at 06:38:08PM +, Christopher L. Morrow wrote: On Fri, 17 Jan 2003, John Kristoff wrote: impractical). If the sources can be tracked, perhaps they can be stopped (but large number of sources make this a scaling issue and sometimes not all responsible parties are as cooperative or friendly as you might like). There is also the threat of legal response, which could encourage networks and hosts to stop and prevent attacks in the Legal response to the kiddies has never shown a marked improvement in their behaviour. Much like the death penalty... its just not a deterrent, perhaps because its not enforced on a more regular basis, perhaps because no one thinks about that before they attack. I think John was more referring to legal action against networks and hosts used in the attack. Without getting too much into the likelihood of any legal body actually understanding anyone's role in an attack besides the attacker and the victim, in this land where tobacco companies are sued by smokers who get lung cancer and fast food restaurants are sued by fat people there must be room for such cases as: XYZ Corp cost me $5mil in lost business. They were negligent in securing their (network|host) from being used as a DoS attack tool despite being informed of such by us both before and during said attack. Perhaps this would cause companies to take security more seriously? Have there been any such cases to date? Did they win? -c
Re: Puerto Rico Peering Point, or existence thereof. (fwd)
Hey, Your best bet is to go with Miami, although it may be a bit expensive to get longhaul circuits to there.. Miami is the closest major bandwidth place from your location.. They even have internet exchange over there on behalf of South and Central American based ISP's. -hc -- Forwarded message -- Date: Fri, 10 Jan 2003 06:00:57 -0500 From: Ray Burkholder [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Puerto Rico Peering Point, or existence thereof. I work for an ISP in St. Thomas, US Virgin Islands. (If you happen to pass through, drop by for a visit). Anyway, ATT has undersea fibre to Puerto Rico. We want to get a DS3 into a Puerto Rico peering center where we can get connectivity to some combo of ATT, Sprint, Worldcom, and T-Data. Is anyone familiar with such a location in PR? If not there, how about Florida? Ray Burkholder
Re: lists of DNS servers by region.
Many DNS load balancing solutions will return the address of the web server closest to the _query source_. This means these systems work best when your recursive DNS servers are topologically closest to your users. Correct me if I am wrong.. But.. I don't think multiple 'A' record load balancing will return the IP address of the web server that is closest to the _query_source_. If this is true, then Akamai has reinvented the wheel with their near-by DNS setup on *.g.akamai.net entries. The NS entry 'name server' record that is closest to the _query_source_ may answer the DNS query.. I.e... such as f.root-servers.net serving many pacific traffic as well as western US in majority. -hc S
Re: lists of DNS servers by region.
Akamai doesn't use the usual round-robin. They do OTHER magic. The OTHER magic Akamai uses can be replicated by using BIND 9's view functions on specific IP blocks for query sources. The problem is, you need to write a backend program that figures out the closest layer3 hops or AS hops and even combine it with latency if necessary, in which it will then update your named.conf's view function section. (Unless you have named.conf split over using include directives for 'views') For your secondary nearby DNS servers running BIND9, you should not slave the zones under view functions b/c view will only return the zone file that your secondary DNS server's IP matches for the query source. You'd need to use rsync or cvsup, then do a reload/restart on named.. Schedule it using crond or whatever.. What I have been told is that Akamai's nearby DNS' selection algorithm is partially based on number of AS hops from BGP path table. These are simply my thoughts+solutions that will give you the simple way to setup nearby DNS tricks/MAGICS, using sorted open source stuff that's all around the 'net. The problem is that the backend doesn't know the source of the original query, they only know the IP address of the DNS server that's doing the recursion. My thoughts here again, do not solve this problem. This is beyond the technical limit of the way DNS infrastructure works on internet.. :-( Perhaps someone could setup like a distributed load balancer that can tunnel the traffic from one place to the other, depending on source of the actual tcp/80 traffic to the web server... But then the SYN packet still has to go thru the load balancer and travel over the tunnel, not being so effective in terms of content delivery. -hc -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
RE: Cisco hardware advice needed
Hello all, A lot of you have replied back to my original email with very good advice. I greatly appreciate everyone's assistance. Thank you --haesu This mail sent through TowardEX Webmail http://mail.towardex.com
Cisco router hardware advice needed..
Hello, We currently run a small ISP network with two Linux based routers called ISis (www.imagestream.com) to aggregate all the customers into the backbone. There are two ISis routers and each ISis has two frame-relay T3's. All customers have a frame-relay T1 and we setup the PVC DLCI mappings over the frame cloud.. Now, the ISis routers are too much of a low quality and unacceptable for our ever-growing network. (Please don't reply back to me telling me how Linux for ISP routing is incorrect to begin with, etc, etc.. I understand and agree.. I never made the call the go with Linux based routers in the beginning..) Anyway.. with that being said. We are in process of removing these ISis routers and replacing them with Cisco routers. We are currently thinking of using Cisco 7206VXR's with at least an NPE300 per replacement of ISis. So that would be two Cisco 7206 routers, each with two frame-relay T3's. Each Cisco 7206 router will have about approximately 150 or so serial sub-interfaces for customer PVC mapping.. And each 7206 will have a 100Meg FastEthernet connection to the backbone core router (since two T3's saturating only goes up to about 90Mbps). Now the question is.. Can a Cisco 7200 handle the two frame-relay T3's with 150 or so subinterfaces? My impression of a 7200 is that it is more designed for deployment at the border, not much at the edge/aggregation.. What do you people think? If it cannot handle such pressure, what other models do you guys suggest for us? We are looking at both Cisco and Juniper products, but we would like to use Cisco whenever we can, so Cisco is our preference. Thanks in advance. --haesu This mail sent through TowardEX Webmail http://mail.towardex.com - End forwarded message - This mail sent through TowardEX Webmail http://mail.towardex.com
Re: IP backbone numbering/naming
Hey, Usually numbering backbone routers with a 10/8 is not a necessary practice. Any backbone routers communicating with the outside world are marked category three and should have globally unique IP numbers. Plus, if you are an ISP (in which it looks like you are..), it will help others on public internet to try to track down abuse a little deeper through traceroutes, which will may be help them identify the upstream provider of the offender. You could also use RFC1918 numbers for your point-to-point /30 aggregation blocks with the customers.. But.. since that would have effect on customer's premise equipment, it would be better to give them globally unique space as well, who knows if your customer comes back and yells at you for not being able to get to his router's serial interface IP. Quoting Steve Rude [EMAIL PROTECTED]: Hi All, I am trying to collect information about using RFC 1918 space on an ISP backbone. I have read the RFC several times, and I don't see where it says that you cannot use 10/8 space to number your backbone links (/30s). I know this is an old thread that has been rehashed several times, but can anyone please send me links or information that I can use to convince my boss that we should use our arin alloc'd space on our backbone instead of using private space. Also if anyone has opinions on naming conventions for backbone such as why to or why not to even have dns resolution for your backbone and some conventions please let me know. TIA! -- Steve Rude [EMAIL PROTECTED] This mail sent through TowardEX Webmail http://mail.towardex.com
