February 2004 - NANOG - lists.nanog.org

RE: Converged Networks Threat (Was: Level3 Outage)
by Sean Crandall 25 Feb '04

25 Feb '04

>From Jared: > I keep hear of Frame-Relay and ATM signaling that is > going to happen in large providers MPLS cores. That's right, > your "safe" TDM based services, will be transported over > someones IP backbone first. > This means if they don't protect their IP network, the TDM > services could fail. These types of CES services are not > just limited to Frame and ATM. > (Did anyone with frame/atm/vpn services from Level3 > experience the same outage?) We use Level3 for IP transit and transport (both DS-3 and Ethernet over MPLS (via Martini)) all over the country. As with everyone else, we saw the problems with the transit traffic out of SJC and ATL. However, our transport services were not affected at all by the problems. In fact, I just ended up sending my Level3-SJC bound traffic to LAX via Level3 which was going through the same equipment as the transit traffic which was having problems. >From Pete: > From this, it can be deduced that reducing unneccessary > system complexity and shortening the strings of pearls that > make up the system contribute to better availablity and > resiliency of the system. Diversity works both ways in this > equation. It lessens the probablity of same failure hitting > majority of your boxes but at the same time increases the > knowledge needed to understand and maintain the whole system. > > I would vote for the KISS principle if in doubt. I agree. Granted the string of pearls is always going to be pretty long, but there are definitely is a trend from what I have seen with customers to make the string longer than it needs to be. -Sean Sean P. Crandall VP Engineering Operations MegaPath Networks Inc. 6691 Owens Drive Pleasanton, CA 94588 (925) 201-2530 (office) (925) 201-2550 (fax)

1 0

RE: possible L3 issues
by Arjan Lugtenberg 25 Feb '04

25 Feb '04

Here at planet (AS8737) we also having problems reaching msn/hotmail/messenger. Seems that C&W are also having problems reaching microsoft?? regards, Arjan -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of kwallace(a)pcconnection.com Sent: maandag 23 februari 2004 23:53 To: nanog(a)merit.edu Subject: possible L3 issues anyone else seeing high latency via L3 , especially the west coast ? - Keith

8 7

RE: New Draft Document: De-boganising New Address Blocks
by Michael.Dillon＠radianz.com 25 Feb '04

25 Feb '04

>> Timothy Brown wrote: >> I disagree with the view that it is a hack. >> It's no more a hack than using a DNS feed; >I concur with this. Besides, from the pragmatic side of the "consumer", >if it does solve a problem (albeit short or medium term) I don't care >much if it's a "hack". Then we all agree. The Cymru bogon feed is a hack. The completewhois feed is a hack. In fact, any third party feed that puports to identify authentic IP allocations is a hack. The only fix for this is to get the addressing authorities to provide an authoritative feed. That probably means first getting the RIRs to do it and then ICANN to fill in the gaps. As to whether the mechanisms used by bogon feeds are hacks or carefully crafted technology, well, my rule of thumb is that if it can completely automate the process while still allowing human intervention to make judgement calls on all changes to network configuration, then it is carefully crafted technology. I'm afraid that by this measure, using BGP feed as the mechanism is a hack because it involves plugging a 3rd party directly into your routing architecture. A directory service like DNS or LDAP is closer to the carefully crafted technology because it can be plugged into OSS systems that allow humans to validate and release any network changes. --Michael Dillon

1 0

RE: New Draft Document: De-boganising New Address Blocks
by Michel Py 25 Feb '04

25 Feb '04

William, > william(at)elan.net wrote: > [http://www.cymru.com/BGP/bogon-rs.html] > Unfortunetly this is kind-of a bgp hack and as has > been already mentioned it needs very carefull > implemention This is not positive thinking. I don't consider this a hack (if it is, then the draft that proposes to re-use ORF mechanisms is even worse). I'm not interested in what things were designed to do, I'm interested in what things _can_ do. I use [Cymru] myself as I am within the applicability domain. I use your stuff too. However, you might be borderline to abusing co-author privileges here; Team Cymru has lead the route-server project for long, and although the bogon list is by nature a lot less controversial than what you do the bottom line is the acceptance of Cymru's feed is far greater than Completewhois. Please don't use draft-py-idr-redisfilter-01.txt as a platform to compete with other co-authors; collaborative competition is sound, please stay within its borders. Thanks Michel.

2 2

RE: Proposal: De-boganising New Address Blocks
by Michel Py 25 Feb '04

25 Feb '04

Daniel, [me puts the Devil's advocate suit on] If I read this correctly, the way I summarize it is: "Instead of waiting for people that get real delegations in a newly allocated /8 to have real problems, we delegate parts of this new /8 to pilot projects before hand, knowing that there will be issues, which allows us to contact operators that are still bogonizing the new block. The idea being that the inconvenience caused by a pilot project being bogonized is of little consequence where the inconvenience of a real delegation being bogonized is real." Good idea, no contest. Now, the devil's advocate asks: what makes you think that operators/ISPs are going to react faster to your pilot stuff being bogonized than they would to real traffic being bogonized, as if it's a pilot project it's by definition not urgent and can wait tomorrow? Although I salute the effort, I am concerned that this will not change current reactive behavior which is to wait for the shit to hit the fan to update bogon lists. Might sound sad, but I think the way to de-bogonize new blocks is to automate the de-bogonization process, as the idea to de-bogonize ahead of time will not cut it as a priority, IMHO. My $0.02, and let me stress that I did not intend to sound negative as the idea is good; I'm just a little skeptical. Michel.

3 2

168.0.0.0/6
by Randy Bush 25 Feb '04

25 Feb '04

route-views.oregon-ix.net>sh ip bgp 169.223.0.0 BGP routing table entry for 168.0.0.0/6, version 7688303 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 3277 13062 20485 20485 20485 8437 3303 194.85.4.249 from 194.85.4.249 (194.85.4.249) Origin IGP, localpref 100, valid, external, best ripe is being overgenerous to the swiss!

8 11

RE: New Draft Document: De-boganising New Address Blocks
by Michel Py 25 Feb '04

25 Feb '04

> Timothy Brown wrote: > I disagree with the view that it is a hack. > It's no more a hack than using a DNS feed; I concur with this. Besides, from the pragmatic side of the "consumer", if it does solve a problem (albeit short or medium term) I don't care much if it's a "hack". Hint: all this bogon or related filtering is not a long-term solution. We need it now, but the long term solution is some kind of authentication that will allow only the rightful owner of a block to announce it. Michel.

2 1

Re: New Draft Document: De-boganising New Address Blocks
by Michael.Dillon＠radianz.com 25 Feb '04

25 Feb '04

>The RIPE NCC has prepared a draft document titled "De-Bogonising New >Address Blocks": That is a misleading title. The problem is that ISPs cannot react quickly enough to open filters when new ranges are allocated. The proposed solution is to provide advance notification. I suppose this could allow ISPs to open filters before the new addresses are actually in use officially. However, it will also allow spammers to announce this space and get it through bogon filters. The real solution to this problem is to make it possible for ISPs to closely track RIR allocations in their filters in a semi-automated way. There may still be a few days of delay before a new allocation is fully routable but ISPs can compensate for that with internal processes. Why can't ISPs subscribe to a feed of all new RIPE allocations in near real-time? --Michael Dillon

5 6

SIGCOMM Workshop on Network Troubleshooting
by jon bennett 25 Feb '04

25 Feb '04

(Recent messages on the list suggest this announcement to be quite timely) We hope that this workshop will be of interest to NANOG members and that many of you will participate and/or submit material to it. Jon Bennett and Mark Allman ( trouble04-chairs(a)icir.org ) http://www.acm.org/sigcomm/sigcomm2004/netts.html ----------------------------------------------------------------------- To be held in conjunction with SIGCOMM '04 Network Troubleshooting: Research Theory and Operations Practice Meet Malfunctioning Reality Call For Papers Network monitoring and measurement has received a great deal of attention in the research community recently. While some research to-date has been focused on finding problems, failures and anomalies in networks this workshop endeavors to focus specifically on such topics. The workshop seeks papers exploring several themes: DETECTION: Mechanisms and techniques for detecting failures, imminent failures and other anomalies in real time. The focus of this workshop is research that can be used operationally to help the network in the short-term. Techniques that require heavyweight off-line analysis to find problems provide the community with an understanding of and an insight into the dynamics and potential long-term solutions for network issues, but are not the main focus of this workshop. CORRECTION: While detecting problems (or imminent problems) and alerting network operators is a good first step, techniques for automatically mitigating problems as they occur are also sought. COORDINATION: Detecting and solving problems in a multi-provider environment inevitably involves communicating between distinct autonomous entities. Mechanisms and facilities to streamline and automate such communication are sought. EXPERIENCE: Insight from network operators into network problems they cannot easily detect (or, detect far too late) and tools that would make network management much easier. Input from network operators on non-obvious or non-technical considerations which impact technical solutions are also sought. This workshop invites two kinds of submissions: Original papers on any area of network measurement, monitoring or management specifically directed towards one or more of the above themes. Poster presentation proposals. While posters on any of the above themes will be accepted, posters on operational experience are highly sought. Note: For this workshop, "networks" includes both physical networks and virtual networks (CDNs, overlays, etc.). Some of the specific problems of interest, include: Protocol failures - link, routing, management Detecting mis-configuration of network elements Partial hardware failures - intermittent, unreported Traffic engineering for overload control Security - DDoS attacks, detecting compromised network elements, intrusion detection (especially for non-edge networks since a large body of work already tackles the problems at the network edge) Submissions: Submissions ranging from presentations of specific research to position papers are welcome. Papers presenting interesting and novel ideas at an early stage of development are preferred over completed journal-style results. Selected papers will be forward-looking, with impact and implications for both operational networks and ongoing or future research. Original papers should be 3-6 standard SIGCOMM formatted pages (with the expectation that position papers will be shorter and research papers longer). Poster proposals should be sent in the form of 1-page abstracts. The submission process and specific guidelines will be posted at a later date. Important Dates: Submission registration: April 8, 2004 Submission deadline: April 15, 2004 Notification deadline: May 15, 2004 Camera ready deadline: June 15, 2004 Workshop Co-Chairs (trouble04-chairs(a)icir.org) Jon C.R. Bennett, Harvard University Mark Allman, ICIR Program Committee: TBD

1 0

RE: eBGP, iBGP, injecting networks
by Fowlie, Colin 25 Feb '04

25 Feb '04

I think the main concern you have here is the advertisement of the networks from two different ASN's to two different upstream providers. You'll have to set it up with your upstream ISP's to allow you to advertise all of the networks, but typically it's not a problem. You won't have an issue with routing loops as BGP speaker will drop a prefix that has its own ASN in the path-list. If you prepend properly to the AS path things will behave the way you want them to. This will provide your inbound redundancy. HTH Colin Fowlie -----Original Message----- From: Curtis Maurand [mailto:curtis@maurand.com] Sent: Monday, February 23, 2004 11:49 AM To: Ing. Hans L. Reyes Cc: isaac(a)ravengate.net; nanog(a)merit.edu Subject: Re: eBGP, iBGP, injecting networks He might try: http://www.cisco.com/en/US/tech/tk365/tk80/technologies_configuration_examp… This one shows how to setup HSRP on the inside for the automatic failover that he's looking for. Curtis On Fri, 20 Feb 2004, Ing. Hans L. Reyes wrote: > > > Hi > > Your problem may be is similar when one ISP buy to another ISP, sometimes > is easy to modify the IGP like in this case (OSPF) because it is something > inside of your company and you have the control over all the devices but > you still have the problem outside of the company; client, others ISP, etc > > Check the feature of BGP "Local-AS" for routers Cisco if yours routers > aren't Cisco, check for someone similar with your vendor. May be you need > to do something else. > > This is the url where explain how it works. > > http://www.cisco.com/en/US/tech/tk365/tk80/technologies_configuration_examp… > > I hope it help you > -Hans > > On Fri, 20 Feb 2004 isaac(a)ravengate.net wrote: > > > > > greetings list, > > > > hoping someone can hook me up on the right way to do this. > > > > --- > > > > we have two ASN's we control. > > > > we have two border/edge routers (1 in each ASN) that talks to a > > different backbone provider. > > > > the two border routers peer with eachother over eBGP and also are in > > the same OSPF process. (we are working to merge them into the same > > BGP ASN) > > > > my question is this: > > > > how do we achieve router redundancy between these two routers? > > > > currently if we lose a transit link, the traffic will flow fine out > > the other pipe. > > > > but we don't have BGP network statements in router 2 that exist in > > router 1 and we don't have BGP network statements in router 1 that > > exist in router 2. > > > > so the routes injected into BGP from router 1 will get withdrawn right > > if router 1 dies? > > > > is it a problem to announce the same networks from two different eBGP > > peers to two different upstreams? > > > > ------ > > > > if you are still reading, thanks! > > > > to clearify some more- > > > > current setup: > > > > current setup: > > > > ASN 1 (we're not Genu!ty- just using for an example) > > > > :) > > > > ASN 1 injects all of its own space and announces this space to > > Above.net and ASN 2 > > > > ASN 2 injects all of its own space and announces this space to Savvis > > and ASN 1. > > > > so stuff out on the net looks like: > > > > 1 6461 etc etc > > > > and > > > > 1 2 6347 > > > > ------- > > > > 2 6347 etc etc > > > > and > > > > 2 1 6461 etc etc > > > > ------- > > > > so, you see we are prepending on of our AS's on the way out. > > > > the problem is tho, we only have 1 router in each respective Autonmous > > System injecting address space. if we lose that router, we lose > > announcing that ASN's space. > > > > is it totally going to cause probs to have routes originating from two > > different AS's? routing loops would be a real drag. > > > > what about having an iBGP router in AS 1 inject the same space as the > > border router in AS 1? this other router also peers with AS 2.... > > > > thanks a lot! > > jg > > > -- -- Curtis Maurand mailto:curtis@maurand.com http://www.maurand.com

2 1