[c-nsp] C6500 IPv6 redistribute with route-map?

[Mark Tinka]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20131211/04429170/attachment.sig>