SNMP credentials -- setting and info

NTA will tell you if the problem is associated with bandwidth congestion, and it'll also show you the IP addresses (and possibly the names) of the devices using the Internet or LAN bandwidth.  If you don't have NTA, I seem to recall at least one Netflow functionality in the Engineer's Toolset that will do the same thing on a smaller scale, and all you really need is to have it pointed at the firewall or the router that's the last hop before the Internet.  You can also do some CLI-level Netflow or IPFIX data gathering, if you have no tools to do it for you.

A convenient practice is to have the same read-only (NOT read-write) snmp community string on all the network devices. 

Another one is to use an Access Control List (or firewall rule, if a firewall is between your NMS and the switches, AP's, routers, etc.) configured on every device that ONLY allows the NMS to talk to it with snmp.

A BEST practice (not just a "convenient" practice) is to never use snmp-v1 or v2.  Only use snmp-v3 to protect your devices from unauthorized folks snooping around and discovering what they ought not.

NPM's latest version has pretty cool mapping and network discovery built into it.  If you've got an NMS on the church's network, and if that NMS has permissions into all the devices, and if they're all using the same snmp-v3 community string, NPM can show you the nodes & connectivity.

However, having managed 60,000+ nodes in a single business's LAN, across 100+ WAN sites, I'm going out on a limb and guessing there really aren't that many devices on the church's network.  How many would you guess?  Half-a-dozen wired computers & printers, using a single switch or hub?  And an Access point or three?  Plus the firewall between the church and the Internet connection?  If that's all you have, it's easy enough to SSH into every node and issue a "show cdp neighbor" command to each one. (Or, if they aren't Cisco devices, you might have luck with commands to show lldp neighbors).  From there you can easily build a Visio diagram showing every network switch or router or AP and the physical and logical interfaces connecting them all. This assumes they're all Cisco and that CDP is enabled on them all, and also assuming you have R/W CLI access into the switches & routers, and possibly https access into the AP's.

One thing that's easy to miss is having AP's signal bleed out into public space or into other buildings and other businesses.  If the AP's aren't properly secured to only allow authorized devices to attach to them, then your Internet pipe may easily be swamped by people gaming, streaming Netflix or Disney+ or Pandora.  You may find it helpful to discover how many clients are attached to each one and see if the number makes sense.  Maybe you'll be able to advise the church council to reduce the signal strength on one or more AP's so they don't reach out 300' in every direction, getting the signal onto the highway or into neighboring homes or businesses or parking lots.

It may not be the friendly-neighbor thing to do, but restricting access to the WLAN to only authorized devices is the way to prevent unauthorized people from stealing the bandwidth.  Do the authorization preferably using something like ISE with appropriate policies (which is complex and expensive) or else manually configure each wireless client to use WPA-2 with AES--and keep the setup confidential so it doesn't get shared to the entire world.  

If you have a public SSID that allows anyone to attach to it, set up QoS policies to restrict that SSID to some fraction of the total Internet bandwidth available.  Keep in mind that someone may be using that bandwidth for their own private business services without permission.  In a worst case scenario you could discover someone's consuming all the upbound bandwidth for illegal activities. It's one reason why restricting access to authorized users is the right thing to do.

And also set that public SSID off into a DMZ that restricts accessing any internal resources.  That will help protect the churches computers and finance programs and mailing lists from being shared or modified or deleted.

In some cases, no matter how unpleasant the option might sound, shutting down public WiFi access can be the right thing to do.  Users should have data plans for their smartphones, and should be using them instead of consuming all the church's bandwidth, and overloading its Gateway.

And speaking of Gateways, it may be worth talking with the ISP and asking if the church's gateway is problematic, or is running old firmware.  Ask their recommendation for hardware revision and OS version.  Sometimes a crashing cable modem or DSL Gateway has to be replaced to prevent it from hanging and needing frequent reboots.

Let us know what you discover, what tools you used, and whether you were able to "fix" the church network--and how you did it!

Swift packets!

Rick Schroeder

NTA will tell you if the problem is associated with bandwidth congestion, and it'll also show you the IP addresses (and possibly the names) of the devices using the Internet or LAN bandwidth.  If you don't have NTA, I seem to recall at least one Netflow functionality in the Engineer's Toolset that will do the same thing on a smaller scale, and all you really need is to have it pointed at the firewall or the router that's the last hop before the Internet.  You can also do some CLI-level Netflow or IPFIX data gathering, if you have no tools to do it for you.

A convenient practice is to have the same read-only (NOT read-write) snmp community string on all the network devices. 

Another one is to use an Access Control List (or firewall rule, if a firewall is between your NMS and the switches, AP's, routers, etc.) configured on every device that ONLY allows the NMS to talk to it with snmp.

A BEST practice (not just a "convenient" practice) is to never use snmp-v1 or v2.  Only use snmp-v3 to protect your devices from unauthorized folks snooping around and discovering what they ought not.

NPM's latest version has pretty cool mapping and network discovery built into it.  If you've got an NMS on the church's network, and if that NMS has permissions into all the devices, and if they're all using the same snmp-v3 community string, NPM can show you the nodes & connectivity.

However, having managed 60,000+ nodes in a single business's LAN, across 100+ WAN sites, I'm going out on a limb and guessing there really aren't that many devices on the church's network.  How many would you guess?  Half-a-dozen wired computers & printers, using a single switch or hub?  And an Access point or three?  Plus the firewall between the church and the Internet connection?  If that's all you have, it's easy enough to SSH into every node and issue a "show cdp neighbor" command to each one. (Or, if they aren't Cisco devices, you might have luck with commands to show lldp neighbors).  From there you can easily build a Visio diagram showing every network switch or router or AP and the physical and logical interfaces connecting them all. This assumes they're all Cisco and that CDP is enabled on them all, and also assuming you have R/W CLI access into the switches & routers, and possibly https access into the AP's.

One thing that's easy to miss is having AP's signal bleed out into public space or into other buildings and other businesses.  If the AP's aren't properly secured to only allow authorized devices to attach to them, then your Internet pipe may easily be swamped by people gaming, streaming Netflix or Disney+ or Pandora.  You may find it helpful to discover how many clients are attached to each one and see if the number makes sense.  Maybe you'll be able to advise the church council to reduce the signal strength on one or more AP's so they don't reach out 300' in every direction, getting the signal onto the highway or into neighboring homes or businesses or parking lots.

It may not be the friendly-neighbor thing to do, but restricting access to the WLAN to only authorized devices is the way to prevent unauthorized people from stealing the bandwidth.  Do the authorization preferably using something like ISE with appropriate policies (which is complex and expensive) or else manually configure each wireless client to use WPA-2 with AES--and keep the setup confidential so it doesn't get shared to the entire world.  

If you have a public SSID that allows anyone to attach to it, set up QoS policies to restrict that SSID to some fraction of the total Internet bandwidth available.  Keep in mind that someone may be using that bandwidth for their own private business services without permission.  In a worst case scenario you could discover someone's consuming all the upbound bandwidth for illegal activities. It's one reason why restricting access to authorized users is the right thing to do.

And also set that public SSID off into a DMZ that restricts accessing any internal resources.  That will help protect the churches computers and finance programs and mailing lists from being shared or modified or deleted.

In some cases, no matter how unpleasant the option might sound, shutting down public WiFi access can be the right thing to do.  Users should have data plans for their smartphones, and should be using them instead of consuming all the church's bandwidth, and overloading its Gateway.

And speaking of Gateways, it may be worth talking with the ISP and asking if the church's gateway is problematic, or is running old firmware.  Ask their recommendation for hardware revision and OS version.  Sometimes a crashing cable modem or DSL Gateway has to be replaced to prevent it from hanging and needing frequent reboots.

Let us know what you discover, what tools you used, and whether you were able to "fix" the church network--and how you did it!

Swift packets!

Rick Schroeder