Re: How Not to Multihome
Justin M. Streiner wrote: On Tue, 9 Oct 2007, Patrick W. Gilmore wrote: Justin, if Provider A _has_ permission from Provider B to announce a prefix, do you believe Provider A should be allowed to announce the prefix? As long as all of the relevant parties know about it and are OK with it, that's fine. It's just not my first choice for solving the customer's multihoming dilemma, that's all :) jms Back when I was a NOC monkey (that stopped a month ago), I had exactly that situation. I had MCI and SBC as upstreams. Before multihoming, my network was split in two segments, one for each substream. This made things like DNS interesting. When I got my ASN, I got agreement from both MCI and SBC to announce my /21 allocations from them over both upstream circuits. As a result, I was able to go back to a single inside network, a single pair of DNS servers, and no more cross-router traffic via the Internet cloud. I then got my ARIN allocation and went through the Fiscal Quarter From Hell renumbering everything into the new number block. I dropped MCI (long story) and lit up Idacomm, but kept SBC link and numbers. When I left the ISP, my routers had been announcing my suballocation of SBC space for more than a year. With their permission. Their only requirement is that I have proper routing objects in a routing registry so SBC could see that the route I was announcing was valid. (What was VERY interesting was that I was using the ARIN registry, and SBC was not. The resulting bru-ha-ha uncovered a synchronization problem that ARIN had, and that ARIN fixed.)
Re: Upstreams blocking /24s? (was Re: How Not to Multihome)
Scott Weeks wrote: --- [EMAIL PROTECTED] wrote: On Oct 8, 2007, at 2:48 PM, Scott Weeks wrote: However, if it's less than a /24 it won't get very far as most upstreams block prefixes longer than a /24. I'm curious: a couple of people have indicated they do not believe this to be the case. Anybody have any hard data on what filters are actually in use today? I found two current policies. Other companies made it too hard to find... Sprint: # Customers may announce routes as small as /26 for ARIN IP address blocks obtained through Sprint. Customers may announce routes as small as /28 for RIPE and APNIC address blocks obtained through Sprint. # Peer block announcements and customer announcements for blocks obtained from other providers are limited to a /24 or smaller mask (/23, /22 etc.). ATT: * not accept Customer route announcements smaller than a /24 network Level3: From the output of whois -h rr.level3.net AS3356 snip remarks: The following import actions are common to every remarks: Level 3 non-customer peering session: remarks: remarks: - RFC1918 and other reserved networks and subnets are remarks: not permitted. remarks: remarks: - Advertisements with reserved ASes in the path remarks: (ie 64512 - 65535) are not permitted. remarks: remarks: - Prefixes shorter than /8 or longer than /24 are remarks: not permitted. snip (the rest is useful reading too if you deal with level3 much) Vince scott
RE: How Not to Multihome
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick W. Gilmore Sent: Monday, October 08, 2007 9:33 PM To: nanog Cc: Patrick W. Gilmore Subject: Re: How Not to Multihome On Oct 8, 2007, at 6:45 PM, Justin M. Streiner wrote: On Mon, 8 Oct 2007, Patrick W. Gilmore wrote: If you do you have permission from the owner of the block, you Should Not Announce it. Agreed. I stated above that you should not announce another provider's space without their permission, and you specifically agreed. Here you are talking about that space being announced without the owner's knowledge. Make up your mind. We both agree that announcing another provider's space without their consent is a Very Bad Thing. I doubt you will find people willing to post here to the contrary. If the owner _does_ know the space is being announced, the edge filters are no different whether it is originated in the second upstream's ASN or an ASN owned by the customer. So again, I ask, how is that different? --- You'll note that you left a word out above. He's agreeing that even if you do have permission, you shouldn't announce space from another provider. Jamie Bowden -- It was half way to Rivendell when the drugs began to take hold Hunter S Tolkien Fear and Loathing in Barad Dur Iain Bowen [EMAIL PROTECTED]
Re: How Not to Multihome
On Oct 9, 2007, at 8:15 AM, Jamie Bowden wrote: On Oct 8, 2007, at 6:45 PM, Justin M. Streiner wrote: On Mon, 8 Oct 2007, Patrick W. Gilmore wrote: If you do you have permission from the owner of the block, you Should Not Announce it. Agreed. I stated above that you should not announce another provider's space without their permission, and you specifically agreed. Here you are talking about that space being announced without the owner's knowledge. Make up your mind. We both agree that announcing another provider's space without their consent is a Very Bad Thing. I doubt you will find people willing to post here to the contrary. If the owner _does_ know the space is being announced, the edge filters are no different whether it is originated in the second upstream's ASN or an ASN owned by the customer. So again, I ask, how is that different? You'll note that you left a word out above. He's agreeing that even if you do have permission, you shouldn't announce space from another provider. Type-o's suck. Thanx for pointing it out. Sorry for the confusion. Justin, if Provider A _has_ permission from Provider B to announce a prefix, do you believe Provider A should be allowed to announce the prefix? -- TTFN, patrick
Re: How Not to Multihome
On 8 Oct 2007, at 22:43, [EMAIL PROTECTED] wrote: I have a client that wants us to advertise an IP block assigned by another ISP. I know that the best practice is to have them request an AS number from ARIN and peer with us, etc. However, I cannot find any information that states as law. Does anyone know of a document or RFC that states this? There was a good discussion following this, but I couldn't find mention of IRR Consistency in the follow ups. If I publish in an IRR that I am the legitimate originator of a prefix, 10.0.0.0/19, and someone else announces 10.0.2.0/24, whether I am aware or not, then they get the traffic. This could be the desired outcome, as in the scenario the OP refers to. However, if a different third-party network then sweeps up their routing table by looking to remove more specifics that seem 'spoofed' using IRR data, the routes you intend to push onto the internet may well start to disappear from their perspective. I'm talking in fairly superficial terms, rfc 2650 might give you more ideas. There's a reason things 'tend' to be done one way even though it means burning through AS numbers and v4 address resources.
Re: How Not to Multihome
On 9 Oct 2007, at 17:47, Andy Davidson wrote: [...] However, if a different third-party network then sweeps up their routing table by looking to remove more specifics that seem 'spoofed' using IRR data, the routes you intend to push onto the internet may well start to disappear from their perspective. I don't think this should be possible if the database implements RPSS (RFC 2725) properly. I believe that it should only be possible to create a more specific route object with the agreement using whatever PGP/X.509 security you like if you have used mnt-lower and mnt-routes attributes as appropriate. I'm not sure I'd want to publish my routing policy in a database that didn't have a reasonable implementation of RPSS. Leo
Re: How Not to Multihome
On 9 Oct 2007, at 18:48, Leo Vegoda wrote: On 9 Oct 2007, at 17:47, Andy Davidson wrote: However, if a different third-party network then sweeps up their routing table by looking to remove more specifics that seem 'spoofed' using IRR data, the routes you intend to push onto the internet may well start to disappear from their perspective. I don't think this should be possible if the database implements RPSS (RFC 2725) properly. I believe that it should only be possible to create a more specific route object with the agreement using whatever PGP/X.509 security you like if you have used mnt-lower and mnt-routes attributes as appropriate. mnt-lower works, but only if I know someone else wants to originate a more specific. Routing in general doesn't care - this was the case I was making - hope I didn't cause confusion. Andy
Re: How Not to Multihome
On Mon, 08 Oct 2007 21:32:50 EDT, Patrick W. Gilmore said: On Oct 8, 2007, at 6:45 PM, Justin M. Streiner wrote: I never said it was. My experience, both in my previous life as the operator of a regional ISP and since then in other capacities is that having disjoint origins for a chunk of some provider's address space is basically asking for trouble, and it's the kind of trouble that may ony pop up when something breaks. I'm afraid your experience is not the same as many, many people. There are currently ~1500 prefixes with inconsistent origin AS. These are trivially identifiable: http://www.cymru.com/BGP/incon_asn_list.html Some of them are obvious mistakes (I doubt HKSuper is supposed to originate 4/8). But many of them are not, and the Internet works just fine. And as Justin said, some sizable fraction of those 1500 prefixes are quite possibly *appearing* to Work Just Fine currently, but if something breaks, that will be 1500 NOC monkeys facing some difficult-to-debug routing issues pgpW8LoxbQP2z.pgp Description: PGP signature
Re: How Not to Multihome
On 10/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: That brings up an interesing point. My biggest fear was that one of my other customers could possible be closer to me that the ISP that provides the primary link and it would cause them to favor the backup link because of AS path. I think they are going to fight me on this and telling them to multihome to their original ISP would probably be frowned upon at this point. I was hoping that there was an RFC for multihoming that I could use to bail myself out. What they're asking to do is really Just Fine. It may or may not accomplish what they want, depending on how they do it, e.g. whether traffic will go through their other ISP or yours. The main reason it's a Not Best Practice is that it often doesn't get what the user wants, e.g. the user only has a /29, so only the aggregate advertisement from their primary ISP works anyway, or it's PA space so they'll still have to give it up if they change ISPs. But if they've got a /24, that's big enough that most carriers will see it these days, and there's no need to clutter up the BGP ASN space if your user doesn't need the extra flexibility. There may even be a market for ISPs to do multihoming on a cabal basis, e.g. Carrier X and Carrier Y get a /20 that they assign routes from to customers that use both of them, but only advertise the aggregate to the rest of the net. They'd still need to handle the more specific routes internally and exchange them across their peering link, but wouldn't have to bother the rest of the net with that level of detail. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: How Not to Multihome
On Tue, 9 Oct 2007, Patrick W. Gilmore wrote: Justin, if Provider A _has_ permission from Provider B to announce a prefix, do you believe Provider A should be allowed to announce the prefix? As long as all of the relevant parties know about it and are OK with it, that's fine. It's just not my first choice for solving the customer's multihoming dilemma, that's all :) jms
Re: How Not to Multihome
On Oct 9, 2007, at 1:53 PM, [EMAIL PROTECTED] wrote: There are currently ~1500 prefixes with inconsistent origin AS. These are trivially identifiable: http://www.cymru.com/BGP/incon_asn_list.html Some of them are obvious mistakes (I doubt HKSuper is supposed to originate 4/8). But many of them are not, and the Internet works just fine. And as Justin said, some sizable fraction of those 1500 prefixes are quite possibly *appearing* to Work Just Fine currently, but if something breaks, that will be 1500 NOC monkeys facing some difficult-to-debug routing issues Considering the number of inconsistently originated prefixes has been non-trivial for at least a decade, I have trouble believing this is a huge threat to the internet. Or even those 1500 NOC monkeys. (And wouldn't it be 3K - at least 2 ASNs per prefix? :) -- TTFN, patrick
Re: How Not to Multihome
On Tue, 09 Oct 2007 14:01:40 EDT, Patrick W. Gilmore said: Considering the number of inconsistently originated prefixes has been non-trivial for at least a decade, I have trouble believing this is a huge threat to the internet. Or even those 1500 NOC monkeys. (And wouldn't it be 3K - at least 2 ASNs per prefix? :) Most likely, one of the two ASN's wouldn't notice a problem. :) pgpDlNHDtHae5.pgp Description: PGP signature
Re: Upstreams blocking /24s? (was Re: How Not to Multihome)
[EMAIL PROTECTED] wrote on 10/08/2007 10:28:37 PM: Hi, On Oct 8, 2007, at 6:28 PM, Justin M. Streiner wrote: On Mon, 8 Oct 2007, Jon Lewis wrote: adopted /24 as the cutoff point. If you make the cutoff point smaller, what is the new point... /26? /32? Presumably the fear is there being no limitation, that is, /32. Anything longer than /24 is unlikely to propagate far on the internet. Pedantically speaking, there ain't no such thing as the internet. There ain't no such thing as ain't but somehow that term has been proliferated as well. (less pedantic) There are a series of interconnected private IP based networks, each with their own policy about what they'll transmit and accept in terms of routing updates. What one ISP accepts and propagates is not necessarily what the next ISP accepts and propagates. Unfortunately that also goes for the customers of that ISP. So if one of the Tier I's decides not to accept my public /29 then the millions of singlehomed subscribers go with it. The idea of random AS's accepting and blocking a prefix scares the hell out of me. It's right under the idea of some director calling me into his office because some customer can't get to AOL subscribers and their NOC told us to beat it when we called and asked for the filters to be updated. What I'm trying to understand is whether there is a sufficient critical mass to define a consensus maximal prefix among those interconnected networks. You can all check your filters to see. I just checked mine, and neither Level3 nor Time Warner has tried to send me anything longer than /24 in recent history. If they did, it'd show up as hits on a distribute-list deny rule. I realize that - I was posing a rhetorical question to the previous poster :) The argument, as I understand it (and those who argue this direction feel free to correct me if I misstate), is that as the IPv4 free pool exhausts, there will be a natural pressure to increase address utilization efficiency. This will likely mean longer prefixes will begin to be put (back) into use, either from assignments and allocations that were rediscovered or from unused portions of shorter prefixes. Customers will approach ISPs to get these long prefixes routed, shopping through ISPs until they find one that will accept their money and propagate the long prefix. Not if their engineering staff possess the gift of clue.. (See above) Now, of course announcing a route doesn't mean anyone will accept it, but as I understand the theory, larger ISPs will agree to accept and propagate longer prefixes from other larger ISPs if those other ISPs will be willing to accept and propagate transmitted long prefixes (scratch my back and I'll scratch yours), particularly if this encourages the smaller ISPs to 'look for other employment opportunities' when they can't afford the router upgrades. Personally, I fully expect the first part to happen. Where I'm having trouble is the second part (the accepting longer prefixes part). However, a few prominent members of the Internet operations community whom I respect have argued strongly that this is going to happen. I thought I'd ask around to see what other folk think... The DOD aside even if some of the larger ISP's are bribed into accepting the smaller blocks. There are still some unanswered questions. First there is no way to force every AS to accept the routes, so some medium sized transit as will respond with not until ARIN makes us and the long networks will have to reachibility to the subscribers of that AS. Also, where do you stop? /26 /30? The biggest argument against the short prefixes is stability. Just imagine the route churn if I start advertising a /30 for some metro E link to China and then it starts flapping. If this isn't enough picture 20 such links or 2000. Fiber cut anyone? Or if this is too unrealistic how about a random /27 owned by some colo customer who router is flapping constantly. IMHO this is one instance where Pandora's box should remain closed. If people feel uncomfortable publicly stating their filter policy is, Does anyone know how to write over my router in RPSL? I'd be happy to summarize responses sent to me directly, keeping individual responses confidential. Regards, -drc
How Not to Multihome
I have a client that wants us to advertise an IP block assigned by another ISP. I know that the best practice is to have them request an AS number from ARIN and peer with us, etc. However, I cannot find any information that states as law. Does anyone know of a document or RFC that states this? Thanks, Keegan
Re: How Not to Multihome
--- [EMAIL PROTECTED] wrote: I have a client that wants us to advertise an IP block assigned by another ISP. I know that the best practice is to have them request an AS number from ARIN and peer with us, etc. However, I cannot find any information that states as law. Does anyone know of a document or RFC that states this? There is no law. ;) Also, you can advertise the other provider's block given to your prospective customer as long as you work with that provider on how to do it. However, if it's less than a /24 it won't get very far as most upstreams block prefixes longer than a /24. scott
Re: How Not to Multihome
On Oct 8, 2007, at 5:43 PM, [EMAIL PROTECTED] wrote: I have a client that wants us to advertise an IP block assigned by another ISP. I know that the best practice is to have them request an AS number from ARIN and peer with us, etc. However, I cannot find any information that states as law. Does anyone know of a document or RFC that states this? There is nothing wrong with both of your originating the prefix, as long as the owner gives you permission. Plus it saves an ASN. If the link between you the customer dies, things get far more interesting, but that doesn't mean you can't or shouldn't do it. Of course, you can probably still find documentation against it. (You can find documentation for or against just about anything.) -- TTFN, patrick
Re: How Not to Multihome
Slightly different approach... Needing to multihome is justification for requesting an ASN. Is this strictly necessary? No. You can source the block on his behalf but that creates various routing inconsistancies. There are other even more unpleasant ways of doing this that are perfectly feasible. (I'd be willing to use them if I was the client since I know what I'm doing but I would not be willing to have a client of mine use them because it would scare the hell out of me.) -Wayne On Mon, Oct 08, 2007 at 05:43:03PM -0400, [EMAIL PROTECTED] wrote: I have a client that wants us to advertise an IP block assigned by another ISP. I know that the best practice is to have them request an AS number from ARIN and peer with us, etc. However, I cannot find any information that states as law. Does anyone know of a document or RFC that states this? Thanks, Keegan --- Wayne Bouchard [EMAIL PROTECTED] Network Dude http://www.typo.org/~web/
Re: How Not to Multihome
On Mon, 8 Oct 2007, [EMAIL PROTECTED] wrote: I have a client that wants us to advertise an IP block assigned by another ISP. I know that the best practice is to have them request an AS number from ARIN and peer with us, etc. However, I cannot find any information that states as law. Does anyone know of a document or RFC that states this? It's not 'law' per se, but having the customer originate their own announcements is definitely the Right Way to go. Some providers take a pretty dim view of seeing chunks of their address space show up in advertisements originating from someone who isn't one of their customers. It can make troubleshooting connectivity problems for that customer (from the provider's point of view) very painful, i.e. Hey, this AS, who isn't one of our customers, is hijacking IP space assigned to one of our customers! The provider could then contact your host's upstream(s) and ask them to drop said announcement under the impression they're stopping someone from doing something bad. Also, if some network out there aggregates prefixes in an aggessive/odd manner, the disjoint announcement, and the reachability info it contains could be washed out of their routing tables, causing connectivity problems. Standard caveats about the block being a /24 or larger also apply. jms
Re: How Not to Multihome
It's not 'law' per se, but having the customer originate their own announcements is definitely the Right Way to go. it is interesting, and worrysome, to consider this in light of likely growth in the routing table (ref ipv4 free pool run out discussion) and vendors' inability to handle large ribs and fibs on enterprise class routers. randy
Re: How Not to Multihome
That brings up an interesing point. My biggest fear was that one of my other customers could possible be closer to me that the ISP that provides the primary link and it would cause them to favor the backup link because of AS path. I think they are going to fight me on this and telling them to multihome to their original ISP would probably be frowned upon at this point. I was hoping that there was an RFC for multihoming that I could use to bail myself out. Justin M. Streiner [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/08/2007 05:55 PM To [EMAIL PROTECTED] cc nanog nanog@merit.edu Subject Re: How Not to Multihome On Mon, 8 Oct 2007, [EMAIL PROTECTED] wrote: I have a client that wants us to advertise an IP block assigned by another ISP. I know that the best practice is to have them request an AS number from ARIN and peer with us, etc. However, I cannot find any information that states as law. Does anyone know of a document or RFC that states this? It's not 'law' per se, but having the customer originate their own announcements is definitely the Right Way to go. Some providers take a pretty dim view of seeing chunks of their address space show up in advertisements originating from someone who isn't one of their customers. It can make troubleshooting connectivity problems for that customer (from the provider's point of view) very painful, i.e. Hey, this AS, who isn't one of our customers, is hijacking IP space assigned to one of our customers! The provider could then contact your host's upstream(s) and ask them to drop said announcement under the impression they're stopping someone from doing something bad. Also, if some network out there aggregates prefixes in an aggessive/odd manner, the disjoint announcement, and the reachability info it contains could be washed out of their routing tables, causing connectivity problems. Standard caveats about the block being a /24 or larger also apply. jms
Re: How Not to Multihome
On Oct 8, 2007, at 5:55 PM, Justin M. Streiner wrote: On Mon, 8 Oct 2007, [EMAIL PROTECTED] wrote: I have a client that wants us to advertise an IP block assigned by another ISP. I know that the best practice is to have them request an AS number from ARIN and peer with us, etc. However, I cannot find any information that states as law. Does anyone know of a document or RFC that states this? It's not 'law' per se, but having the customer originate their own announcements is definitely the Right Way to go. That is not at all guaranteed. Some providers take a pretty dim view of seeing chunks of their address space show up in advertisements originating from someone who isn't one of their customers. It can make troubleshooting connectivity problems for that customer (from the provider's point of view) very painful, i.e. Hey, this AS, who isn't one of our customers, is hijacking IP space assigned to one of our customers! The provider could then contact your host's upstream (s) and ask them to drop said announcement under the impression they're stopping someone from doing something bad. If you do you have permission from the owner of the block, you Should Not Announce it. If the owner gives you permission and can't figure out why their block is originated by another ASN as well, they need help. (Yes, I realize the latter part of the last sentence is probably true for the majority of providers, but whatever.) In either case, your hypothetical question should not hold. Also, if some network out there aggregates prefixes in an aggessive/ odd manner, the disjoint announcement, and the reachability info it contains could be washed out of their routing tables, causing connectivity problems. How is this different than if the customers gets their own ASN and announces a sub-block from one of the providers? Or are you suggesting they should get PI space? -- TTFN, patrick
Re: How Not to Multihome
The only thing that sounds worse would be to give them address space and tell them to NAT the traffic based on the path it takes. Keegan Holley Network Engineer, Network Managed Services SunGard Availability Services Mezzanine Level MC-95 401 N. Broad St. Philadelphia, PA 19108 215.446.1242 (office) 609.670.2149 (cell) [EMAIL PROTECTED] ___ Keeping People and Information Connected® http://www.availability.sungard.com Wayne E. Bouchard [EMAIL PROTECTED] 10/08/2007 05:53 PM To [EMAIL PROTECTED] cc nanog nanog@merit.edu, [EMAIL PROTECTED] Subject Re: How Not to Multihome Slightly different approach... Needing to multihome is justification for requesting an ASN. Is this strictly necessary? No. You can source the block on his behalf but that creates various routing inconsistancies. There are other even more unpleasant ways of doing this that are perfectly feasible. (I'd be willing to use them if I was the client since I know what I'm doing but I would not be willing to have a client of mine use them because it would scare the hell out of me.) -Wayne On Mon, Oct 08, 2007 at 05:43:03PM -0400, [EMAIL PROTECTED] wrote: I have a client that wants us to advertise an IP block assigned by another ISP. I know that the best practice is to have them request an AS number from ARIN and peer with us, etc. However, I cannot find any information that states as law. Does anyone know of a document or RFC that states this? Thanks, Keegan --- Wayne Bouchard [EMAIL PROTECTED] Network Dude http://www.typo.org/~web/
Re: How Not to Multihome
On Mon, Oct 08, 2007 at 05:43:03PM -0400, [EMAIL PROTECTED] wrote: I have a client that wants us to advertise an IP block assigned by another ISP. I know that the best practice is to have them request an AS number from ARIN and peer with us, etc. However, I cannot find any information that states as law. Does anyone know of a document or RFC that states this? If the address space is assigned to another provider, getting clarification from them directly or indirectly(*) that the customer is allowed to use it, if it is portable or allowed to be seen outside their ASN, etc. If their are truly attempting to multihome, doing so with multiple-origin ASNs can create nondeterministic behavior in the exact failure conditions that multihoming is seeking to solve. Given the clue level of the customer or their business/traffic, it may not matter (anycasters, CDNs, or other edges with levels of indirection). Most ISPs quite simply have a policy that multihoming is done by BGP in such and such fasion and that's that. Cheers, Joe (*) whois delegation at best, some providers indicate portability or multihoming policy in whois or IRR allocations,etc -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: How Not to Multihome
On Mon, 8 Oct 2007, [EMAIL PROTECTED] wrote: That brings up an interesing point. My biggest fear was that one of my other customers could possible be closer to me that the ISP that provides the primary link and it would cause them to favor the backup link because of AS path. I think they are going to fight me on this and telling them to multihome to their original ISP would probably be frowned upon at this point. I was hoping that there was an RFC for multihoming that I could use to bail myself out. If you went ahead and did this, the more specific route being announced by you on behalf of your customer would be more likely to attract traffic back to you. Prefix length is checked in the BGP route selection process before AS path length. This would work in normal everything works fine situations, but when things break, troubleshooting the source of the customer's reachabilit woes will get very interesting. jms
Re: How Not to Multihome
I'm really interested to see what happens when we start filling those same routers with ipv6 routes. Randy Bush [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/08/2007 06:10 PM To Justin M. Streiner [EMAIL PROTECTED] cc nanog nanog@merit.edu Subject Re: How Not to Multihome It's not 'law' per se, but having the customer originate their own announcements is definitely the Right Way to go. it is interesting, and worrysome, to consider this in light of likely growth in the routing table (ref ipv4 free pool run out discussion) and vendors' inability to handle large ribs and fibs on enterprise class routers. randy
Re: How Not to Multihome
Also, if some network out there aggregates prefixes in an aggressive/ odd manner, the disjoint announcement, and the reachability info it contains could be washed out of their routing tables, causing connectivity problems. How is this different than if the customers gets their own ASN and announces a sub-block from one of the providers? Or are you suggesting they should get PI space? ARIN will only hand out /22's or larger. If a client wants to multihome with a /23 or a /24 it has to be assigned by one of hte ISP's and removed from the aggregate. Patrick W. Gilmore [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/08/2007 06:16 PM To nanog nanog@merit.edu cc Patrick W. Gilmore [EMAIL PROTECTED] Subject Re: How Not to Multihome On Oct 8, 2007, at 5:55 PM, Justin M. Streiner wrote: On Mon, 8 Oct 2007, [EMAIL PROTECTED] wrote: I have a client that wants us to advertise an IP block assigned by another ISP. I know that the best practice is to have them request an AS number from ARIN and peer with us, etc. However, I cannot find any information that states as law. Does anyone know of a document or RFC that states this? It's not 'law' per se, but having the customer originate their own announcements is definitely the Right Way to go. That is not at all guaranteed. Some providers take a pretty dim view of seeing chunks of their address space show up in advertisements originating from someone who isn't one of their customers. It can make troubleshooting connectivity problems for that customer (from the provider's point of view) very painful, i.e. Hey, this AS, who isn't one of our customers, is hijacking IP space assigned to one of our customers! The provider could then contact your host's upstream (s) and ask them to drop said announcement under the impression they're stopping someone from doing something bad. If you do you have permission from the owner of the block, you Should Not Announce it. If the owner gives you permission and can't figure out why their block is originated by another ASN as well, they need help. (Yes, I realize the latter part of the last sentence is probably true for the majority of providers, but whatever.) In either case, your hypothetical question should not hold. Also, if some network out there aggregates prefixes in an aggessive/ odd manner, the disjoint announcement, and the reachability info it contains could be washed out of their routing tables, causing connectivity problems. How is this different than if the customers gets their own ASN and announces a sub-block from one of the providers? Or are you suggesting they should get PI space? -- TTFN, patrick
Re: How Not to Multihome
On Mon, 8 Oct 2007, Patrick W. Gilmore wrote: It's not 'law' per se, but having the customer originate their own announcements is definitely the Right Way to go. That is not at all guaranteed. I never said it was. My experience, both in my previous life as the operator of a regional ISP and since then in other capacities is that having disjoint origins for a chunk of some provider's address space is basically asking for trouble, and it's the kind of trouble that may ony pop up when something breaks. My experience has also been that if a customer has a need to multihome and is willing to invest both in the equipment and the expertise to do so, then so be it. If you do you have permission from the owner of the block, you Should Not Announce it. Agreed. If the owner gives you permission and can't figure out why their block is originated by another ASN as well, they need help. (Yes, I realize the latter part of the last sentence is probably true for the majority of providers, but whatever.) In either case, your hypothetical question should not hold. Also, if some network out there aggregates prefixes in an aggessive/odd manner, the disjoint announcement, and the reachability info it contains could be washed out of their routing tables, causing connectivity problems. How is this different than if the customers gets their own ASN and announces a sub-block from one of the providers? In the case you described, the provider who holds the parent address block should expect to see an advertisement for a chunk of that block come in as part of the BGP feeds they receive from their upstreams, and they need to accept traffic accordingly. The customer would need to tell the provider of their intentions to multihome. If the provider in question employs some type of ingress/egress filtering, that filter would need to be updated to recognize that traffic sourced from that sub-block as legitimate, even if it comes in over their normal transit pipes. In the case I described, where the end user requested that a third party provide transit for their PA space, without that provider necessarily being aware of it is when things can break in strange and spectacular ways. Or are you suggesting they should get PI space? PI space, while nice, is not an option for many end users. jms
Re: How Not to Multihome
[EMAIL PROTECTED] wrote: I'm really interested to see what happens when we start filling those same routers with ipv6 routes. All 970 of them? joelja *Randy Bush [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 10/08/2007 06:10 PM To Justin M. Streiner [EMAIL PROTECTED] cc nanog nanog@merit.edu Subject Re: How Not to Multihome It's not 'law' per se, but having the customer originate their own announcements is definitely the Right Way to go. it is interesting, and worrysome, to consider this in light of likely growth in the routing table (ref ipv4 free pool run out discussion) and vendors' inability to handle large ribs and fibs on enterprise class routers. randy
Upstreams blocking /24s? (was Re: How Not to Multihome)
Hi, On Oct 8, 2007, at 2:48 PM, Scott Weeks wrote: However, if it's less than a /24 it won't get very far as most upstreams block prefixes longer than a /24. I'm curious: a couple of people have indicated they do not believe this to be the case. Anybody have any hard data on what filters are actually in use today? Others have indicated that such filters (assuming they exist) will not last in the face of paying customers presenting longer than /24 prefixes for routing. Specifically, that ISPs will relax their filters (allowing longer than /24) in order to get their peers to accept their long prefixes. Anybody have an opinion on the likelihood of this? Thanks, -drc
Re: How Not to Multihome
please elaborate. My knowledge of IPv6 is admittedly lacking, but I always assumed that the routing tables would be much larger if the internet were to convert from IPv4 due to the sheer number of networks available. Joel Jaeggli [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/08/2007 06:49 PM To [EMAIL PROTECTED] cc Randy Bush [EMAIL PROTECTED], nanog nanog@merit.edu, [EMAIL PROTECTED], Justin M. Streiner [EMAIL PROTECTED] Subject Re: How Not to Multihome [EMAIL PROTECTED] wrote: I'm really interested to see what happens when we start filling those same routers with ipv6 routes. All 970 of them? joelja *Randy Bush [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 10/08/2007 06:10 PM To Justin M. Streiner [EMAIL PROTECTED] cc nanog nanog@merit.edu Subject Re: How Not to Multihome It's not 'law' per se, but having the customer originate their own announcements is definitely the Right Way to go. it is interesting, and worrysome, to consider this in light of likely growth in the routing table (ref ipv4 free pool run out discussion) and vendors' inability to handle large ribs and fibs on enterprise class routers. randy
Re: IPv6 routes, was: How Not to Multihome
On Mon, 8 Oct 2007 [EMAIL PROTECTED] wrote: I'm really interested to see what happens when we start filling those same routers with ipv6 routes. Well, IPv6 prefixes will eventually be some number between the total number of ASes in use (which represents the number of networks that can afford and desire to run BGP) and the number of IPv4 prefixes in use (which represents the number of customers that can afford, justify, and desire to get address space). So today, if IPv6 was instantly ubiquitously deployed by every network on the planet that runs IPv4: you would would see between 26,249 and 235,174 IPv6 routes (data from http://bgp.potaroo.net/as6447/). You bought or are planning to buy core routers that support IPv6 at wirespeed in hardware didn't you? If you are (or plan to be) operating an IPv4 network for over 5 years (let alone the folks here that can say 10 or 15+ years), you are planning core router purchases on a cycle like 3 to 5 years by estimating what you need at the end of that time and then specifying accordingly. By looking at the graph at the top of the page http://bgp.potaroo.net/as6447/ for total route announcements you could make a wild guess that if you want a router that has a high probability of working without needing workarounds (or giving you unnecessary headaches) in 3 years it needs to handle 500,000 IPv4 routes and 500,000 IPv6 routes in hardware when you buy it. Arguably this is overkill for IPv6, and might last 5 to 7 years. *All* the core router vendors (Cisco, Juniper, Foundry, Force10, etc) sell routers that can do this today. If you are buying something that can't handle the 3 year IPv4 requirement, let alone the IPv6 requirement, why are doing that to yourself? Contrary to what seems to be popular misconception, your refrigerator will not be multihomed under IPv6. There are dynamic economic pressures (such as consolidation, competition, effective regulatory monopoly, etc) that limit the number of networks in the global routing table. Mike. +- H U R R I C A N E - E L E C T R I C -+ | Mike Leber Wholesale IPv4 and IPv6 Transit 510 580 4100 | | Hurricane Electric Web Hosting Colocation AS6939 | | [EMAIL PROTECTED] http://he.net | +---+
Re: Upstreams blocking /24s? (was Re: How Not to Multihome)
On Mon, 8 Oct 2007 16:06:52 -0700 David Conrad [EMAIL PROTECTED] wrote: Hi, On Oct 8, 2007, at 2:48 PM, Scott Weeks wrote: However, if it's less than a /24 it won't get very far as most upstreams block prefixes longer than a /24. I'm curious: a couple of people have indicated they do not believe this to be the case. Anybody have any hard data on what filters are actually in use today? That's a good question. http://www.nanog.org/mtg-0105/prefix.html says what was in use 6.5 years ago; it would be good to look at newer data. Others have indicated that such filters (assuming they exist) will not last in the face of paying customers presenting longer than /24 prefixes for routing. Specifically, that ISPs will relax their filters (allowing longer than /24) in order to get their peers to accept their long prefixes. Anybody have an opinion on the likelihood of this? The traditional answer has been paying whom? A given ISP's customers might pay it to announce their routes; *maybe* they'll have bilateral agreements with some of their peers to carry each other's longer routes. But what about the next hop? Put another way, there's been a lot of discussion -- pardon me, a *FLEEPING LOT of DISCUSSION* -- on this list lately about how lots of folks need to upgrade line cards and/or IOS and/or routers to keep up with the growth of the routing table. If the growth is due to long prefixes, who pays? Again, it's (relatively) easy to charge your own customers. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: How Not to Multihome
[EMAIL PROTECTED] wrote: please elaborate. My knowledge of IPv6 is admittedly lacking, but I always assumed that the routing tables would be much larger if the internet were to convert from IPv4 due to the sheer number of networks available. Currently The IPv6 DFZ is 970 routes from 808 ASes. The reflects actually pretty steady growth... participating in the IPV6 dfz is not presently expensive. Were it maximally aggregated it would be 926 routes. 95% agregation is pretty nice. In ipv4 land we're at 239k routes ~154k maximally aggregated 64% efficiency from the aggregation angle... But only 25506 ASes are actually participating in the v4 routing system. While I won't presume that the IPV6 routing table will remain unmessy when the other 24698 ASes decide they need some v6 I think it's be quite some time before the v6 picture looks like the v4 one (most of those networks will not be going back to the rir for a new block at regular intervals). Their is always the possibility that somebody decides they need announce all their /48s for TE or anti-hijacking purposes in which case filters and clue should be applied in that order. There is no reason in the ipv4 dfz for example for me to need a thousand routes from 18566 or 9498 in order to reach all their address blocks.
Re: IPv6 routes, was: How Not to Multihome
Mike Leber [EMAIL PROTECTED] wrote on 10/08/2007 07:36:56 PM: On Mon, 8 Oct 2007 [EMAIL PROTECTED] wrote: I'm really interested to see what happens when we start filling those same routers with ipv6 routes. Well, IPv6 prefixes will eventually be some number between the total number of ASes in use (which represents the number of networks that can afford and desire to run BGP) and the number of IPv4 prefixes in use (which represents the number of customers that can afford, justify, and desire to get address space). So today, if IPv6 was instantly ubiquitously deployed by every network on the planet that runs IPv4: you would would see between 26,249 and 235,174 IPv6 routes (data from http://bgp.potaroo.net/as6447/). Wouldn't resources still be an issue. Since the address space is so much larger wouldn't the 235k v6 routes take up more than 4 times the router memory? You bought or are planning to buy core routers that support IPv6 at wirespeed in hardware didn't you? If you are (or plan to be) operating an IPv4 network for over 5 years (let alone the folks here that can say 10 or 15+ years), you are planning core router purchases on a cycle like 3 to 5 years by estimating what you need at the end of that time and then specifying accordingly. By looking at the graph at the top of the page http://bgp.potaroo.net/as6447/ for total route announcements you could make a wild guess that if you want a router that has a high probability of working without needing workarounds (or giving you unnecessary headaches) in 3 years it needs to handle 500,000 IPv4 routes and 500,000 IPv6 routes in hardware when you buy it. Arguably this is overkill for IPv6, and might last 5 to 7 years. What about MPLS? The last time I poked around in one of the core routers there were about 1.2 million routes. This includes all the private space that is routed between different sites in the same vpn and customers that use overlapping IP space. I had always assumed the routing tables would be massive under IPv6. *All* the core router vendors (Cisco, Juniper, Foundry, Force10, etc) sell routers that can do this today. If you are buying something that can't handle the 3 year IPv4 requirement, let alone the IPv6 requirement, why are doing that to yourself? Can I interest you in some used M40's? Contrary to what seems to be popular misconception, your refrigerator will not be multihomed under IPv6. There are dynamic economic pressures (such as consolidation, competition, effective regulatory monopoly, etc) that limit the number of networks in the global routing table. Well I guess I can nix that rootkit for IP enabled cukoo clocks. : ) Keegan
Re: How Not to Multihome
On Mon, 8 Oct 2007, [EMAIL PROTECTED] wrote: please elaborate. My knowledge of IPv6 is admittedly lacking, but I always assumed that the routing tables would be much larger if the internet were to convert from IPv4 due to the sheer number of networks available. Not many networks are pushing IPv6 at this point, or more correctly, not many relative to the 230k+ routes that currently makes up a full IPv4 routing table. There likely won't be a mass flash-cut to IPv6, which is a subject that has been debated to death and back again here on NANOG over the last few weeks :) jms
Re: Upstreams blocking /24s? (was Re: How Not to Multihome)
--- [EMAIL PROTECTED] wrote: On Oct 8, 2007, at 2:48 PM, Scott Weeks wrote: However, if it's less than a /24 it won't get very far as most upstreams block prefixes longer than a /24. I'm curious: a couple of people have indicated they do not believe this to be the case. Anybody have any hard data on what filters are actually in use today? I found two current policies. Other companies made it too hard to find... Sprint: # Customers may announce routes as small as /26 for ARIN IP address blocks obtained through Sprint. Customers may announce routes as small as /28 for RIPE and APNIC address blocks obtained through Sprint. # Peer block announcements and customer announcements for blocks obtained from other providers are limited to a /24 or smaller mask (/23, /22 etc.). ATT: * not accept Customer route announcements smaller than a /24 network scott
Re: Upstreams blocking /24s? (was Re: How Not to Multihome)
On Mon, 8 Oct 2007, David Conrad wrote: Others have indicated that such filters (assuming they exist) will not last in the face of paying customers presenting longer than /24 prefixes for routing. Specifically, that ISPs will relax their filters (allowing longer than /24) in order to get their peers to accept their long prefixes. Anybody have an opinion on the likelihood of this? The only exceptions I've seen to the /24 policy are when the customer in question multihomes to the same upstream - sometimes done with a specific AS designated for that purpose, i.e. what UUNET does with AS7046. Those routes are then aggregated that provider's parent block(s). As far as allowing prefixes longer than a /24, that decision was made when the Internet was considerably smaller than it is now, and many networks adopted /24 as the cutoff point. If you make the cutoff point smaller, what is the new point... /26? /32? Many networks see customers multi-homing as pretty easy justification to provide them with a /24 of PA space, even if they're small enough that justifying a /24 while single-homed wouldn't work. jms
Re: Upstreams blocking /24s? (was Re: How Not to Multihome)
On Mon, 8 Oct 2007, Justin M. Streiner wrote: As far as allowing prefixes longer than a /24, that decision was made when the Internet was considerably smaller than it is now, and many networks adopted /24 as the cutoff point. If you make the cutoff point smaller, what is the new point... /26? /32? Anything longer than /24 is unlikely to propogate far on the internet. You can all check your filters to see. I just checked mine, and neither Level3 nor Time Warner has tried to send me anything longer than /24 in recent history. If they did, it'd show up as hits on a distribute-list deny rule. Rather than ISPs relaxing filters, you're likely to see them get more strict, filtering shorter prefixes, when routers start falling over in the next few months. Many networks see customers multi-homing as pretty easy justification to provide them with a /24 of PA space, even if they're small enough that justifying a /24 while single-homed wouldn't work. This is actually in the ARIN rules. Multihoming is justification (regardless of utilization) for one of the multihomed network's providers to assign them a /24. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: How Not to Multihome
On Oct 8, 2007, at 6:19 PM, Justin M. Streiner wrote: On Mon, 8 Oct 2007, [EMAIL PROTECTED] wrote: That brings up an interesing point. My biggest fear was that one of my other customers could possible be closer to me that the ISP that provides the primary link and it would cause them to favor the backup link because of AS path. I think they are going to fight me on this and telling them to multihome to their original ISP would probably be frowned upon at this point. I was hoping that there was an RFC for multihoming that I could use to bail myself out. If you went ahead and did this, the more specific route being announced by you on behalf of your customer would be more likely to attract traffic back to you. Prefix length is checked in the BGP route selection process before AS path length. This would work in normal everything works fine situations, but when things break, troubleshooting the source of the customer's reachabilit woes will get very interesting. You have made an assumption that the original upstream would not originate a prefix equivalent to the one you are originating. -- TTFN, patrick
Re: IPv6 routes, was: How Not to Multihome
On 10/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Wouldn't resources still be an issue. Since the address space is so much larger wouldn't the 235k v6 routes take up more than 4 times the router memory? Keegan, According to Cisco's product feature pages IPv6 routes take up twice as much space in the TCAM as IPv4 routes. Make of that what you will. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Upstreams blocking /24s? (was Re: How Not to Multihome)
On Mon, 8 Oct 2007, Jon Lewis wrote: adopted /24 as the cutoff point. If you make the cutoff point smaller, what is the new point... /26? /32? Anything longer than /24 is unlikely to propogate far on the internet. You can all check your filters to see. I just checked mine, and neither Level3 nor Time Warner has tried to send me anything longer than /24 in recent history. If they did, it'd show up as hits on a distribute-list deny rule. I realize that - I was posing a rhetorical question to the previous poster :) This is actually in the ARIN rules. Multihoming is justification (regardless of utilization) for one of the multihomed network's providers to assign them a /24. Been down that road a few times too, both as a provider and a customer. jms
Re: How Not to Multihome
On Oct 8, 2007, at 6:45 PM, Justin M. Streiner wrote: On Mon, 8 Oct 2007, Patrick W. Gilmore wrote: It's not 'law' per se, but having the customer originate their own announcements is definitely the Right Way to go. That is not at all guaranteed. I never said it was. My experience, both in my previous life as the operator of a regional ISP and since then in other capacities is that having disjoint origins for a chunk of some provider's address space is basically asking for trouble, and it's the kind of trouble that may ony pop up when something breaks. I'm afraid your experience is not the same as many, many people. There are currently ~1500 prefixes with inconsistent origin AS. These are trivially identifiable: http://www.cymru.com/BGP/incon_asn_list.html Some of them are obvious mistakes (I doubt HKSuper is supposed to originate 4/8). But many of them are not, and the Internet works just fine. My experience has also been that if a customer has a need to multihome and is willing to invest both in the equipment and the expertise to do so, then so be it. That statement does not say anything. If you do you have permission from the owner of the block, you Should Not Announce it. Agreed. If the owner gives you permission and can't figure out why their block is originated by another ASN as well, they need help. (Yes, I realize the latter part of the last sentence is probably true for the majority of providers, but whatever.) In either case, your hypothetical question should not hold. Also, if some network out there aggregates prefixes in an aggessive/odd manner, the disjoint announcement, and the reachability info it contains could be washed out of their routing tables, causing connectivity problems. How is this different than if the customers gets their own ASN and announces a sub-block from one of the providers? In the case you described, the provider who holds the parent address block should expect to see an advertisement for a chunk of that block come in as part of the BGP feeds they receive from their upstreams, and they need to accept traffic accordingly. The customer would need to tell the provider of their intentions to multihome. If the provider in question employs some type of ingress/egress filtering, that filter would need to be updated to recognize that traffic sourced from that sub-block as legitimate, even if it comes in over their normal transit pipes. In the case I described, where the end user requested that a third party provide transit for their PA space, without that provider necessarily being aware of it is when things can break in strange and spectacular ways. I stated above that you should not announce another provider's space without their permission, and you specifically agreed. Here you are talking about that space being announced without the owner's knowledge. Make up your mind. We both agree that announcing another provider's space without their consent is a Very Bad Thing. I doubt you will find people willing to post here to the contrary. If the owner _does_ know the space is being announced, the edge filters are no different whether it is originated in the second upstream's ASN or an ASN owned by the customer. So again, I ask, how is that different? Or are you suggesting they should get PI space? PI space, while nice, is not an option for many end users. Which is why I was assuming you did not mean PI space, but wanted to ask in case you were going to suggest it. -- TTFN, patrick
Re: How Not to Multihome
On Mon, 8 Oct 2007, Patrick W. Gilmore wrote: If you went ahead and did this, the more specific route being announced by you on behalf of your customer would be more likely to attract traffic back to you. Prefix length is checked in the BGP route selection process before AS path length. This would work in normal everything works fine situations, but when things break, troubleshooting the source of the customer's reachabilit woes will get very interesting. You have made an assumption that the original upstream would not originate a prefix equivalent to the one you are originating. Internally or externally? A /24 would exist in the provider's IGP to point traffic to that customer. Off the top of my head, I don't see why the provider who holds the parent block would do this externally. If the provider has, say, a /18 and they assign a /24 of that to this customer, there would be no legitimate reason to originate that /24 and propagate it out to the rest of the Internet. Note that I don't consider breaking that /18 up into 64 /24s and announcing them all separately to accomplish some sort of poor-man's traffic engineering to be a legitimate reason :) jms
Re: How Not to Multihome
On Oct 8, 2007, at 9:46 PM, Justin M. Streiner wrote: On Mon, 8 Oct 2007, Patrick W. Gilmore wrote: If you went ahead and did this, the more specific route being announced by you on behalf of your customer would be more likely to attract traffic back to you. Prefix length is checked in the BGP route selection process before AS path length. This would work in normal everything works fine situations, but when things break, troubleshooting the source of the customer's reachabilit woes will get very interesting. You have made an assumption that the original upstream would not originate a prefix equivalent to the one you are originating. Internally or externally? A /24 would exist in the provider's IGP to point traffic to that customer. Well, internally is kinda useless to this discussion, wouldn't you think? I get the feeling that you are trying to ask a clever question there, but it didn't come across that way. Off the top of my head, I don't see why the provider who holds the parent block would do this externally. If the provider has, say, a /18 and they assign a /24 of that to this customer, there would be no legitimate reason to originate that /24 and propagate it out to the rest of the Internet. Note that I don't consider breaking that /18 up into 64 /24s and announcing them all separately to accomplish some sort of poor-man's traffic engineering to be a legitimate reason :) Interesting. Did you not read the first paragraph in this e-mail? In fact, I seem to recall that you wrote it (attribution is missing, so I can't be 100% certain). Personally, I'd call that a legitimate reason. To be clear, I am not suggesting de-aggregating every CIDR down to / 24s. But the global table doesn't grow any more whether the customer announces the /24 from their own ASN, or if you muti-originate it from two upstreams - or just one upstream for that matter. So there is no legitimate reason to _not_ announce it, but there is a reason to announce it. -- TTFN, patrick
Re: Upstreams blocking /24s? (was Re: How Not to Multihome)
Hi, On Oct 8, 2007, at 6:28 PM, Justin M. Streiner wrote: On Mon, 8 Oct 2007, Jon Lewis wrote: adopted /24 as the cutoff point. If you make the cutoff point smaller, what is the new point... /26? /32? Presumably the fear is there being no limitation, that is, /32. Anything longer than /24 is unlikely to propogate far on the internet. Pedantically speaking, there ain't no such thing as the internet. There are a series of interconnected private IP based networks, each with their own policy about what they'll transmit and accept in terms of routing updates. What one ISP accepts and propagates is not necessarily what the next ISP accepts and propagates. What I'm trying to understand is whether there is a sufficient critical mass to define a consensus maximal prefix among those interconnected networks. You can all check your filters to see. I just checked mine, and neither Level3 nor Time Warner has tried to send me anything longer than /24 in recent history. If they did, it'd show up as hits on a distribute-list deny rule. I realize that - I was posing a rhetorical question to the previous poster :) The argument, as I understand it (and those who argue this direction feel free to correct me if I misstate), is that as the IPv4 free pool exhausts, there will be a natural pressure to increase address utilization efficiency. This will likely mean longer prefixes will begin to be put (back) into use, either from assignments and allocations that were rediscovered or from unused portions of shorter prefixes. Customers will approach ISPs to get these long prefixes routed, shopping through ISPs until they find one that will accept their money and propagate the long prefix. Now, of course announcing a route doesn't mean anyone will accept it, but as I understand the theory, larger ISPs will agree to accept and propagate longer prefixes from other larger ISPs if those other ISPs will be willing to accept and propagate transmitted long prefixes (scratch my back and I'll scratch yours), particularly if this encourages the smaller ISPs to 'look for other employment opportunities' when they can't afford the router upgrades. Personally, I fully expect the first part to happen. Where I'm having trouble is the second part (the accepting longer prefixes part). However, a few prominent members of the Internet operations community whom I respect have argued strongly that this is going to happen. I thought I'd ask around to see what other folk think... If people feel uncomfortable publicly stating their filter policy is, I'd be happy to summarize responses sent to me directly, keeping individual responses confidential. Regards, -drc
Re: How Not to Multihome
On Mon, 8 Oct 2007, Patrick W. Gilmore wrote: :To be clear, I am not suggesting de-aggregating every CIDR down to / :24s. But the global table doesn't grow any more whether the customer :announces the /24 from their own ASN, or if you muti-originate it :from two upstreams - or just one upstream for that matter. So there :is no legitimate reason to _not_ announce it, but there is a reason :to announce it. Bingo. And, I'd hazard to guess that many readers of this thread have broken more than a single unwritten rule. I recall being chastised relentlessly years back for doing ibgp over a gre tunnel as I saved up for a real trunk. Guess what - it worked wonders in the short term (though I'll admit I'm embarrassed to rehash it). Bottom line (getting back to the original question) is yes, it's ok, so long as you handle due diligence with the owner of the cidr space. RFC, no, courtesy among peers, yup. cheers, brian
Re: Upstreams blocking /24s? (was Re: How Not to Multihome)
On Oct 8, 2007, at 10:28 PM, David Conrad wrote: The argument, as I understand it (and those who argue this direction feel free to correct me if I misstate), is that as the IPv4 free pool exhausts, there will be a natural pressure to increase address utilization efficiency. This will likely mean longer prefixes will begin to be put (back) into use, either from assignments and allocations that were rediscovered or from unused portions of shorter prefixes. Customers will approach ISPs to get these long prefixes routed, shopping through ISPs until they find one that will accept their money and propagate the long prefix. Now, of course announcing a route doesn't mean anyone will accept it, but as I understand the theory, larger ISPs will agree to accept and propagate longer prefixes from other larger ISPs if those other ISPs will be willing to accept and propagate transmitted long prefixes (scratch my back and I'll scratch yours), particularly if this encourages the smaller ISPs to 'look for other employment opportunities' when they can't afford the router upgrades. We know this is not the case from history. For instance, look at Sprint ACL112. Also, we know from history that smaller ISPs sometimes are better able to do router upgrades than large ones. Personally, I fully expect the first part to happen. Where I'm having trouble is the second part (the accepting longer prefixes part). However, a few prominent members of the Internet operations community whom I respect have argued strongly that this is going to happen. I thought I'd ask around to see what other folk think... I'd bet against the first part happening, so the second part is moot. -- TTFN, patrick
