On Wednesday, December 11, 2013 09:01:56 PM Nick Hilliard wrote: > Mostly no argument there when everything is running > smoothly, but from a design perspective, it is a lot > cleaner to handle this stuff in ibgp. You get a bunch > of advantages, including stuff like continuous edge link > flaps not trashing your entire network (before you > pooh-pooh this, I have had to deal with the consequences > of this on a sup720 based core with small numbers of > prefixes in the igp and it's not pretty), being able to > scale your network to arbitrarily large, consistently > controlling distribution of prefixes around the place in > a way that you just can't do with an IGP, implementing > network-wide RTBH infrastructure, etc.
Not to mention that applying routing policy which follows your commercial model is easier done in iBGP than in any IGP. > If your RR can run on pc hardware, it's mostly a > religious thing whether you should run this sort of > thing on bare metal or on a vm. The performance loss > from VM overhead is negligible, but the admin gain can > be large. I run my RRs on esxi because that provide > better console access when operating system stuff goes > wrong or connectivity is lost, as happens occasionally. > > btw I'm not suggesting running RRs on your local stack of > teh-cloud boxes because that would be silly. All my > virtualised RR boxes are running on dedicated hardware, > with a single RR vm on each and with each having > redundant network connectivity into the core. I.e. they > are treated as dedicated routers with the VM layer being > used for OOB management. This works nicely for me; > ymmv. We are looking at deploying dedicated route reflectors on 1U Dell or HP servers against inside ESXi or Qemu/KVM hypervisors, mostly to benefit from the super quick multi- core CPU's and tons of fast RAM that you just don't get in routers. I'll report back how this goes, in a few months, as it will be relatively large scale. Mark.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
