Monitoring Alarm Status on Juniper EX Switches

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

http://www.oidview.com/mibs/2636/JUNIPER-ALARM-MIB.html

Object Name Object Identifier
jnxAlarms jnxAlarms 1.3.6.1.4.1.2636.3.4
jnxCraftAlarms jnxCraftAlarms 1.3.6.1.4.1.2636.3.4.2
jnxAlarmRelayMode jnxAlarmRelayMode 1.3.6.1.4.1.2636.3.4.2.1
jnxYellowAlarms jnxYellowAlarms 1.3.6.1.4.1.2636.3.4.2.2
jnxYellowAlarmState jnxYellowAlarmState 1.3.6.1.4.1.2636.3.4.2.2.1
jnxYellowAlarmCount jnxYellowAlarmCount 1.3.6.1.4.1.2636.3.4.2.2.2
jnxYellowAlarmLastChange jnxYellowAlarmLastChange 1.3.6.1.4.1.2636.3.4.2.2.3
jnxRedAlarms jnxRedAlarms 1.3.6.1.4.1.2636.3.4.2.3
jnxRedAlarmState jnxRedAlarmState 1.3.6.1.4.1.2636.3.4.2.3.1
jnxRedAlarmCount jnxRedAlarmCount 1.3.6.1.4.1.2636.3.4.2.3.2
jnxRedAlarmLastChange jnxRedAlarmLastChange 1.3.6.1.4.1.2636.3.4.2.3.3

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

edit
set chassis alarms management-interface link-down ignore
commit and-quit
request system configuration rescue save

Now when I refresh the checks in Opsview I get an OK state for both checks

Symantec Endpoint Protection Manager 12.1 configuration

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.

For more information from Symantec on the configuration of the truncate and index rebuild options please review the following KB article: http://www.symantec.com/business/support/index?page=content&id=TECH166658

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.

 

Backup Exec 2012 – One time Exchange Backup doesnt flush transaction logs

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.

Googling this came up with the following technote: http://www.symantec.com/business/support/index?page=content&id=TECH187838 and there is no way that you can change the option to do a full log flush in the one time backup.

I can’t fathom why this wouldn’t be a useful feature of the software to at least have the flush committed logs as a tickbox in the job options for the one-time backup.

Juniper EX view pending changes

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:

show | compare rollback 0

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.

 

Asymmetric routing with Cisco ASA firewalls

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

Representing the traffic flow

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 object Local_LAN object Remote_LAN_1
access-list firewall_bypass extended permit ip object Local_LAN object Remote_LAN_2
access-list firewall_bypass extended permit ip object Local_LAN object Remote_LAN_3

Now we create a class map to match the ACL

class-map class_firewall_bypass
match access-list firewall_bypass

Then apply this to a policy map

policy-map inside-policy
class class_firewall_bypass
set connection advanced-options tcp-state-bypass

Finally we assign that policy to the inside interface on the firewall

service-policy inside-policy interface inside

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