adminuser@switch01> edit
Entering configuration mode
Users currently editing the configuration:
adminuser terminal p0 (pid 28439) on since 2013-02-28 14:27:28 GMT, idle 01:41:42
[edit]

The easiest thing to do is to log out the other session once you have reconnected to the device by using the PID of the stale session (in this case 28439) with the following command:

request system logout pid 28439

You should now no longer see that message when you log back into the switch.

Alongside the implementation of a standardised user interface the post also explains how Citrix can automatically create some GPO templates to lock down the server farm so the users are not able to perform tasks they shouldn’t be able to do. These policies will need to be tweaked to match the requirements of your particular environmetn but provides a strong starting point for configuring and standardising your Citrix farm.

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	1.3.6.1.4.1.2636.3.4
jnxCraftAlarms	1.3.6.1.4.1.2636.3.4.2
jnxAlarmRelayMode	1.3.6.1.4.1.2636.3.4.2.1
jnxYellowAlarms	1.3.6.1.4.1.2636.3.4.2.2
jnxYellowAlarmState	1.3.6.1.4.1.2636.3.4.2.2.1
jnxYellowAlarmCount	1.3.6.1.4.1.2636.3.4.2.2.2
jnxYellowAlarmLastChange	1.3.6.1.4.1.2636.3.4.2.2.3
jnxRedAlarms	1.3.6.1.4.1.2636.3.4.2.3
jnxRedAlarmState	1.3.6.1.4.1.2636.3.4.2.3.1
jnxRedAlarmCount	1.3.6.1.4.1.2636.3.4.2.3.2
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

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.

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.

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.

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 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

First thing you need to do is download the traceroute package if its not already installed

sudo apt-get install traceroute

Once installed you will find that the plugin will fail and show the following error:

The specified type of tracerouting is allowed for superuser only
Can't use an undefined value as an ARRAY reference at ./check_route line 129.

Googling the first line I found that you have to setuid root for the traceroute binary

chmod u+s /usr/sbin/traceroute

Trying the plugin again you get the following error

Use of uninitialized value $time_units in string eq at ./check_route line 114.
ROUTE UNKNOWN - Cannot cope with line 'traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets'

To get around this you need the plugin to ignore the first line of the output from the traceroute which can be done with the following patch

http://snipt.net/mattywhi/opsview-check_route-diff/

Now the script runs as expected and you get the following output

ROUTE OK - Time taken is 145.895 ms | total_time=145.895ms;5000;100000 hops=14;; route_change=0;;

The first thing we need to do is move the interfaces that will contain the Internet connections so each is in their own virtual router. This will allow us to have an active default route for each connection and they can behave independently of each other.

set interface ethernet0/0 zone null
set interface ethernet0/1 zone null
set zone untrust vrouter untrust-vr
set vrouter name adsl-vr
set zone name BackupUntrust
set zone BackupUntrust vrouter adsl-vr

For this example I am using the 192.0.2.0/24 address range for my WAN connections – this was defined by the IETF as a subnet to be used for testing and documentation in RFC 5735. As these interfaces are both public facing I am also going to restrict the management to secure protocols only

set interface ethernet0/0 ip 192.0.2.2/29
set interface ethernet0/0 route
set interface ethernet0/0 manage-ip 192.0.2.3
et interface ethernet0/0 manage ping
set interface ethernet0/0 manage ssh
set interface ethernet0/0 manage ssl
set interface ethernet0/1 ip 192.0.2.10/29
set interface ethernet0/1 route
set interface ethernet0/1 manage-ip 192.0.2.11
set interface ethernet0/1 manage ping
set interface ethernet0/1 manage ssh
set interface ethernet0/1 manage ssl

Now we need to setup the default routes out of each virtual router so that each connection can communicate with the rest of the Internet

set vrouter untrust-vr
set route 0.0.0.0/0 interface ethernet0/0 gateway 192.0.2.1
exit
set vrouter adsl-vr
set route 0.0.0.0/0 interface ethernet0/1 gateway 192.0.2.9
exit

We need to ensure that our internal users are able to route to both the untrust-vr and adsl-vr. This can be done by exporting the default static route from the untrust-vr and adsl-vr

set vrouter "untrust-vr"
set access-list 1
set access-list 1 permit ip 0.0.0.0/0 1
set route-map name "untrust-vr_export" permit 1
set match ip 1
set preserve preference
exit
set export-to vrouter "trust-vr" route-map "untrust-vr_export" protocol static
set vrouter "adsl-vr"
set access-list 1
set access-list 1 permit ip 0.0.0.0/0 1
set route-map name "adsl-vr_export" permit 1
set match ip 1
exit
set export-to vrouter "trust-vr" route-map "adsl-vr_export" protocol static

This will import both default routes to the trust-vr and set maintain the preference of the export from the untrust-vr at 20 whilst setting the metric of the adsl-vr export to 140.

Now that our users can connect to the Internet we need to make sure that should there be an issue with the primary internet circuit the backup circuit can be used for Internet access. This is achieved by using track-ip to monitor a number of hosts on the Internet and should they become unreachable shut the interface down.

In this example we are using the IP address of some of the root DNS servers as the addresses the firewall will use to check for a valid Internet connection but they could be any IP addresses that you expect to remain online and will respond to PING requests

set interface ethernet0/0 monitor track-ip ip
set interface ethernet0/0 monitor track-ip threshold 75
set interface ethernet0/0 monitor track-ip weight 75
set interface ethernet0/0 monitor track-ip ip 192.58.128.30 threshold 25
set interface ethernet0/0 monitor track-ip ip 192.58.128.30 weight 25
set interface ethernet0/0 monitor track-ip ip 192.36.148.17 threshold 25
set interface ethernet0/0 monitor track-ip ip 192.36.148.17 weight 25
set interface ethernet0/0 monitor track-ip ip 193.0.14.129 threshold 25
set interface ethernet0/0 monitor track-ip ip 193.0.14.129 weight 25

This will PING the three addresses every second and will consider the address to have failed when the test has failed 25 times consecutively. Summing these three failures together will hit the weight and threshold limits of 75 needed to shut down the interface.

If you want to test the status of the track-ip monitoring you can issue the following commands

get interface ethernet0/0 monitor
get interface ethernet0/0 monitor track-ip

and you will be able to see the failure statistics as well as whether the interface is failed or not.

When the interface is shut down the default route no longer becomes valid in the untrust-vr and will be deleted in the trust-vr leaving the export from the adsl-vr active and Internet traffic will continue to function as normal. In the background, the management address on the primary connection will continue to poll the IP addresses configured and when they become available the weight and threshold will be below the failure values, the interface comes back up and the untrust-vr route export re-appaers in the trust-vr.

The only other thing to consider here is inbound services on the backup line such as MX records to permit mail delivery to a MIP or VIP on the secondary circuit

If this is all configured correctly the only things the user should notice is that any websites/services that login and use session data (eg online banking) will need to login after fail-over or fail-back as their existing session will no longer be valid.

The link to the article can be found here – http://h30507.www3.hp.com/t5/Technical-Support-Services-Blog/6-Simple-Steps-to-Monitoring-ESXi-with-Insight-Remote-Support/ba-p/100789

RANCID is running on an Ubuntu 10.04 server and is running version 2.3.3. and has the jlogin scripts in place. After adding the device information to the .cloginrc file I tested jlogin to check that it could connect as root to the device – it did. When I performed rancid_run however the device did not backup as expected and Rancid hung until it timed out. Upon closer inspection the issue came down to the fact that the root account will ssh to the BSD shell on the switch and not directly to the JunOS command line. To get around this I needed to setup a new user on the switches with the correct permissions and then get this to perform the backup of the switches. The command to add the config is as follows:

set system login user adminusername class super-user authentication plain-text-password

You will be prompted to choose a password and then confirm it before writing it to configuration

commit and-quit

Now you can specify the details in RANCID:

add user ip_address {username}
add password ip_address {password}
add method ip_address {ssh}

The last thing that I did was to take a copy of jlogin and jrancid from an installation of RANCID 2.3.6 and everything seems to be working as expected.

What I had in my .cloginrc file was:

add user ip_address {username}
add password ip_address {password}
add method ip_address {ssh}
add noenable ip_address 1

when I ran bin/clogin ip_address the device would login and get me to the enable prompt as expected but when run as part of rancid_run nothing was coming back for the config. After a bit of reading and searching the solution was simple enough and it wasnt a problem with RANCID or the Aironets….

add autoenable ip_address 1

should have been used instead of the noenable line.

I also managed to get RANCID to backup the config on my Juniper EX switches but that is a story for another post

The latest release allows you to monitor the size of a single volume as well as a single check to monitor all volumes. I setup the check in Opsview as normal and then proceeded to configure the Host Attributes for the SAN host for each volume on the SAN (there were 75 volumes to monitor). Having added all the checks and reloading Opsview I started to see a large number of OK checks for the volumes but also a number of UNKNOWN outputs from the plugin. Closer inspection showed that when you have two volumes that have the similar names (e.g. BES01-D and DR-BES01-D) the more generic name, BES01-D in this example will match for both volumes and the script will return an unknown value. The DR-BES01-D volume returned the correct stats as the volume name only matched one entry.

Looking through the code in the plugin the line that is causing the issue is:

volarray=$(snmpwalk -v 2c -c ${community} ${host} 1.3.6.1.4.1.12740.5.1.7.1.1.4 | grep -n ${volume} | cut -d : -f1)

When it grep’s the list of volumes from the SNMP walk it returns two values and the script cannot cope so exits. After some playing around (and remembering the basics of writing bash scripts) I managed to work around the problem and changed the line to the following:

volarray=$(eval snmpwalk -v 2c -c ${community} ${host} 1.3.6.1.4.1.12740.5.1.7.1.1.4 | grep -n "\"${volume}\"" | cut -d : -f1)

The change adds the quotation marks that are surrounding the string value that is returned from the SNMPwalk so GREP should only return the exact matches. Having updated the script and re-run the checks the UNKNOWN status was gone and the checks all returned the correct data.

It turns out that since RSA was installed the Security Console Super Admin account had its password changed and in the updated documentation we lost the details of the password for the Operations Console as the two passwords are not linked. In order for us to get back into the Operations Console we had to run through the following:

1. Create a new Super Admin from the Security Console in the Internal Database
2. Run the RSA command line utility (C:\Program Files\RSA Security\RSA Authentication Manager\utils\RSAutil) to create a new Operations Console user account

Unfortunately it wasnt that easy to complete!

Initially when we ran RSAutil as one of the admin accounts we received an error stating that only one account could run it, the account that originally installed RSA! Luckily the account was still listed and we just needed to enable this and perform a swift “runas” to bring up a command prompt as that user.

Next we sent a good bit of time running through various commands to work out how we create a new Operations Console admin account. The final command that we needed to run was as follows:

rsautil manage-oc-administrators -a create -u UserCreatedEarlier -p PasswordForUserCreatedEarlier -g OperationsConsole-Administrators NewOperationsConsoleUsername NewOperationsConsolePassword

We were now able to login to the Operations Console using the account we created. Now to find another maintenance window to patch the RSA server

I’ve passed

Following a long break from completing my MCSA: Messaging in Server 2003 I have finally got round to updating this for the modern era and upgraded this first to MCTS in Windows Server 2008 and finally this afternoon completed my 70-647 exam to attain the qualification of Microsoft Certified IT Professional: Enterprise Administrator.

For those of you with an MCSA in Windows Server 2003 the upgrade is done with the following exams:

• 70-648 – TS: Upgrading from Windows Server 2003 MCSA to, Windows Server 2008, Technology Specializations. This is equivalent to completing the following two exams 70-640 and 70-642
• 70-680 – TS: Windows 7, Configuring. This is the client exam required as part of the qualification
• 70-643 – TS: Windows Server 2008 Applications Infrastructure, Configuring
• 70-647 – Pro: Windows Server 2008, Enterprise Administrator

Once Microsoft confirm it on the MCP site I will update the qualifications links on the left with the new logo.