I am in the process of installing a number of Juniper EX2200, EX3200 and EX4200 switches for a client and as part of the setup need to be able to monitor the switches for any alarms (eg Switch Management interface down or Switch booted from Backup Partition) and have them dealt with accordingly.
Having a look at the SNMP OID tree for the EX switches I came across the following useful table
I have used the jnxRedAlarmCount and jnxYellowAlarmCount oid values as basic Opsview SNMP Service Checks to give me an initial overview but in the long term will be looking to combine this into a full service check script that can be used to check a number of different things.
The setup of the Service Check in Opsview is fairly simple and below are screenshots of the config that I have for each service check.
All you need to configure on your hosts is the SNMP community string and you can apply these checks individually or via a Host Template.
Once I performed a reload I could see the following in Opsview for one of my switches:
A bit of inspection showed that the Red Alarm was for the Management Interface being down (but wasnt being used on this switch) and the Yellow alarm was due to not setting a rescue configuration. I cleared the alarms by isuing the following commands
set chassis alarms management-interfacelink-down ignore
request system configuration rescue save
Now when I refresh the checks in Opsview I get an OK state for both checks
Just stated to deploy my first SEP 12.1 implementation for a new client and came across a bug whereby the disk space on the system drive where SEPM had been installed was decreasing rapidly. Investigation showed that the Endpoint Protection Manager is not configured by default to backup or truncate the log files for its database.
One other thing that was pointed out by a colleague was that Backup Exec is unable to backup the Database files and you will need to configure SEPM to backup and export the data if you would like to recover the current SEPM configuration in the event of having to restore the server from backup.
To fix this is straightforward but led me to ask the question why Symantec wouldn’t think this needs to be enabled by default for the product.
I have spent the last few days trying to understand why a successful one time backup hadn’t flushed the transaction logs on my client’s Exchange 2010 server. We spent a lot of time troubleshooting message queues and looking for a transaction that hadn’t completed as the Backup job had reported successful. Digging a bit deeper into some of the job logs I can see that the one-time backup was doing a COPY – Full database and logs and not a FULL – database and flush committed logs.
When making changes to Juniper EX switches yesterday I wanted to check the changes that I had made to my configuration before committing them. A quick look in the reference manual gave me the following command:
This will show the edited candidate config and pipe that into the compare function and look at the changes to the specified version (rollback 0). I could look at the changes compared to a previous config by replacing 0 with another number in the rollback sequence.
Today I sat and passed my JNCIA-FWV to re-certify myself in the eyes of Juniper for another two years. I was in and out in 30 minutes and achieved a 93% pass mark. Work have also booked my CCNA exam for the end of May so hopefully I will soon have that to add to my list of accreditations.
Last month I installed a new Cisco ASA 5510 for a client and came across an issue where traffic was hitting the “inside” interface of the firewall before travelling back out the same interface and into another router on the internal LAN – an issue as reported in this article Cisco ASA Deny TCP (no connection)
The diagram below demonstrates the network setup with PC1 trying to communicate with PC2. When the traffic leaves the MPLS router (RED line) it does not traverse the ASA and the next packet will follow the original route (GREEN then ORANGE lines) to get to PC2
Long term the resolution is to place the extra routers into their own DMZ networks on the perimeter network but as this didn’t exist at the time I needed to disable the TCP SYN checking for the traffic being routed to the MPLS routers – a process described in this article by Cisco – Configuring TCP State Bypass
First thing we do is create an ACL for all the items we want to bypass the SYN check
access-list firewall_bypass extended permit ip objectLocal_LAN objectRemote_LAN_1
access-list firewall_bypass extended permit ip objectLocal_LAN objectRemote_LAN_2
access-list firewall_bypass extended permit ip objectLocal_LAN objectRemote_LAN_3
Now we create a class map to match the ACL
match access-list firewall_bypass
Then apply this to a policy map
set connection advanced-options tcp-state-bypass
Finally we assign that policy to the inside interface on the firewall
service-policy inside-policy interfaceinside
Traffic that hits the inside interface of the firewall that matches the rules on the ACL will not be checked for their tcp state and traffic should now flow.
In the long term it is recommended that this isnt the adopted approach and the firewall is configured to have the traffic traverse through from the inside to a DMZ interface to prevent the issues with the TCP SYN issue