Cisco 800 series Wireless routers: Wireless and Ethernet on the same IP subnet

twade — Tue, 21 Jul 2009 17:23:50 +1000

For a recent customer install of our point of sale products Amicus Retail (POS) and Amicus PDA. The customer requested that the wireless and Ethernet interfaces sit on the same IP subnet.

Normally the 800 series routers are configured with NAT between the WAN and VLAN interfaces, for this setup NAT will be performed between the WAN and a bridging interface. This then allows the VLAN and wireless interfaces to be bridged via this bridging group, thus both interfaces can be placed on the same IP subnet.
The Cisco router used in this example is an 877W router, which has an ADSL interface for itâ€™s WAN Connection. The configuration for other routers in the wireless 800 series range will follow a similar process for the VLAN, Wireless and bridging interfaces, but the WAN interfaces will be model specific.

Configuration of the ADSL dialer interface:
This interface is configured as the external interface for NAT via the â€œIP Nat outsideâ€ command.

Interface Dialer0
Ip address negotiated
Ip mtu 1452
Ip nat outside
Ip virtual-reassembly
Encapsulation ppp
No ip route-cache cef
No ip route-cache
Dialer pool 1
Dialer-group 1
No cdp enable
Ppp authentication chap pap callin
â€¦

Configuration of Bridging
The Bridging interface has been configured as the internal NAT interface via the command â€œip nat insideâ€.
It also has been configured with an IP address via the â€œ IP address A.B.C.D â€œ; this IP address will be the default gateway for all devices attached to the router.
Other relevant commands are listed below:
â€œBridge irbâ€: enables IRB on router.
â€œBridge 1 protocol ieeeâ€: enables bridging on the router.
â€œBridge 1 route IPâ€: enables routing of all IP protocol packets

Bridge irb
â€¦
Bridge 1 protocol ieee
Bridge 1 route ip
!
Interface BVI1
Ip address 192.168.1.1 255.255.255.0
Ip nat inside
Ip virtual-reassembly
!

Configuration of VLAN interface
This interface has been configured with no IP address and as a member of the bridging group via the commands â€œno ip addressâ€ and â€œbridge-group 1â€.

!
Interface Vlan1
No ip address
Ip virtual-reassembly
Bridge-group 1
Bridge-group 1 spanning-disabled
!

Configuration of the Wireless Interface
This interface has been configured as a member of the bridging group via the bridge-group commands listed in the configuration below.

!
Interface Dot11Radio0.1
Encapsulation dot1Q 1 native
No snmp trap link-status
No cdp enable
Bridge-group 1
Bridge-group 1 subscriber-loop-control
Bridge-group 1 spanning-disabled
Bridge-group 1 block-unknown-source
No bridge-group 1 source-learning
No bridge-group 1 unicast-flooding
!

Dual ADSL Connections in one Cisco router

twade — Fri, 07 Aug 2009 16:28:11 +1000

Recently a POS customer wanted to install another ADSL connection at one of their main sites. They wanted this second connection in order to segment some internet connected services off their old connection and onto the new ADSL connection, as these services where saturating the old connection on uploads. Quality of service (QOS) was discussed, but was rejected on the basis that these services really needed the majority of the upload speed available in order to function correctly. Given the requirements listed by the Customer we drafted some solutions with various levels of redundancy and price tags. As our they wanted to keep the solution cost low and were not concerned by redundancy they chose the cheapest option, which was to purchase another ADSL Card and utilise it in their current Router.

The Configuration to allow this single router, two ADSL cards was based on Ciscoâ€™s implementation of â€œpolicy based routingâ€.

The ADSL cards where configured as normal, the first was configured as â€œdialer interface 0â€ and the second was configured as â€œdialer interface 1â€. For this example Dialer 0 has the subnet 192.168.10.0/24 routed to it by the ISP and dialer 1 has subnet 192.168.11.0/24 routed.

The route-maps for policy based routing were configured as follows:

Route-map PBR permit 10
Match ip address 110
Set interface Dialer0
Route-map PBR permit 20
Match ip address 111
Set interface Dialer1
The ACLâ€™s 110 and 115 are show below:
Access-list 110 deny ip 192.168.10.0 0.0.0.255 192.168.11.0 0.0.0.255
Access-list 110 permit ip 192.168.10.0 0.0.0.255 any
Access-list 111 deny ip 192.168.11.0 0.0.0.255 192.168.10.0 0.0.0.255
Access-list 111 permit ip 192.168.11.0 0.0.0.255 any
The access-lists where configured to allow traffic to flow between the two subnets without having to traverse either ADSL connection.

VMware VCenter Server: Basic Installation

twade — Tue, 08 Sep 2009 09:59:36 +1000

We got our Licences from VMware this week; and the first cab of the ranks was installing VCenter Server. As with all VMware products the documentation was bountifully and the installation process was painless. After the recent P2V migration of our Amicus POS test lab equipment we have a few spare physical servers around the office, so we picked a medium specification server from the bunch to host the server install. During the planning phase we also decided to host the database for VCenter on a separate SQL server, rather than the default setup of a local SQL express installation. The default install utilising SQL express is recommended for environments containing less than 50 virtual machines spread over a maximum of 5 hosts, our testing environment alone almost exceeds this.

When installing VCenter Server, we created a domain account to run the VCenter service, this account was also given local administrator privileges on the host server. I also found it best to run through the entire VCenter install process whilst logging on as this service account, I also created the 32bit DSN using this account, as we where installing VCenter on a 64bit OS a 32bit DSN was created using â€œ[WindowsDir]\SysWOW64\odbcad32.exeâ€.

P2V from Hyper-V to VMware ESX using VMwareâ€™s Convertor 4

twade — Fri, 28 Aug 2009 16:36:29 +1000

During the last week, we have been busy migrating our POS test VMâ€™s from a mixed Hyper-V/VMware server infrastructure to a VMware ESX environment. The majority of our virtual testing environment was run off a single hyper-v server, so the method used for these virtual servers would be P2V, as convertor 4 cannot perform V2V from hyper-v. No such issue with the virtual servers hosted on VMware Server, V2V is supported all the way and worked seamlessly. The P2V migration for the VMs hosted on the hyper-v server also went to plan, with the aid of the tips and caveats listed below.

â€¢ Make sure to edit the â€œDisk Controllerâ€ on view/edit options, it defaults to â€œPreserve sourceâ€. If this option is not changed, the migrated VMâ€™s will fail to detect the virtual HDD on power up.
â€¢ If you select â€œPower on targetâ€ and â€œPower off sourceâ€ on the view/edit option screen, this will lead to both VMs being powered on for a brief period during the final stages of the migration. If you select the option to automatically uninstall the DPM agent from the source VM this period will be extended, as the source VM shutdown will be delayed by the agent uninstall. For our migration I just selected the â€œpower off Sourceâ€ option and manually powered on the target VM once the source had shutdown.
â€¢ Due to the changes in hardware, windows will need to be reactivated after the migration.
â€¢ If you allocate/reserve IPâ€™s by MAC addresses in your DHCP environment, these will need to be reconfigured due to the change in the virtual NIC on the target VM. This change in hardware also affects static IP addresses, so itâ€™s a good to review your server infrastructure documentation prior to migration.
â€¢ We used Ghost 11.5 via Ghostcast to migrate one Windows 2008 core VM, where the agent could not be installed. Ghost 11.5 cannot image to the .sv2i format required by convertor, but it can export to a .vmdk, this can be used to rebuild the VM on ESX by creating a new VM and selecting the â€œExisting Diskâ€ option.

All things considered this was a painless migration, and compared to the looming SharePoint 2007 farm migration, I am actually looking forward to the migration of our production Hyper-v environment to ESX.