Which Interfaces?

AM NPM All,

As long as interface monitoring has been around, engineers have always debated which interfaces to monitor. I know from a network perspective, my "critical" interfaces have always been the uplinks. However, for the server teams, they are most interested in the server interfaces. And more so today with the new innovations with UDT and IPAM, the destop teams are looking at all the access ports. So, I'd like to open this debate/discussion up for everyone once again to get a current "trend" and opinion. What are you doing to help support all the requirements?

My interfaces:

Network - we monitor all uplinks for up/down and stats.

Servers - we monitor up/down on the switch port, as well as, up/down and stats on the server interface.

Access interfaces - currently we don't yet, we are still evaluating the need for UDT in our environment (which is what sparked this discussion).

Find more posts tagged with

monitor

udt

interfaces

ipam

npm

Accepted answers

All comments

RichardLetts

We monitor router interfaces and inter-switch links ( mostly trunk interfaces, but a couple of thousand switches are on non-VLAN subnets and those don't have trunks defined between all of the switches.). We do not monitor every trunk interface because some (like the ones in my office) are actually converged voice/data subnets.

We do not monitor server ports because, frankly we have several hundred racks of them, and at any time a system administrator might be working on their servers. We let the server managers monitor their server status.

/RjL

branfarm

It probably depends a lot on the size of environment you monitor. My environment is relatively small, so I monitor every utilized router and switch port, as well as server and access ports. Though if I were reaching my license limit, the access ports, then server ports, would be the first to go.

deverts

Bump...

Just trying to get more opinions on this. So far, Richard and branfarm confirmed that legecy opinions haven't waivered; which is good because it would just mean more work for me.

rschroeder

We monitor all active interfaces, but alert differently based on location and use.

One alert triggers if any of a large list of critical interfaces goes down. In it I defined Critical Interfaces as those which are uplinks/downlinks or resilient links within port-channels, plus a variety of special ports.

A different report of Data Center Interfaces alerts whenever a monitored port goes down, and monitored ports in this group are those which connect to servers. Alerts go to the Data Center Operations Team and the IS Networks teams.

SysAdmins have their own view that shows the info, but aren't in the alerting group because the DC Ops handle ports, patches, outages in their areas, etc.

michael.kent

All interfaces are monitored, this is looked after by the NOC, then dependent on the alert this is raised to the appropriate team. Networks/Servers/Devs etc.

chad71

Email alerts from edge switch access interfaces is a form of masochism.

rschroeder

I could buy into that in many circumstances.

Some useful access switch alerts could include:

Notification that one of two or more port-channeled interfaces between an access switch and its distribution switch is down. Traffic to the switch still flows, no one knows you've lost an uplink but NPM and you. But your resilience has been cut in half, along with your resilience. My environment is 25 hospitals and 75 clinics, and I want to know when half my resilience to a 10-slot access chassis switch, supporting 400+ medical users and perhaps 80 AP's is down to just one uplink.
Alerts on errors on access switch ports. If something's not getting along with auto negotiate (e.g.: the edge device was misconfigured to use 100 Mb FD while its switch port is at auto; the result is the switch going to 10 Mb Half Duplex, with collisions and retransmits and CRC errors and slow performance), then you can make life better for the user by proactively contacting them and helping get their device using auto negotiate, or by setting the switch port to match their manual speed & duplex settings.
Critical devices may be attached to an access switch ( e.g.: security cameras, intercoms, HVAC automation, health monitors, etc.). Monitoring those ports give you an opportunity to create alerts that can be sent to the appropriate groups who rely on those devices, and who support them. They love the additional view into the network, you can help them better achieve an SLA with their customers, everyone wins. And you're the rock star as a result of helping them by giving them access. You could even create a view in NPM just for them, so they can see when their special devices are up or down, how long they've been up or down, how much bandwidth they're using. They'll think you're a wizard.

But yes, I agree, monitoring access interfaces results in additional work load to my team. Still, it's the right thing to do for my environment.

chad71

I have actually been working on a plan similar to what you have mentioned. As long as I can stay away from those PC access port up/down alerts...it is worth the extra time! Thanks for the extra insight!!

d09h

Sounds like a use case for the 'unpluggable' interfaces.