- NANOG - lists.nanog.org

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

REMINDER: ARIN to allocate from 70.0.0.0/8
by Leslie Nobile 24 Feb '04

24 Feb '04

Hello- This is a reminder that ARIN will begin allocating IP address space from 70.0.0.0/8 in the immediate future. This will include allocations of /20 and shorter prefixes, according to ARIN's minimum allocation policy. You may wish to adjust any filters you have in place accordingly. For informational purposes, a list of ARIN's currently administered IP blocks can be found under "CIDR Blocks" at: http://www.arin.net/statistics/index.html Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN)

1 0

Sprint and AT&T backbone engineer
by alex＠yuriev.com 24 Feb '04

24 Feb '04

Hello, If any Sprint and AT&T backbone engineer with visibility into live capacity issues in North East could drop me a message of list, I would greatly appreciate it. Thanks, Alex

1 0

Re: [IP] VeriSign prepares to relaunch "Site Finder" -- calls
by Paul Vixie 24 Feb '04

24 Feb '04

> > It's a module plug-in into bind and if you prefer to try and do this > > in a opt-in basis they have a client program that you download and > > it gets hooked into the users browser. > > This is the right way to do it, end user opt in, and browser only. i'm a little bit worried about the idea of doing this inside BIND, since DNS is supposed to be coherent, and answers are supposed to be based on fact rather than value. but the larger point of this reply is: > Unlaterally forcing it upon everyone and breaking non www based apps is > the wrong way to do it. if you have well founded views on this topic and you have not yet shared them with ICANN's SSAC, please do so. see <http://secsac.icann.org/>.

2 1

T1 Customer CPE Replacement?
by Claydon, Tom 24 Feb '04

24 Feb '04

Hello, We're looking for a good replacement for fractional T1 customers with Cisco 1600- & 1700-series routers as their CPE. They are good routers, but the ongoing support costs are an issue, and we need to replace them ASAP. Someone had mentioned several CPE vendors, such as Adtran and Netopia. Are there any others, and does anyone have any pros/cons of what they're familiar with? Thanks, = TC -- Tom Claydon, IT/ATM Network Engineer Dobson Telephone Company phone: (405) 391-8201 cell: (405) 834-0341

5 4

Re: [IP] VeriSign prepares to relaunch "Site Finder" -- calls
by Michael.Dillon＠radianz.com 24 Feb '04

24 Feb '04

>Okay, they are lying here. That's a bit strong. If you had looked at the Paxfire website it doesn't take long to realize they are completely clueless. They are an Internet traffic broker but the traffic that they deal in is web page views which illustrates a certain level of technical cluelessness. But then when you read their "about" pages and see the long lists of trivial accomplishments of the principals in the company, you have to wonder about their business acumen as well. Let's face it, these guys just don't really understand what they are doing. --Michael Dillon

1 0

Proposal: De-boganising New Address Blocks
by Daniel Karrenberg 24 Feb '04

24 Feb '04

[Apologies for duplicate messages] This is of interet to all operators worldwide. Operators who do not participate in RIPE are invited to send comments and suggestions directly to the author. "De-Bogonising New Address Blocks" <http://www.ripe.net/ripe/draft-documents/deboganising-draft.html> Abstract "This document describes an improvement in the notification process about new blocks of address space being distributed by the RIRs. It is a draft at this stage and your comments are solicited. However to gain experience before finalising the procedures, the RIPE NCC will shortly start announcing the routes from 84/8 described in the document under "84/8 Pilot"."

1 0

FCC rulemaking for mandatory outage reporting
by Sean Donelan 24 Feb '04

24 Feb '04

Communication providers of all sizes, which may include Internet service providers, may want to review http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-04-30A1.pdf This is the FCC's notice of proposed rulemaking concerning communication provider outage reporting. The definitions are very expansive.

1 0

RE: BL of Compromised Hosts?
by Michel Py 24 Feb '04

24 Feb '04

>> Michel Py wrote: >> There is a regrouping of BGP feeds for various "questionable" >> hosts and networks around AS29467; > william(at)elan.net wrote: > That is actually not correct. The AS29467 will stay as being > used for BOGON and similar data. It is quite likely that other > ASNs would be used for other "questionable" hosts, possibly > one for various anti-spam lists and other for yet more > "questionable" hosts such as DoS sources, etc. My mistake, thanks for correcting me. > The draft is not about data sources the draft about the > changes that need to be done to the router software in > handing BGP that would actually allow for use of outside > BGP feed for filtering (or marking) routes Indeed. > The draft which was originally only for bogon filtering > during private discussions between authors it was changed > to be more general to be used for other situations, > unfortunetly it does still suffer from being too BOGON > specific and when draft was sent to IDR they immediately > complained about that too. Indeed; however after some face to face discussion and clarified by the presentation they did understand our intentions that the purpose was the mechanism and not the qualification of the bogon/bad sources. > It has been suggested that draft be rewritten and even > more be removed from it to be less bogon specific and > to only describe this kind of filtering in the concept > with non-specific examples if possible. Still on the table, although I would like have some beta code to grind prior to rewriting... The existing draft is not nearly as bad as the initial versions in terms of being tied to bogon filtering, but I agree that it would be better if it was more generic. Michel.

1 0