On Fri, Sep 30, 2011 at 10:20 AM, Leo Bicknell <[email protected]> wrote: > In a message written on Fri, Sep 30, 2011 at 12:40:24AM -0400, Christopher > Morrow wrote: >> keep in mind that 'enterprises' may be deploying anycast services >> inside their wan's, NOT publicly visible... What advice would you give >> them in such a situation? > > Just to level set here, I'm assuming you mean a large enterprise > using something like a MPLS L3VPN service, and thus running BGP > with their service provider inside the VPN to communicate routing
that's one option, enterprises come in lots of flavors... I've seen them with mpls-vpn cores and with leased line cores and with ipsec-over-internet cores. (I'm sure you have as well) > information. I clarify, because if it's a simpler IGP only Enterprise > I don't think much of anything we've been discussing makes any > difference, drop it in the IGP and be done. sure. > > I think, basically, most of what we've discussed does not apply. > If it really is a private network there will be no third parties > doing route monitoring. The chance of a rogue ASN injecting the > route is near zero. The provider of the service is also the end the troubleshooting though with something like unique origin is 'simpler' for them: "Oh, as27 is NYC, as37 is WDC... why is Newark seeing WDC as the best path?" > user of the service, and has control of virutally every routing > device in the middle, so there are a multitude of ways they could > monitor and troubleshoot. There will be no external services doing > things like inconsistent asn reports. true, we hope. > Personally I would still originate all of my Anycast from a private > ASN (a la what F does with 3557) for the sole reason that then the > announcement is consistent, thus "show bgp ipv4 unicast inconsistent-as" > actually produces useful output. While it is far less likely to > be used in an enterprise context, it is far more likely to be useful > when it is used given the end to end control. If the enterprise > migrates routes from one site to another (e.g. virtuals in a data > center move) the command will show if they are coming from two > different sites quickly and easily. you are highlighting one troubleshooting technique, yes. I highlighted another. potato/potatoe. Again, for 'smart folks' who know their service inside/out they'll figure this out on their own. For a new deployment, however, some guidelines seem like a good plan. > Honestly though, if I were providing recomendations to an enterprise > I would likely encourage them not to run Anycast. They control the > end clients. They can configure the clients for even better > redundancy than Anycast provides given a little thought. Plus, as > you said, enterprises tend not to be staffed with super-bgp-ninjas, > and so giving them something outside the CCNA traning class is not > a good idea. :) but that network world article... I agree with you mostly, I've seen some good uses of anycast internal to enterprises. Again, 'smart people' and all of that. > > Anycast is best used when you don't control, or have limited control > over the end clients. For instance root operators get to provide > 1 IP address in root.hints or in the root zone, which limits the > ability to do redundancy with multiple IP adddresses... dns servers exist for desktop/vpn clients in corporations too. maybe it's a little 'all I have is a hammer', but it does work well. -chris _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
