[c-nsp] Management stuff in VRFs

[Scott Granados]

Hi, just to add to this...

I have to strongly support the out of band management angle.  If designed 
properly you can carry all your management traffic including provisioning 
and authentication as well as provide emergency access.  A simple setup with 
T1's and 25xx / 26xx boxes with the octopus cables should do the trick. 
Aggregate them over a reasonable sized geographic area to an aggregation 
core and Bob's your uncle.  When you see DS1 loop pricing in some markets 
sub $40 per it seems worth it instead of dealing with the headaches and lack 
of functionality of inband management.

----- Original Message ----- 
From: "Frank Bulk - iName.com" <frnkblk at iname.com>
To: "'Peter Rathlev'" <peter at rathlev.dk>; "cisco-nsp" 
<cisco-nsp at puck.nether.net>
Sent: Friday, September 04, 2009 1:05 PM
Subject: Re: [c-nsp] Management stuff in VRFs


> In short, the best management VRF is a serial-based terminal server. =)
>
> Frank
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Rathlev
> Sent: Thursday, September 03, 2009 4:34 PM
> To: cisco-nsp
> Subject: Re: [c-nsp] Management stuff in VRFs
>
> Thank you all for the reponses.
>
> As many replies point out, and as many previous threads bear witness to,
> the current implementations of IOS lack full support for a seperate
> management VRF. This alone made me curious why people still push in that
> direction.
>
> Generally I assume that some kind of OoB management is best practice
> already; the typical setup where I'm from is a terminal server of some
> kind (e.g. Cisco 2512) in each PoP and some octopus cables reaching out
> to all the console ports. This is for emergencies though, not for
> "production", i.e. not for Netflow, TACACS+ and so on.
>
> A management network in a seperate VRF will not in itself give anyone
> emergency access to devices. I could imagine obscure software bugs that
> would actually hinder this access instead. And even though using
> seperate physical interfaces is much easier with an isolated VRF it is
> not a prerequisite, and without that some of the arguments for the VRF
> fall apart IMHO.
>
> Seperating non-business traffic (like Netflow, TACACS+, syslog) from
> business traffic is idealogically a good idea. If you extend this
> thought we would actually end up with a seperate set of interfaces for
> _everything_ which is not customer traffic, including IGP and BGP (and
> LDP for those so inclined). Or am I crossing a line here?
>
> And for the record: Yes, poor me, I have no real SP experience, having
> only worked with enterprise networks. We use exactly what Donn
> describes: A lean global table with all user traffic carried as MPLS.
>
> /Peter
>
> (... off to the purgatory for top posting, sorry. :-))
>
>
>
> On Thu, 2009-09-03 at 10:42 -0700, Lasher, Donn wrote:
>> -----Original Message-----
>> From: cisco-nsp-bounces at puck.nether.net
>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jerome Durand
>> Subject: Re: [c-nsp] Management stuff in VRFs
>>
>> >We went in that direction in our latest deployment and discovered also
>> >that many pieces were missing in IOS and IOS-XR to have full management
>>
>> >in a dedicated VRF for all our devices.
>>
>> >At this stage we have the VRF but not all management goes there... so
>> >there is more complexity and network is no more secure... I must admit
>> >IOS-XR gives us more troubles as more management features are missing
>> in
>> >VRF's.
>>
>> The most effective way to do this I've seen so far essentially turns
>> your network inside out. The "Global" portion of the router is
>> management, in RFC1918 space, and your "internet/public"
>> IP's/traffic/etc are all carried in a dedicated VRF.
>>
>> Taking a production network NOT designed that way, and doing the
>> inside-out... well.... that's every bit as hard as it sounds...
>
>
> _______________________________________________
> 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/
>
> _______________________________________________
> 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/