- Test - lists.nanog.org

Re: ISP's In Uproar Over Verizon-MCI Merger
by Fergie (Paul Ferguson) 24 Aug '05

24 Aug '05

Amen, brother. ;-) - ferg -- Chris Boyd <cboyd(a)gizmopartners.com> wrote: For those outside the state or the US, Texas has some very odd political traditions and laws that are beyond explanation in email. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Re: BGP AS Sets in the wild
by Danny McPherson 24 Aug '05

24 Aug '05

On Aug 23, 2005, at 4:36 AM, Abhishek Verma wrote: > > I was looking at route-views.routeviews.org for the BGP routes and i > dont see any AS-Sets whatsoever. Are BGP routes with AS-SETs not > generally leaked into the wild? > > Is this the case? Not quite, see below.. > I am under the impression that AS_SETs are generated whenever there > are some routes that are aggregated. Is there any other way also to > generate AS_SETs in BGP? > Well, yes, but mostly via proxy aggregation type stuff, which isn't real common these days (i.e., dynamic proxy aggregation on behalf of downstream ASes). Yep, quite a few (I was just looking at this a while back for something else). As of a few hours ago, route-views had 45 unique prefixes that contained AS_SET path attributes. Interestingly enough, ~60% of those AS_SETs only contain a single AS -- hrmm. It's also interesting to see some of these AS_SETs, albeit only a couple, contain private AS space, I'm wondering if some naive implementations "remote-private-as"-type knob is letting them slip by inside AS_SETs on egress. danny@foo% grep { oix-full-snapshot-latest.dat | wc -l 1717 danny@foo% grep { oix-full-snapshot-latest.dat | grep \> | wc -l 45 danny@foo% grep { oix-full-snapshot-latest.dat | grep "^...[0-9]" * 24.223.128.0/17 129.250.0.11 1 0 2914 1668 10796 {11060,12262} i * 24.223.160.0/19 129.250.0.11 1 0 2914 1668 10796 {11060,12262} i *> 64.132.88.0/22 209.161.175.4 0 14608 4323 {33127} i *> 64.132.102.0/24 209.161.175.4 0 14608 4323 {32510} i * 64.132.220.0/23 129.250.0.11 17 0 2914 4323 {18664} i * 65.17.160.0/19 129.250.0.11 1 0 2914 1668 10796 {11060,12262} i * 65.189.0.0/16 129.250.0.11 17 0 2914 3356 10796 {11060,12262} i * 65.205.32.0/24 129.250.0.11 55 0 2914 10913 10913 26134 {30060} i * 65.221.0.0/19 129.250.0.11 0 0 2914 701 11486 {15297} i * 65.254.96.0/19 129.250.0.11 0 0 2914 7911 2552 {25662,25887} ? *> 66.162.17.0/24 209.161.175.4 0 14608 4323 {29704,65102} i * 66.163.160.0/19 129.250.0.11 7 0 2914 3561 26085 {14776} i * 82.135.152.0/21 129.250.0.11 0 0 2914 1299 8764 8764 8764 {31006,34037} i * 128.116.0.0 129.250.0.11 0 0 2914 7911 14041 {16519} i * 129.19.0.0 129.250.0.11 0 0 2914 7911 14041 {12145,16519} i *> 129.165.192.0/18 134.55.200.1 0 293 10886 1701 {270,65200} ? * 140.31.0.0 129.250.0.11 0 0 2914 701 668 {132,3381} i * 140.32.0.0 129.250.0.11 0 0 2914 701 668 {22,5957,14077} ? * 147.241.0.0 129.250.0.11 0 0 2914 701 668 {13} i * 147.249.0.0 129.250.0.11 0 0 2914 701 7381 {3561,6419,12178} i *> 168.215.137.0/24 209.161.175.4 0 14608 4323 {29704} i * 200.62.40.0/22 129.250.0.11 6 0 2914 5511 18747 {12180,23383,23520} i * 200.85.0.0/20 129.250.0.11 0 0 2914 701 26617 {17079} i * 201.217.192.0/19 129.250.0.11 6 0 2914 5511 18747 {26596} i * 202.30.88.0/23 129.250.0.11 5 0 2914 4766 3608 3608 3608 17832 {9494} i * 202.224.128.0/18 129.250.0.11 258 0 2914 4688 4688 4688 {18071} i * 206.169.96.0/22 129.250.0.11 17 0 2914 4323 {11636} i * 206.169.208.0/22 129.250.0.11 17 0 2914 4323 {21593} i * 207.19.96.0/21 129.250.0.11 0 0 2914 701 7381 {14455} i * 207.133.7.0 129.250.0.11 0 0 2914 209 721 27064 6026 {65535} i *> 207.235.48.0/20 209.161.175.4 0 14608 4323 {32258,32418,32434} i *> 207.250.94.0/23 209.161.175.4 0 14608 4323 {33395} i * 208.16.208.0/21 129.250.0.11 0 0 2914 701 7381 {14455} i * 208.142.248.0/21 129.250.0.11 0 0 2914 4436 14390 {27481} ? * 208.254.0.0/19 129.250.0.11 0 0 2914 701 11486 {12156} i * 209.159.192.0/18 129.250.0.11 47 0 2914 30167 20412 {14507} i * 209.213.209.0 129.250.0.11 0 0 2914 7911 6517 {21953} i *> 209.234.168.0/22 209.161.175.4 0 14608 4323 {5710} i * 210.23.192.0/19 129.250.0.11 4 0 2914 9299 9299 7491 {23862} i * 210.23.208.0/21 207.246.129.6 0 11608 2914 6453 7491 {23862} i * 210.23.208.0/20 207.246.129.6 0 11608 2914 6453 7491 {23862} i * 214.40.0.0/16 129.250.0.11 0 0 2914 209 721 27064 {27065,27066} i * 216.83.160.0/19 129.250.0.11 0 0 2914 701 7381 {14455} i *> 216.110.12.0/23 209.161.175.4 0 14608 4323 {35970} i *> 216.110.88.0/21 209.161.175.4 0 14608 4323 {32868} i * 216.203.0.0/18 129.250.0.11 0 0 2914 701 7381 {14033,14455,35938} i * 216.203.48.0/20 129.250.0.11 0 0 2914 701 7381 {14455} i -danny

1 0

RE: 4-Byte AS Number soon to come?
by Glen Kent 24 Aug '05

24 Aug '05

> Is it common or uncommon to fire up 'ethereal' or 'tcpdump' to debug > a BGP problem? I have done that a few times in my life (not that i have lived long enough like others in this list) > > Would it be problematic to have to either a) clear sessions for your > analyser to fully understand the BGP stream or b) tell your analyser Are you're talking about clearing the BGP session between the two remote ends, for the *analyser* to work? This is weird and will most definitely not be accepted. There could be numerous such applications running that would want to look at the BGP stream. The peers are not expected to reset the session to make them work! > whether the flow uses 2 or 4 byte ASNs? This would imply prior knowledge about the ASNs which may not be available with the analyser. > Essentially, this draft as it stands is going to make it difficult to > observe and comprehend BGP AS_PATH without either human intervention > or restart of the session(s) concerned. A guage how much of a problem > this would be in real-life (if any problem at all?) would be useful > in determining whether it's worth lobbying to change the draft. If there isnt a wide installed base for the draft, and if there are solutions available that can solve this problem then i would prefer going ahead with the new solution and picking it up if it works! Kent

4 5

Re: ISP's In Uproar Over Verizon-MCI Merger
by Fergie (Paul Ferguson) 24 Aug '05

24 Aug '05

..and life is probably going to get a lot more interesting for service providers. All today, we have leaders in the field with completely opposite views of the word: U.S. Broadband Policy Exists -- And Works, Claims NTIA's Gallagher http://www.advancedippipeline.com/169600336 [and] Nortel chief: U.S. needs new broadband vision http://www.infoworld.com/article/05/08/23/HNnortelchief_1.html And just to make life more fun, it looks like there's an effort afoot to get VoIP consumers to pay (read: tax) into the USF: New taxes could slam Net phone users http://news.com.com/New+taxes+could+slam+Net+phone+users/2100-7352_3-584223… So, aren't you glad that life isn't boring? ;-) - ferg -- "Gary E. Miller" <gem(a)rellim.com> wrote: You forget the third choice the AT&T taught us so well before the big breakup: Less broadband at higher prices. Just look at how hard it has been to get Qwest to fulfill their promises of more broadband outside of the cities in return for less state control over prices. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1

LAN to LAN dial solution
by sbrillus＠blueyonder.co.uk 23 Aug '05

23 Aug '05

Can anyone suggest, other than using Cisco's a brand of UK-compliant boxes that effectively will perform a PSTN dial up function, so that when the two boxes are connected, the LAN's are effectively bridged together Basically what we want to be able to do is connect a PC on a LAN, so that at will, a number can be dialed and you can then telnet to the far end Thanks Simon

2 1

RE: Rip again!
by Chris Ranch 23 Aug '05

23 Aug '05

In case no one else has suggested it: the source MAC address will identify the source. Chris > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Scott Morris > Sent: Sunday, August 21, 2005 9:21 AM > To: 'Tom Sanders'; nanog(a)nanog.org > Subject: RE: Rip again! > > > How about the source IP? > > RIP v1 is sent to 255.255.255.255 broadcast. RIPv2 is sent > to 224.0.0.9 multicast. Both are local-link only, so won't > go THROUGH a router. The sending source IP will tell you > where they came from. > > If you're using VLANs (trunks), there won't be any issues. > If you're using > secondary addresses, this will depend on whose devices you > use. In the > Cisco world, packets will always be sourced from the primary > IP address on an interface. And if the receiving router > doesn't have a subnet matching the sender, packets/updates > are ignored. (Again, Cisco world you can use "no > validate-update-source" to override this check) > > But that gives you a tracking method on packets. > > Scott > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Tom Sanders > Sent: Sunday, August 21, 2005 12:13 PM > To: nanog(a)nanog.org > Subject: Rip again! > > > Hi, > > There isnt IMO a way in RIP to identify the source of the RIP > packet (the way we have Router ID in OSPF, system ID in ISIS, etc.) > > Now assume we have 2 vlans defined on an ethernet. Thus we > would have two IP interfaces, 1.1.1.1/24 and 2.2.2.2/24 and > both using the same physical interface. RIP is running on > both these interfaces. > > My doubt is that how will another router, which is configured > in the same way (2 vlans) be able to differentiate between > the RIP responses originated by 1.1.1.1 and 2.2.2.2? > > Thanks, > Toms > >

2 1

Re: 4-Byte AS Number soon to come?
by Yakov Rekhter 23 Aug '05

23 Aug '05

Hi, > On 23-aug-2005, at 11:53, Paul Jakma wrote: > > >The IDR draft is awaiting implementation report. > > If this is true, it's very distressing. The IDR draft awaits an implementation report in order to advance the draft to Proposed Standard. What is so distressing about this ? > Drafts are deleted after > about six months. That means that any implementations will be based > on a no longer existing specification. That's wrong in so many ways. Drafts are deleted after about six months *unless* the drafts are renewed (republished). The draft we are talking about is an *existing* specification (draft-ietf-idr-as4bytes-10.txt). Yakov.

2 1

4-Byte AS Number soon to come?
by Elvis DePaula 23 Aug '05

23 Aug '05

Anyone in the list has a good update on the IETF:draftietf- idr-as4bytes-10.txt ? Is the projection os AS Number exhaustion of 2011-2013 exaggerated or do we really have a potential big problem with a slow solution ahead of us? -Elvis.

7 10

BGP AS Sets in the wild
by Abhishek Verma 23 Aug '05

23 Aug '05

Hi, I was looking at route-views.routeviews.org for the BGP routes and i dont see any AS-Sets whatsoever. Are BGP routes with AS-SETs not generally leaked into the wild? Is this the case? I am under the impression that AS_SETs are generated whenever there are some routes that are aggregated. Is there any other way also to generate AS_SETs in BGP? Any clues. Thanks, Abhishek -- Class of 2004 Institute of Technology, BHU Varanasi, India

3 2

Question about propagation and queuing delays
by David Hagel 23 Aug '05

23 Aug '05

I was wondering what are the typical coast-to-coast propagation and queuing delays observed by today's backbone networks in North America. Is there any data/study which provides a breakdown of different components of such end-to-end delays in today's backbone networks? Thanks, David

11 17