Cisco – Joining Layer 2 Networks Over Layer 3 Networks

KB ID 0001313 

Problem

It’s a common problem, you want to connect one site to another and still have them on the same layer 2 network.

As you can see above both the routers at the bottom are in the 172.16.1.0/24 network, let’s assume they are clients in the same layer 2 network how would you connect them?

Solution

Option 1: xconnect over L2TP

All the ‘heavy lifting’ is done on the SiteA and SiteB routers. We will start with Site A. You create a pseudowire class, and specify the interface that will do the encrypting .

[box]

!
pseudowire-class CL-XCONNECT
 encapsulation l2tpv3
 protocol none
 ip local interface Ethernet 0/0
!

[/box]

Set the public (internet facing)  IP.

[box]

!
interface Ethernet0/0
 ip address 192.168.200.1 255.255.255.0
 no shut
!

[/box]

Finally setup the private, (LAN facing) interface, and specify the ‘other side’ of the encryption tunnel, (the internet facing interface at SiteB.) Then setup a unique ID.

[box]

!
interface Ethernet0/1
 description LAN
 no ip address
 xconnect 192.168.100.1 1 encapsulation l2tpv3 manual pw-class CL-XCONNECT
 l2tp id 1 2
!

[/box]

Site B is the mirror opposite;

[box]

!
pseudowire-class CL-XCONNECT
 encapsulation l2tpv3
 protocol none
 ip local interface Ethernet 0/0
!
interface Ethernet0/0
 ip address 192.168.100.1 255.255.255.0
!
interface Ethernet0/1
 description LAN
 no ip address
 xconnect 192.168.200.1 1 encapsulation l2tpv3 manual pw-class CL-XCONNECT
 l2tp id 2 1
!        

[/box]

To test you can use the ‘show l2tun tunnel all‘ command

Option 2: MPLS

Hang about! Isn’t MPLS very complicated? Well not for layer two networks. There are certain steps we have to take;

Backbone Routers (That will be Site A, SiteB, AND the ISP one.) We will need a loopback address, (don’t forget these addresses will need advertising into whatever routing protocol is running over the backbone).

[box]

Site A

!         
interface Loopback1
 ip address 192.168.255.4 255.255.255.255
!

Site B

!         
interface Loopback1
 ip address 192.168.255.3 255.255.255.255
!

ISP

!
interface Loopback1
 ip address 192.168.255.2 255.255.255.255
!

[/box]

Backbone Routers: Enable MPLS on all the interfaces that will pass traffic;

[box]

Site A

!
interface Ethernet0/0
 ip address 192.168.200.1 255.255.255.0
 mpls ip
!

Site B

!
interface Ethernet0/0
 ip address 192.168.100.1 255.255.255.0
 mpls ip
!

ISP

!
interface Ethernet0/0
 ip address 192.168.100.254 255.255.255.0
 mpls ip
!
interface Ethernet0/1
 ip address 192.168.200.254 255.255.255.0
 mpls ip
!

[/box]

Client facing interfaces:, (these can also be sub interfaces, if you are trunking). Need xconnect setting up, the syntax is as follows;

xconnect {ip of target loopback) {id-must-match-other-end} encapsulation mpls

[box]

Site A

!
interface Ethernet0/1
 description LAN
 no ip address
 xconnect 192.168.255.3 3000 encapsulation mpls
!


Site B

!
interface Ethernet0/1
 description LAN
 no ip address
 xconnect 192.168.255.4 3000 encapsulation mpls
!

[/box]

Option 3: VPLS

Virtual Private LAN Service, is pretty much designed to do exactly what we want, it let’s us stretch layer two networks to multiple points, let’s assume both my network segments (above) need to be in VLAN 300, so they share the same broadcast domain.

The setup process is similar to MPLS, you create a loopback interface on the backbone routers, advertise those addresses into the routing protocol of your choice, then you enable ‘mpls ip‘. But then, on the routers that face the clients you need to create a ‘vfi‘ (virtual forwarding instance,) then attach that VFI to the VLAN interface that the clients are connected to.

[box]

!
l2 vfi VPLS-300 manual
 vpn id 300
 neighbor 192.168.255.3 encapsulation mpls
!
interface Vlan300
 mtu 1600
 xconnect vfi VPLS-300
!

[/box]

Note: Obviously the physical interface connected to the clients, needs to be in VLAN 300, and don’t forget (at both ends), to make sure that vlan 300 is up (no shut).

To Test:

[box]

SiteA#show mpls l2transport vc 300

Local intf     Local circuit              Dest address    VC ID      Status
-------------  -------------------------- --------------- ---------- ----------
VFI VPLS-300   VFI                        192.168.255.3     300        UP

and

SiteA#show mac address-table vlan 300

Legend: * - primary entry
        age - seconds since last seen
        n/a - not available
        S - secure entry
        R - router's gateway mac address entry
        D - Duplicate mac address entry

Displaying entries from active supervisor:

     vlan   mac address    type   learn    age                 ports
----+----+---------------+-------+-----+----------+-----------------------------
*     300 0050.56ab.2eae  dynamic  Yes       90     VPLS peer 192.168.255.3(2:1)
*     300 0050.56ab.12ee  dynamic  Yes      340     VPLS peer 192.168.255.3(2:1)

[/box]

In the bottom example, you can see MAC addresses being learned form the ‘other’ sire of the VPLS link.

 

Related Articles, References, Credits, or External Links

NA

Cisco Licence Differences LAN-Lite / LAN Base / IP Base / IP Services

KB ID 0001270 

Problem

Actually finding the answer to this question is far more challenging than it needs to be! As usual Cisco can change this on a whim so before you purchase any equipment it’s still a good policy to check on the feature navigator.

Solution

This is about the best reference I’ve found. Although anyone who can tell me what the correct Layer 2 differences between Enterprise Access and Complete Access are, please do so!

Related Articles, References, Credits, or External Links

NA

Azure to Cisco VPN – ‘Failed to allocate PSH from platform’

KB ID 0001219

Problem

It’s been a week for strange VPN shenanigans with Cisco and Azure. I was liaising with an Azure service provider for a customer this week, and trying to get a VPN up from a Cisco ASA in one of our data centres in the UK. This is what we were seeing;

And I could see the same error in the debugs;

[box]

Decrypted packet:Data: 616 bytes
IKEv2-PROTO-1: Failed to allocate PSH from platform
IKEv2-PROTO-1:
IKEv2-PROTO-5: SM Trace-> SA: I_SPI=65EAE07164D4916D R_SPI=034FB3DBCA5E9891 (R) MsgID = 00000000 CurState: IDLE Event: EV_DELETE
IKEv2-PROTO-5: Action: Action_Null
IKEv2-PROTO-5: SM Trace-> SA: I_SPI=65EAE07164D4916D R_SPI=034FB3DBCA5E9891 (R) MsgID = 00000000 CurState: EXIT Event: EV_ABORT
IKEv2-PROTO-5: SM Trace-> SA: I_SPI=65EAE07164D4916D R_SPI=034FB3DBCA5E9891 (R) MsgID = 00000000 CurState: EXIT Event: EV_CHK_PENDING_ABORT
IKEv2-PROTO-5: SM Trace-> SA: I_SPI=65EAE07164D4916D R_SPI=034FB3DBCA5E9891 (R) MsgID = 00000000 CurState: EXIT Event: EV_UPDATE_CAC_STATS
IKEv2-PROTO-2: Abort exchange
IKEv2-PROTO-2: Deleting SA

[/box]

Solution

After a conversation with the service provider, it turns out that they are providing a multi tenant solution that utilises many VPNs for multiple clients, because of this they HAVE TO use a security gateway that uses ‘Route Based/Dynamic Routing’.

There are two types of VPNs that you can run out of Azure;

  • Static routing VPNs – Static routing VPNs or policy-based VPNs. These encrypt and route traffic through an interface based on a customer defined policy. Static routing VPNs require a static routing VPN gateway. With this type of VPN you CAN NOT have multiple site to site VPNs.
  • Dynamic routing VPNs – Dynamic routing or route-based VPNs. These depend on a tunnel interface specifically created for forwarding traffic. Any traffic arriving on the virtual tunnel interface (VTI) will be forwarded through the correct VPN connection. 

Why is this a problem?

If you look on the currently supported VPN devices for Azure;

Route-based is not compatible, this is because VPN’s based on VTI’s are NOT supported on the Cisco ASA platform. If you are a Cisco firewall type, this is the same reason you can’t use an ASA for DMVPN, or to terminate a GRE tunnel on.

What can you do?

In my case I’m going to put a Cisco IOS Router (Cisco ISR 1921), beside the Firewall and route all the Azure traffic via that. As you can see from the table above that IS supported.

Related Articles, References, Credits, or External Links

NA

Cisco IOS – DHCP Helper (DHCP Relay) – IP-Helper Setup

KB ID 0001168 

Problem

Cisco documentation calls this a ‘DHCP Relay’, and uses the command IP-Helper, and I usually call this DHCP Helper, just to confuse everyone. To be fair the term DHCP Relay is an industry standard, it’s not particular to Cisco (as you will see later when I Wireshark the traffic).

So If you are reading this you have a DHCP server and you want to use it to lease addresses to clients that are on a different network segment (layer 2, or layer3).

To do that you need an agent to be on the same network segment as the client listening for DHCP requests, when it receives one it talks to the DHCP server on the clients behalf and gets the correct address.

Solution

Example 1 Cisco Router

Here we need to lease two different DHCP scopes to two different network segments, R1 will act as the IP-Helper for both of those networks, R2 and R3 will get their IP addresses from the correct DHCP scope.

This works because each (client facing) interface on R1 has an IP-Helper address defined that points to the DHCP server.

So How Does It Know Which Scope To Lease From? This is because the Router supplies the IP address of a RELAY AGENT, which is just the IP address of the physical interface that intercepted the DHCP request. When it asks for an IP address from the DHCP server, the Server leases an address from the same range, (again I’ve tracked all this in Wireshark below).

IP-Helper Router Configuration

[box]

R1 Config

!
interface GigabitEthernet0/0
 description Uplink to DHCP Server
 ip address 10.2.2.254 255.255.255.0
 negotiation auto
!
interface GigabitEthernet2/0
 description Uplink to 192_168_2_0
 ip address 192.168.2.1 255.255.255.0
 ip helper-address 10.2.2.10
 negotiation auto
!
interface GigabitEthernet3/0
 description Uplink to 192_168_3_0
 ip address 192.168.3.1 255.255.255.0
 ip helper-address 10.2.2.10
 negotiation auto
!
ip route 0.0.0.0 0.0.0.0 10.2.2.10
!


R2 Config

!
interface GigabitEthernet2/0
 description Uplink to R1
 ip address dhcp
 negotiation auto
!
ip route 0.0.0.0 0.0.0.0 GigabitEthernet2/0
!

R3 Config

!
interface GigabitEthernet3/0
 description Uplink to R1
 ip address dhcp
 negotiation auto
!
ip route 0.0.0.0 0.0.0.0 GigabitEthernet3/0
!

[/box]

You can see this works because the DHCP server has matching scopes for both network segments. (Yes one of my test servers is 2003, you’re going to see some Windows XP in a minute!

Well that’s fine for routers, but what about machines? They send a DHCP Discover just like any other client. I’ve replaced one of the routers with an actual machine.

With its network card set to DHCP you will again get a lease from the correct scope, because the Router brokered it for us.

Back on the DHCP server you can see the lease to the windows XP machine entered in the current scope leases, It knows the name of the client because (as you will see below) the relay agent (Router) passed that information (along with the MAC address of the client) to the DHCP server.

Example 2 Cisco Switches

OK, I did the routers first because I find it easier to explain things at layer 3. Not that you can’t create sub interfaces on the router, add those sub interfaces to VLANs, and run DHCP relays from them. But in most cases you will be setting up DHCP helpers on switches. Here the principle is the same but you define the ip-helper on the VLAN, (unless it’s routed port then treat it the same as a router interface). Let’s modern things up a bit, and use a 2012 R2 DHCP server, and some Windows 8 clients.

I need to lease addresses from my second scope to clients in VLAN 200, (the other client and server are in the same VLAN, so that will just work. (Remember a VLAN is a broadcast domain, and DHCP is using broadcasts).

Here’s the two scopes setup on the 2012 server;

And my client, (DHCP Client in VLAN 200) gets the correct IP.

IP-Helper Switch Configuration (VLANS)

[box]

SW1 Config

interface FastEthernet1/0/1
 description Uplink to DHCP Server
 switchport access vlan 100
 switchport mode access
 spanning-tree pordtfast
!
interface FastEthernet1/0/4
 description Uplink 192_168_200_0
 switchport access vlan 200
 switchport mode access
 spanning-tree pordtfast
!
interface FastEthernet1/0/5
 description Uplink 192_168_100_0
 switchport access vlan 100
 switchport mode access
 spanning-tree portfast
!
interface Vlan200
 ip address 192.168.200.1 255.255.255.0
 ip helper-address 192.168.100.10
!

IF YOU HAVE MULTIPLE/FAILOVER IP-HELPERS OR SPLIT SCOPES YOU CAN ADD A SECOND 
ADDRESS LIKE SO;

!
interface Vlan200
 ip address 192.168.200.1 255.255.255.0
 ip helper-address 192.168.100.10
 ip helper-address 192.168.100.15
!

[/box]

Analysing (Packet-Sniffing) DHCP Relay Sequence with Wireshark

Other packet sniffers are available, but I’ve got a soft spot for Wireshark. To filter DHCP traffic you can use the following ‘filter’.

bootp.option.type == 53

DHCP works by using four messages, (which I remember using the acronym DORA: Discover, Offer, Request, Acknowledge). If you sniff the traffic on the DHCP server, you can watch this process being brokered by your DHCP Relay Agent.

Discover

Offer

Request

Acknowledge

And just to prove it’s not all ‘smoke and mirrors’, here’s the client with the leased address, showing a matching MAC address, and hostname.

Related Articles, References, Credits, or External Links

NA

Cisco ASA – Reverse Route Injection with EIGRP

KB ID 0001137 

Problem

I’ve followed your Reverse Route Injection article and its not working? This email dropped in my mailbox a while back As it turns out the article I had written was for OSPF, and this chap was using EIGRP. So I ran it up with EIGRP as well to test.

Heres my topology, I want to inject the route for the remote site, into my internal EIGRP routing table.

Solution

Assuming EIGRP is already setup between the ASA and the LAN (i.e. Core Switch).

[box]

ASA

Petes-ASA# show run router
!
router eigrp 20
 no auto-summary
 network 10.1.0.0 255.255.0.0
 passive-interface default
 no passive-interface inside
 redistribute static
!

Switch

Core-SW#show run | sec router
router eigrp 20
 network 10.1.0.0 0.0.255.255
 network 10.2.0.0 0.0.255.255
 network 10.3.0.0 0.0.255.255
 no auto-summary

[/box]

Also assuming you already have a site to site VPN established and working.

[box]

Petes-ASA# show cry isakmp 

IKEv1 SAs:

   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: 192.168.249.254
    Type    : L2L             Role    : responder 
    Rekey   : no              State   : MM_ACTIVE 


Petes-ASA# show cry ipsec sa
interface: outside
    Crypto map tag: CRYPTO-MAP, seq num: 1, local addr: 192.168.253.254

      access-list VPN-INTERESTING-TRAFIC extended permit ip 10.1.0.0 255.255.0.0 10.250.0.0 255.255.0.0 
      local ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0)
      remote ident (addr/mask/prot/port): (10.250.0.0/255.255.0.0/0/0)
      current_peer: 192.168.249.254

      #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
      #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4

[/box]

Show the Cryptomap, then add the RRI.

[box]

Petes-ASA# show run crypto   
crypto ipsec ikev1 transform-set VPN-TRANSFORM esp-aes-256 esp-sha-hmac 
crypto map CRYPTO-MAP 1 match address VPN-INTERESTING-TRAFIC
crypto map CRYPTO-MAP 1 set pfs 
crypto map CRYPTO-MAP 1 set peer 192.168.249.254 
crypto map CRYPTO-MAP 1 set ikev1 transform-set VPN-TRANSFORM
crypto map CRYPTO-MAP interface outside
crypto ikev1 enable outside
crypto ikev1 policy 10
 authentication pre-share
 encryption aes-256
 hash sha
 group 2
 lifetime 86400


Petes-ASA# configure terminal 
Petes-ASA(config)# crypto map CRYPTO-MAP 1 set reverse-route
Petes-ASA(config)#

[/box]

Create a ‘Prefix-List’ for the routes to inject (i.e the remote LAN at the other end of the VPN tunnel).

[box]

Petes-ASA(config)# prefix-list PL-VPN-ROUTES description Route-Map For Injecting Remote VPN Routes
Petes-ASA(config)# prefix-list PL-VPN-ROUTES seq 5 permit 10.250.0.0/16

[/box]

Create a ‘route-map’ to inject your prefix-list.

[box]

Petes-ASA(config)# route-map RM-VPN-ROUTES permit 10
Petes-ASA(config-route-map)# match ip address prefix-list PL-VPN-ROUTE 
Petes-ASA(config-route-map)# set metric 1200
Petes-ASA(config-route-map)# exit
Petes-ASA(config)# route-map RM-VPN-ROUTES deny 100

[/box]

With the tunnel up check your internal routing table;

Update: As pointed out by Steve Housego

You’ve missed the route-map off the re-distribute command,

router eigrp 20
redistribute static route-map RM-VPN-ROUTES

[box]

Core-SW#show ip route
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 10.1.1.1 to network 0.0.0.0

     10.0.0.0/16 is subnetted, 4 subnets
C       10.2.0.0 is directly connected, GigabitEthernet2/0
C       10.3.0.0 is directly connected, GigabitEthernet3/0
C       10.1.0.0 is directly connected, GigabitEthernet1/0
D EX    10.250.0.0 [170/28416] via 10.1.1.1, 00:00:02, GigabitEthernet1/0
D*EX 0.0.0.0/0 [170/28416] via 10.1.1.1, 00:00:02, GigabitEthernet1/0

[/box]

Related Articles, References, Credits, or External Links

Cisco ASA – Reverse Route Injection with OSPF

Exchange – 4.5.1. 4.4.0 Primary Target 4.2.1 unable to connect to alternative host

KB ID 0000790 

Problem

My colleague Allen was doing an Exchange 2003 to 2010 migration today, and things were not going well, mail refused to flow from the Exchange 2003 server to the Exchange 2010 server (it flowed from 2010 to 2003 without error). During migrations that’s not unusual, and removing and recreating the routing groups usually fixes it, but he had done that. Mail was sat on the Exchange 2003 Server outbound queues on the queue that matched the routing group connector, but refused to move with the above error.

Solution

For about 45 minutes I was also scratching my head, but then I had a brainwave. If Exchange 2003 has a ‘Smart Host’ Configured on the ‘Default SMTP Virtual Server’ then it attempts to send traffic down the routing group via the smart host, (which will obviously fail). Remove any entry from the smart host section.

When done, restart the SMTP Service, and the Exchange Routing Service, and the queues should start to clear.

Related Articles, References, Credits, or External Links

NA

Juniper SRX – ‘The Routing Subsystem Is Not Running’

KB ID 0001045 

Problem

While trying to deploy Solarwinds to monitor a Juniper SRX failover cluster, we were having no joy connecting to the management interface of the secondary/standby firewall. The management (fxp0) interface on the primary (node0) firewall we could get to OK.

]

After jumping on the secondary firewall (via the console connection) we observed the following;

error: the routing subsystem is not running

Solution

As you can see (above) I couldn’t get the routing services started. And I soon found out, this is quite normal, the primary (active) firewall maintains the routing instance, the secondary firewall does not.

Well that fine but what about out Solarwinds box, what happens if the secondary firewall goes down? No one would know, and we also can’t take daily backups of its config.

To fix this problem you need to use the ‘backup-router’ command. This lets the appliance maintain some routes in the event that it is not hosting the live routing instance.

1. I’ll connect to to the primary firewall from this console session on the secondary firewall with the following command;

[box]request routing-engine login node0[/box]

2. Now I can add the backup-router routes, but assign them to the secondary (node1) firewall. Note: Where 192.168.100.1 is the next hop.

[box]

To get traffic back to the Solarwinds Management Server

set groups node1 system backup-router 192.168.100.1 destination 10.1.20.10/32

To get traffic back to the Cisco ACS Appliance

set groups node1 system backup-router 192.168.100.1 destination 10.1.20.10/32

[/box]

3. Don’t forget if the firewalls failover you will have the same problem (but the opposite way round), so I need the same to the primary node as well.

[box]

To get traffic back to the Solarwinds Management Server

set groups node0 system backup-router 192.168.100.1 destination 10.1.20.10/32

To get traffic back to the Cisco ACS Appliance

set groups node0 system backup-router 192.168.100.1 destination 10.1.20.10/32

[/box]

3. Save the config with a ‘commit’ command.

Related Articles, References, Credits, or External Links

NA

 

Manually Configuring HP Wireless (MSM 720 controller) for Public and Private Wireless Networks

KB ID 0000833 

Problem

In the following procedure I’ll configure the following;

  1. HP 5412zl Switch.
  2. Cisco ASA 5510 Firewall.
  3. HP MSM720 Controller.
  4. HP MSM460 and MSM317 Access Points.

If you are configuring an MSM765zl or MSM775zl use the following article first.

HP MSM765zl and 775zl – Initial Setup and Routing

Assumptions

  1. Private SSID will be on the normal corporate LAN (In this case 172.16.254.0/24).
  2. Public SSID will get its IP addressing from the controllers DHCP Server. (10.220.0.0/16).
  3. The Wireless traffic will traverse the corporate LAN (After being natted on the controller) as 10.210.0.0/16.
  4. My LAN DNS Servers are 172.16.254.1 and 172.16.254.2.

Solution

HP Switch Configuration.

1. The switch must be performing LAN routing, if the LAN’s default gateway is a firewall that needs rectifying first. (where 172.16.254.200 is the firewall).

[box]ip routing
ip route 0.0.0.0 0.0.0.0 172.16.254.200[/box]

2. Switch must be able to resolve DNS queries.

[box]ip dns server-address priority 1 172.16.254.1[/box]

3. Declare a VLAN for the guest VLAN (210), name it, and give it an IP address > Add a Port (A1) to that VLAN which will connect to the Internet Port of the MSM Controller (Port5).

[box]vlan 210
name WIRELESS-TRAFFIC
ip address 10.210.0.1 255.255.255.0.0
untagged A1 [/box]

4. Tag This VLAN on the ‘Inter Switch’ Links from the core switch to the firewall/perimeter device.

[box]tag D24[/box]

5. Save the Switch changes with a write mem command.

Configure the Cisco ASA To Allow the Wireless Traffic out.

Actions for different firewall vendors will vary but you need to achieve the following;

Make sure that a client on the 10.210.0.0/16 network can get access to the Internet

To do that you will need to achieve the following;

Make sure that the 10.210.0.0/16 network has http and https access allowed outbound on the firewall.
Make sure that 10.210.0.0/16 is getting NATTED through the firewall to the public IP address
.

1. Connect to the firewall > Allow the Wireless Traffic out.

[box]

access-list outbound extended permit ip 10.210.0.0 255.255.0.0 any

Note: this permits ALL IP traffic you might prefer

access-list outbound extended permit ip 10.210.0.0 255.255.0.0 any eq http
access-list outbound extended permit ip 10.210.0.0 255.255.0.0 any eq https

Note2: This also assumes you have an ACL called outbound applied to traffic that is destined outbound (show run access-group will tell you)

[/box]

2. Perform NAT on the new wireless outbound traffic.

[box]

object network WLAN-CLIENTS
subnet 10.210.0.0 255.255.0.0
nat (inside,outside) dynamic interface

Note: For Firewalls running versions older than 8.3 the NAT commands will be different, e.g.

nat (inside) 1 10.210.0.0 255.255.0.0

{Where you have a matching global (outside) 1 command in the config already}

[/box]

3. Allow the firewall to ‘route’ traffic back to the wireless clients. (where 172.16.254.254 is the core switch performing LAN routing).

[box] route inside 10.210.0.0 255.255.0.0 172.16.254.254[/box]

4. Save the changes.

5. At this point plug a PC/Laptop into the core switch (Port A1) and make sure you can get Internet access (‘you will need a static IP on the 10.210.0.0 range).

Configure the HP MSM 720 Controller

MSM 720 Initial Setup and IP Addressing.

1. Connect to to the MSM 720 controller (Port 1) 192.168.1.1 (username admin, password admin).

2. Go though the initial setup > Stop when you get to the Automated workflows screen (simply press Home).

3. Setup Access Network: Home > Network > Access Network > Set the Addressing and Management IP addresses like so;

  • Addressing 172.16.254.115/24
  • Management address 172.16.254.116/25

Save.

Note: There’s two because you can separate the management traffic off to another subnet if you wish.

4. Connect Port 1 on the MSM controller to ANY normal port on the Switch (which will be untagged in VLAN 1) >Then connect to the Controller on its new IP https://172.16.254.115.

5. Setup Internet Network: Home > Network > Internet Network > Static.

6. Configure > IP = 10.210.0.2 > Address Mask 255.255.0.0 > Save (don’t worry if you get a warning about DNS).

7. Connect Port 5 on the MSM to Port A1 on the switch (the one you untagged in VLAN 210).

8. Setup DNS: Home > Network > DNS > Enter the Primary LAN DNS servers (172.16.254.1 and 172.16.254.2).

9. Tick DNS Cache > Tick DNS Switch over > Tick DNS interception > Save.

10. Setup Default Route: Home > Network > IP Routes > Add.

11. Enter 10.210.0.1 with a Metric of 1 > Add.

12. Setup DHCP (Note: you will create the scope later)

Obviously only complete this step if you want the Controller to act as a DHCP server for your ‘Public’ Wireless network.

Home> Network > Address allocation > Tick DHCP Server > Configure.

13. Enter the domain name > change Lease tome to 1500.

Note: At this point it automatically fills in DHCP Settings (these will NOT be used don’t panic!)

14. REMOVE the tick form Listen for DHCP Requests on ‘Access Network’

15. MAKE SURE there is a tick in the ‘Client data tunnel’ box > Save.

HP MSM 720 Configure Wireless Access Public and Private

For this procedure we will rename the default VSC which is called HP.

1. Home > Controller (on the left) > VSCs) > HP > Change the Profile name for HP to “Private” > Untick Authentication > Untick Access control.

2. Change the SSID from HP to ‘Private’ > Tick Broadcast Filtering.

3. Ensure Wireless security filters is unticked.

4. Tick Wireless Protection > Set the mode to WPA2 (AES/CCMP) > Change Key Source to ‘Preshared Key’ > Enter and confirm the WPA Password > Save (at the bottom of the screen).

5. Setup Public/Guest VSC: Home > VSC’s > Add New VSC Profile.

6. Set the profile name to ‘Public’ > MAKE SURE authentication and access control ARE ticked.

7. Change the SSID to Public > Tick broadcast filtering.

8. Change Allow Traffic between wireless clients to NO > Expand Client Data Tunnel > Tick ‘always tunnel client traffic’.

9. Ensure Wireless Protection is unticked.

10. If you require HTML based logins, tick that (Note: You will need to create a user later, if you enable this).

11. If using the controller for DHCP > Enable the DHCP Server and specify;

  • DNS 10.220.0.1
  • Start 10.220.0.100
  • End 10.220.0.200
  • Gateway 10.220.0.1
  • Net mask 255.255.0.0
  • Subnet 10.220.0.0

Create a Network Profile for Each of the New VSC’s

1. Home > Network > Network Profiles > Add New Profile.

2. Call it ‘Private’ Tick VLAN ID select 1 > Save.

3. Add New Profile > Call it ‘Public’ > Tick VLAN ID and set it to 210 > Save.

4. At this point, connect your wireless AP’s to the network, and the controller should detect them.

Bind the VSC’s to the Default AP Group (Using the network profiles we just created)

1. On the left hand menu > Controller > Controlled Alps > Default Group > VSC Bindings (top) > Select the ‘Private’ VSC Binding.

2. Make sure ‘Egress Network’ is NOT ticked and none is selected > Save.

3. Add New Binding > Select the ‘Public’ VSC Profile > Tick EGRESS NETWORK > Set the Network profile to ‘Public (210)’ > Save.

Create user accounts (Only if using HTML Based Authentication)

1. Home > Users > User Accounts > Add New Account > specify a name i.e guest > specify and confirm a password i.e. Password123.

2. Change the MAX concurrent Sessions to 250 > Enable VSC Usage > Add the ‘Public’ VSC (right arrow) > Save.

Synchronize the Access Points to the MSM Controller

1. Home > Controller (left) > Controller APs > Overview Tab > Change the Action drop down to Synchronize Configuration > Apply.

2. Wait for the APs to synchronize > Test both the SSIDs.

 

Related Articles, References, Credits, or External Links

NA

 

HP MSM765zl and 775zl – Initial Setup and Routing

KB ID 0000917 

Problem

The MSM 765zl and 775zl, unlike the rest of the HP MSM controller series, do not have any physical Ethernet ports on them.

So before you can get to its web management interface, you need to be able to give it an IP address, and then the controller needs to be able to find a route back to where you are, assuming you are not on a flat unrouted/single VLAN. Obviously if you are directly connected to the same network segment then you can set the devices ‘default route’ from the web management console.

Solution

1. Connect to the chassis that the controller is in, either via telnet or console cable. As I outlined in an earlier article you need to find the controllers slot letter and index number with a services command. (If you are sat in front of the switch the slot letter should already be known!)

2. Now, connect to the MSM directly and give the controller its LAN and WAN IP addresses.

Note: HP call them LAN and WAN interfaces, (I know it’s confusing), the WAN interface does not have to connect to the WAN it only points in that direction. I’m assuming it’s a throw back from when these devices were developed by Colubris.

[box] CORE-SW# services F 2
CORE-SW(msm765-aplication-F)> enable
CORE-SW(msm765-aplication-F)# config
CORE-SW(msm765-aplication-F)(config)# interface ip wan
CORE-SW(msm765-aplication-F)(config-if-ip)# ip address 192.168.1.1/24
CORE-SW(msm765-aplication-F)(config-if-ip)# ip address mode static
CORE-SW(msm765-aplication-F)(config-if-ip)# end
CORE-SW(msm765-aplication-F)(config)# interface ip lan
CORE-SW(msm765-aplication-F)(config-if-ip)# ip address 10.254.0.100/16
CORE-SW(msm765-aplication-F)(config-if-ip)# ip address mode static
CORE-SW(msm765-aplication-F)(config-if-ip)# end
[/box]

3. Now if you are on the same network (or VLAN) as the controller, you should be able to connect to the web management console. If not you will need to do two further steps

a) Connect the TWO virtual ports of the MSM to the correct VLANs on the switch.

b) Add a route back to the network you are on, either by setting a default route (if there is only one) or a static route.

Connect The Two MSM Virtual Ports

At this point the MSM blade can be treated like any other blade with Ethernet ports on it. Above we found out the blade was in slot F, so the ports with show up on the chassis switch as F1 and F2.

Port number 1: Is the WAN/Internet port
Port number 2: Is the LAN port

At the very least the WAN port should be in a different VLAN like so;

[box]

CORE-SW> enable
Password xxxxxxxx
CORE-SW# configure terminal
CORE-SW(config)# vlan 210 name WifiLink
CORE-SW(config)# vlan 210
CORE-SW(vlan-210)# untagged F1
CORE-SW(vlan-210)# exit
CORE-SW(config)#

If all your LAN traffic is on VLAN 1 (which is the default), then the MSM LAN port will already be untagged in VLAN 1. If not you will also need to present the MSM LAN port to the LAN VLAN.

CORE-SW# configure terminal
CORE-SW(config)# vlan 10 name LANTraffic
CORE-SW(config)# vlan 10
CORE-SW(vlan-10)# untagged F2
CORE-SW(vlan-10)# exit
CORE-SW(config)#

[/box]

Adding Default and Static Routes to the MSM controller.

The controller needs a default route, or it will not be able to send traffic out of the local LAN. In a simple flat network that should be all that you need. But if you have multiple network segments (or VLANs), then it will also need a static route adding for each of these. This is important for both access to the web management console, and because your wireless access points need to be able to speak to the controller! If your wireless access points are on a different network you may need to follow the article below to let them know where the controller is.

Register HP Wireless Access Points With an HP MSM Controller on a Different Subnet

[box]

CORE-SW# services F 2
CORE-SW(msm765-aplication-F)> enable
CORE-SW(msm765-aplication-F)# config
CORE-SW(msm765-aplication-F)(config)# ip route gateway 0.0.0.0/0 192.168.1.254 1

If you need to add additional routes the syntax is the same as above.

CORE-SW(msm765-aplication-F)(config)# ip route gateway 10.100.0.0/16 10.254.0.254 1
CORE-SW(msm765-aplication-F)(config)# ip route gateway 10.200.0.0/16 10.254.0.254 1

[/box]

Now you should be able to connect to the web management console and configure your wireless networks, this process is identical to configuring the physical controllers, like the MSM 720 see the link below.

Manually Configuring HP Wireless (MSM 720 controller) for Public and Private Wireless Networks

Related Articles, References, Credits, or External Links

NA

 

Cisco ASA 5500 – VPN Reverse Route Injection With OSPF

KB ID 0000982 

Problem

Reverse Route injection is the process that can be used on a Cisco ASA to take a route for an established VPN, and populate/inject that route into the routing table of other devices in it’s routing group.

In the example below, on the main site, we have a Layer 3 switch that’s routing all the 192.168.x.x networks, and we have an established site to site VPN to a remote site. To access the web server at 172.16.1.10 the 192.168.x.x networks need a route to it.

I’m going to use OSPF, (the ASA also supports EIGRP and RIP.)

Solution

1. We already have a site to site VPN, let’s find out what cryptomap it is using.

[box]

Main-GW# show run crypto map
crypto map CRYPTO-MAP 1 match address VPN-INTERESTING-TRAFIC
crypto map CRYPTO-MAP 1 set pfs
crypto map CRYPTO-MAP 1 set peer 123.123.123.60
crypto map CRYPTO-MAP 1 set ikev1 transform-set VPN-TRANSFORM
crypto map CRYPTO-MAP interface outside
Main-GW#

[/box]

2. So in this example it’s called CRYPTO-MAP 1, let’s enable reverse route injection for that crypto map.

[box]

Main-GW# configure terminal
Main-GW(config)# crypto map CRYPTO-MAP 1 set reverse-route

[/box]

3. Now create a ‘prefix-list‘ that contains our remote VPN subnet. (Note: if you had a lot of remote subnets you could add them separately or simply summarise them if they were contiguous networks).

[box]

Main-GW(config)# prefix-list PL-VPN-ROUTES description Route-Map For Injecting Remote VPN Routes
Main-GW(config)# prefix-list PL-VPN-ROUTES seq 5 permit 172.16.0.0/16

[/box]

4. Now create a ‘route-map‘ that uses our prefix-list.

[box]

Main-GW(config)# route-map RM-VPN-ROUTES permit 10
Main-GW(config-route-map)# match ip address prefix-list PL-VPN-ROUTE
Main-GW(config-route-map)# set metric 12000
Main-GW(config-route-map)# set metric-type type-1
Main-GW(config-route-map)# exit
Main-GW(config)# route-map RM-VPN-ROUTES deny 100 

[/box]

5. To be honest you would already have OSPF setup at this point but, for completeness, let’s run through the OSPF setup.

[box]

Main-GW(config)# router ospf 20
Main-GW(config-router)# router-id 192.168.1.1
Main-GW(config-router)# network 192.168.1.0 255.255.255.0 area 0
Main-GW(config-router)# log-adj-changes

[/box]

6. And while still in config-router mode, set it to redistribute our VPN network(s). And finally remember the ASA wont send out any networks, without a default-information originate command.

[box]

Main-GW(config-router)# redistribute static subnets route-map RM-VPN-ROUTES
Main-GW(config-router)# default-information originate

[/box]

7. Save the changes.

[box]

Main-GW# write mem
Building configuration...
Cryptochecksum: 79745c0a 509726e5 b2c66028 021fdc7d

7424 bytes copied in 1.710 secs (7424 bytes/sec)
[OK]
Main-GW#

[/box]

8. To make sure it has worked, on the core switch CORE-SW-01, look at the routing table.

[box]

Core-SW-01#show ip route
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 123.123.123.123 to network 0.0.0.0

O E1 172.16.0.0/16 [110/12011] via 192.168.1.1, 00:00:04, GigabitEthernet0/0
C    192.168.10.0/24 is directly connected, GigabitEthernet0/1
C    192.168.50.0/24 is directly connected, GigabitEthernet0/2
C    192.168.100.0/24 is directly connected, GigabitEthernet0/3
O*E2 0.0.0.0/0 [110/1] via 192.168.1.1, 00:00:03, GigabitEthernet0/0

[/box]

 

Related Articles, References, Credits, or External Links

Cisco ASA 5500 – VPN Reverse Route Injection With EIGRP