Re: about interdomain multipath routing.
On Tue, Nov 10, 2009 at 3:50 AM, Matthew Petach mpet...@netflight.com wrote: I've outlawed the use of multihop eBGP for load-sharing here; when we get multiple links off the same router to a peer or upstream, they are configured with multipath. We've got hundreds of BGP sessions across the network configured with multipath on them. Do you use iBGP multipath as well to load-balance between links on different routers? I know eBGP multipath is fairly common, but I wonder how many are using iBGP multipath as well. I doubt any carriers would support it, so it's probably only useful for load-balancing outbound traffic. The problem with eBGP multipath alone is that you might want to terminate circuits from a given carrier on two different routers for redundancy reasons, but that precludes any load-balancing with eBGP multipath. Obviously your network has to be designed with equal-cost paths for iBGP multipath to be of any value. -Doug
Re: about interdomain multipath routing.
On Tue, Nov 10, 2009 at 1:10 AM, Doug Lane lan...@gmail.com wrote: On Tue, Nov 10, 2009 at 3:50 AM, Matthew Petach mpet...@netflight.com wrote: I've outlawed the use of multihop eBGP for load-sharing here; when we get multiple links off the same router to a peer or upstream, they are configured with multipath. We've got hundreds of BGP sessions across the network configured with multipath on them. Do you use iBGP multipath as well to load-balance between links on different routers? Yes. I know eBGP multipath is fairly common, but I wonder how many are using iBGP multipath as well. I doubt any carriers would support it, so it's probably only useful for load-balancing outbound traffic. The problem with eBGP multipath alone is that you might want to terminate circuits from a given carrier on two different routers for redundancy reasons, but that precludes any load-balancing with eBGP multipath. Obviously your network has to be designed with equal-cost paths for iBGP multipath to be of any value. -Doug iBGP with multipath, multiple LSPs to each BGP next-hop...much load balancing across all same-cost internal links to each of the eBGP multihop next-hops. inet.0: 300787 destinations, 2675963 routes (300092 active, 2 holddown, 2086 hidden) Yes...takes up a chunk more memory keeping track of all the different paths, but it does provide more end-to-end load balancing of traffic even on different routers. Matt
Re: BGP Peer Selection Considerations
If nothing else by the time this deployment is finished I will surely have become extremely cynical. Now reading through peoples answers, I think the general consensus is that I would be giving too much control to provider A in the scenario I suggested below. So as someone mentioned they have the ability to foul up my connections all by themselves. From all of this I gather that the most resilience would be provided by: 1) Go to two tier 1 carriers myself - say Global Crossing and Level 3. Arrange to get two 100meg BGP feeds, burstable. Pick them up at different datacentres as well I suppose to provide datacentre redundancy? Negotiate pricing, any tips on negotiating appreciated. 2) Arrange cross connects to these providers i.e. get to the datacentres the Tier1 providers are in. They are not on net at the colo we are in. With regards to arranging the cross connects am I able to ask the cross connect providers for fibre maps? Is this a done thing or will they brush me off with you don't need this our network is diverse? 3) Arrange for PI space and ASN myself, so become an LIR through RIPE. Do I really lose a lot by asking Level3 or GBLX to get the PI and ASN for me? I think the failure mode cited by someone was if the PI and ASN provider goes out of business. I would prefer not to go through becoming an LIR and maintaining the membership, as they are not an ISP and so it is more attractive to do that through one of the Tier 1 providers. I'm not sure what my options are in terms of getting to the datacentres to pick up the Tier1 providers. The provider A below has said they run a diverse fibre backhaul network etc etc. and I should go with them for connectivity to other datacentres. Now it would be easier to go with them just because they are running colo for us and they run the datacentre we are in. However I assume that I should not be scared of arranging a second cross connect with someone else altogether. In all of the above, I'm most worried about administrative overhead. Managing two cross connect providers, managing ongoing relationship with two Tier1 providers and so on. However resilience comes at a cost I suppose is the answer. Comments appreciated. Adel On Mon 7:10 PM , William Herrin herrin-na...@dirtside.com sent: On Mon, Nov 9, 2009 at 12:40 PM, adel@ baklawasecrets.com wrote: I have an existing relationship with provider A, colo, cross connects etc. Provider A has offered to get the PI space, ASN number, purchase the transit for us with provider B and manage cross connects to provider B (they say they have a diverse fibre backhaul network). This is quite attractive from a support and billing perspective. Also suspect that provider A will be able to get more attractive pricing from Provider B than I would be able to. Am I missing things that I need to consider? What happens when provider A is bought by provider C and you want to dump provider C but keep provider B? You'll have created a conflict of interest for provider B in any negotiation you have with them. Be aware that provider A's diverse network for provider A's service is the same diverse network they'll use to connect you to provider B. As a result, many or most of the outages which impact provider A will also impact your connectivity to provider B, defeating the central purpose of having a provider B. Regards, Bill Herrin -- William D. Herrin her...@di rtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/Falls Church, VA 22042-3004
Re: BGP Peer Selection Considerations
On 10/11/2009 09:52, a...@baklawasecrets.com wrote: 3) Arrange for PI space and ASN myself, so become an LIR through RIPE. You don't need to become a LIR to get PI space and an ASN. Do I really lose a lot by asking Level3 or GBLX to get the PI and ASN for me? You lose relatively little. If you wish to move your provider independent resources to another LIR at a later stage, RIPE are very happy to assist. I think the failure mode cited by someone was if the PI and ASN provider goes out of business. If they go out of business, there's a small amount of overhead - you find yourself a new LIR and life will continue on. I wouldn't worry about it too much. I would prefer not to go through becoming an LIR and maintaining the membership Probably sensible. Nick
Re: What DNS Is Not
On Mon, 09 Nov 2009 18:15:09 -0500 David Ulevitch dav...@everydns.net wrote: On 11/9/09 6:06 PM, Alex Balashov wrote: Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or why this could possibly be controversial. Because some people want the ability and choice to block DNS responses they don't like; just as they have the ability and choice to reject email they don't want to accept. When the conficker worms phones home to one of the 50,000 potential domains names it computes each day, there are a lot of IT folks out there that wish their local resolver would simply reject those DNS requests so that infected machines in their network fail to phone home. To use your language, I don't understand how or why this could possibly be controversial. -- Apparently it is. In which case, make your own nameserver authoritative for those domains; do not foist your own wishes on other people. -- John
Re: What DNS Is Not
When the conficker worms phones home to one of the 50,000 potential domains names it computes each day, there are a lot of IT folks out there that wish their local resolver would simply reject those DNS requests so that infected machines in their network fail to phone home. To use your language, I don't understand how or why this could possibly be controversial. -- Apparently it is. In which case, make your own nameserver authoritative for those domains; do not foist your own wishes on other people. Since people need to *explicitly* choose using the OpenDNS servers, I can hardly see how anybody's wishes are foisted on these people. If you don't like the answers you get from this (free) service, you can of course choose to use a different service - for instance your ISP's name servers. (I may or may not agree with what OpenDNS does - that is completely irrelevant in this case.) Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: What DNS Is Not
On Mon, Nov 09, 2009 at 06:15:09PM -0500, David Ulevitch dav...@everydns.net wrote a message of 18 lines which said: When the conficker worms phones home to one of the 50,000 potential domains names it computes each day, there are a lot of IT folks out there that wish their local resolver would simply reject those DNS requests so that infected machines in their network fail to phone home. That's an extremely bad idea: many of the domains generated by the Conficker algorithm are already registered by a legitimate registrant (in .FR: the national railways, a national TV, etc). Also, the example is not a good choice since Conficker now mostly uses P2P: http://mtc.sri.com/Conficker/P2P/ for those who like assembly code and awful technical details.
AfNOG 2010
AfNOG-11 and AfriNIC-12: Meetings 23 May-4 June, 2010 The African Network Operators' Group (AfNOG) and the African Network Information Centre (AfriNIC) are pleased to announce that the 11th AfNOG Meeting and the AfriNIC-12 Meeting would be held in Kigali, Rwanda during May June 2010. About the Entire Event AfNOG and AfriNIC are jointly organizing a two-week event that includes the AfNOG Workshop on Network Technology (offering advanced training in a week-long hands-on workshop), several full-day Advanced Tutorials, a one-day AfNOG Meeting, and a two-day AfriNIC Meeting. In addition, several side meetings and workshops will be hosted in collaboration with other organizations. Timetable Unix Boot Camp 23 May 2010 (Sunday) AfNOG Workshop 24 - 28 May 2010 (Monday - Friday) AfriNIC IPv6 Workshop 29 - 30 May 2010 (Saturday - Sunday) AfREN Meeting / AAF 29 - 30 May 2010 (Saturday - Sunday) http://www.afnog.org/afnog2010/tutorial/ AfNOG Tutorials 30 - 31 May 2010(Sunday - Monday) AfriNIC LIR Workshop 31 May 2010 (Monday) http://www.afnog.org/afnog2010/conference/ AfNOG-11 Meeting 1 June 2010 (Tuesday) http://www.afrinic.net/meeting/ AfriNIC-12 Meeting 2- 3 June 2010 (Wednesday - Thursday) Africa INET Day 4 June 2010 (Friday) Venue Hotel Venue hotel for the event will be announced shortly. About AfNOG AfNOG (See http://www.afnog.org/ http://www.afnog.org/) is a forum for cooperation and the exchange of technical information between operators of Internet-connected networks in Africa. AfNOG has organized an event like this one every year since 2000. About AfriNIC AfriNIC (See http://www.afrinic.net/ http://www.afrinic.net/) is a Regional Internet Registry (RIR), responsible for Internet Number resources Management in the Africa region. AfriNIC organizes two Public Policy meetings every year (see http://www.afrinic.net/meeting/ http://www.afrinic.net/meeting/). AfNOG Workshop on Network Technology The AfNOG Workshop on Network Technology aims to offer advanced training to people who are in the process of developing and enhancing an Internet-connected network with regional and international connectivity. The target audience includes senior and mid-level technical staff of commercial Internet service providers (ISPs), academic networks, government networks, or NGO networks. This workshop builds on the experience of previous AfNOG workshops held annually from 2000 to 2009 in ten different African countries, and also the Internet Society's INET workshops, held annually from 1993 to 2000 at eight locations around the world. The workshop's instructors are an international team with many years of experience operating large networks and teaching about network operations. The workshop is divided into four parallel tracks: * SA-E - Unix System Administration (in English), focused on using a Unix-like operating system as a platform for delivery of Internet services. * SS-E - Scalable Internet Services (in English), focused on the design and operation of email, web, and other Internet services, in ways that can scale to handle large numbers of end users. * SI-E - Scalable Network Infrastructure (in English), focused on the design and operation of networks using routers and switches, in ways that can scale to handle large numbers of interconnected sites. * SI-F - Infrastructure Reseaux IP (en francais), similar to track SI-E, but given in French. Workshop application information is available here: http://www.afnog.org/afnog2010/workshop/online_application_en.html http://www.afnog.org/afnog2010/workshop/online_application_fr.html AfREN Meeting The Africa Research and Education Networking community will be holding a two-day meeting on 29 - 30 May 2010. The meeting will discuss issues of interest to the NREN community such as coordination on activites in the region, advocacy, bandwidth consortia, regional RENs etc. Additional information about AfREN 2010 will be provided shortly. AfNOG Tutorials AfNOG will offer 1 to 2 full-day(s) tutorials on advanced topics. Tutorials take place in a classroom-style environment, and may include a hands-on practical component. Tutorials are non-commercial in nature, and most are technically oriented. They are intended to offer advanced training on technology already deployed or soon to be deployed on networking and related services provisioning for ISP operations. Additional information about AfNOG 2010 Tutorials will be availabe here: http://afnog.org/afnog2010/tutorial/ http://www.afnog.org/afnog2010/tutorial/ 11th AfNOG Meeting The 11th AfNOG meeting will be held in Kigali, Rwanda on 01 June 2010. AfNOG conferences provide a forum for the coordination and dissemination of technical information related to backbone/enterprise networking technologies and operational practices. The meetings are informal, with an emphasis on relevance to current and future African backbone engineering practices.
Re: What DNS Is Not
When the conficker worms phones home to one of the 50,000 potential domains names it computes each day, there are a lot of IT folks out there that wish their local resolver would simply reject those DNS requests so that infected machines in their network fail to phone home. That's an extremely bad idea: many of the domains generated by the Conficker algorithm are already registered by a legitimate registrant (in .FR: the national railways, a national TV, etc). It's an idea that needs to be used *with caution*. We did something similar as part of testing a new DNS product, and found that any such list of domain names needed to be *manually* vetted before being used as input to a DNS-based blackhole system. We also found that we had to explicitly whitelist a number of domains (generated by Conficker but registered many years ago and pretty clearly legit). Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: What DNS Is Not
On 11/10/09 9:04 AM, sth...@nethelp.no wrote: When the conficker worms phones home to one of the 50,000 potential domains names it computes each day, there are a lot of IT folks out there that wish their local resolver would simply reject those DNS requests so that infected machines in their network fail to phone home. That's an extremely bad idea: many of the domains generated by the Conficker algorithm are already registered by a legitimate registrant (in .FR: the national railways, a national TV, etc). It's an idea that needs to be used *with caution*. We did something similar as part of testing a new DNS product, and found that any such list of domain names needed to be *manually* vetted before being used as input to a DNS-based blackhole system. We also found that we had to explicitly whitelist a number of domains (generated by Conficker but registered many years ago and pretty clearly legit). This is correct. And we take this into consideration in determining what to block using our existing datasets, which are sufficient considering the volume of DNS traffic that crosses our network. -David
Re: What DNS Is Not
On 11/10/09 8:05 AM, John Peach wrote: On Mon, 09 Nov 2009 18:15:09 -0500 David Ulevitchdav...@everydns.net wrote: On 11/9/09 6:06 PM, Alex Balashov wrote: Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or why this could possibly be controversial. Because some people want the ability and choice to block DNS responses they don't like; just as they have the ability and choice to reject email they don't want to accept. When the conficker worms phones home to one of the 50,000 potential domains names it computes each day, there are a lot of IT folks out there that wish their local resolver would simply reject those DNS requests so that infected machines in their network fail to phone home. To use your language, I don't understand how or why this could possibly be controversial. -- Apparently it is. In which case, make your own nameserver authoritative for those domains; do not foist your own wishes on other people. Umm... That's precisely what I've done. Please read the thread. -David
BGP Traffic Engineering question
Howdy, If you have several transit providers connected to your network and much of your traffic is generally directed by the BGP tiebreaker (i.e. lowest IP address) is there a way, without specifying on a per-prefix basis to prefer the tie breaker winner slightly less often? I don't want to completely flip the preference so that it just saturates a different link, I am just trying to see if there is any good way to influence the natural selection method. We have 6 transit providers, and Level3 always wins because it is 4/8, normally this isn't a problem because we have traffic engineering systems (route science/avaya) which move traffic away from that link, but if we need to reboot the RS, or something catastrophic happens we would like it to spread out a little more evenly. Anyone have any thoughts on this? -Drew
Re: BGP Traffic Engineering question
Isn't Route Science EOL? Jeff On Tue, Nov 10, 2009 at 1:31 PM, Drew Weaver drew.wea...@thenap.com wrote: Howdy, If you have several transit providers connected to your network and much of your traffic is generally directed by the BGP tiebreaker (i.e. lowest IP address) is there a way, without specifying on a per-prefix basis to prefer the tie breaker winner slightly less often? I don't want to completely flip the preference so that it just saturates a different link, I am just trying to see if there is any good way to influence the natural selection method. We have 6 transit providers, and Level3 always wins because it is 4/8, normally this isn't a problem because we have traffic engineering systems (route science/avaya) which move traffic away from that link, but if we need to reboot the RS, or something catastrophic happens we would like it to spread out a little more evenly. Anyone have any thoughts on this? -Drew -- Jeffrey Lyon, Leadership Team jeffrey.l...@blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to protect your booty.
RE: BGP Traffic Engineering question
Sure, it still works however (for now). -Drew -Original Message- From: jeffrey.l...@gmail.com [mailto:jeffrey.l...@gmail.com] On Behalf Of Jeffrey Lyon Sent: Tuesday, November 10, 2009 1:34 PM To: Drew Weaver Cc: nanog@nanog.org Subject: Re: BGP Traffic Engineering question Isn't Route Science EOL? Jeff On Tue, Nov 10, 2009 at 1:31 PM, Drew Weaver drew.wea...@thenap.com wrote: Howdy, If you have several transit providers connected to your network and much of your traffic is generally directed by the BGP tiebreaker (i.e. lowest IP address) is there a way, without specifying on a per-prefix basis to prefer the tie breaker winner slightly less often? I don't want to completely flip the preference so that it just saturates a different link, I am just trying to see if there is any good way to influence the natural selection method. We have 6 transit providers, and Level3 always wins because it is 4/8, normally this isn't a problem because we have traffic engineering systems (route science/avaya) which move traffic away from that link, but if we need to reboot the RS, or something catastrophic happens we would like it to spread out a little more evenly. Anyone have any thoughts on this? -Drew -- Jeffrey Lyon, Leadership Team jeffrey.l...@blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to protect your booty.
Re: Interesting Point of view - Russian police and RIPE accused of aiding RBN
Greetings! By the way, Jeffrey, by the 24th of October, when you posted the information that the RBN is located in our networks we couldn't even know about any malware redirectors on our clients resources - http://www.stopbadware.org/reports/asn/44571. I'm trying to solve the Google SB issue (still under investigation both by our team and the resource owner, but NB - it's only 1 ip from 345 sites tested by Google ) but one little question - how did you get to know about the malware abuse _before_ the actual report on stopbadware.org or on google? What were your conclusions based on? Why didn't you write to the abuse email the way it's traditionally done in the network operators' sphere? Kanak Akrino Abuse Team
Re: Interesting Point of view - Russian police and RIPE accused of aiding RBN
Kanak, NANOG moderators have requested this conversation go off list. Jeff On Tue, Nov 10, 2009 at 1:50 PM, noc acrino noc.akr...@gmail.com wrote: Greetings! By the way, Jeffrey, by the 24th of October, when you posted the information that the RBN is located in our networks we couldn't even know about any malware redirectors on our clients resources - http://www.stopbadware.org/reports/asn/44571. I'm trying to solve the Google SB issue (still under investigation both by our team and the resource owner, but NB - it's only 1 ip from 345 sites tested by Google ) but one little question - how did you get to know about the malware abuse _before_ the actual report on stopbadware.org or on google? What were your conclusions based on? Why didn't you write to the abuse email the way it's traditionally done in the network operators' sphere? Kanak Akrino Abuse Team -- Jeffrey Lyon, Leadership Team jeffrey.l...@blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to protect your booty.
Re: about interdomain multipath routing.
We use multipath setups for our EIGRP and iBGP configurations for our internal routing as well. Although for larger networks iBGP multipath might be of use due to memory limitations on a lot of devices. Doug Lane wrote: On Tue, Nov 10, 2009 at 3:50 AM, Matthew Petach mpet...@netflight.com wrote: I've outlawed the use of multihop eBGP for load-sharing here; when we get multiple links off the same router to a peer or upstream, they are configured with multipath. We've got hundreds of BGP sessions across the network configured with multipath on them. Do you use iBGP multipath as well to load-balance between links on different routers? I know eBGP multipath is fairly common, but I wonder how many are using iBGP multipath as well. I doubt any carriers would support it, so it's probably only useful for load-balancing outbound traffic. The problem with eBGP multipath alone is that you might want to terminate circuits from a given carrier on two different routers for redundancy reasons, but that precludes any load-balancing with eBGP multipath. Obviously your network has to be designed with equal-cost paths for iBGP multipath to be of any value. -Doug -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional
Re: BGP Traffic Engineering question
On Tue, 10 Nov 2009, Drew Weaver wrote: If you have several transit providers connected to your network and much of your traffic is generally directed by the BGP tiebreaker (i.e. lowest IP address) is there a way, without specifying on a per-prefix basis to prefer the tie breaker winner slightly less often? Assuming Cisco, set bgp always-compare-med, bgp deterministic-med, and in your route-map in, set origin igp and set metric X. You can then vary X as you see fit as an alternate tie-breaker. As long as you never set the metric the same on two different paths for the same prefix, it'll never fall back to router-id. Depending on the transit provider, you can often match bgp communities to determine which are customer routes or the region where the announcement was heard, which you can then use as a tie-breaker when setting the metric. Barring that, as-path access-lists matching specific path fragments can do the same thing, but seems to take more work to maintain as relationships change over time. -- Aaron
Re: BGP Traffic Engineering question
Aaron Hopkins wrote: On Tue, 10 Nov 2009, Drew Weaver wrote: If you have several transit providers connected to your network and much of your traffic is generally directed by the BGP tiebreaker (i.e. lowest IP address) is there a way, without specifying on a per-prefix basis to prefer the tie breaker winner slightly less often? Assuming Cisco, set bgp always-compare-med, bgp deterministic-med, and in your route-map in, set origin igp and set metric X. You can then vary X as you see fit as an alternate tie-breaker. As long as you never set the metric the same on two different paths for the same prefix, it'll never fall back to router-id. Depending on the transit provider, you can often match bgp communities to determine which are customer routes or the region where the announcement was heard, which you can then use as a tie-breaker when setting the metric. Barring that, as-path access-lists matching specific path fragments can do the same thing, but seems to take more work to maintain as relationships change over time. -- Aaron Tutorial: Effective BGP Load Balancing Using The Metric System Dani Roisman, Peak Web Consulting http://tinyurl.com/yzlmmo8
Re: Failover how much complexity will it add?
a...@baklawasecrets.com wrote: Actually thinking about this, I still need to understand the implications of not taking a full routing table to my setup. So what is the likely impact going to be if I take partial instead of full routing table. Would appreciate any feedback on this. My organisation is only looking at using BGP as a means of failover between two separate upstream ISPs. We are not an ISP. I'm up against the same issue. I'm having a hard time understanding what partial routes will accomplish in the following scenario. Let's say we were BGP multi homed and accepting partial tables from two top level ISPs (like Sprint, Cogent, Telia, ATT whatever). Let's say they get into a peering spat with another top level ISP. This results in one of your upstreams not routing packets to one or more ASs. In this situation, as far as I can tell, you'd want a full routing tables from your upstreams. Without a full routing table how would your router know that certain ASs are reachable through one upstream, but not the other? In this day of and age of wild-west, cowboy attitudes between some of the biggest players on the Internet, does protecting against these problems require a routing device that can handle multiple full routing tables? It would seem so... Cheers, Stef
Re: BGP Peer Selection Considerations
I've decided to get transit from provider B independently of A, so I don't create a conflict of interest as mentioned below. However I think that I will have to use provider A's dark fibre network to connect to both peerings. Provider A tells me that they will use different routes and different entry points to get to their peering and separate routes, entries to get to B's peering. As they own the datacentre and can probably provide the bests costs for getting into the datacentres where the second transit provider is, I think I will have to use I should mention there are no transit providers on net at the datacentre facility which has been acquired by the business. I suspect it will be cheaper to get the cross connects to where the transit provider is from provider A, (did I mention provider A owns the datacentre?). I know I'll be sacrificing some resilience by using A's network to get to both Internet services, however I think I will just have to outline the risks to the business and go with it. Moving datacentres isn't an option and as long as I understand exactly what resilience I sacrifice by getting A to provide all the cross connects, I can explain that to the business. Adel On Mon 7:10 PM , William Herrin herrin-na...@dirtside.com wrote: On Mon, Nov 9, 2009 at 12:40 PM, wrote: I have an existing relationship with provider A, colo, cross connects etc. Provider A has offered to get the PI space, ASN number, purchase the transit for us with provider B and manage cross connects to provider B (they say they have a diverse fibre backhaul network). This is quite attractive from a support and billing perspective. Also suspect that provider A will be able to get more attractive pricing from Provider B than I would be able to. Am I missing things that I need to consider? What happens when provider A is bought by provider C and you want to dump provider C but keep provider B? You'll have created a conflict of interest for provider B in any negotiation you have with them. Be aware that provider A's diverse network for provider A's service is the same diverse network they'll use to connect you to provider B. As a result, many or most of the outages which impact provider A will also impact your connectivity to provider B, defeating the central purpose of having a provider B. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web:
Re: Failover how much complexity will it add?
Stef Walter wrote: In this day of and age of wild-west, cowboy attitudes between some of the biggest players on the Internet, does protecting against these problems require a routing device that can handle multiple full routing tables? It would seem so... It has been routinely observed in nanog presentations that settlement free providers by their nature miss a few prefixes that well connected transit purchasing ISPs carry. If business requirements for reachability necessitate multi-homing then carrying the tables if probably also a requirement. joel Cheers, Stef
Re: Failover how much complexity will it add?
It has been routinely observed in nanog presentations that settlement free providers by their nature miss a few prefixes that well connected transit purchasing ISPs carry. just trying to understand what you mean, o no transit-free provider actually has all (covering) prefixes needed to cover the active space, but o one or more reasonably small subsets of the set of transit-free providers do cover the whole active space. randy
Re: Failover how much complexity will it add?
I would have thought that this lesson would still be fresh in the minds of people, as we just passed 256K routes a little while ago and broke a whole bunch of Catalyst 6500/7600 SUP720-3B's (etc). I guess the pain isn't as memorable as I thought. Not all of us forgot... I remember the day our 7606's filled and started trying to software switch. Was a painful day indeed. At least we knew it was coming.. just couldn't do anything about it due to budgets.
