- Test - lists.nanog.org

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

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