Re: What to do when your ISP off-shores tech support
Matthew Black wrote: I've had difficulties reaching anyone with a brain at my DSL provider Verizon California. I can reliably ping the first hop from my home to the CO with a 25ms delay. But if I ping any other location, packets get dropped or significantly delayed. To me, this sounds like Verizon has an internal routing problem rather than a problem with my phone line. Note that it rained recently in our area and the cable vault in front of my is usually covered with stagnant water because the gutters don't drain it away. I have tried to explain this to tech support but they refuse to go off script, even the supervisors. They keep insisting on sending a tech to my home when I suggest this should be escalated to their network operations team. Anyhow, if I can reliably ping the first hop from my home, would that eliminate my telephone connection as part of the problem? Just a sanity check on my part. Thanks. matthew black california state university, long beach Are you seeing drops or slow response times for the Verizon hops but not for the last hop destination? If so, remember that most of the larger ISPs will be rate limiting non-admin (ie from their support network ranges) traffic directed to the enterprise equipment. This means they will either ignore or delay responding to ICMP requests directed to their own IP addresses vs forwarding traffic. If your seeing about the same for the destination and for the intermediate hops then it's more likely an issue on the Verizon network. -- James Michael Keller
Re: IPv6: IS-IS or OSPFv3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Dec 28, 2008, at 3:00 AM, Mark Tinka wrote: On Saturday 27 December 2008 09:27:05 pm Randy Bush wrote: as one who has been burned when topologies are not congruent, i gotta ask. if i do not anticipate v4 and v6 having different topologies, and all my devices are dual-capable, would you still recommend mt for other than future-proofing? In practice, we realized that enabling IS-ISv6 on interfaces already running IS-ISv4 was problematic without MT pre- configured. at least in my case, I did turned ISISv6 in one WAN interface where the router on the other side (a Cisco) did not have the ipv6 unicast routing general command on and the isis adjacency went down completely. So, yes that was an issue. But if you enabled IPv6 in both ends first and then one interface at the time, it worked. I used MT to avoid IPv6 black holes during the configuration period, but as some boxes did not implemented it, I needed to use the transition option where IPv6 adjacencies are carried in both native and the MT-IPv6. Fortunately the two vendors that were lacking of MT support are up-to-date, however not in time as the migration ended and MT was removed and I left the company. Roque. - - - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAklabZkACgkQnk+WSgHpbO49PACg2Rx0yaH4owU2GA5koORD+pra kjgAoMgoXYDVD2ayWhn56fkt0urcyyAx =1tWb - - - -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAklacwUACgkQnk+WSgHpbO4TUgCfVpGEMMIdS8y0RrtNQh9rh1Ne fQcAoIOBUc2O4em8NwqwR2UJDDm1Z7Mh =YAeJ -END PGP SIGNATURE-
ARIN receives 2 new /8 blocks
ARIN received the IPv4 address blocks 108.0.0.0/8 and 184.0.0.0/8 from the IANA on Dec. 22, 2008. We will begin making allocations of /20 and shorter prefixes from these blocks in the near future in accordance with ARIN's minimum allocation policy. Network operators may wish to adjust any filters in place accordingly. For informational purposes, a list of ARIN's currently administered IP address blocks can be found at: http://www.arin.net/reference/ip_blocks.html Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN)
Youtube contact
Hi, Can someone from Youtube/Google please contact me off list, I have a strange routing issue at the youtube-cogent border. Usual contact methods have failed me. Thanks Regards Simon
Re: Youtube contact
done. On Tue, Dec 30, 2008 at 1:41 PM, Simon Allard simon.all...@team.orcon.net.nz wrote: Hi, Can someone from Youtube/Google please contact me off list, I have a strange routing issue at the youtube-cogent border. Usual contact methods have failed me. Thanks Regards Simon -- Nathan Hickson KI6RWZ aim/y!: nullrouten efnet: N2k
Failover solution using BGP
Hi, I would appreciate insight and experience for the following situation. I have a client that would like to announce a /18 /19 over BGP in Sacramento and LA, us being the second location in LA. Our location will be a failover location incase Sacramento goes down. They want failover for extreme cases when they're completly down in Sacramento. They have strict requirements so that traffic to their blocks should exclusively go to Sacramento or LA. This seems difficult to automate and they are aware of this. They will contact their provider to stop announcing the blocks and subsequently contact us to announce their routes. I am wondering is there a better way to approaching the situation without resorting to announcing the routes when the client calls us and tells us to failover. This seems to be the inherent problem aswell because the customer wants this to be a manual process. -- Naveen Nathan To understand the human mind, understand self-deception. - Anon
Re: Failover solution using BGP
Conditional advertisements might be what you're looking for: http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a0080094309.shtml Regards, Chris Ely On Wed, 31 Dec 2008, Naveen Nathan wrote: Hi, I would appreciate insight and experience for the following situation. I have a client that would like to announce a /18 /19 over BGP in Sacramento and LA, us being the second location in LA. Our location will be a failover location incase Sacramento goes down. They want failover for extreme cases when they're completly down in Sacramento. They have strict requirements so that traffic to their blocks should exclusively go to Sacramento or LA. This seems difficult to automate and they are aware of this. They will contact their provider to stop announcing the blocks and subsequently contact us to announce their routes. I am wondering is there a better way to approaching the situation without resorting to announcing the routes when the client calls us and tells us to failover. This seems to be the inherent problem aswell because the customer wants this to be a manual process. -- Naveen Nathan To understand the human mind, understand self-deception. - Anon
Re: Failover solution using BGP
If the infrastructure is the same in both locations, why not load balance with stateful failover? If it's not the same in both locations, what are they doing for replication and the such in the event a site does go down? - Chandler On Dec 30, 2008, at 7:08 PM, Naveen Nathan wrote: Hi, I would appreciate insight and experience for the following situation. I have a client that would like to announce a /18 /19 over BGP in Sacramento and LA, us being the second location in LA. Our location will be a failover location incase Sacramento goes down. They want failover for extreme cases when they're completly down in Sacramento. They have strict requirements so that traffic to their blocks should exclusively go to Sacramento or LA. This seems difficult to automate and they are aware of this. They will contact their provider to stop announcing the blocks and subsequently contact us to announce their routes. I am wondering is there a better way to approaching the situation without resorting to announcing the routes when the client calls us and tells us to failover. This seems to be the inherent problem aswell because the customer wants this to be a manual process. -- Naveen Nathan To understand the human mind, understand self-deception. - Anon
RE: Failover solution using BGP
Why not just AS prepend your secondary site if the services to the Internet are the same at both sites and tied to the same IP addresses? Mike -Original Message- From: Chandler Bassett [mailto:chandler.bass...@gmail.com] Sent: Tuesday, December 30, 2008 4:15 PM To: Naveen Nathan Cc: nanog@nanog.org Subject: Re: Failover solution using BGP If the infrastructure is the same in both locations, why not load balance with stateful failover? If it's not the same in both locations, what are they doing for replication and the such in the event a site does go down? - Chandler On Dec 30, 2008, at 7:08 PM, Naveen Nathan wrote: Hi, I would appreciate insight and experience for the following situation. I have a client that would like to announce a /18 /19 over BGP in Sacramento and LA, us being the second location in LA. Our location will be a failover location incase Sacramento goes down. They want failover for extreme cases when they're completly down in Sacramento. They have strict requirements so that traffic to their blocks should exclusively go to Sacramento or LA. This seems difficult to automate and they are aware of this. They will contact their provider to stop announcing the blocks and subsequently contact us to announce their routes. I am wondering is there a better way to approaching the situation without resorting to announcing the routes when the client calls us and tells us to failover. This seems to be the inherent problem aswell because the customer wants this to be a manual process. -- Naveen Nathan To understand the human mind, understand self-deception. - Anon -- THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM.
Re: IPv6: IS-IS or OSPFv3
On Wednesday 31 December 2008 03:14:13 am Roque Gagliano wrote: at least in my case, I did turned ISISv6 in one WAN interface where the router on the other side (a Cisco) did not have the ipv6 unicast routing general command on and the isis adjacency went down completely. So, yes that was an issue. One of the things I'm hoping Cisco can fix in not-too- distant future releases of IOS. But if you enabled IPv6 in both ends first and then one interface at the time, it worked. What we saw on our test segment was that v4 adjacencies were not torn down by merely enabling IS-ISv6 on an interface (given that JunOS enables IS-ISv6 by default when IS-IS is enabled on the router; in IOS, you have to explicitly turn IS-ISv6 on). v4 adjacencies were torn down *after* an IPv6 address was added to the interface. We witnessed this issue under both IOS and JunOS. Cheers, Mark. signature.asc Description: This is a digitally signed message part.
Re: IPv6: IS-IS or OSPFv3
For IS-IS, highly recommend MT to avoid any nasties while turning up v6 in a dual-stack environment. Also when doing MT on cisco, configure no-adjacency-check under the v6 address-family during the migrate else you will bounce your sessions. Cisco of course warn you against doing this but without it the change is bumpy. From the cisco docs: Disabling the adjacency-check command can adversely affect your network configuration. Enter the no adjacency-check command only when you are running IPv4 IS-IS on all your routers and you want to add IPv6 IS-IS to your network but you need to maintain all your adjacencies during the transition. When the IPv6 IS-IS configuration is complete, remove the no adjacency-check command from the configuration. source: http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-is-is.html David Freedman Group Network Engineering Claranet Limited http://www.clara.net
RE: Failover solution using BGP
If you don't have control over the other site my best advice would be to use the BGP communities your transit providers give you. If you setup your clients routes to a lower Local Perf on your transit provider's network, your transit provider will always pick the primary provider's routes first. The moment the primary site stops announcing the route your transit provider will immediately start announcing yours. This works better then AS prepend because almost all providers override the AS prepend with a higher local pref for free peers, local customers, etc. The only other issue would be, how to stop the primary network from advertising your client's routes automatically. This could be done by the client setting up BGP with the primary provider and then pulling the routes. If your client does not run BGP then it all depends on how the ips are setup on the primary side. My best advice is if they don't have BGP to tell them to set it up. Tell them to setup a private AS BGP session with their provider and just get a default route from them. This way they use just about any piece of networking equipment and they don't need their own external AS. Then they can either shutdown the port, BGP session, or pull the route (all they can do themselves) to have their provider pull the route from the internet. Use this link to find common communities: http://www.onesc.net/communities/ Otherwise, the customer could get around this whole issue by setting up some type global server load balancing. There are quite a few companies that have solutions for this. But it would take a lot more technical networking knowledge on the client side. Austin -Original Message- From: Naveen Nathan [mailto:nav...@calpop.com] Sent: Tuesday, December 30, 2008 5:09 PM To: nanog@nanog.org Subject: Failover solution using BGP Hi, I would appreciate insight and experience for the following situation. I have a client that would like to announce a /18 /19 over BGP in Sacramento and LA, us being the second location in LA. Our location will be a failover location incase Sacramento goes down. They want failover for extreme cases when they're completly down in Sacramento. They have strict requirements so that traffic to their blocks should exclusively go to Sacramento or LA. This seems difficult to automate and they are aware of this. They will contact their provider to stop announcing the blocks and subsequently contact us to announce their routes. I am wondering is there a better way to approaching the situation without resorting to announcing the routes when the client calls us and tells us to failover. This seems to be the inherent problem aswell because the customer wants this to be a manual process. -- Naveen Nathan To understand the human mind, understand self-deception. - Anon
Re: Failover solution using BGP
Hi, Am 31.12.2008 01:19 Uhr, Braun, Mike schrieb: Why not just AS prepend your secondary site if the services to the Internet are the same at both sites and tied to the same IP addresses? because that simply does not work (reliably). It would depend on AS-paths of the same length from every possible source. Simple, reliable and quite stylish is another way: Choose primary and secondary location by announcing more specifics at Sacramento, e.g. all networks as /20 subnets. As longest match always wins, any source seeing both routes for an IP address will choose Sacramento. The only way traffic could reach LA would be a missing route to Sacramento. In any other case, Sacramento is chosen. Thus, if Sacramento (manually or automatically) stops announcing the /20s, LA's /18 and /19 will be chosen. CAVE: This is no failover solution for single services, just for whole subnets depending on the announcement at Sacramento. CAVE2: My suggestion creates inconsistent announcements for the source AS. That may or may not be a problem. Kind regards, Malte -- Malte v. dem Hagen Abteilung Technik - Network Operations Centre - Host Europe GmbH- http://www.hosteurope.de/ Welserstrasse 14- D-51149 Köln - Germany Telefon 0800-4 67 83 87 - Telefax 01805-66 32 33 HRB 28495 Amtsgericht Koeln - UST ID DE187370678 GF: Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller - signature.asc Description: OpenPGP digital signature
Re: Failover solution using BGP
On Tue, Dec 30, 2008 at 7:08 PM, Naveen Nathan nav...@calpop.com wrote: I have a client that would like to announce a /18 /19 over BGP in Sacramento and LA, us being the second location in LA. Our location will be a failover location incase Sacramento goes down. They want failover for extreme cases when they're completly down in Sacramento. They have strict requirements so that traffic to their blocks should exclusively go to Sacramento or LA. Announce from Sacramento normally. Announce from LA with an AS prepend 3 or 4 deep. GRE tunnel from LA back to Sacramento diverting the few packets which insist on going to LA back to Sacramento during normal operation. Or conditionally announce in LA based on a monitoring process which watches Sacramento and deal with the extra complexity and longer restoration time. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Failover solution using BGP
Thank to everyone that took the time to respond with their ideas. To those who asked, the client didn't provide details on the application. However they were insistent that it wasn't possible to have it run in an active/active configuration, so load balancing at either the application or BGP level wasn't an option. Also they didn't want to subnet the space for the failover location, so it's all or nothing style routing. Of the several solutions presented the two that seem to be simple to implement and guarantee traffic were conditional route advertisements or using more specific routes. I was unable to find information for conditional route advertisements in JunOS, so it seems like advertising specific routes at the primary option will be the easiest option. If anyone has information on conditional routing for JunOS, I would be much appreciative if you could send this to me. Happy Holidays everyone. - Naveen
