RE: Microsoft's participation in World IPv6 day
Bill Woodcock [mailto:wo...@pch.net] spake: http://support.microsoft.com/kb/2533454/ Uh... This does rather assume that users can access Google/Bing (both IPv6 day participants) to search for a solution to the problems they are experiencing, and then that they can actually access the KB article... j.
RE: IPv6 day fun is beginning!
No issues connecting to FB for me on IPv6 (both to www.v6.facebook.com and to the returned by www.facebook.com now). Interesting (perhaps) side note - www.facebook.com has a , but facebook.com does not. Google / Youtube records are up and running nicely also. J. -Original Message- From: Jared Mauch [mailto:ja...@puck.nether.net] Sent: Tuesday, June 07, 2011 7:15 PM To: Iljitsch van Beijnum Cc: NANOG list Subject: Re: IPv6 day fun is beginning! On Jun 7, 2011, at 7:13 PM, Iljitsch van Beijnum wrote: www.facebook.com has but doesn't load for me over IPv6, it does for others though If you go to www.v6.facebook.com it works, but it seems they have some problem on their main site. I am seeing some issues reaching them over IPv6. - Jared
RE: Failover how much complexity will it add?
Seth Mattinen [se...@rollernet.us] said: Forget all of that and just multihome to two separate providers with BGP --Assuming that you're advertising PI space or can work around that appropriately with your providers, I agree, that's the ideal situation. Having multiple circuits to one provider *will not* back anything up if that provider has an outage as they are %99.999 likely to be part of the same larger circuit --True - if you don't specify otherwise when you're ordering, then why would they make the effort? Comments made in some of the other responses in this thread are also valid even with a single service provider - diverse entry points into your facility, diverse upstream circuit routing, and homing to different POPs - which may mean backhauling your secondary circuit away from your local POP and taking a hit for the higher latency on that second link. The moral of this is that whether you're using one provider or more than one, state your diversity requirements clearly up front, and then stay involved and make sure that what's presented to you is _actually_ diverse (oldsflash: even the best intentioned people sometimes make mistakes, especially when there's a handoff to a different last mile provider who may not have been clear on the requirement ). Of course, all of this is potentially wasted effort if the data center you're providing connectivity for does not also maintain the same kind of diversity itself in terms of power, connectivity, architecture, etc. and certainly share the same infrastructure at the provider. --If you enter a single provider's network at diverse points, then that local infrastructure isn't the same at least. But by the same measure, if that provider has a major BGP issue for example, then yeah - they're both screwed... in which case we loop back to the dual provider scenario you mentioned in the first place :) Ultimately choosing the appropriate solution will boil down to the what level of service unavailability one can tolerate in the first place, and put a business value on that impact. From that one can derive technical options, then go cap in hand with a business case to the poor soul paying the bill ;-) j.
RE: Failover how much complexity will it add?
From: a...@baklawasecrets.com [a...@baklawasecrets.com] - BGP router capable of holding full Internet routing table. (whether I go for partial or full, I think I want something with full capability). --Capable of holding _2_ full internet routing tables if you are looking for diversity. (just being picky ;-) j.
RE: Multi site BGP Routing design
Depending on your security policies you may want to encrypt said tunnel also. Other than that, it all depends on it all depends. For example - if you receive / or have a default route pointing to the ISP, then the fact you have the same AS and won't receive the other site's routes in BGP doesn't matter at all - you'll follow a default from site 1 to the ISP, and the ISP will have a route to site 2 and can pass the traffic in the right direction. If you don't mind your traffic being passed unencrypted over the Internet, that is. You'll obviously need to adapt your firewall policies to allow for that flow as well. j. From: Chris Adams [cmad...@hiwaay.net] Sent: Friday, June 05, 2009 20:16 To: nanog@nanog.org Subject: Re: Multi site BGP Routing design Once upon a time, Steve Bertrand st...@ibctech.ca said: Unless someone else has any better advice (I'm sure they do), you will need two separate public ASNs. Site 1 advertises it's space out of AS1, and site 2 advertises it's space from AS2. I don't know that it's better advice, but another way to link the two sites is via a tunnel (GRE or IPIP). Use the upstream IP on each router as the local endpoint, and then run some routing protocol over the tunnel. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
RE: Multi site BGP Routing design
This is a good concept but if the ISP route is a Juniper then as I recall by default it looks ahead, sees the as-path routing loop if it were to send it to the other router, and doesn't send it. So while you might be able to configure it on the receiving router, if the sending router won't send it, you're SOL. j. From: Chuck Anderson [...@wpi.edu] Sent: Friday, June 05, 2009 20:33 To: nanog@nanog.org Subject: Re: Multi site BGP Routing design On Fri, Jun 05, 2009 at 05:50:28PM -0500, Justin Krejci wrote: If the private link between the two sites fails, will BGP allow for us to access the IP subnets at site 2 from site 1 via the internet given that both sites are advertising under the same ASN? Maybe. Especially if both sites are connected to the same ISP, you can tweak some BGP knobs to allow your own ASN to appear in the AS PATH N times where N 1, and accept the routes anyway.
RE: Multi site BGP Routing design
Steve, Agreed. I'm not suggesting that a tunnel is the ultimate best solution, but rather just pointing out that if you go with a tunnel, it's worth remembering that it's going unencrypted over a public network rather than site to site over a private link. j. From: Steve Bertrand [st...@ibctech.ca] Sent: Friday, June 05, 2009 20:40 To: Herbert, John Cc: cmad...@hiwaay.net; nanog@nanog.org Subject: Re: Multi site BGP Routing design john.herb...@ins.com wrote: Depending on your security policies you may want to encrypt said tunnel also. Other than that, it all depends on it all depends. For example - if you receive / or have a default route pointing to the ISP, then the fact you have the same AS and won't receive the other site's routes in BGP doesn't matter at all - you'll follow a default from site 1 to the ISP, and the ISP will have a route to site 2 and can pass the traffic in the right direction. If you don't mind your traffic being passed unencrypted over the Internet, that is. You'll obviously need to adapt your firewall policies to allow for that flow as well. Personally, I don't really like the tunnel idea... I've had to deal with them for v6 connectivity, and they seem so 'ugly'. My first thoughts were about de-aggregation, but since he's already advertising different space out of each site, that became irrelevant. I was just thinking that two AS numbers would be the cleanest, easiest to maintain method for him to take. Certainly tunnelling did go through my mind though to ensure site-to-site peering over the Internet. Steve
RE: IXP BGP timers (was: Multi-homed clients and BGP timers)
For those in multivendor environments, it's worth also being aware that since 7.6R1 JunOS sets the minimum BGP hold timer to 20 seconds. If I were creating a standard timer config to deploy consistently on customer peers (and needed something on the fast side in timer terms) I would need to take that into account. (And yes, there is of course a way to override the 20s hold timer, but it's not a supported config last time I checked) j. From: Andree Toonk [andree+na...@toonk.nl] Sent: Monday, May 25, 2009 2:33 PM To: Chris Caputo Cc: nanog@nanog.org Subject: Re: IXP BGP timers (was: Multi-homed clients and BGP timers) Hi Chris, .-- My secret spy satellite informs me that at Mon, 25 May 2009, Chris Caputo wrote: Would going below 60-180 without first discussing it with your peers, tend to piss them off? 60-180 is fairly conservative. 60-180 is the Cisco default I believe, however Junipers defaults are 30-90. I never pissed anyone off with that ;) Cheers, Andree
