FRR with BFD for route failover via different paths on HP 5820 (Comware5)

HP 5820 (running Comware5 OS) does support fast reroute (FRR) & bidirectional forwarding detection (BFD) feature like Cisco, Juniper and others. Recently I have implemented FRR & BFD with static routes to get route protection/detour to a destination network via different paths on HP5820.

Before come across FRR & BFD – I was looking for a solution that could do tracking of next-hop address in-case of primary link failure and detour the same route through an alternative path using static routes. As the network got multi-vendor devices – a good IGP protocols might not work properly over IPsec VPN tunnel (few latest products does support this although); that’s why I was looking to get this done through static routes. A lot of documents mentioned FRR as a feature of MPLS – this works fine on non-MPLS environment as well.

The next-hope address tracking was done by using BFD (bidirectional forwarding detection) – this is a super fast compared to IGP hello intervals. Default BFD check interval is 50ms. However, BFD is not suitable for slow speed & higher latency network.

Here is the network topology –

FRR-Topology

In this topology –

a. Primary connectivity between Site-A and Site-B is dark optical fiber link – which provides full wire speed.

b. In case optical fiber fail – the Site-A and Site-B connectivity must go through site to site IPsec VPN over the Internet.

The configurations are following –

a. Site-to-site IPsec VPN been established (omitted)

b. IP address configurations have been done on vlan interfaces on both Site-A & Site-B switches (omitted).

c. Configurations on Site-A HP5820-SW01-

#configure BFD (bidirectional forwarding detection) source to track next-hop IP address
bfd echo-source-ip 172.16.10.1

##define the primary route to Site-B via optical fiber – static route
ip route-static 2.2.2.0 255.255.255.0 Vlan-interface10 172.16.10.2

##define Site-B network prefix to be used in the route policy
ip ip-prefix site-b-prefix 10 permit 2.2.2.0 24

##define route-policy to route to Site-B via IPsec VPN as backup route
route-policy site-a-frr permit node 10
   if-match ip-prefix site-b-prefix
   apply fast-reroute backup-interface Vlan-interface20 backup-nexthop 172.16.20.2

##configure the backup next hop static route
ip route-static fast-reroute route-policy site-a-frr

d. Configurations on Site-B HP5820-SW02-

#enable BFD (bidirectional forwarding detection) source to track next-hop IP address
 bfd echo-source-ip 172.16.10.2

##define the primary route to Site-A via optical fiber
ip route-static 1.1.1.0 255.255.255.0 Vlan-interface10 172.16.10.1

##define Site-B network prefix to be used in route policy
ip ip-prefix site-a-prefix 10 permit 1.1.1.0 24

##define route-policy to route to Site-B via IPsec VPN as backup route
route-policy site-b-frr permit node 10
   if-match ip-prefix site-a-prefix
   apply fast-reroute backup-interface Vlan-interface30 backup-nexthop 172.16.30.2

##configure the backup next hop static route
ip route-static fast-reroute route-policy site-b-frr

That’s all for the configurations!

Let’s verify the configuration –
#display bfd session      ;this will display tracking of next-hop

If the state is DOWN – “backup next-hop” will become the active route

BFD-Sessions

#display ip routing-table 2.2.2.0 verbose                             ;on HP5820-SW01

#display ip routing-table 1.1.1.0 verbose                             ;on HP5820-SW02

FRR-RoutingTable

This will display both NextHop and BackupNextHop for the same destination.

Enable SSH on HP ProCurve 6600 series switch

HP ProCurve 6600 runs “ProVision” network operating system. ProVision command syntaxes are pretty much similar to Cisco IOS commands.

Following are commands to enable SSH on a ProCurve 6600 series –

First create local user account on the switch; command is –

#password manager user-name admin; this will prompt to enter password

Generate crypto keys for SSH server; command is –

#crypto key generate ssh

Enable SSH service; command is –

#ip ssh

To check SSH service status, enter the following command –

#show ip ssh

hp-6600-ssh

To restrict access to SSH (or local services on the switch), configure authorised manager IP address; command is –

#ip authorized-managers IP_Address

That’s all.

Inter-VRFs routing on the same router (VRF-lite route leak) with MP-BGP – HP 5820 (Comware5)

I was trying to implement inter-VRFs routing in a multi VRF-lite environment – there was a requirement to implement routing between two VRFs on the same router. This time the routers are HP 5820 series Layer-3 switches running Comware5 network Operating System (HP 5820 is a 24 port 10GB SFT+ Layer3 device). I have done the same on Cisco IOS (check my previous post on this).

I couldn’t find any specific recommendation on HP documentation regarding inter-VRFs routing on the “same device”. Also HP docs say when you configure BGP you need to specify BGP neighbor (I was thinking the same – without a neighbor BGP is incomplete!).

However, Cisco already published a recommendation on this – so I took Cisco’s recommendation and configured BGP without neighbor on Comware5 and found its working fine! Cisco recommendation specify two items (i) vrf route-target import (ii)BGP redistribution but no neighbor required.

“You can not configure two static routes to advertise each prefix between the VRFs, because this method is not supported—packets will not be routed by the router. To achieve route leaking between VRFs, you must use the import functionality of route-target and enable Border Gateway Protocol (BGP) on the router. No BGP neighbor is required. http://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/multiprotocol-label-switching-vpns-mpls-vpns/47807-routeleaking.html

Here is the topology –

inter-vrfs-BGP

Routing/connectivity requirements are –

Within same router inter-VRF routing:

Source Network Destination Network Site Number
A-1-network-web A-1-network-app Site 1
A-2-network-web A-2-network-app Site 2

Inter-site VRFs routing:

1. Single source to > multiple destinations

Source Network Destination Network
A-1-network-web A-2-network-web
A-1-network-web A-2-network-app
A-1-network-app A-2-network-app
A-1-network-app A-2-networl-web

2. Single source to > single destination

Source Network Destination Network
A-1-network-iscsi A-2-network-scsi
B-1-network-appserver B-2-network-app

Based on above mentioned scenario –

  1. VRFs routing between Site 1 and Site 2 – static route or any dynamic routing protocol such as EIGRP, OSPF are suitable.
  2. VRFs routing within the same router at each site (routing for web & app on the same site) need to be done through multiprotocol BGP and route-target import – which is a recommendation by Cisco.

In this example –

Site-1 (source) networks are-

-Customer A webserver network is – 192.168.101.0/24 (VLAN101); default route is 192.168.101.254

-Customer A appserver network is – 192.168.102.0/24 (VLAN102); default route is 192.168.102.254

-Customer A iscsi network is – 192.168.103.0/24 (VLAN103)

-Customer B appserver network is – 192.168.104/24 (VLAN104)

Site-2 (destination) networks are-

-Customer A webserver network is – 192.168.201.0/24 (VLAN201); default route is 192.168.201.254

-Customer A appserver network is – 192.168.202.0/24 (VLAN202); default route is 192.168.202.254

-Customer A iscsi network is – 192.168.203.0/24 (VLAN203)

-Customer B appserver network is – 192.168.204/24 (VLAN204)

Interconnect network between Site-1 & Site-2 are (both sites are connected through dark fibre which is Layer 2 connectivity)-

-“A-1-Web” to “A-2-Web” interconnect is 172.16.101.0/24 (VLAN 171)

-“A-1-App” to “A-2-App” interconnect is 172.16.102.0/24 (VLAN 172)

-“A-1-iSCSI” to “A-2-iSCSI” interconnect is 172.168.103.0/24 (VLAN 173)

-“B-1-App” to “B-2-App” interconnect is 172.168.104.0/24 (VLAN 174)

I will show here two things –

  1. Inter-VRFs routing on the same site through BGP and vpn-target export-import.
  2. SITE-1 and SITE-2 inter- VRFs routing through static routing (dynamic can be done as well).

Following are configuration commands on SITE-1-Router-01,

01. Define VRFs and route-target export & import as following:

#
ip vpn-instance a-1-webserver
 route-distinguisher 65111:101
 vpn-target 65111:101 export-extcommunity
 vpn-target 65111:101 65111:102 import-extcommunity ;import “a-1-network-appserver”
#
ip vpn-instance a-1-appserver
 route-distinguisher 65111:102
 vpn-target 65111:102 export-extcommunity
 vpn-target 65111:101 65111:102 import-extcommunity ;import “a-1-network-webserver”
#
ip vpn-instance a-1-iscsi
 route-distinguisher 65111:103 ;no import-export required
#
ip vpn-instance b-1-appserver
 route-distinguisher 65111:104 ;no import-export required
#

2. Apply VRFs to interfaces and also configure interface IP address

#
interface Vlan-interface101
 description A-1-Web Servers
 ip binding vpn-instance a-1-webserver
 ip address 192.168.101.254 255.255.255.0
#
interface Vlan-interface102
 description A-1-App Servers
 ip binding vpn-instance a-1-appserver
 ip address 192.168.102.254 255.255.255.0
#
interface Vlan-interface103
 description A-1-iSCSI
 ip binding vpn-instance a-1-iscsi
 ip address 192.168.103.254 255.255.255.0
#
interface Vlan-interface701
 description A-1-web to A-2-web interconnect
 ip binding vpn-instance a-1-webserver
 ip address 172.16.101.254 255.255.255.0
#
interface Vlan-interface702
 description A-1-app to A-2-app interconnect
 ip binding vpn-instance a-1-appserver
 ip address 172.16.102.254 255.255.255.0
#
interface Vlan-interface703
 description A-1-iscsi to A-2-iscsi interconnect
 ip binding vpn-instance a-1-iscsi
 ip address 172.16.103.254 255.255.255.0
#
interface Vlan-interface704
 description B-1-app to B-2-App interconnect
 ip binding vpn-instance b-1-appserver
 ip address 172.16.104.254 255.255.255.0
#

3. Configure BGP without neighbor with the VPN instances name as following:

(we need routing between webserver & appserver on the same router)

#
bgp 65111
 router-id 1.1.1.1
 undo synchronization
 #
 ipv4-family vpn-instance a-1-webserver
  import-route direct
 #
 ipv4-family vpn-instance a-1-appserver
  import-route direct!
#

Once the BGP is done – you should be able to ping between “a-1-webserver” and “a-1-appserver” networks.

Its time check routing table for the VRFs – you will find BGP is doing the routing for the same switch inter-VRFs.

#display ip routing-table vpn-instance a-1-webserver
#display ip routing-table vpn-instance a-1-appserver
#display bgp vpnv4 vpn-instance a-1-webserver routing-table
#display bgp vpnv4 vpn-instance a-1-appserver routing-table

####rest of the configurations are for inter site (site-1 & site-2) communication####

4. Following are routing between SITE-1 and SITE-2 VRFs via static routing:

(static routes to be added to SITE-1-Router-01)

#
ip route-static vpn-instance a-1-webserver 0.0.0.0 0.0.0.0 192.168.101.254
ip route-static vpn-instance a-1-webserver 192.168.201.0 255.255.255.0 172.16.101.2; (A-1 web to A-2 web)
ip route-static vpn-instance a-1-webserver 192.168.202.0 255.255.255.0 172.16.101.2; (A-1 web to A-2 app)
ip route-static vpn-instance a-1-appserver 0.0.0.0 0.0.0.0 192.168.102.254
ip route-static vpn-instance a-1-appserver 192.168.202.0 255.255.255.0 172.16.102.2; (A-1-app to A-2-app)
ip route-static vpn-instance a-1-appserver 192.168.201.0 255.255.255.0 172.16.102.2; (A-1-app to A-2-web app)
ip route-static vpn-instance a-1-iscsi 192.168.203.0 255.255.255.0 172.16.103.2; (A-1 iscsi to A-2 iscsi)
ip route-static vpn-instance b-1-iscsi 192.168.204.0 255.255.255.0 172.16.104.2; (B-1 app to B-2 app)
#

Configure the SITE-2-Router-02 same way (change the source and destination networks).

At this stage routing between both the site-1 and site-2 VRFs should be fine.

Check routing table for all the VRFs –
#display ip routing-table vpn-instance vrf_name

Do ping test as well; command is –
#ping -vpn-instance vrf_name IP_address

Adding a new disk ONLINE to a Linux VM running on VMware (no reboot required)

Adding a new disk ONLINE on a virtual Linux server is easy as adding disk to a Windows 2008/2012 Server online! No reboot required.

Make sure the following software already installed on your Linux VM.

-VMware Tools (for other hypervisor install the guest plugin on the VM)

-sg3_utils

-lsscsi

In this example I used RedHat/CentOS running on VMware.

Technical procedures are following –

Before we began let’s see how many disks are currently provisioned on the Linux VM. To do this execute “#lsscsi” command; screenshot –

In this example the server currently have three disks (03) installed.

Linux-VM-Disk-1

Now add a new disk to the VM through vSphere client. Execute the same “#lsscsi” command – the newly disk will not appear!

To get this newly added disk recognized by the Linux system we need to do “rescan SCSI bus”. Usually “SCSI bus” rescan happen every time when the machine gets rebooted – however this time we don’t want to reboot the system!

Execute the following command to rescan “scsi bus” –

# /usr/bin/rescan-scsi-bus.sh -l

(this script is a part of sg3_utils)

You should be able to see the newly added disk on the command output. Screenshot –

Linux-VM-Disk-2

Now if you do a “#lsscsi” this will display four (04) disks. Previously it was three (03) disks in this example.

The new disk information will appear in “dmesg” as well; do a “dmesg | grep disk” to find details.

Next step should be partition the new disk, create file system and provide a mount point; if you want auto mount then add the partition details to “/etc/fstab”.

 

Configure Perl CPAN to use HTTP mirror instead of FTP – also access mirrors via HTTP Proxy

By default perl CPAN is configured to use FTP mirrors instead of HTTP mirrors.

If your environment only allows HTTP out through http proxy service – this prevents installation of new perl CPAN modules over the internet. I have seen lot of companies they allow access to internet only through http/https proxy server.

In this configure I will show –

(i)how to configure CPAN to use HTTP mirrors instead of FTP.

(ii)how to configure CPAN to use a http proxy server to access HTTP mirrors over the Internet.

Part 1: Configure CPAN to use HTTP mirror instead FTP

i. invoke perl cpan command shell first

#perl –MCPAN –e shell

If you ran CPAN for the first time in a computer – the above command might ask you

Are you ready for manual configuration? [yes]

Enter no.

ii. Set your preferred CPAN HTTP mirror URL

#cpan> o conf urllist push http://www.perl.com/CPAN; you can enter your preferred CPAN mirror URL here.

iii. List and verify your newly entered http mirror

#cpan> o conf urllist       ; this should return the above http mirror URL

iv. Save the new configuration

#cpan> o conf commit

CPAN is ready to use HTTP instead of FTP.

Part 2: Configure CPAN to use a HTTP proxy server to access Internet

i. invoke perl CPAN command shell first

#perl –MCPAN –e shell

If you ran CPAN for the first time in a computer – the above command might ask you

Are you ready for manual configuration? [yes]

Enter no.

ii. Set your HTTP proxy server address, port and auth details

#cpan> o conf init /proxy/

Your ftp proxy?                                 ;nothing to enter here

Your http proxy?myproxy:8080                 ;enter your proxy server IP or hostname with port number

Your proxy user id?                         ; if your proxy use proxy_auth enter username

iii. Save your configuration

#cpan> o conf commit

Your CPAN should be ready to access HTTP mirrors via proxy!

Cisco ASA 5500 series recommended IOS upgrade path

You might encounter problem while attempt to upgrade Cisco Adaptive Security Appliance (ASA) to Version 8.4.7 or later or to Version 9.1.3 or later. Here is below the recommended upgrade path – that resolves the problem.

ASA-firmware

ASA version pre-8.3 NAT rule syntax are different than version 8.4 and later. This upgrade path will automatically convert pre-8.3 version NAT rule syntax to version 8.4 and later.

Few well known errors are “”No Cfg structure found in downloaded image file” and “no NAT rule found after the upgrade”.

HP 5820 LACP (802.3ad) with non-HP (Cisco, F5 and others)

HP 5820-24XG-SFP+ is a 24 port 10GB SFP+ Layer 3 enterprise and carrier grade Ethernet switch. This is running Comware5 network operating system. This switch is actually manufactured by H3C.

HP 5820 series LACP (802.3ad) link aggregation is called “Bridge-Aggregation” interface. The configuration is pretty much similar to Cisco EtherChannel.

I will discuss two things here–

(a). how to configure link-aggregation between HP and non-HP (Cisco, F5, Juniper) devices.

(b). how to configure link-aggregation between HP and HP (HP ProCurve ProVision, Comware5/7, HP SAN).

Following are configuration commands to create LACP between HP and non-HP devices –

(a). Enter the following command on the HP switch to create bridge-aggregation interface

(trunk/tagged vlan interface example)

interface Bridge-Aggregation1
 description “LACP Trunk goes to a non-HP device”
 port link-type trunk
 port trunk permit vlan all ;this can be limited to user define VLANs only 
 link-aggregation mode dynamic  ;for non-HP mode dynamic is require

(access port example)

interface Bridge-Aggregation2
 description “LACP access goes to a non-HP device”
 port access vlan 100
 link-aggregation mode dynamic  ;for non-HP mode dynamic is require

After define bridge aggregation interface – you need to add physical interfaces to it. Physical interface should inherit all the parameters configured on the bridge-aggregation interface.

Make sure physical interfaces are configured with “default” settings only before put them to a bridge-aggregation group to get settings auto inherited. Otherwise you need to specify “link-type” and “permit vlan” parameters once again on all the member physical interfaces.

interface Ten-GigabitEthernet1/0/22
   port link-mode bridge
   description “this interface is a member of bridge-aggregation 1”
   port link-type trunk
   port trunk permit vlan all
   port link-aggregation group 1

interface Ten-GigabitEthernet2/0/22
   port link-mode bridge
   description “this interface is a member of bridge-aggregation 1”
   port link-type trunk
   port trunk permit vlan all
   port link-aggregation group 1

Once done – you should be able to see aggregated bandwidth on the “Bridge-Interface”.

Do a “#display interface Bridge-Aggregation 1

Screenshot of a two 10Gbps LACP interface (20Gbps aggregated) –

5820-LACP

(b). For LACP between HP and HP devices enter all the above commands except “link-aggregation mode dynamic”.

Splunk user authentication with Windows Active Directory

Recently I have implemented Windows Active Directory authentication for Splunk. My Windows AD DS is a mix of Windows 2008 and Windows 2012; Splunk version is 6.x.

Here is below the technical steps-

1. Login to Splunk using admin account. Go to “Settings > Access Controls > Authentication method”. You should be able to see the available authentication methods here. Select “LDAP” and click on “Configure Splunk to use LDAP and map groups”. Screenshot –

Splunk-AD-1

2. Click on the “New” button. On the new page – this is the main LDAP strategy configuration settings page. Following are the main AD items that you need to enter here –

a. LDAP connection settings – based on connection settings Splunk will talk to AD.

LDAP strategy name: just a name.

You can have multiple LDAP strategies such as –  (i)strategy one for ready only access through an AD Group mapping to Splunk roles (user & power user), (ii)strategy two for full access through another AD Group mapping to other Splunk roles (Admin, Splunk-system-role) or similar.

Default Splunk roles are – admin, can_delete, power, splunk-system-role, user.

Port number: 389 (this is AD LDAP default)

Connection order: default

Bind DN: cn= AcctName Splunk,ou=yourSvcAcctOU,dc=yourDCName,dc=yourDCExtension

This is distinguished name of your Splunk account that you created in AD. It is recommended you should not use default AD administrator account or your own AD login here. You should create a dedicate account for Splunk – no AD administrative privilege required on this account.

Bind DN Password: enter the password of AD Splunk account

Splunk-AD-2

b. User Settings – Splunk will look for users in AD based on this

User base DN: dc=yourDCName,dc=yourDCextension

User base filter: leave this blank or you can enter specific AD search filter here

User name attribute: samaccountname

Real name attribute: displayname

Group mapping attribute: dn

Screenshot –

Splunk-AD-3

c. Group settings – Splunk will look for AD groups in AD based on this

Group base DN: cn=Group_Splunk_Access_Admins,ou=youGroupOUName,dc=yourDCName,dc=DCextension

This is the AD group that been created to grant access in Splunk.

Static member attribute: member

Screenshot-

Splunk-AD-4

d. Dynamic group settings – optional

e. Advanced settings – default is ok; however you can increase search request size limit.

Screenshot –

Splunk-AD-5

Click on the “Save”. If entered parameters are not correct – you won’t be able to save.

Now you should be able to see your LDAP strategy. Make sure it is enabled.

To see your AD group in Splunk, click on “Map groups”.

To map Splunk role(s) to an AD group – click on “Map groups > AD Group Name > available and selected roles”; screenshots –

Splunk-AD-6

Splunk-AD-8

Also you should be able to see AD users at “Settings > Access controls >Users”. Make sure AD users are member of the Splunk group that been created on AD.

Inter-VRF routing on the same Router (VRF-lite route leak) – Cisco IOS

I was trying to implement inter-VRFs routing in a multi VRF-lite environment – there was a requirement to implement routing between two VRF domains on the same router. I couldn’t make this working through typical static routing or IGP. Later on I found Cisco recommendation – this has to be done through (i)route-target export/import and (ii)BGP.

“You can not configure two static routes to advertise each prefix between the VRFs, because this method is not supported—packets will not be routed by the router. To achieve route leaking between VRFs, you must use the import functionality of route-target and enable Border Gateway Protocol (BGP) on the router. No BGP neighbor is required. http://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/multiprotocol-label-switching-vpns-mpls-vpns/47807-routeleaking.html

Here is my topology diagram–

inter-vrfs-BGP

Routing/connectivity requirements are –

Within “same router” inter-VRFs routing:

Source Network Destination Network Site Number
A-1-network-webserver A-1-network-appserver Site 1
A-2-network-webserver A-2-network-appserver Site 2

Inter site (site 1 & site 2) VRFs routing:

  1. Multiple site-1 sources to > multiple site-2 destinations;
Source Network Destination Network
A-1-network-webserver A-2-network-webserver
A-1-network-webserver A-2-network-appserver
A-1-network-appserver A-2-network-appserver
A-1-network-appserver A-2-network-webserver
  1. One site-1 source to > one site-2 destination;
Source Network Destination Network
A-1-network-iscsi A-2-network-scsi
B-1-network-appserver B-2-network-app

Based on above mentioned scenario –

  1. VRFs routing between Site 1 and Site 2 – static route or any dynamic routing protocol such as EIGRP, OSPF are suitable.
  2. VRFs routing within the same router at each site (routing for web & app on the same site) need to be done through multiprotocol BGP and route-target import – which is a recommendation by Cisco.

I will show here how to do inter VRFs routing within the same router using BGP and route-target export-import.

Following are configurations on SITE-1-Router-01,

(Step 1) Define VRFs and route-target export & import as following:

!
ip vrf a-1-webserver
rd 65111:101
route-target export 65111:101
route-target import 65111:101
route-target import 65111:102  ;import “a-1-network-appserver”
!
ip vrf a-1-appserver
rd 65111:102
route-target export 65111:102
route-target import 65111:102
route-target import 65111:101  ;import “a-1-network-webserver”
!
ip vrf a-1-iscsi
rd 65111:103      ;no network export-import here
!
ip vrf b-1-appserver
rd 65111:104      ;no network export-import here
!

(Step 2) Apply the VRFs to proper interfaces – assign IP address to interfaces as well.

(Step 3) Configure BGP without neighbour with the VPN instances name as following:

(we need routing between webserver & appserver on the same router)

!
router bgp 65111
bgp log-neighbor-changes
!
address-family ipv4 vrf a-1-webserver
redistribute connected
exit-address-family
!
address-family ipv4 vrf a-1-appserver
redistribute connected
exit-address-family
!

Once the BGP is done – do a “#show ip route vrf a-1-webserver”; it should display both a-1-appserver & a-1-webserver networks. Same result should display for “#show ip route vrf a-1-appserver”. At this stage a-1-webservers should be able to talk to a-1-appservers. Configure the same on SITE-2-Router-02 router.

####rest of the configuration are for inter site (site-1 & site-2) communication####

(Step 4) For routing between SITE-1 and SITE-2 following is an example with static routing:

In this example –

Site-1 (source) networks are-

-Customer A webserver network is – 192.168.101.0/24; default route is 192.168.101.254
-Customer A appserver network is – 192.168.102.0/24; default route is 192.168.102.254
-Customer A iscsi network is – 192.168.103.0/24
-Customer B appserver network is – 192.168.104/24

Site-2 (destination) networks are-

-Customer A webserver network is – 192.168.201.0/24
-Customer A appserver network is – 192.168.202.0/24
-Customer A iscsi network is – 192.168.203.0/24
-Customer B appserver network is – 192.168.204/24

SITE-1-ROUTER-01 inter site routing commands are following –

!
ip route vrf a-1-webserver 0.0.0.0 0.0.0.0 192.168.101.254
ip route vrf a-1-webserver 192.168.201.0 255.255.255.0 172.16.101.2; (A-1 web to A-2 web)
ip route vrf a-1-webserver 192.168.201.0 255.255.255.0 172.16.101.2; (A-1 web to A-2 app)
ip route vrf a-1-appserver 0.0.0.0 0.0.0.0 192.168.102.254
ip route vrf a-1-appserver 192.168.202.0 255.255.255.0 172.16.102.2; (A-1 app to A-2 web)
ip route vrf a-1-appserver 192.168.202.0 255.255.255.0 172.16.102.2; (A-1 app to A-2 app)
ip route vrf a-1-iscsi 192.168.203.0 255.255.255.0 172.16.103.2; (A-1 iscsi to A-2 iscsi)
ip route vrf b-1-iscsi 192.168.204.0 255.255.255.0 172.16.104.2; (B-1 app to B-2 app)
!

Configure the SITE-2-Router-02 same way (change the source and destination networks).

Do “#show ip vrf vrfname” to check your routes; also do ping test “#ping vrf vrfname ip ipAddr”.

HP ProCurve 6600 series firmware upgrades using USB flash drive

Firmware upgrade on a HP ProCurve 6600 series (24g-4xg or 48g-4xg or 24xg) can be done in several ways, here I will cover upgrading firmware using USB stick.

HP 6600 series always keep two boot images on the flash – (i)primary boot image and (ii)secondary boot image; by default switch boot from the primary. During new firmware upgrade the system automatically take a backup of primary image and copy this to the secondary – so no worry; if you messed up with firmware upgrade you can tell the system to boot from secondary (which is you current good one in fact).

Also firmware upgrade process will keep a backup of your “configurations” in the switch – however it is recommended you should take copy of the same before start upgrade process.

1. Download the latest firmware from HP My Networking site – https://h10145.www1.hp.com/downloads/ProductsList.aspx?lang=&cc=&prodSeriesId=

The latest firmware as of today (June 2014) is K.15.13.0005. The firmware file is a “.swi” extension file. Copy this file onto a USB flash drive (do not put this in a sub directory). Before the upgrade make sure which version is you are currently running; the command is “#show flash” – screenshot –

HP-6600-firmware-1

2. Insert the USB stick to the switch; the switch will automatically mount the USB. Do a “#show flash” to see the firmware file visible on the switch.

3. Once you see the firmware file on the switch – let’s start firmware upgrade process. Copy the firmware file to primary flash. The command and screenshot following –

#copy usb flash K_15_13_0005.swi primary

HP-6600-firmware-2

4. Once the copy is finish make sure your primary flash is showing the latest version; the command is “#show flash” again –

HP-6600-firmware-3

(now primary and secondary version are different)

5. Optional – you might need to tell the switch to boot from the primary image; command is “#boot system flash primary” – screenshot following –

HP-6600-firmware-4

The switch will reboot during firmware upgrade.

Once all above are done – do a “#show flash” to confirm the switch is running with the latest firmware.