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: [email protected] [[email protected]] On Behalf Of Peter Rathlev [[email protected]] 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 [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
