- Test - lists.nanog.org

RE: PSI/Digex announcements
by Chris Flores 11 Nov '99

11 Nov '99

Joe, Yes - this is indeed not optimal. To keep routing tables manageable, BGP announcements should be aggregated into a shorter prefix such as /20 or /19 (whatever is possible). Many autonomous systems accidentally leak longer announcements for various reasons; accurate filtering can eliminate these mistakes. It looks like the autonomous system from your email is redistributing connected routes - you can start by contacting the originating autonomous system. Hope this helps. CF -----Original Message----- From: Joe Shaw [mailto:jshaw@insync.net] Sent: Thursday, November 11, 1999 3:58 PM To: nanog(a)merit.edu Subject: PSI/Digex announcements I have a non peering T1 to PSI for VPN customers. While troubleshooting some problems for one of those VPN customers I came across these: HOUSTON_BR1#show ip bgp regex ^174$ Network Next Hop Metric LocPrf Weight Path *> 12.15.224.192/27 38.7.128.1 200 174 i *> 154.32.255.0/30 38.7.128.1 200 174 i *> 192.245.179.248/30 38.7.128.1 200 174 i *> 198.17.203.0/25 38.7.128.1 200 174 i *> 198.137.240.32/27 38.7.128.1 200 174 i *> 198.207.208.192/27 38.7.128.1 200 174 iA *> 204.4.196.32/27 38.7.128.1 200 174 i *> 204.4.196.64/27 38.7.128.1 200 174 i *> 204.4.196.96/27 38.7.128.1 200 174 i *> 204.68.218.0/27 38.7.128.1 200 174 i *> 204.180.67.160/27 38.7.128.1 200 174 i *> 206.181.125.188/30 38.7.128.1 0 200 174 i *> 206.119.241.96/27 38.7.128.1 200 174 i *> 207.37.154.120/29 38.7.128.1 200 174 i *> 207.138.126.128/27 38.7.128.1 200 174 i Isn't it considered "bad" to be announcing nets that small, especially the /30's? -- Joseph W. Shaw - jshaw(a)insync.net Free UNIX advocate - "I hack, therefore I am."

1 0

Re: PSI/Digex announcements
by Joe Shaw 11 Nov '99

11 Nov '99

> *> 206.181.125.188/30 38.7.128.1 0 200 174 i HOUSTON_BR1#traceroute 206.181.125.189 Type escape sequence to abort. Tracing the route to dfw2-core1-s3-1-0.atlas.digex.net (206.181.125.189) 1 lspr.dallas.tx.ce.us.psi.net (38.7.128.1) [AS 174] 28 msec 8 msec 12 msec 2 dfw2-core1-s3-1-0.atlas.digex.net (206.181.125.189) [AS 174] 176 msec * 12 msec Sorry, I didn't mean to implicate it was you, it was that network that made me go back and look for all the others. The original title was PSI/DIgex announcement, then I changed it to announcements without removing Digex. My apologies for the confusion. -- Joseph W. Shaw - jshaw(a)insync.net Free UNIX advocate - "I hack, therefore I am." On Thu, 11 Nov 1999, Aaron Weintraub wrote: > Hi, I'm kind of curious as to how digex is implicated in this mail. I > can't seem to find any indication of our involvement here. Thanks, > > aw > -- > Aaron Weintraub - aaronw(a)digex.net > IP Operations

1 0

Re: IPv4 Hash Function
by Vadim Antonov 11 Nov '99

11 Nov '99

In my experience, Fibonacci hashing is faster and gives a better spreading. --vadim Richard Steenbergen <ras(a)above.net> wrote: I have seen the IPv4 hash function: (ip ^ (ip >> 23) ^ (ip >> 17)) & ~(bucketsize - 1) for power-of-2 sized hash tables attributed to Van Jacobson, in many places, but I have never found any paper or writing that is the actual source of this. Does anyone know where I might find such? Personal curiosity only.

1 0

IPv4 Hash Function
by Richard Steenbergen 11 Nov '99

11 Nov '99

I have seen the IPv4 hash function: (ip ^ (ip >> 23) ^ (ip >> 17)) & ~(bucketsize - 1) for power-of-2 sized hash tables attributed to Van Jacobson, in many places, but I have never found any paper or writing that is the actual source of this. Does anyone know where I might find such? Personal curiosity only. -- Richard A Steenbergen <ras(a)above.net> http://users.quadrunner.com/humble PGP Key ID: 0x60AB0AD1 (E5 35 10 1D DE 7D 8C A7 09 1C 80 8B AF B9 77 BB) AboveNet Communications - AboveSecure Network Security Engineer, Vienna VA

1 0

ARIN to Allocate from 64.0.0.0/8
by Richard Jimmerson 11 Nov '99

11 Nov '99

This is a reminder of ARIN's message sent to NANOG on 10 September, 1999. On November 22, 1999, ARIN will begin making allocations from the 64.0.0.0/8 block. This will include allocations of /20 and shorter prefixes, according to ARIN's minimum allocation policy. For informational purposes, ARIN currently administers the following blocks: 24.0.0.0/8 (portions of) 63.0.0.0/8 64.0.0.0/8 196.0.0.0/8 198.0.0.0/8 199.0.0.0/8 200.0.0.0/8 204.0.0.0/8 205.0.0.0/8 206.0.0.0/8 207.0.0.0/8 208.0.0.0/8 209.0.0.0/8 216.0.0.0/8 Regards, American Registry for Internet Numbers (ARIN)

6 7

No Op. - Arbitration clauses in peering agreements
by Lauren F. Nowlin 10 Nov '99

10 Nov '99

Hi all, Apologies to Randy for the non-operational content here... I'm trying to modify our peering agreement to reflect more international standards and am having issue with arbitration procedures. From the 20-30 documents I've poured through in the past 24 hours: - most large US carrier peering agreements opt for senior management intervention prior to termination of the peering agreement - no arbitration - most mid-size US carrier peering agreements have very bland, offered in the state the governing law applies to, language for arbitration; - a few international carriers have UN arbitration (see wording below) that might make more sense for a global network; - very few international carriers have peering agreements in any form and default to the standard US format. A few international carriers have the following arbitration clause: "All disputes, controversies, claims or differences which may arise between the Parties, out of or in relation to or in connection with this Agreement, or the breach thereof, and cannot be solved to the mutual satisfaction of the Parties, shall be finally settled by arbitration in accordance with the United Nations Commission on International Trade Law ("UNCITRAL") Arbitration Rules as at present in effect with the following conditions. The award rendered by arbitrators shall be final and binding upon both Parties. a) The number of arbitrators shall be three (3), the first to be nominated by <peer who is the primary on the peering document>, the second by UNA, and the third to be nominated by two (2) aforementioned arbitrators. b) The place of arbitration shall be New York, NY. c) The language to be used in the arbitration proceedings shall be English." I am mostly okay with the format but would like to see the second arbitrator elected by the peer receiving the document and the third arbitrator selected by the UN Arbitration group. Replies are needed to put forth a reasonable document prior to wasting tons of legal time... Credit to the domain name of the reply authors is not what I'm looking for... I'm looking for reasonable expectance that an arbitration method like the outline above would not be out of hand rejected by most legal teams. If you have arbitration language in your document that has been accepted (signed by more than 5 peers) widely please do forward it to me. To prevent outrage, please do not reply to the NANOG list. Thanks in advance for your attention to this matter, -Ren Lauren F. Nowlin, ren(a)onyx.net / peering(a)onyx.net Director, Peering & Interconnects Onyx Networks, Inc., a wholly owned subsidiary of Pacific Gateway Exchange Voice: 650-558-3262, Fax: 650-558-3154, Cellphone: 650-281-6963

3 2

Re: Concurrent bridging & routing on a channelized interface.
by Dean Anderson 10 Nov '99

10 Nov '99

Well, I _think_ channelized T3 looks just like a bunch of T1's to the cisco, and protocol can be set individually--as though there were a mux. That may be wrong. You'll have to figure that out. But, assuming its not: Set them up using frame relay encapsulation, turn on frame relay switching, and enable bridging. Frame relay doesn't do broadcasts, but I seem to recall there is a way to approximate it. I'm not sure that bridging works over frame relay, so you'll have to check that too. Note that you are completely in control of the frame relay network. One router will be DTE, and one will be DCE. You are the frame switch. Good luck. --Dean Around 02:37 PM 11/10/1999 -0500, rumor has it that jeanlou.dupont(a)na.marconicomms.com said: > > > > >Is it possible to concurrently do bridging & IP routing on a DS3 channelized >interface on a cisco router? > >Suppose I have a bunch of customers with T1 coming in through a DS3 channelized >interface and they want to be part of a layer 2 VLAN >& >concurrently have other customers with T1 coming in with IP feeds to the >Internet. > >Any help is appreciated. > >jld. :)) > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Concurrent bridging & routing on a channelized interface.
by jeanlou.dupont＠na.marconicomms.com 10 Nov '99

10 Nov '99

Is it possible to concurrently do bridging & IP routing on a DS3 channelized interface on a cisco router? Suppose I have a bunch of customers with T1 coming in through a DS3 channelized interface and they want to be part of a layer 2 VLAN & concurrently have other customers with T1 coming in with IP feeds to the Internet. Any help is appreciated. jld. :))

1 0

Route Filtering by Network Size
by Marsh, Jerry 10 Nov '99

10 Nov '99

I've changed jobs and been off the NANOG list for some time, so please excuse the question. I know some providers (such as SPRINT) filter BGP routing announcements based on minimum announcement size. The questions are: 1) Who all has such policies? 2) What are the specific sizes and address blocks being filtered? 3) Do they affect "portable" (provider independent) and "non-portable (provider supplied) addressing in the same way. Thanks.

1 0

RE: ARIN's New E-commerce System
by Mark Persiko 10 Nov '99

10 Nov '99

As long as we are talking about ASN registrations, I have a question. How many ISP's currently use a Routing Registry to configure their routers to accept network annoucements from only the AS's in the registry? Thanks, Mark - Mark C. Persiko Network Analyst/Systems Programmer - - Email: persiko(a)bvsd.k12.co.us Boulder Valley School District - -----Original Message----- From: Kim Hubbard [mailto:kimh@arin.net] Sent: Tuesday, November 09, 1999 3:00 PM To: jim(a)reptiles.org Cc: memsvcs(a)arin.net; nanog(a)merit.edu Subject: Re: ARIN's New E-commerce System > > > On Tue, Nov 09, 1999 at 03:52:20PM -0500, Member Services wrote: > > ARIN is now offering its customers the option of submitting payment > > for the registration of Autonomous System Numbers (ASNs) by credit > > card. If your organization submits a request to ARIN and is approved > > to receive an ASN, you can select to either: 1) receive an invoice and > > pay by check, or 2) make your remittance on-line by providing your > > credit account number. > > is this in addition to the fees being levied per ASN by Merit? Merit isn't levying a per ASN fee, they are charging a per maintainer fee for their routing registry. ARIN's fees aren't changing, we're just offering additional payment options for ASNs. Regards, Kim Hubbard ARIN > > -- > [ Jim Mercer jim(a)reptiles.org +1 416 506-0654 ] > [ Reptilian Research -- Longer Life through Colder Blood ] > [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ] >

2 1