[142997] in North American Network Operators' Group
Re: OOB
daemon@ATHENA.MIT.EDU (Cameron Byrne)
Tue Jul 26 10:25:46 2011
In-Reply-To: <CAB_zYd+Dswo=+YXSDz9qW4EKXX0LZE8i66rYDjFH+hXmhDpH5g@mail.gmail.com>
Date: Tue, 26 Jul 2011 07:25:14 -0700
From: Cameron Byrne <cb.list6@gmail.com>
To: harbor235 <harbor235@gmail.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jul 26, 2011 6:57 AM, "harbor235" <harbor235@gmail.com> wrote:
>
> I am curious what is the best practice for OOB for a core
> infrastructure environment. Obviously, there is
> an OOB kit for customer managed devices via POTS, Ethernet, etc ... And
> there is OOB for core infrastructure
> typically a separate basic network that utilizes diverse carrier and
diverse
> path when available.
>
> My question is, is it best practice to extend an inband VPN throughout for
> device management functions as well?
> And are all management services performed OOB, e.g network management,
some
> monitoring, logging,
> authentication, flowdata, etc ..... If a management VPN is used is it also
> extended to managed customer devices?
>
> What else is can be done for remote management and troubleshooting
> capabilities?
>
IMHO, it is always a good idea to have completely different infrastructure
supporting Oob. It is the only way you can recover remotely from many types
of network errors. If the router is hung at rommon, somebody has to get on
console .... or accidentally removes your igp instanance ...
But, the business criticality of the network needs to justify the cost
(dial, DSL, 3rd party L3 vpn ....)
Cb
> Mike
