- NANOG - lists.nanog.org

Need Solid Sprintlink Contact
by Patrick J. Chicas 13 Mar '97

13 Mar '97

Greetings All, In one of my current lives, we have a need to establish peering connectivity with Sprintlink at their Anahiem POP. I am looking for a solid Sprintlink Sales Engineer that can help. Please, pass on your recommendations. Regards Patrick J. Chicas

1 0

Re: consistent policy != consistent announcements
by Vince Fuller 13 Mar '97

13 Mar '97

> 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. My peer fears that and would like me to fix it. I don't understand how I can do that in a simple maintainable fashion. > More than likely your peer is doing the same thing unto you. Quite possibly, but they won't 'fess up to it. And I don't want to whine at them unless I know how to constructively address the opportunity (the peer is a Californian:-). A correction: the peer individual is definitely not a native Californian, though he does reside there. As best I can tell, we present consistant routes to all of our peers. How do I know this? Because I set up test routers to peer with our public interconnect points and run periodically run my consistancy checker against them. If my peer does not agree that my policy is reasonable and a consequence of current tools, their reaction may be to reject inconsistent announcements thereby increasing the likelihood that no path is propagated. >From our point of view, we aren't seeing any route which can be used for shortest-exit to your multi-homed customers. Why? Probably because we don't peer with the other ISP which serves those customers. The result is that we have to backhaul traffic to other interconnect points, something which is expensive for us and inconsistant with our normal peering policy. I can see why you present inconsistant routes to us but I'm not sure that I understand why you'd prefer a customer prefix via a direct connection to them at one point in your network but via a connection to another provider at a different point in your network. That would seem internally inconsistant to me. Is this deliberate behavior to do shortest-exit within your network toward your customer? --Vince

4 3

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

13 Mar '97

>It's a BGP design point for a router to only announce the route(s) that >it is actively *using*. In your comment above, > >a. If a router has a route it believes is "best", why isn't it using > it? I believe this is why it is called a "policy routing," to force sub-optimal behavior compared to the normal selection algorithm of the routing protocol. You may have a 'best' route to a destination you use internally, but you don't advertise it outside of your AS because of policy reasons. The standard example is not announcing routes heard from peers to other peers. This keeps all of MCI's traffic from being routed through a small customer in the Northwest. You may also have a 'lessor' path, which you would advertise, except its not the 'best' route according to your policy, i.e. a multi-homed customer with unequal cost lines. Policy: Shortest Path X X A X D X D C X D C +----+ +----+ -----| A |-----| B |----- X A B / +----+ +----+ / | \ | X | \ | \ | \ | \ +----+ +----+ ----| D |-----| C |----- X A C +----+ +----+ X X A X A X D X A B Policy: Fastest/Biggest Path between X & A(T1) & D(T3) X D X D A X X D C X C D +----+ +----+ T1-----| A |-----| B |----- X D A B / +----+ +----+ / | \ | X | \ | \ | \ | \ +----+ +----+ T3-----| D |-----| C |----- X D C +----+ +----+ X X D X A X D A X D A B Policy: Shortest Path/Do Not Announce Peer-to-Peer X X A X D +----+ +----+ -----| A |-----| B |----- X A / +----+ +----+ / | \ | X | \ | \ | \ | \ +----+ +----+ -----| D |-----| C |----- X A +----+ +----+ X X A X A X D Policy: Fastest/Biggest Path between X & A & D/Do Not Announce Peer-to-Peer X D X +----+ +----+ T1-----| A |-----| B |----- No Route / +----+ +----+ / | \ | X | \ | \ | \ | \ +----+ +----+ T3-----| D |-----| C |----- X D +----+ +----+ X X D X A >b. Regardless of the answer, the router should announce the route it is > using for its own forwarding. To do otherwise would be to lie about > the path which traffic will take to the advertised destination. > > If policy forbids it from announcing the route it is using, so be > it. (Or, if that's not acceptable change the policy.) Policy is a business decision, not a technical decision. You can be unfair to C by congesting the line XA. Or you can be unfair to B by announcing a longer path XDAB, or no path. Who do you care more about B or C? All animals are equal, but some animals are more equal than others. Yes, you might be able to play enough games with this simple example, to force things to work 'right.' But the mesh is being extended all the time. >By the way, this general fact about BGP (external announcements are >governed by internal route selection) also means that for Randy to >always announce the same route to his peer, he would have to change his >own, internal routing policy to do cold-potato routing to one of the >two candidate paths. This doesn't seem like a reasonable thing for a >peer to demand he do. In any business negotiation, either side can demand whatever they want. But the other side doesn't have to give it to them. This really isn't an operational issue, other than the engineers need to keep their managers informed of the consequences of managerial decisions. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: consistent policy != consistent announcements
by Vince Fuller 13 Mar '97

13 Mar '97

Vince Fuller writes: >I can see why you present inconsistant routes to us but I'm not sure that >I understand why you'd prefer a customer prefix via a direct connection to >them at one point in your network but via a connection to another provider >at a different point in your network. That would seem internally >inconsistant to me. Is this deliberate behavior to do shortest-exit within >your network toward your customer? We have some customers that have specifically requested this sort of arrangement. Hmm. Do you treat the customer routes received from the other peer to be "customer" routes, i.e. will you provide transit for them and re-advertise them to your interconnect peers? If not, then you'll prevent interconnect peers from using shortest-exit to get to those customer routes, which may be considered a problem by those peers. --Vince

2 1

IP over ATM overhead
by Stephen Balbach 13 Mar '97

13 Mar '97

We are installing an ATM backbone connection and wondering what level of overhead can be expected. Ive read from %10 to %50 - this will be a LAN connection so we can assume almost no cell loss. Our provider has said on average %12 bandwidth is overhead. It will be a Cisco->Cisco LAN configuration. Thanks! Stephen Balbach VP ClarkNet

4 3

Re: IP over ATM overhead
by pkavi＠pcmail.casc.com 13 Mar '97

13 Mar '97

The complete answer is that it depends upon packet size distributions. Let's assume that typical Internet type traffic patterns, which tend to have high percentages of packets at 40, 44, and 552 bytes. If you have a DS3 backbone, and have PLCP turned on, the maximum cell rate is 96,000 cells/sec. If you multiply this value by the number of bits in the payload, you get: 96000 cells/sec * 48 bytes/cell * 8 = 36.864 Mbps But this is unrealistic, as it assumes perfect payload packing. There are two other things that eat into the overhead value, namely the wasted padding, and the 8 byte SNAP header. It's the SNAP header which causes most of the problems, forcing most small packets to consume two cells, with the second cell to be mostly empty padding. This causes a loss of about another 16% from the 36.8 Mbps ideal throughput. So the total throughput ends up being (for a DS3): DS3 Line Rate: 44.736 PLCP Overhead - 4.032 Per Cell Header: - 3.840 SNAP Header & Padding: - 5.900 ========= 30.960 Mbps So, from a DS3 line rate of 44.736 Mbps, the total overhead is about 31%. Hope this helps. Prabhu Kavi Manager, Network Architecture Group Cascade Communications. ______________________________ Reply Separator _________________________________ Subject: IP over ATM overhead Author: Stephen Balbach <stephen(a)clark.net> at SMTPLINK Date: 3/13/97 10:47 AM We are installing an ATM backbone connection and wondering what level of overhead can be expected. Ive read from %10 to %50 - this will be a LAN connection so we can assume almost no cell loss. Our provider has said on average %12 bandwidth is overhead. It will be a Cisco->Cisco LAN configuration. Thanks! Stephen Balbach VP ClarkNet

1 0

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 13 Mar '97

13 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