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