[c-nsp] Management stuff in VRFs

[John.Herbert at ins.com]

Personally, my recommendation is that if you can afford to have a separate management network, do it. It would also be nice if more network devices had truly isolated management ports such that bearer/management traffic never have to cross paths, share routing tables, and so forth.

Various IOS versions also do not have syntax to tell the router to send syslog / snmp trap / tacacs via the management VRF, defaulting instead to the global routing table. This can be worked around with some effort, but it's an annoyance.

Plus if you have instability in your network environment for any reason, you don't want to be reliant on that unstable network to get access to the routers so you can fix it - you're working on the very transport you're relying on for connectivity.

That said, it can be done with some careful planning, and especially if you have out of band console access as a 'back door' in case of bad connectivity issues, you may have a reasonable compromise without having the expense of parallel management infrastructure.

John.

________________________________
From: cisco-nsp-bounces at puck.nether.net [cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Rathlev [peter at rathlev.dk]
Sent: Wednesday, September 02, 2009 15:36
To: cisco-nsp
Subject: [c-nsp] Management stuff in VRFs

I'm a little curious since there have been so many threads about running
management stuff in VRFs. I've until now considered VRFs something for
customers only; management is in the global table.

Is management from a VRF to be considered "best practice"?

What are the benefits from using a VRF for this?

I assume everyone uses infrastructure ACLs so the VRF thingy shouldn't
be any more "secure". Or should it?

Regards,
Peter




_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/