Search This Blog

Thursday, July 18, 2013

Cisco ASA Failover setup

Here is a setup for Cisco ASA failover (active/standby)

Network Topology:


VLAN22 = OUTSIDE
VLAN21 = Management
VLAN20 = INSIDE



Primary unit interface configuration:

interface Ethernet0/0
 nameif INSIDE
 security-level 100
 ip address 192.168.10.1 255.255.255.0
!
interface Ethernet0/1
 nameif OUTSIDE
 security-level 0
 ip address 10.0.0.1 255.255.255.224
!
interface Ethernet0/3
 description LAN Failover Interface
!
interface Management0/0
 management-only
 nameif MGMT
 security-level 0
 ip address 172.16.99.1 255.255.255.0
!

Secondary unit interface configuration:

interface Ethernet0/0
 nameif INSIDE
 security-level 100
 ip address 192.168.10.2 255.255.255.0
!
interface Ethernet0/1
 nameif OUTSIDE
 security-level 0
 ip address 10.0.0.2 255.255.255.224
!
interface Ethernet0/3
 description LAN Failover Interface
!
interface Management0/0
 management-only
 nameif MGMT
 security-level 0
 ip address 172.16.99.2 255.255.255.0
!

Now let’s configure the failover on the primary unit:

failover
failover lan unit primary
failover lan interface FAILOVER Ethernet0/3
failover key *****
failover replication http
failover link OUTSIDE
failover interface ip FAILOVER 10.100.0.1 255.255.255.0 standby 10.100.0.2

An explanation regarding the configuration:
Line 1: enable failover
Line 2: set the unit role in the failover setup
Line 3: set the failover interface between the units
Line 4: set secret key (optional)
Line 5: replicate HTTP sessions between the units (optional)
Line 6: set the sync interface between the units
Line 7: assign active/standby IP addresses for the failover link

Now configure failover on secondary unit:

failover
failover lan unit secondary
failover lan interface FAILOVER Ethernet0/3
failover key *****
failover replication http
failover link OUTSIDE
failover interface ip FAILOVER 10.100.0.1 255.255.255.0 standby 10.100.0.2

And add tracking on INSIDE and OUTSIDE interfaces, which in case of failure will switch the failover unit:

interface Ethernet0/0
 ip address 192.168.10.1 255.255.255.0 standby 192.168.10.2
!
interface Ethernet0/1
  ip address 82.166.44.101 255.255.255.224 standby 82.166.44.102
!



In order to switch between the active unit use the command:

failover active







Monday, July 15, 2013

VRF Lite leakage



Let’s say we have a situation, as I encountered one, where we need to use VRF lite between two interfaces, each one on different VRF, and we need to have connectivity between the two VRF’s.

This  is the network topology:



The configuration is pretty much the same as working with PE/MPLS-VPN network but with slight difference.

R1 is the router which connected to 3 interfaces, Fa1/0 is connected to VRF RED, Fa1/1 is connected to VRF BLUE and Fa2/0 is connected to R4 through the global routing table.

So first configure the VRF’s on R1 with the corresponding interfaces:

ip vrf BLUE
 rd 200:200
 route-target export 200:200
 route-target import 200:200
!
ip vrf RED
 rd 100:100
 route-target export 100:100
 route-target import 100:100
!
interface FastEthernet1/0
 ip vrf forwarding RED
 ip address 10.1.12.1 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet1/1
 ip vrf forwarding BLUE
 ip address 10.1.13.1 255.255.255.0
 duplex auto
 speed auto
!

Then configure BGP, without peers, but with address-families:

router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 no auto-summary
 !
 address-family ipv4 vrf RED
  redistribute connected
  redistribute static
  no synchronization
 exit-address-family
 !
 address-family ipv4 vrf BLUE
  redistribute connected
  redistribute static
  no synchronization
 exit-address-family
!

Then add route import/export between the two VRF’s:

ip vrf BLUE
 rd 200:200
 route-target import 100:100
!
ip vrf RED
 route-target import 200:200
!

VRF BLUE import VRF RED (100:100) while VRF RED import VRF BLUE (200:200).
The routing table on VRF RED (on R1):

R1#show ip route vrf RED

Routing Table: RED
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

B    192.168.31.0/24 [20/0] via 10.1.13.3 (BLUE), 00:21:10
S    192.168.21.0/24 [1/0] via 10.1.12.2
     10.0.0.0/24 is subnetted, 2 subnets
B       10.1.13.0 is directly connected, 00:20:25, FastEthernet1/1
C       10.1.12.0 is directly connected, FastEthernet1/0

Note route 192.168.31.0/24 via 10.1.13.3 (BLUE) which has just imported to VRF RED.
Now let’s advertise the networks in VRF RED to the global:

ip route 192.168.21.0 255.255.255.0 FastEthernet1/0
ip route 192.168.31.0 255.255.255.0 FastEthernet1/1
ip route vrf RED 0.0.0.0 0.0.0.0 10.1.14.4 global
ip route vrf BLUE 0.0.0.0 0.0.0.0 10.1.14.4 global
!

Note the first 2 lines route networks 192.168.21.0/24 and 192.168.31.0/24 to interface next-hop Fa1/0 and Fa1/1 accordingly. This way the global routing table knows how to reach these networks.

The next 2 lines insert default route into the VRF’s routing table allowing them access to the global routing table for every network that they doesn’t know.

Let’s test R2 connectivity:

R2#ping 192.168.41.1 source lo1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.41.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.21.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/43/48 ms

R2#ping 192.168.41.1          

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.41.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Note that only when using source interface Loopback1, R2 can reach network 192.168.41.0/24 on R4, the reason is because I have configured only network 192.168.21.0/24 on the global routing table.

VRF lite helps to create separate routing instances on a single device but as we can see we can share networks and routes between the VRF’s as needed.



SNMP Secure Access



Here are few steps to secure SNMP access to Cisco device:
     
     1.       Configure community ACL
     2.       Define view command which allow the user access only to limited parts of the   Management Information Base (MIB).
     3.       Use SNMPv3

Configure ACL:

ip access-list standard ACL_SNMP_ACCESS
permit 10.10.10.0 0.0.0.255
deny any
!
snmp-server community cisco RO ACL_SNMP_ACCESS

This ACL allow only hosts from network 10.10.10.0/24 with Read-Only access.

Define view command:

snmp-server view MYVIEW mgmt.* included
!
snmp-server community cisco view MYVIEW RO ACL_SNMP_ACCESS

The view command allow us to create a group (MYVIEW) with specific parts of the MIB instead of allowing full access to the whole MIB.

The following OID (mgmt..*) allow access to system general and interface information only.

You can use snmp-walk or snmp MIB browser to select the required parts from the device MIB.

Use SNMPv3:

snmp-server engineID local 111100000000000000000000
snmp-server user USER1 GRP1 v3
snmp-server user USER2 GRP2 v3
snmp-server user USER3 GRP3 v3 auth md5 USER3PASS
snmp-server user USER4 GRP4 v3 auth md5 USER4PASS priv des56 USER4PRIV
!
snmp-server group GRP1 v3 noauth
snmp-server group GRP2 v3 noauth read MYVIEW
snmp-server group GRP3 v3 auth
snmp-server group GRP4 v3 priv
!
snmp-server view MYVIEW mgmt.* included
!
snmp-server community public RO

In this example I have configured 4 types of users along with 4 types of groups. Each user tied to a group. The SNMP engine ID is optional and it used to define device entity.

USER1 gets full access without authentication or encryption.
USER2 gets limited access, using the view command which configured under the group, without authentication or encryption.
USER3 gets full access with authentication but without encryption.
USER4 gets full access with authentication and encryption (DES 56bit).

Use the user/group type according to your needs.

Combining all three will allow highly secure (and encrypted) SNMP access to your Cisco device. 

Packet capture for various users access:

User1:


User2:

 
User3:


 User4:


note the encrypted message data.