multi-homing without the BGP (was RE: Packet Loss)
I will spare everyone my own personal experiences as of late in dealing with ARIN for a /20. How about some talk on this topic, multi-homing without the application of the BGP, a pressing concern amongst mid-level ISPs and small dot com's. Jade P.S. Mr. Jimmerson... I want a /20, and a pony. Give me a /20 and a pony, I want a pony!!!! Jade E. Deane Network Engineer helloNetwork.com Las Vegas, Nevada Office: +1 (702) 938-9267 Cell: +1 (702) 604-4759 Fax: +1 (702) 456-1471 email: jade.deane@helloNetwork.com urgent epage: 7026044759@page.nextel.com
Jade, You don't really need a /20 to multihome or use BGP. Just get an ASN, multiple providers, and advertise your space. There are a couple ways to deal with those who will filter smaller blocks. One way is to get two providers, get space from one or both with a block larger than a /21. Ensure that the two providers peer directly with each other, and that they will advertise blocks smaller than a /20 to each other (/24 is a more normal filtering level these days). Also ensure that whichever of the upstreams that is giving you the space advertises it as the larger, less specific, aggregate as well. Given this situation, you should be fine. If your connection to the ISP announcing the globally routable aggregate goes down, it will still announce the aggregate, then route your traffic to the more specific route in the block being announced by it's peer. Works like a charm. - Dan Golding NetRail, Inc. -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Jade E. Deane Sent: Friday, December 15, 2000 1:23 PM To: 'nanog@merit.edu' Subject: multi-homing without the BGP (was RE: Packet Loss) I will spare everyone my own personal experiences as of late in dealing with ARIN for a /20. How about some talk on this topic, multi-homing without the application of the BGP, a pressing concern amongst mid-level ISPs and small dot com's. Jade P.S. Mr. Jimmerson... I want a /20, and a pony. Give me a /20 and a pony, I want a pony!!!! Jade E. Deane Network Engineer helloNetwork.com Las Vegas, Nevada Office: +1 (702) 938-9267 Cell: +1 (702) 604-4759 Fax: +1 (702) 456-1471 email: jade.deane@helloNetwork.com urgent epage: 7026044759@page.nextel.com
On Fri, 15 Dec 2000, Daniel Golding wrote:
advertise blocks smaller than a /20 to each other (/24 is a more normal filtering level these days). Also ensure that whichever of the upstreams
Is it safe to assume[*] that an announced /23 will not be filtered by any major (or even the minor) backbones? We just got our ARIN allocation (and I won't go into that, the lag time was all my fault), and I'm currently planning allocation for some remote offices and a couple of hosted buildouts. I'm hoping to not have to announce anything larger than a /23 from any one site unless necessary. -j [*] - It's never safe to assume anything internet related; relatively speaking, is it safe... -Jonathan Disher -Systems and Network Engineer, Web Operations -Internet Pictures Corporation, Palo Alto, CA -[v] (650) 388-0497 | [p] (877) 446-9311 | [e] jdisher@eng.ipix.com
Jonathan, It is not safe to assume that. Verio, amongst others, still filters at ARIN allocation boundaries. Also, those trying to subnet old class B address blocks, will have significant problems, even at the /17 level. If you have upstream(s) willing to advertise aggregates for you, that's the best way to handle this problem in a discontiguous network. - Dan Golding NetRail, Inc. -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Jonathan Disher Sent: Friday, December 15, 2000 2:43 PM To: nanog@merit.edu Subject: Filtering levels (was RE: multi-homing without the BGP (was RE: Packet Loss)) On Fri, 15 Dec 2000, Daniel Golding wrote:
advertise blocks smaller than a /20 to each other (/24 is a more normal filtering level these days). Also ensure that whichever of the upstreams
Is it safe to assume[*] that an announced /23 will not be filtered by any major (or even the minor) backbones? We just got our ARIN allocation (and I won't go into that, the lag time was all my fault), and I'm currently planning allocation for some remote offices and a couple of hosted buildouts. I'm hoping to not have to announce anything larger than a /23 from any one site unless necessary. -j [*] - It's never safe to assume anything internet related; relatively speaking, is it safe... -Jonathan Disher -Systems and Network Engineer, Web Operations -Internet Pictures Corporation, Palo Alto, CA -[v] (650) 388-0497 | [p] (877) 446-9311 | [e] jdisher@eng.ipix.com
Depends on what class it's in. Let me explain further. Verio, in their infinite wisdom, has decided that they are going to throw CIDR right out the window. We own 64.240.0.0-64.242.255.255. We advertise MANY smaller blocks of this space obviously, and what we have found is that in that space (since it is "Class A" space, remember we don't know what CIDR is since we're Verio) is that Verio does not accept anything smaller than a /20. Now many of our customers run BGP with us and advertise a /24 only, I guess they're SOL as far as Verio is concerned (actually if it's our space they're probably going to see the larger aggregate as well, so it's not as big of a deal, but still mighty annoying). Oh, and did I mention that Verio isn't even one of our peers? Oh well. On Fri, 15 Dec 2000, Jonathan Disher wrote:
On Fri, 15 Dec 2000, Daniel Golding wrote:
advertise blocks smaller than a /20 to each other (/24 is a more normal filtering level these days). Also ensure that whichever of the upstreams
Is it safe to assume[*] that an announced /23 will not be filtered by any major (or even the minor) backbones? We just got our ARIN allocation (and I won't go into that, the lag time was all my fault), and I'm currently planning allocation for some remote offices and a couple of hosted buildouts. I'm hoping to not have to announce anything larger than a /23 from any one site unless necessary.
-j
[*] - It's never safe to assume anything internet related; relatively speaking, is it safe...
-Jonathan Disher -Systems and Network Engineer, Web Operations -Internet Pictures Corporation, Palo Alto, CA -[v] (650) 388-0497 | [p] (877) 446-9311 | [e] jdisher@eng.ipix.com
On Sun, 17 Dec 2000 nanog@rmrf.net wrote:
Depends on what class it's in. Let me explain further. Verio, in their infinite wisdom, has decided that they are going to throw CIDR right out the window. We own 64.240.0.0-64.242.255.255. We advertise MANY smaller blocks of this space obviously, and what we have found is that in that space (since it is "Class A" space, remember we don't know what CIDR is since we're Verio) is that Verio does not accept anything smaller than a /20. Now many of our customers run BGP with us and advertise a /24 only, I guess they're SOL as far as Verio is concerned (actually if it's our space they're probably going to see the larger aggregate as well, so it's not as big of a deal, but still mighty annoying). Oh, and did I mention that Verio isn't even one of our peers? Oh well.
Maybe if you aggregated your announcements instead of feeding a /14 to us as /22, /23, and /24 blocks, it wouldn't be necessary to do minimum-allocation filtering. -travis
Travis, By doing a summary-only aggregate, you can lose routing information that your downstreams want seen by the global internet. A good example of this is prepending. If I only advertise a /14, then supress a /24 that is subordinate to that block, I may fail to advertise a prepend upon that /24 block. Paying customer don't like stuff like that. BTW, ARIN is pretty clear that it's allocation policies are NOT intended for use as filtering criteria. Most folks seem to get along fine, filtering at the /24 level. It's not like most core routers at large ISPs are 7500s with 64mb anymore. - Daniel Golding On Sun, 17 Dec 2000, Travis Pugh wrote:
On Sun, 17 Dec 2000 nanog@rmrf.net wrote:
Depends on what class it's in. Let me explain further. Verio, in their infinite wisdom, has decided that they are going to throw CIDR right out the window. We own 64.240.0.0-64.242.255.255. We advertise MANY smaller blocks of this space obviously, and what we have found is that in that space (since it is "Class A" space, remember we don't know what CIDR is since we're Verio) is that Verio does not accept anything smaller than a /20. Now many of our customers run BGP with us and advertise a /24 only, I guess they're SOL as far as Verio is concerned (actually if it's our space they're probably going to see the larger aggregate as well, so it's not as big of a deal, but still mighty annoying). Oh, and did I mention that Verio isn't even one of our peers? Oh well.
Maybe if you aggregated your announcements instead of feeding a /14 to us as /22, /23, and /24 blocks, it wouldn't be necessary to do minimum-allocation filtering.
-travis
Hi Daniel. You're entirely correct, in the case of a multihomed customer who needs routing information propagated. However, I differentiate between wholesale deaggregation and an ISP that takes care of multihomed customers' needs. To me, there's a believability factor in people claiming that they do large-scale deaggs for their customers. Part of that believability is doing due diligence on what they announce, and part of it is doing due diligence on what their customers announce. It doesn't appear that any of that has been done here, which makes me skeptical. A bunch of /25 and greater adverts from 6347, and a bunch of /30s from customer ASNs, won't convince me that anyone needs to relax their filters any time soon. Some snippets from nitrous: *>i64.240.169.224/27 209.44.160.105 4294967294 100 0 6347 i *>i64.241.182.128/25 209.83.160.22 4294967294 100 0 6347 i *>i64.242.80.0/27 209.44.160.105 4294967294 100 0 6347 i *>i209.44.23.160/28 64.241.88.17 4294967294 100 0 6347 i *>i209.83.163.128/26 209.83.160.22 4294967294 100 0 6347 i *>i209.83.182.208/28 209.83.160.22 4294967294 100 0 6347 i *>i209.102.112.4/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.8/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.208/28 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.232/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.240/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.244/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.248/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.8/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.12/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.16/29 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.24/29 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.32/28 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.48/28 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.126.143.192/27 209.44.160.105 4294967294 100 0 6347 i *>i209.144.220.128/25 209.44.160.105 4294967294 100 0 6347 i *>i209.223.197.128/27 209.83.160.22 4294967294 100 0 6347 i *>i209.242.13.152/29 64.241.88.17 4294967294 100 0 6347 10692 13950 i *>i209.242.13.204/30 64.241.88.17 4294967294 100 0 6347 10692 13950 i *>i209.242.13.212/30 64.241.88.17 4294967294 100 0 6347 10692 13950 i *>i209.242.13.216/30 64.241.88.17 4294967294 100 0 6347 10692 13950 ? *>i209.242.13.220/30 64.241.88.17 4294967294 100 0 6347 10692 13950 ? On Sun, 17 Dec 2000, Daniel L. Golding wrote:
Travis,
By doing a summary-only aggregate, you can lose routing information that your downstreams want seen by the global internet. A good example of this is prepending. If I only advertise a /14, then supress a /24 that is subordinate to that block, I may fail to advertise a prepend upon that /24 block. Paying customer don't like stuff like that.
BTW, ARIN is pretty clear that it's allocation policies are NOT intended for use as filtering criteria. Most folks seem to get along fine, filtering at the /24 level. It's not like most core routers at large ISPs are 7500s with 64mb anymore.
- Daniel Golding
Travis, I think the way to fix this is to use non-summary aggregates in combination with reasonable prefix limit filters - nothing smaller than /24. This is a fair combination of cutting down on extraneous route advertisements, and preserving customer route informations. I certainly agree that advertising /30s to peers is unacceptable. How does it go? "Be liberal in what you accept, be conservative in what you advertise". - Daniel Golding On Sun, 17 Dec 2000, Travis Pugh wrote:
Hi Daniel.
You're entirely correct, in the case of a multihomed customer who needs routing information propagated. However, I differentiate between wholesale deaggregation and an ISP that takes care of multihomed customers' needs.
To me, there's a believability factor in people claiming that they do large-scale deaggs for their customers. Part of that believability is doing due diligence on what they announce, and part of it is doing due diligence on what their customers announce. It doesn't appear that any of that has been done here, which makes me skeptical. A bunch of /25 and greater adverts from 6347, and a bunch of /30s from customer ASNs, won't convince me that anyone needs to relax their filters any time soon.
Some snippets from nitrous:
*>i64.240.169.224/27 209.44.160.105 4294967294 100 0 6347 i *>i64.241.182.128/25 209.83.160.22 4294967294 100 0 6347 i *>i64.242.80.0/27 209.44.160.105 4294967294 100 0 6347 i *>i209.44.23.160/28 64.241.88.17 4294967294 100 0 6347 i *>i209.83.163.128/26 209.83.160.22 4294967294 100 0 6347 i *>i209.83.182.208/28 209.83.160.22 4294967294 100 0 6347 i *>i209.102.112.4/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.8/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.208/28 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.232/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.240/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.244/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.112.248/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.8/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.12/30 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.16/29 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.24/29 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.32/28 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.102.118.48/28 209.44.160.105 4294967294 100 0 6347 15131 ? *>i209.126.143.192/27 209.44.160.105 4294967294 100 0 6347 i *>i209.144.220.128/25 209.44.160.105 4294967294 100 0 6347 i *>i209.223.197.128/27 209.83.160.22 4294967294 100 0 6347 i *>i209.242.13.152/29 64.241.88.17 4294967294 100 0 6347 10692 13950 i *>i209.242.13.204/30 64.241.88.17 4294967294 100 0 6347 10692 13950 i *>i209.242.13.212/30 64.241.88.17 4294967294 100 0 6347 10692 13950 i *>i209.242.13.216/30 64.241.88.17 4294967294 100 0 6347 10692 13950 ? *>i209.242.13.220/30 64.241.88.17 4294967294 100 0 6347 10692 13950 ?
On Sun, 17 Dec 2000, Daniel L. Golding wrote:
Travis,
By doing a summary-only aggregate, you can lose routing information that your downstreams want seen by the global internet. A good example of this is prepending. If I only advertise a /14, then supress a /24 that is subordinate to that block, I may fail to advertise a prepend upon that /24 block. Paying customer don't like stuff like that.
BTW, ARIN is pretty clear that it's allocation policies are NOT intended for use as filtering criteria. Most folks seem to get along fine, filtering at the /24 level. It's not like most core routers at large ISPs are 7500s with 64mb anymore.
- Daniel Golding
Hi, You may be able to get two or more providers to agree to do this for you now, but this will get more difficult in the future. Special deals like you describe below will get tiresome very fast when you need to maintain them. Let's just say that there are some real scaling issue's with it, and leave it at that. - marcel On Fri, 15 Dec 2000, Daniel Golding wrote:
Jade,
You don't really need a /20 to multihome or use BGP. Just get an ASN, multiple providers, and advertise your space. There are a couple ways to deal with those who will filter smaller blocks. One way is to get two providers, get space from one or both with a block larger than a /21. Ensure that the two providers peer directly with each other, and that they will advertise blocks smaller than a /20 to each other (/24 is a more normal filtering level these days). Also ensure that whichever of the upstreams that is giving you the space advertises it as the larger, less specific, aggregate as well. Given this situation, you should be fine. If your connection to the ISP announcing the globally routable aggregate goes down, it will still announce the aggregate, then route your traffic to the more specific route in the block being announced by it's peer. Works like a charm.
- Dan Golding NetRail, Inc.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Jade E. Deane Sent: Friday, December 15, 2000 1:23 PM To: 'nanog@merit.edu' Subject: multi-homing without the BGP (was RE: Packet Loss)
I will spare everyone my own personal experiences as of late in dealing with ARIN for a /20. How about some talk on this topic, multi-homing without the application of the BGP, a pressing concern amongst mid-level ISPs and small dot com's.
Jade
P.S. Mr. Jimmerson... I want a /20, and a pony. Give me a /20 and a pony, I want a pony!!!!
Jade E. Deane Network Engineer helloNetwork.com Las Vegas, Nevada
Office: +1 (702) 938-9267 Cell: +1 (702) 604-4759 Fax: +1 (702) 456-1471 email: jade.deane@helloNetwork.com urgent epage: 7026044759@page.nextel.com
participants (7)
-
Anne Marcel Roorda -
Daniel Golding -
Daniel L. Golding
-
Jade E. Deane -
Jonathan Disher -
nanog＠rmrf.net -
Travis Pugh