- Test - lists.nanog.org

MAE ATMs... guessing & monitoring... in the absense of PeerMaker
by Lauren F. Nowlin 12 Nov '99

12 Nov '99

Hi all, More operational today than usual... "PeerMaker" with all the bells & whistles (i.e. any monitoring capability at the MAE ATM NAPs) has been shelved until next year due to 'performance hiccups' Great. This problem doesn't arise at AADS or PBNAP because the silly guesstimates and ceilings for sustained cell rate and assigned PVC sizes aren't an issue. It would seem noc troubleshooting MAE ATM cell drops would be nightmare if the peer is having an event or somesuch... I just spoke to a couple of peers with circuits soon to arrive (same boat Onyx is in) and we are wondering why we have to supply this guess if there isn't a way to monitor and make proper adjustments when necessary. My MAE account rep. is on vacation. Looking for feedback from participating peers... via private mail please. Thanks, -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

1 0

Y2K rollover status report participation
by Sean Donelan 12 Nov '99

12 Nov '99

Its getting towards the end, and I didn't want anyone to say "Nobody asked me." The reporting channels for a few of the major ISPs is established, but I didn't want to leave important folks out, e.g. exchange points, route servers, root servers, measurement servers, and anyone else with something to contribute. I will be using this information to make a list of which part of the Internet is being handled by which status reporting organization. For the parts of the Internet otherwise not being handled, I plan to set up a couple of very simple reporting methods. Since I don't think the Internet will be affected too much, it will be via standard Internet communications, including regular status templates via e-mail, a multicast sesssion, and possibly one or two others (we know USENET works during an earthquake). There is essentially no time to develop anything more than the simplest status reporting using time-tested methods. I expect most reports to be "Situation Normal, Nothing to Report." For exception reporting, there will be an out-of-band method and the details will be provided to those participating. Since e-mail and the other methods can handle much larger groups than a teleconference bridge, I expect to be able to handle a large group with only a few volunteers over those days. Yes, I also need a few people to do some work. Send e-mail if interested. No pay, but I will have a cool T-shirt for those who work. If you already believe you have a reporting channel (e.g. IOPS, NCS, Y2K/CC, PR Newswire), please fill this out. If you don't know or don't have one, and would like one, please enter "NEED" as your reporting channel. Under "Reporting For:" for networks enter the ASNs of the networks you will be responsible for reporting (e.g. don't list customers unless you will explicitly be reporting customer status), for root servers enter the machine name (e.g. a.root-servers.net) for exchange points enter the name of the exchange point and IP network(s) used, for other services enter whatever reasonably unique identify I can use. Organization Name: Reporting Channel: Reporting For: Admin Contact: Admin Address 1: Admin Address 2: Admin City: Admin State/Province: Admin Zip/Postal Code: Admin Country: Admin Voice Number: Admin Fax Number: Admin Email: I need this information no later than November 18, 1999. I can't add anyone after that point. As always, you could always decide later not to participate. Note: please send replies to sean(a)donelan.com, unless you really want to copy the entire nanog list.

1 0

PSI/Digex announcements
by Joe Shaw 11 Nov '99

11 Nov '99

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."

2 2

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