Out-Of-Band Access - Network Devices

[jimmy20.bpl]

Hi All, 

Seeking help for  "Out-Of-Band Access" Solution for Network Devices, which is very well inline with current day requirement.

If anyone having good information and document (sort of solution document) , please advise. 

Rgds

[Mark Malone]

I built oob for our network I cant provide our solutions for obvious security reasons but I can assist in how to set it up to get you started

Are you planning to go full OOB with parallel network running through actual MGMT ports on devices ?

Do you have switches that will solely at as MGMT switches ? And are you going to push MGMT traffic through the firewalls ?

https://ltlnetworker.wordpress.com/2015/08/16/management-network-topology-and-asymmetric-routing/

[jimmy20.bpl]

Hi Mark, 

Thanks a ton !

I can understand the security reasons. 

1) Well, We don't have management ports availability on all devices.

2) Yes, we do have 2 or 3 management switches in our DC network.

3) Understand , we don't want firewall involvement for pushing management traffic for OOB. as this OOB would be accessed from our Network Operation Center only hence there should be not any security concern. 

Will do through the shared link, Waiting for more inputs.

Rgds

[Mark Malone]

Ok without firewall your setup might be slightly different but here's a quick breakdown of what I did and you can probably work off that to get started or tweak it differently for your needs, a true oob network should all be on MGMT ports but that's not always possible budget restrictions , distance (are you going to run parallel cabling everywhere may not be possible) etc so you can have a combination but really only the MGMT ports are fully protected

Ports without a mgmt. interface use a vlan interface say as example vlan 333 same vlan/subnet to be consistent across all devices we used a /23 it depends on how many devices you have and future proof it as well for expansion so leave plenty spare ips  , then have a layer 2 port associated with the vlan 333 and have that directly connect back to one of your mgmt. switch which will also have a vlan interface 333, now that should provide connectivity between both but obviously on devices without MGMT port its not true oob as its still the same plane on the device , the best you can do here is use a vrf under the interface to segregate traffic, this will work fine on dist switches that support l3 and have no MGMT interfaces but pure layer 2 switches some 2960s wont have the ability for vrf at all

If you have a MGMT. interface that's the best option you would give that an address out of the vlan 333 range and then that would have connectivity back to the MGMT. switch , thi sis true oob

We also built an extended acl and applied it to all the vlan interfaces where there was no MGMT. interface available and locked it down in and out as much as possible for MGMT traffic and then sourced everything from that vlan in and out with the protocols , ntp,ssh,netflow etc

we directed all traffic to the firewalls to be processed so you will have to do something different there , it was not just about who accessed it it was about the protocols to be pushed through a secure environment but we have remote sites as well and were splitting DC traffic with standard user prod traffic so you may not require that setup exactly

For managing routers that had to oob port we used a sub interface basically same as using a vlan interface and applied the oob acls to that as well

interface GigabitEthernet0/0/0.333
 description NETMGMT in xxxxxx
 encapsulation dot1Q 333
 ip address x.x.x.x x.x.x.x
 ip access-group 158 in
 ip access-group 159 out

some examples L3 that supports VRF  , when using vrf make sure everything else knows to use it as well

ip vrf Mgmt-vrf
ip route vrf Mgmt-vrf 0.0.0.0 0.0.0.0 x.x.x.x
ip ssh source-interface f0
logging host x.x.x.x vrf Mgmt-vrf
ip flow-export source f0
ntp source f0
ntp server vrf Mgmt-vrf x.x.x.x
ntp server vrf Mgmt-vrf x.x.x.x
ntp server vrf Mgmt-vrf x,x,x,x
ip flow-export destination x.x.x.x 9995 vrf Mgmt-vrf
ip flow-export destination x.x.x.x 2055 vrf Mgmt-vrf

aaa group server tacacs+ xtacacs
 server-private x.x.x.x key xxxxxxxxxxxxxxxx
 server-private x.x.x.x key xxxxxxxxxxxxxxxx
 ip vrf forwarding Mgmt-vrf
 ip tacacs source-interface f0

line vty 0 4
 access-class 166 in vrf-also

vrf context Mgmt-vrf
  ip route 0.0.0.0/0 x.x.x.x (firewall)

interface mgmt0
  description <OOB.TRUSTED.USER>
  vrf member Mgmt-vrf

ip address x.x.x.x

********************************************************************

Layer 2 with no MGMT port and just vlan no vrf

ip ssh source-interface vlan333
ip tacacs source-interface vlan333
logging source-interface vlan333
ntp source vlan333
ip default-gateway x,x.x.x we senr everything to FW by default

************************************************************************************************

Part of the HLD attached , LLD had too much ip information etc in it to post

[jimmy20.bpl]

Really Thanks Mark, 

This all is prefect, what medium you are suggesting for accessing DC devices Remotely ai.e Through Modem (PSTN) ...or through some other way  ? 

[Mark Malone]

so as we used like yourself  a combination of actual MGMT ports & vlans/vrfs we also put in place ethernet serial console devices(opengear and blackbox are the best ones 8poort right up t48)  as last resort access especially for DC devices and ran a cable back from each console port to the serial console device

this gives us at least another method of access if the switch had no mgmt. port and went into a spin effecting MGMT vlan and it still effected MGMT traffic too , least that way we had console too

remote sites we stuck a gsm sim card into these opengear devices they support that too for remote dial over 4g in but locally there very easy to setup and access , we felt that was a must for devices in DC and devices that are not true oob from MGMT port , but its a personal choice on how critical things really are on your network

[Collin Clark]

One thing to note...you'll more than likely have to secure the OOB device as well. We used Avocent which is a good product. However we, the network team, we're responsible for securing the Avocent OS (linux) to our security requirements. I know Linux, but no one else on the team did so it quickly became my project. I now usually suggest using a Cisco router with either an async card or 4g card or whatever the secondary and tertiary transport will be. I find it easier to secure another router than a linux box. You can even setup menu's for the helpdesk or junior guys.