March 1997 - Test - lists.nanog.org

Re: consistent policy != consistent announcements
by Sean Donelan 13 Mar '97

13 Mar '97

>Therefore I will not announce any route to M to my peers in some locations, >as I don't announce peers to other peers, and in others I will announce "C >M". Again, I do not make identical announcements to my peers, yet I have a >consistent policy. Yep, policy filters run up against the policy of only announcing the single, best route. I've been thinking with policy filters and variable weighting, should it be changed to announcing the 'best' route that meets policy, even if it is the second or third 'best' route you know about. >Am I being unfair to my peers? Would they be justified in making a stronger >requirement than 'consistent' policy? What requirement would be reasonable? >[ note that, in the first example, the common policy of preferring customer >routes over peer routes will not change my announcements. ] Fairness by what measure, and to which peers? My first concern is the loss of information when the route to M isn't announced. This causes unfairness when traffic ends up taking the 'long' route. Since we don't have a full-mesh among peering partners, the unfairness of the long route could be considered a normal part of today's Internet, like asymetrical routing. More than likely your peer is doing the same thing unto you. The second effect of M's route not being announced happens when traffic is blocked because no 'longer' path shows up anywhere else due to different route weightings and policy filters across various combinations of ASs. I consider this possibility the more serious problem. As the peering mesh becomes sparser, expect more missing in action paths, even if the physical connections exist the 'best' path may not be announced. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

consistent policy != consistent announcements
by randy＠psg.com 13 Mar '97

13 Mar '97

[ Most of this work was done by Andrew ] A normal condition of peering between consenting adults is that the peers have consistent policy across all points where they peer. This is to allow hot potato, whereby I can get rid of my packets destined for a peer at my nearest exit to them. A naive assumption we make is that this means that the peers will be making the same announcements to each other at all points. This turns out to not always be the case. I have customer A who connects to multihomed site M. I also have customer B who also connects to M. I will see M as either "A M" or "B M", equal length AS paths. depending on whether I am closer to A or B. So in some portions of my network, I will prefer to get to M via A and in others I will prefer to go via B. Thus I will announce to my peers in some locations "A M" and in others "B M". The result is that I do not give the same announcements to my peers at all locations, yet I have a consistent, simple, and seemingly reasonable policy. In another example, I have a peer P who connects to multihomed site M. I also have a customer C who connects to the multihomed site M. I will see M as either "P M" or "C M" - again equal length AS paths. If I follow the 'normal' BGP path selection rules (and don't always prefer customers over peers), then in some portions of my network, I will prefer M via P and in others I will prefer M via C. Therefore I will not announce any route to M to my peers in some locations, as I don't announce peers to other peers, and in others I will announce "C M". Again, I do not make identical announcements to my peers, yet I have a consistent policy. Am I being unfair to my peers? Would they be justified in making a stronger requirement than 'consistent' policy? What requirement would be reasonable? [ note that, in the first example, the common policy of preferring customer routes over peer routes will not change my announcements. ] randy

2 1

Re: How to protect registered IP addresses
by chris＠netasset.com 13 Mar '97

13 Mar '97

On Thu, Mar 13, 1997, 3:39:29 AM PST George Herbert wrote: > >I believe you can just deny by default and allow traffic from the >registered address blocks under each interface, on incoming interfaces >at your central router (and sub-routers). Nice short list. > >-george william herbert >gherbert(a)crl.com > This is obviously better then nothing, and probably the most practical solution, but most networks have holes in their allocated blocks. Wouldn't some sort of authentication scheme (RADIUS/TACACS or maybe Kerbros) be a better solution? More complicated for sure. The idea would be to check the connection request to the outgoing router against some sort of database, then expiring the token after it's use. The real trick to this is checking only the initial request. Something more in the realm of switching authentication... Anyone have any ideas how something as large as a class B with say 30% address utilization on scattered addresses (non-contigeous) could be rapidly verified without checking every packet? Thanks for your indulgance, Chris Cook Network Engineer __________________________________________________________________________ Net Asset Network Operations Center 1315 Van Ness Ave., Suite 103 Fresno CA 93721 209/225-0222

2 1

How to protect registered IP addresses
by Sun Wei 12 Mar '97

12 Mar '97

Hi, Internet Experts, I run into a problem these days. We have a campus network with a class B IP block. This network is connected with Internet. By now, we have thousands of registered users and allocate IP addresses to them. Recently, we installed an accouting system to monitor how much traffic each user had accounted for. Each month, these users should pay their bills based on how much traffic they have used. Soon, we find some problems: Some guys are using the unallocated addresses, and they are accessing Internet wildly; At the same time, other anonymous users are using illegally the addresses of registered users. Here my questions are: First, Is there any better solution to protect the unallocated addresses --- besides access-list? The first selection seems to be adding access-lists on the routers, to block all the unallocted addresses. However, considering the quantity of the IP addresses(a class B), it sure is a great burden to block the addresses one by one(or almost one by one). I'm not sure if cisco routers support such long access-list. Second, how can we protect the IP addresses of registered users from being used by other people ? Any tips are greatly appreciated! regards, Wei Sun

2 1

New email address and telephone numbers
by Danny Stroud 12 Mar '97

12 Mar '97

I finally got set up with a GES Internet mail account. Please update your address books with this address. Also, if you don't have it, note the new phone and fax numbers. This should make a lot of you happy that I no longer use the un-cool .msn address! Thanks, des ____________________________________________________ Danny E. Stroud President GES Internet t: 609-514-3792 f: 609-514-9010 e: stroud(a)ges.com

1 0

Boston MXP Meeting
by sgarfink＠hq.mainet.com 12 Mar '97

12 Mar '97

This is MAI's official notice for the Boston MXP Meeting on Friday: The Boston MXP Meeting will be held in Boston City Hall this coming Friday, March 14th, at 2pm. We must receive your reply for you to gain entrance. Please let us know the number of people you wish to bring, as well as their names. We look forward to seeing you there and to your participation in the Boston MXP. Please RSVP to noc(a)mai.net. The meeting will take place in the MIS Conference Room (room 200) in City Hall. City of Boston CIO (Chief Information Officer) Michael Hernon will attend. Lunch will be provided. For more information on the Boston MXP, see: http://www.mai.net/bostonmxp To join the Boston-MAX list, please email boston-max(a)hq.mainet.com with subscribe in the body. More good news for the Boston MXP! In the foreseeable future, the Boylston St. collocation will be bridged to a collocation facility in 1 City Hall Plaza to provide additional rack space for all MXP members. Please send all questions/flames to noc(a)mai.net! Thank you. Now returning you to your regularly scheduled brangles... Sarah Garfinkel Network Support Specialist MAI Network Services - http://www.mai.net 1-888-624-2780

1 0

Re: AS1
by Tony Tauber 12 Mar '97

12 Mar '97

On Mar 12, 10:51am, Alexandre Leib Grojsgold wrote: > Subject: AS1 > A "sh ip bgp 200.255.71.0" command executed in a router connected to > MAE-EAST shows an AS-path of 1 7365. > > Could someone tell me what is AS1 ?? > > TIA > Alexandre. > >-- End of excerpt from Alexandre Leib Grojsgold noc-~ 169: whois 1 BBN Planet (ASN-BBN) BBNPLANET 1 Gives a boost to know your #1, sometimes. 8-) Tony

1 0

Re: AS1
by Danny McPherson 12 Mar '97

12 Mar '97

(danny@cognition):~$ whois 1 BBN Planet (ASN-BBN) BBNPLANET 1 IANA (RESERVED-9) RESERVED-9 1.0.0.0 To single out one record, look it up with "!xxx", where xxx is the handle, shown in parenthesis following the name, which comes first. The InterNIC Registration Services Host contains ONLY Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. (danny@cognition):~$ whois ASN-BBN BBN Planet (ASN-BBN) 150 Cambridge Park Dr. Cambridge, MA 02140 Autonomous System Name: BBNPLANET Autonomous System Number: 1 Coordinator: Curran, John (JC347) jcurran(a)BBNPLANET.COM (617) 873-4398 Record last updated on 08-Dec-95. The InterNIC Registration Services Host contains ONLY Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. -danny > A "sh ip bgp 200.255.71.0" command executed in a router connected to > MAE-EAST shows an AS-path of 1 7365. > > Could someone tell me what is AS1 ?? > > TIA > Alexandre. >

1 0

AS1
by algold＠lambda.lncc.br 12 Mar '97

12 Mar '97

A "sh ip bgp 200.255.71.0" command executed in a router connected to MAE-EAST shows an AS-path of 1 7365. Could someone tell me what is AS1 ?? TIA Alexandre.

3 2

Re: Class "B" forsale (fwd)
by Paul Ferguson 11 Mar '97

11 Mar '97

At 10:07 AM 3/9/97 -0500, Golan Ben-Oni wrote: >> Next time you rent a car, when you finish driving over the things that can >> kill your tires. Just yell to the guy 'Possession is 9/10'th of the law' >> and never come back. > >Only, they've got signed paperwork which encourages you to return the >rental when you're not using it. > And pay for damages. ;-) - paul

8 11