- Test - lists.nanog.org

Cisco 7513/HSA
by Lowell Hanson 11 Mar '96

11 Mar '96

This may not be the exact purpose of this forum, but I am interested in your experience since this group has an obvious interest in High Performance and High Systems Availability of routers. We have a 7505, 7507, 7513 and another 7513 on its way. We were under the impression that we would soon be able to use the dual RSP2 capability of some of these routers soon, like maybe this week. Upon loading 11.1 we, of course, found out that it did not work at all with both processors installed. Tech Support concurred that at least 11.2 would be needed and no date has been set for its release. Does anyone have and experience or information contrary to this? If so I would certainly like to hear from you! Thanks! Lowell Lowell K. Hanson http://www2.dgsys.com/~lkh Philip Morris Network Services lkh(a)dgsys.com 804-274-5462

1 0

new A
by asp＠uunet.uu.net 11 Mar '96

11 Mar '96

It looks like we picked up yet another /8... --asp(a)uunet.uu.net (Andrew Partan) * 4.0.0.0 192.41.177.180 10 0 3561 86 1 i *>i 198.32.136.14 10 100 0 1 i

3 2

Re: RS transparency survey
by hcb＠clark.net 08 Mar '96

08 Mar '96

Jake's comments on RS transparency relate directly to a discussion in the Routing Policy Specification working group. I would hope that all interested parties define a consistent approach to the problem. >From my rough notes for RPS: There was extensive discussion of mechanisms to split route advertisements among specific routers rather than an AS-wide basis. Sue Hare described to problem of wanting to send half the traffic on one router, and half the traffic on another. It was observed that such a policy should be stored in registries, but the current language does not describe this policy. There was discussion whether registries should stay at the AS level, or go down to the interas-in/out level. It was also observed that traffic policies may be outside the scope of the RPS WG. For the case AS1-------+ | | AS4------>AS2 (RS) Cengiz proposed adding a "via" option to the AS-IN statement, as: as-in: from AS1 via AS4 5 accept AS1 Where AS4 is the route server, it might have full routes where true AS1 does not. What is difference between accept from AS4 (the RS) and accept from AS1 via AS4? It was suggested this might be a local preference This allows specification of the source of the route advertisement. Allows taking from RS rather than drectly peering. Route server does not insert himself into path where peering normally would do so. Sue cited a case where half the policies are in the RS and half in the originating [transit] AS BGP speaker. This raised a more basic question: is a route server transparent? Filtering down to router is more specific, but AS filtering provides a higher level of abstraction. Sue prefers to support an AS filtering need Abecause that has been seen with real customers while router solution has not been seen. The discussion did not reach a complete conclusion. Several emails were sent to the group between the two RPS WG meetings: Jerry Scharf said, There was a discussion that happened after the meeting that made things much clearer to me, and might help others as well. We have mixed two things together. One is what routes are seen in the receiving AS, which is the routing policy. The second is whether the route server will send those routes along. The second one can not be cleanly expressed by policy, since even to the receiving AS this can not be seen in any table (only the BGP session byte counts would be different.) Cengiz responded with the model AS2 AS1 | | -|---|-----|- | AS4 While aut-num: AS2 as-in: from AS1 via AS4 accept AS1 can be written as as-in: from AS4 accept AS1 AND <^AS4 AS1> (assuming we make RS's AS visible in this fashion), the following can not: aut-num: AS1 as-out: to AS2 via AS4 announce AS1 (as-out: to AS4 announce AS1 does not tell who the route server can pass AS1's routes). Anyway, I will look into alternate ways of doing this. Perhaps a routeserver specific solution is the best. >### On Wed, 06 Mar 1996 22:01:52 -0500, "Jake Khuon" <khuon(a)Merit.Net> wrote >### to "North American Network Operator's Group Mailing List" >### <nanog(a)Merit.Net> concerning "RS transparency survey": > >JK> Some of you may have noticed that the RSes have stopped injecting their ASN >JK> into the ASPath expression. This was a feature I have just recently turned >JK> on to meet the original design goals of the project. As per >specification, >JK> the RSes were to be transparent in its operation. >JK> >JK> I realise I may have erred by doing this without asking the community >first. >JK> Therefore, I would like to take a poll as to what everyone prefers. I can >JK> turn the ASN injection back on in a peer-by-peer basis if necessary. I >JK> sincerely apologise if this has caused any confusions and/or problems. > >I will be rolling back transparency status of the RS to all peers with >exception of those who have responded saying they like not seeing the RS's >AS in the ASPath. I will turn on transparency in the future for anyone who >wishes it. Simply send me a request. > >Additionally, I've updated the peering request template >(http://www.ra.net/.peering.template.html) allowing you to >specify whether or not you wish to have the RS peer transparently. > > >-- >/*===================[ Jake Khuon <khuon(a)Merit.Net> ]======================+ > | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | > | VOX: (313) 763-4907 FAX: (313) 747-3185 / |/ |[_|\| | Incorporated | > +==[ Suite C2122, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 ]==*/

3 2

Re: RS transparency survey
by Jake Khuon 07 Mar '96

07 Mar '96

### On Wed, 06 Mar 1996 22:01:52 -0500, "Jake Khuon" <khuon(a)Merit.Net> wrote ### to "North American Network Operator's Group Mailing List" ### <nanog(a)Merit.Net> concerning "RS transparency survey": JK> Some of you may have noticed that the RSes have stopped injecting their ASN JK> into the ASPath expression. This was a feature I have just recently turned JK> on to meet the original design goals of the project. As per specification, JK> the RSes were to be transparent in its operation. JK> JK> I realise I may have erred by doing this without asking the community first. JK> Therefore, I would like to take a poll as to what everyone prefers. I can JK> turn the ASN injection back on in a peer-by-peer basis if necessary. I JK> sincerely apologise if this has caused any confusions and/or problems. I will be rolling back transparency status of the RS to all peers with exception of those who have responded saying they like not seeing the RS's AS in the ASPath. I will turn on transparency in the future for anyone who wishes it. Simply send me a request. Additionally, I've updated the peering request template (http://www.ra.net/.peering.template.html) allowing you to specify whether or not you wish to have the RS peer transparently. -- /*===================[ Jake Khuon <khuon(a)Merit.Net> ]======================+ | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | | VOX: (313) 763-4907 FAX: (313) 747-3185 / |/ |[_|\| | Incorporated | +==[ Suite C2122, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 ]==*/

1 0

Re: RS transparency survey
by Jessica Yu 07 Mar '96

07 Mar '96

Jake: How about doing the following: By default, insert RS's AS in the path unless otherwise requested by the peer? There is a RS peer request template which might be a good place to allow new peers to specify if they want the AS inserted or not. Please re-insert the RS's AS for the RS peer session with AS690 for now. Thanks! --Jessica ------- Forwarded Message Return-Path: nanog-owner(a)merit.edu Received: from interlock (interlock.ans.net [147.225.5.2]) by cannes.aa.ans.net (8.7.4/8.7.3) with SMTP id XAA11095 for <jyy(a)cannes.aa.ans.net>; Wed, 6 Mar 1996 23:07:24 -0500 (EST) Received: from merit.edu by interlock with SMTP id AA11622 (InterLock SMTP Gateway 3.0 for <jyy(a)ans.net>); Wed, 6 Mar 1996 23:07:17 -0500 Received: (from daemon@localhost) by merit.edu (8.7.4/merit-2.0) id WAA21066 for nanog-outgoing; Wed, 6 Mar 1996 22:00:42 -0500 (EST) Received: from merit.edu (espresso.merit.net [198.108.60.61]) by merit.edu (8.7.4/merit-2.0) with ESMTP id WAA21060 for <nanog(a)Merit.Net>; Wed, 6 Mar 1996 22:00:37 -0500 (EST) Message-Id: <199603070300.WAA21060(a)merit.edu> From: "Jake Khuon" <khuon(a)Merit.Net> To: "North American Network Operator's Group Mailing List" <nanog(a)Merit.Net> Subject: RS transparency survey Reply-To: khuon(a)Merit.Net (Jake Khuon) Priority: Normal X-Uri: http://Espresso.Merit.Net/~khuon/ X-Organisation: Merit Network, Inc. X-Mailer: MH 6.8.4 #4[UCI] (Espresso.Merit.Net) of Mon Feb 19 15:14:03 EST 1996 Date: Wed, 06 Mar 1996 22:01:52 -0500 Sender: owner-nanog(a)merit.edu Precedence: bulk Content-Type: text Content-Length: 890 Some of you may have noticed that the RSes have stopped injecting their ASN into the ASPath expression. This was a feature I have just recently turned on to meet the original design goals of the project. As per specification, the RSes were to be transparent in its operation. I realise I may have erred by doing this without asking the community first. Therefore, I would like to take a poll as to what everyone prefers. I can turn the ASN injection back on in a peer-by-peer basis if necessary. I sincerely apologise if this has caused any confusions and/or problems. - -- /*====================[ Jake Khuon <khuon(a)Merit.Net> ]=====================+ | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | | Vox: (313) 763-4907 Fax: (313) 747-3185 / |/ |[_|\| | Incorporated | +==[ Suite C2122, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 ]==*/ ------- End of Forwarded Message

1 0

RS transparency survey
by Jake Khuon 07 Mar '96

07 Mar '96

Some of you may have noticed that the RSes have stopped injecting their ASN into the ASPath expression. This was a feature I have just recently turned on to meet the original design goals of the project. As per specification, the RSes were to be transparent in its operation. I realise I may have erred by doing this without asking the community first. Therefore, I would like to take a poll as to what everyone prefers. I can turn the ASN injection back on in a peer-by-peer basis if necessary. I sincerely apologise if this has caused any confusions and/or problems. -- /*====================[ Jake Khuon <khuon(a)Merit.Net> ]=====================+ | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | | Vox: (313) 763-4907 Fax: (313) 747-3185 / |/ |[_|\| | Incorporated | +==[ Suite C2122, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 ]==*/

1 0

NANOG NOTES COMPLETED
by sob＠academ.com 06 Mar '96

06 Mar '96

All of my notes are now on-line from the last meeting. I still have to add the notes from the speakers themselves. That will come as time permits. http://www.academ.com/nanog/feb1996/index.html is the root URL for these notes. Enjoy. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: ISP list
by Ehud Gavron 05 Mar '96

05 Mar '96

>Is there a list of all the registered ISPs out there? Hope this is the right >place to ask this. Thanks... Are you tired of going to all those regular ISPs out there? Are you tired of those so-called professional ISPs. We are the American Society of Registered ISPs and we are the real thing. When you call now, you get a FREE sample IP packet. "I was down on my luck. Then I tried the American Society of Registered ISPs. WOW, what a difference! Their FREE sample IP packets had headers and a real TTL and IHL and everything!" "I was worried about fortune, love, and marriage. I called the American Society of Registered ISPs. My IP counselor helped me and I didn't even give them my name! All I can say is WOW, what a difference." Hear more testimonials from our satisfied customers, or, see for yourself. Just dial 1-911-CYBERSPACE for your free sample IP packets today*. > >> Bharat << > mm mm sssss nnnnnn * Bharat Ranjan > m m m s nnnnnnn * Network Engineer > m m m sssss nn nn * Microsoft On-Line Services > m m s nn nn * (206)-936-0471 > m m sssss nn nn * bharatr(a)microsoft.com Ehud -- Ehud Gavron (EG76) gavron(a)Hearts.ACES.COM * Unsolicited Commercial E-Mail will cost $500/message under USC 47 * * which can be found online at http://www.law.cornell.edu/uscode/47/ * * Free sample IP packets two only. All other packets billed at the InternetMCI per-packet rate to be applied in March.

3 2

unsubscribe (fwd)
by Elise Gerich 01 Mar '96

01 Mar '96

I'm sorry to send this to the list, but so many folks seem to be unaware that they can unsubscribe without alerting the whole list. If you would like to unsubscribe, please do so by mailing your request to: nanog-request(a)merit.edu with the word unsubscribe in the body of the note. The majordomo software will handle this just fine and you will avoid posting your request to the entire list. Thank you. --Elise >Quad writes: > From list-admin(a)merit.edu Fri Mar 1 15:13:11 1996 > Date: Fri, 1 Mar 1996 10:52:13 -0800 > Message-Id: <2.2.16.19960301105256.09b75f7e(a)best.com> > X-Sender: quad(a)best.com > X-Mailer: Windows Eudora Pro Version 2.2 (16) > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > To: "nanog" <nanog(a)merit.edu> > From: Quad <quad(a)best.com> > Subject: unsubscribe > > unsubscribe > >

1 0

Using CIDR and NAT in mid-level systems
by Tim Bass 01 Mar '96

01 Mar '96

FYI: A draft postscript version of a paper for the EARTHEN BOF is available for preview: http://www.silkroad.com/ietf/preview.ps Comments welcome. The last section about 'Further Research' is under construction and not included in version 0.4 (this draft). Best Regards, Tim +------------------------------------------------------------------------+ | Tim Bass | | | Principal Network Systems Engineer | "... the fates of men are bonded | | The Silk Road Group, Ltd. | one to the other by the cement | | | of wisdom." | | http://www.silkroad.com/ | Milan Kundera | | | | +------------------------------------------------------------------------+

1 0