Category: Virtualization

New Additions to My Home Lab: HP MicroServer & Synology NAS

March 14, 2015 / anas / 2 Comments

I have been preparing for my VMvware Certified Professional (VCP) exam. Early this year I decided to invest and buy HP ProLiant MicroServer G8 and Synology DS414slim NAS appliance to expand my home lab.

I’m one on those who learn better by doing rather than reading and I wanted to rely on practice labs and hands-on experience instead of books and practice tests to pass the exam.

I bought everything from newegg.com. The HP MicroServer came with 8GB of RAM installed. I then upgraded the RAM to 16GB and downloaded the ESXi 5.5 ISO directly from the HP website which comes with all the drivers required to run ESXi on HP ProLiant servers.

I’m running few VMs on the HP server including the VMware vCenter Server Virtual Appliance (vCSA) which manages my ESXi servers. The HP server is one of two ESXi servers I have running. The other ESXi server runs inside VMware Fusion (nested) on my iMac. Because my HP server and iMac desktop have two different CPU architectures, I had to enable VMware Enhanced vMotion Compatibility (EVC) to provide CPU compatibility and support for vMotion and DRS.

I populated the Synology appliance with two SSDs configured in RAID 1. On it, I have a datastore configured that provides NFS storage to my VMs. I also store there all of my ISOs and OVA files.

I’m happy so far with both devices. The HP MicroServer is relatively quiet compared to other devices I have seen. In terms of noise the HP MicroServer fan generates on average 40 dB-A of noise (equivalent to the noise which a fan of Dell Latitude laptop would put out) according to my iPhone noise meter. The Synology NAS appliance is also pretty quiet. Its fan comes on for few seconds only when the CPU is doing heavy processing. I keep both devices in my home office, which is where I do most of my work.

One thing I wanted to do was to schedule automatic shut down at night to save power. So I searched online for a script to do so but the problem I ran into was that in vSphere 5.5 the host had to be put into maintenance mode before it could shut off gracefully. That meant that the server would come up as a result in maintenance mode when it powered back on and I would need to intervene and take it out of maintenance mode every time.

After experimenting with few ESX CLIs and with some help from the online community I came up with the following Apple script (hack) which basically shuts down the powered on VMs, puts the host in maintenance mode and then issues a shut down command with a delay of 10 seconds. Before the delay timer expires the script executes another command (last command below) and takes the host out of maintenance mode. When the delay timer finally expires the host gracefully shuts down.

do shell script “ssh -i sshkey [email protected] vim-cmd vmsvc/power.shutdown 1”

do shell script “ssh -i sshkey [email protected] esxcli system maintenanceMode set -e true -t 0″

do shell script “ssh -i sshkey [email protected] esxcli system shutdown poweroff -d 10 -r Shell”

do shell script “ssh -i sshkey [email protected] esxcli system maintenanceMode set -e n -t 0″

From there I scheduled an action in my Apple calendar to launch and execute the script every night.

I will be sharing in future posts some of the lessons I have learned during my prep journey so stay tuned for that.

Anas

@anastarsha

Additional Information:

– Install VMware ESxi 5.5 on HP ProLiant MicroServer G8

– HP ProLiant MicroServer G8 Links

Share This:

Troubleshooting vMotion Connectivity Issues

September 20, 2014 / anas / 0 Comments

I attended a panel discussion session at VMUG this week. A guy from the audience asked a question on how to troubleshoot connectivity issues after moving a VM. The guy had a one flat VLAN with one IP subnet and every time he vMotioned a VM to another host, users lost connectivity with that VM.

To answer his question, a guy on the stage advised him to recreate another VLAN/IP subnet, move that VM to the newly created subnet, and then try to do the vMotion again.

Well obviously that wasn’t a good advice and changing the VM IP address in this case would not help. In this post I will explain what happens when a VM moves and steps you can take to troubleshoot network delay and connectivity issues related to vMotion.

First before you do any vMotion, ensure that the VLAN is configured on all switches and allowed on all necessary trunk ports in the network. You can use the commands show vlan and show trunk to verify that that.

When you create a new VM, the host allocates and assigns a MAC address to that VM. The physical switch which the host is connected to eventually learns the VM MAC address (that happens when the VM ARPs for its gateway, starts sending traffic and the switch sees that traffic, or when the Notify Switches in vSphere option is tuned on).

When a VM moves to another host (the new host could be either connected to another port or the same physical switch or connected to a different switch), somebody has to tell the network to change its destination port for that MAC address in order to continue to deliver traffic to that VM. In vSphere that is usually handled by the host when the “Notify Switches” option is turned on. The host in this case notifies the network by sending several RARP messages on behalf of the VM to ensure that the upstream physical network updates its MAC table.

So the first step in troubleshoot this specific issue is to ensure that the “Notify Switches” settings is set to Yes before you vMotion the VM. In vSphere 5.5 you would go to the vSwitch/vDS settings and then to Teaming and Failover to verify the setting.

If that does not help, try to do the followings:

On the physical switch (the switch the destination host is connected to), issue a command to look up MAC table and find out which destination port the switch is using to reach the VM. On a Cisco Catalyst switch, you can use the “show mac address-table” command for example. If the switch is still using the old MAC-to-port mapping, then it’s either that the switch is not reaching the RARP notification from the host or the host itself is not sending it.

If you don’t do anything to correct the problem, the aging timer for that MAC address on the switch (default is set to 5 mins on Cisco switches) will eventually expire and the switch will learn the MAC address via the new port but to speed things up you can alway flush out the VM MAC address from the switch MAC table (clear mac address-table on Cisco catalyst).

Obviously having to manually intervene and troubleshoot every time you move a VM defeats the whole purpose of vMotion. vMotion is supposed to do live migration of a VM and preserves all active network connections during the process. But hopefully the above steps will give you some pointers on where to look and start to find the root cause.

Additionally VMware recommends disabling the followings on the physical ports connected to the host to minimize networking delay:

– Port Aggregation Protocol (PAgP) and Link Aggregation Control Protocol (LACP).

– Dynamic Trunking Protocol (DTP) or trunk negotiation.

– Spanning Tree Protocol (STP).

Share This:

Deploying Secure Hybrid Cloud Extension Using LISP For Workload Mobility – Part 2

August 20, 2014 / anas / 0 Comments

This post assumes a working knowledge of Locator/ ID Separation Protocol (LISP), you may first want to review Part 1 before reading through this post.

In Part 1 we created two LISP sites and enabled connectivity between these two sites. We also enabled VM mobility and showed how you can migrate a VM to the cloud without changing its IP address, mask, or default gateway.

In this post I will expand on Part 1 and enable connectivity between non-LISP and LISP sites. As shown in the diagram below I have a branch office (non-LISP site) which needs to reach the VM (IP address 10.122.139.91) in the cloud.

LISP2

To do so we have three design options…

Option 1 is to enable LISP on the branch edge router. In this design traffic leaving the branch will be redirected by the branch edge router to the cloud however this option is costly and requires deploying a router with LISP support on each branch router.

Option 2 is to deploy a LISP proxy router in the service provider WAN to intercept traffic and re-direct it to cloud. This option is less expensive than option 1 but requires routing all traffic thru the proxy router which could cause this router to become a choke point.

Option 3 is to configure the already LISP-enabled router in the data center as proxy which will redirect traffic to the cloud. This is the least expensive option but obviously does not provide optimal routing as you need to backhaul traffic to the data center first, however this might be acceptable design when local internet access is not available at the branch and internet-bound traffic needs to traverse the data center anyway or when the customer wants the traffic from the branch to traverse the data center firewall first for policy enforcement.

In this post I will show you what you need to do to enable option 3.

To add the proxy functionality to the design, first we need to configure CSR1 as Proxy Tunnel Router (PxTR) which tells CSR1 to intercept the traffic coming from any non-LISP site and redirect it to the cloud:

CSR_1#sh run | i ipv4

no ipv4 itr

ipv4 proxy-etr

ipv4 proxy-itr 1.1.1.1

Now if I run a show command I can see that CSR1 is configured as PxTR:

CSR_1#sh ip lisp

Instance ID: 0

Router-lisp ID: 0

Locator table: default

EID table: default

Ingress Tunnel Router (ITR): disabled

Egress Tunnel Router (ETR): enabled

Proxy-ITR Router (PITR): enabled RLOCs: 1.1.1.1

Proxy-ETR Router (PETR): enabled

The second step is to configure CSR3 to use CSR1 as its default proxy ETR (PETR). This is necessary as CSR3 is not going to know how to get back to the source 2.2.2.2 since this prefix is not a LISP entry and does not exist in its cache table.

CSR_3# show run | b lisp

router lisp

ipv4 use-petr 1.1.1.1

Now let’s run a ping test from R2 (2.2.2.2) to see if we can reach the VM:

R2#ping 10.122.139.92 source 2.2.2.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.122.139.92, timeout is 2 seconds:

Packet sent with a source address of 2.2.2.2

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 48/51/63 ms

Comment below if you have any questions. Also please help me spread out the word if you like this post and share with your network on Twitter/Facebook/Linkedin.

Anas

Twitter: @anastarsha

Share This:

Deploying Secure Hybrid Cloud Extension Using LISP For Workload Mobility – Part 1

August 2, 2014 / anas / 2 Comments

There are times when you want to leverage public cloud but want to keep some workloads in your data center. You can do that with Hybrid Cloud.

According to Gartner the most important use case for Hybrid Cloud is cloud bursting. That’s running the workloads internally in the data center and bursting to a public cloud during peak times. The other common use cases for hybrid cloud is disaster recovery where you migrate the workloads to a public cloud during disasters or maintenance windows.

Migrating a workload to the cloud is time consuming especially if you have to re-IP all the VMs.

In this post I will show how to migrate an application to the cloud without changing its IP address, mask, default gateway, or security policies. This makes the migration easier especially if you are migrating the workload temporarily and do not want to change the IP addresses or DNS settings.

Why I Like This Solution

You can certainly enable workload mobility between two data centers using a Layer 2 extension technology such as VPLS or Cisco OTV. However I prefer LISP over any L2 extension simply because it’s based on Layer 3 and therefore does not exntend the broadcast/failure domain like L2 extensions and you get all the benefits and scale of L3 routing.

I also think that using LISP is better than relying on any cloud extension technology like Cisco Nexus 1000v InterCloud or Verizon CloudSwitch because those technologies add a shim layer to allow the VM to run in a cloud provider environment and that degrades the VM performance. With this LISP design the VM runs natively on the hypervisor and behaves like any VM local to the cloud provider environment.

Prerequisites

– To get this solution to work to you need two Cisco routers that support Locator/ID Separation Protocol (LISP). The data center router can be either virtual or physical while the cloud provider router has to be virtual. I will be using here two Cisco CSR 1000v routers running IOS XE 3.12S for this solution.

– I will briefly explain how LISP works along the way and will be focusing only on the required components for this design. You can find more information on LISP on Cisco.com

– I will be using Verizon Terremark as my cloud provider. You may use other providers like Microsoft Azure or AWS if you wish.

Before The Migration

The diagram above shows a VM running in a data center/private cloud with IP address 10.122.139.92. The default gateway for this VM is currently CSR-1 and from the outside DNS resolves to the VM public IP address which is part of the data center addressing scheme. Now because CSR-1 is a LISP enabled router and because it’s also acting as a LISP map-server/map-resolver, it will cache the VM IP address in its database so it can inform other LISP routers about the VM location when asked.

In the cloud provider, CSR-3 is also a LISP enabled router and configured to query CSR-1 for any hosts trying to reach. So if CSR-3 receives any traffic destined for the VM it queries CSR-1 for the location of that VM. CSR-1 replies back to CSR-3 and tells it to encapsulate and send all traffic designed for the VM to him because the VM is located on its LAN.

The output below shows that the VM is located on CSR-1 local subnet at the moment:

CSR_1#sh ip lisp forwarding eid local

Prefix

10.122.139.92/32

The next output below shows that CSR-1 (1.1.1.1) is currently the locator for the VM:

CSR_1#sh ip lisp data

LISP ETR IPv4 Mapping Database for EID-table default (IID 0), LSBs: 0x1, 2 entries

10.122.139.92/32, dynamic-eid Cloud-dyn, locator-set DC1

Locator Pri/Wgt Source State

1.1.1.1 1/100 cfg-addr site-self, reachable

On CSR-3 if I issue “where is the VM” command I see that CSR-1 (1.1.1.1) is currently the locator:

CSR_3#lig 10.122.139.92

Mapping information for EID 10.122.139.92 from 10.0.20.1 with RTT 49 msecs

10.122.139.92/32, uptime: 00:02:28, expires: 23:59:59, via map-reply, complete

Locator Uptime State Pri/Wgt

1.1.1.1 00:02:28 up 1/100

That’s good. Both routers are in sync and know that the VM is located in the data center. Let’s now migrate this bad boy to the public cloud.

After the Migration

Now the VM has migrated (cold migration) to public cloud as shown in the diagram above. When the VM boots up of the first time it will ARP for its default gateway (which is CSR-3 in this case). When CSR-3 detects that the VM is now on its LAN it registers it with the map-server (CSR-1) and declares itself as the new locator for that VM. Now the DNS mapping for the VM has not changed and the outside world still thinks that the VM resides in the enterprise data center. So when CSR-1 receives traffic destined for that VM it does a lookup in its database, encapsulates the traffic, and sends it to the new locator (CSR-3) which in turn decapsualtes the traffic and sends it off to the VM.

Now back to the router CLI. If I issue the “where is the VM now” command again, I see that CSR-3 (3.3.3.3) is now the locator:

CSR_1#lig 10.122.139.92

Mapping information for EID 10.122.139.92 from 10.0.20.3 with RTT 48 msecs

10.122.139.92/32, uptime: 00:02:27, expires: 23:59:59, via map-reply, complete

Locator Uptime State Pri/Wgt

3.3.3.3 00:02:27 up 1/100

If I ping the VM from CSR-1 sourcing my packets from the LAN interface, the ping is successful:

CSR_1#ping 10.122.139.92 source loopback 10

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.122.139.92, timeout is 2 seconds:

Packet sent with a source address of 10.10.10.1

.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 47/47/48 ms

Conclusion

LISP allows migrating workloads to the cloud without relying on L2 extensions. Use this design if you are migrating your workload temporarily. If you are migrating the workload permanently you might want to consider adding a LISP router at the WAN edge or at the branch office to redirect user traffic to the public cloud provider before its enters the enterprise data center.

Ping me if you want the full configurations.

Part 2 of this post is coming soon, make sure to subscribe to the blog or follow me on Twitter to get notified when new content is added.

Anas

Twitter: @anastarsha

Share This:

Building A New Home Lab – Phase 1

July 20, 2014 / anas / 0 Comments

I have big goals set for this year and one of the things I need to archive these goals is a home lab to train on OpenStack, network virtualization, hypervisor networking, and just virtualization in general. In this post I will be sharing some details on my new home lab which I’m in the process of building.

For me the one thing I was trying to avoid was investing in physical hardware as I don’t have much space at the moment to place the servers. So far I have managed to run everything in Virtual Machine (VM) form factor. However as the lab grows I will probably need to invest in some physical servers.

Few Upgrades First

Before deploying any VMs I had to do some upgrades:

– Upgraded from VMware Fusion 4.0 to 6.0 Professional on my iMac which is 30% faster than 4.0 and supports creating additional virtual networks (similar to Network Editor in VMware Workstation)

– Upgraded my iMac memory from 12GB to 16GB to make room for additional VMs

Spinning Up VMs

I then deployed the following VMs:

– A Cisco CSR 1000v router as an internet gateway where I do packet filtering and run IPSec VPN with my cloud provider.

– 2 x VMware ESXi 5.5 hosts running on Fusion for VM mobility, HA, etc..

– VMware vCener 5.5 server running on Windows 2008 server to mange the two ESXi hosts (I will be also trying the vCenter virtual appliance shortly)

– Windows 7 VM to run the vSphere Client and run other monitoring/debugging tools.

I will be sharing over the next few weeks some interesting use cases I have been working on. Make sure to subscribe to the blog to get notified when I add new content.

Let the fun begin!

Homelab

Share This:

Spin up Cisco CSR 1000v in VMware Fusion in 5 Minutes

July 13, 2014 / anas / 0 Comments

I have been using the Cisco CSR 1000v as a default gateway in my home lab and I run an IPSec tunnel & LISP between it and my cloud provider (more on LISP in a separate post). The CSR 1000v runs on VMware ESXi, Microsoft Hyper-V, and Amazon Xen hypervisors but it can also run on a laptop/desktop hypervisor like VirtualBox or VMWare Fusion for testing or training purposes.

In this post I will show how to spin up a CSR 1000v instance in VMware Fusion for Mac.

Requirements:

1) I’m running VMWare Fusion 6.0 Professional but you can also run this virtual router on Fusion 4 or 5. I highly recommend using Fusion 5 Professional or 6 Professional if you want to create additional networks and assign the CSR 1000v interfaces to those networks. The feature to add additional networks (similar to Network Editor in VMWare Workstation) was added by VMWare in Fusion 5 Professional and it’s not available in the standard edition of Fusion. Alternatively if you don’t want to pay the extra bucks for the Professional edition, you can use this free tool from Nick Weaver to create the networks if you are running the standard edition. Nick’s tool isn’t the best but it does the job.

2) Go to Cisco and download the latest and greatest software version of the CSR 1000v. The CSR runs Cisco IOS XE and you need to download the OVA package for the deployment.

Installation:

The installation process is simple and quick:

1- Launch Fusion and go to File -> New from the top bar menu

2- Once the Installation wizard starts click on More options. Select Install an existing virtual machine and click Continue.

3- On the next screen click Choose File. Navigate to the folder containing the OVA package, select the file, and click Open and then Continue.

4- The next window will ask you to save the VM name, choose a name and click Save.

5- The final step of the wizard is to either customize or click fire up the VM. The CSR 1000v by default comes with three interfaces. If you need to add more interfaces click on Customize, otherwise click Finish.

Finish

6- Once you click Finish, the CSR 1000v will boot a couple of times and then you will be in traditional Cisco router User Mode.

Interfaces Management:

Enter Exec mode and enter “show ip int bri” to see the three interfaces.

By default interfaces will become part of the Ethernet or WiFi network (that’s done by Fusion) depending on which adapter is active during the installation and you can assign from here IP interfaces and default gateway.

If you wish to put the interfaces on separate networks (VLANs), select the CSR VM and go to Virtual Machine -> Setting and choose the desired Network Adapter. You may also create custom networks by going to VMWare Fusion -> Preferences -> Network. From there add the + sign to add additional network and choose wether to enable DHCP or not.

Activating The License

In order to enable the full features of the CSR 1000v, you need to purchase a license from Cisco. If you want to try the full features before purchasing, Cisco offers 60 day free trial license. To activate the free trial license, go into the router configuration mode and enter: license boot level premium. You will be asked to boot the router after you enter the command.

Share This:

How to Deploy Cisco Cloud Services Router (CSR) 1000v on Verizon Terremark Cloud

March 21, 2014 / / 3 Comments

Note: This post is obselete. There is easier way now to install the Cisco CSR 1000v on Verizon Cloud. This link describes how to quickly spin up an instance.

The Cisco Cloud Services Router (CSR) 1000v is Cisco’s first virtual router and it runs as a VM on x86 virtualized server. The CSR 1000v runs Cisco IOS XE and brings many benefits to a cloud environment where it can operate as a secure VPN gateway to terminate site-to-site IPSEC tunnels. Other use cases of the CSR 1000v include MPLS WAN termination and control & traffic redirection. You can find more information n this virtual router on the Cisco CSR 1000v page.

In this post I’m going to show you how to install the CSR 1000v on the Verizon Terremark eCloud. If you are not familiar with the Verizon Terremark cloud console, you can go here for some video tutorials.

Download A Free Trial Image

Go to the Cisco Download Center and log in using your Cisco credential. Select the latest software release from the left pane and then download the .iso package from the right pane to your desktop. Don’t download the OVA or BIN packages. This free trial should be good up to 6 months.

You can purchase a license from Cisco and upgrade to a full version after you install the CSR.

Create the VM

Go over to the Verizon Terremark Enterprise Cloud (eClould) page and log in using your credential.
The first step here is to create a blank server. A blank server is just a container inside the VMware environment that will hold the Cisco IOS later. So go to Devices -> Create Server -> Blank Server to launch the wizard.

On the next screen select Linux for the OS Family, Other 2.6x Linux (64-bit) for the Version. Give the server a name and a description (optional). Then choose an INT network and choose in which Row and Group you want to place the router.

On the next screen choose 4 or more for the Processors and 4096 MB or more for Memory.

On the next screen enter 8 for the Disk size or choose a Detached Disk that’s at least 8GB. Click Next.
From the next window you can optionally assign tags or just click Next if you don’t want any tag.
On the next window review your configurations, check the Agreement box, and click Deploy. Give it about 2 minutes and the server should be ready. If you go to the row and group where you placed the router you should see a greyed out icon (powered off) there.
If you recall we attached only one network to the server earlier, however the CSR requires a minimum of 3 interfaces to run so next we are going to create two additional networks and attach them to the blank server. Right click on the server and go to Configure to launch the wizard.
On the next screen choose Configure the Server and click Next.
On the next screen click on Network Settings from the top. At this point you should see only one INT network under the Current Connection. Click Add a Connection from the top right to add a new DMZ Network.
Go click again on Add a Connection and this time choose an INT network (INT_XXX). Choose a unique INT network different from the one you have used when you created the blank server. Click Save.

Now the VM will take a minute or so to reconfigure itself.

Once the wheel stops spinning and VM is ready, right click on it and go to Power On. Powering on this VM should take a minute or so and while the machine is powering on an icon with gear spinning is presented. The greyed out icon should turn into an icon with “blue light” once the server is completely powered on.

Console to the VM

In order to console to the blank server you must VPN first and use the VMware remote console plugin in Firefox or Internet Explorer to connect to the server for the first time. So for the following steps make sure you are using either Firefox or IE. Once the CSR is up and running you can switch back to your favorite browser or use a Telnet/SSH client to connect it directly instead of using the console.

Click on the VPN Connect link from the top of the page. This will install the Cisco AnyConnect Mobility Client on your machine if you don’t already have it and connect you via secure SSL VPN to eClould. If the browser prompts you to install any Java or ActiveX plugin during this step make sure to accept.

Now click on the router icon and then click on Connect from the bottom pane. This will start installing the VMware remote console plugin if it’s not already installed on your machine and will connect you to the server console to install the CSR.
By now you should see “Operating system not found” message on the console screen. Go to Devices-> CD/DVD drive -> Connect to Disk Image File ISO. This will open a new window for you to locate the ISO package.
Select the ISO package from your local machine and click OK. The system will start uncompressing/unzipping the package and installing software. Depending on the file size and your network speed this process may take up to 2 or 3 hours. Come back in 3 hours to check on the install process. If the console session times out, reconnect again as you did previously.
Once the CSR is successfully installed, you should see the traditional Cisco router prompt and you can then log in and start configuring it.

Assigning IP Addresses

In this section we will assign IP addresses to the CSR 1000v interfaces. When we created the VM we added 3 interfaces for the CSR 1000v to use (INT_XXX, DMZ_XXX, and INT_XXX). Each CSR interface will map to a logical vNIC assigned by the VMware hypervisor. The vNIC in turn is mapped to a physical MAC address.

The following steps are very important and you should not begin configuring any features on the CSR 1000v before you execute all of them.

First we need to find the CSR interface to vNIC mappings so go ahead and create the following table on a piece of paper. You will be populating its fields along the way:
NIC ID Network MAC CSR Interface IP/Mask Default Gateway
1 (eth0) INT
2 (eth1) DMZ
3 (eth2) INT

Log in to the CSR console and issue the following command:
show platform software vnic-if interface-mapping

You should see three interfaces with their vNIC and MAC addresses mapping. If you are running IOS XE 3.10S or earlier the first interface from the top should be GigabitEthernet0 and it’s the management interface. On the other hand if you are running 3.11S or higher the first interface is usually GigabitEthernet1. Start populating the table you have created n the previous step with the information from the command you just executed (IP information will come in the next steps) .
Go back to the eClould portal, click on the router and go then to Administrative Tasks -> Manage PIs
From the Networks section, click on the drop-down menu and select your DMZ network. Then from the left pane Available IPs select one IP address and click on the right green arrow to assign it to the server. Click Save.
Repeat the previous step to assign IP addresses for the INT (internal) interfaces.
Go back to the table and fill out the IP addresses, mask, gateway sections before you move on.
Now that you have the IP addresses, masks, and interface mappings start configuring the DMZ and INT interfaces of the CSR by issuing the following commands for each interface:
config t
int gX
ip add <ip> <mask>
description <Outside or LAN interface>

Configure A Default Route

The final step here is to assign a default route so that the CSR can reach the internet. The CSR must use the DMZ default gateway to reach the internet because only the DMZ network can reach the internet because the INT networks are not visible from the outside. So copy from the table you have created the default gateway IP address for the DMZ network.
Go back to the CSR console and issue the following commands. Make sure that you replace the text in italic with the IP address of the default gateway

config t

ip route 0.0.0.0 0.0.0.0 <DMZ_Default_gateway>

end

write mem

Try now pining the default gateway, you should get a response:

ping <DMZ_default_gateway>

At this point, the CSR should be able to reach the internet. Issue the following ping to make sure:
ping 8.8.8.8
If you don’t get a response then something is wrong and you should revisit the previous steps.

Share This:

Private VLAN and How It Affects Virtual Machine Communication

March 16, 2014 / / 0 Comments

Private VLAN (PVLAN) is a security feature which has been available for quite some time on most modern switches. It adds a layer of security and enables network admins to restrict communication between servers in the same network segment (VLAN). So for example let’s say you have an Email and Web servers in the DMZ in the same VLAN and you don’t want them to communicate with each other but still want each server to communicate with the outside world. Obviously one way to prevent the servers from talking directly to each other is to place each server in a separate VLAN and apply ACLs on the firewall/router preventing communication between the two VLANs. This solution though requires using multiple VLANs and IP subnets. It also requires you to re-IP the servers in an existing environment. But what if you are running out of VLANs or IP subnets and/or re-IPing is too disruptive? Well then you can use PVLAN instead.

With PVLAN you can provide network isolation between servers or VMs which are in the same VLAN without introducing any additional VLANs or having to use MAC access control on the switch itself.

While you can configure PVLAN on any modern physical switch, this post will focus on deploying PVLAN on a virtual distributed switch in a VMware vSphere environment.

But first let me explain briefly how PVLAN works. The basic concept behind Private VLAN (PVLAN) is to divide up the existing VLAN (now referred to as Primary PVLAN) into multiple segments , called secondary PVLANs. Each Secondary PVLAN type then can be one of the following:

Promiscuous: VMs in this PVLAN can talk to any other VMs in the same Promiscuous PVLAN or any other secondary PVLANs. On the diagram above, VM E can communicate with A, B, C, and D.
Community: VMs in this secondary PVLAN can communicate with any VM in the same Community PVLAN and it can communicate with the Promiscuous PVLAN as explained above. However VMs in this PVLAN cannot talk to the Isolated PVLAN. So on the diagram, VM C and D can communicate with each other and communicate also with E.
Isolated: A VM in this secondary PVLAN cannot communicate with any VM in the same Isolated PVLAN nor with any VM in the Community PVLAN. It can only communicate with the Promiscuous PVLAN. So looking at the diagram again, VM A and B cannot communicate with each other nor with C or D but can communicate with E.

There are few things you need to be aware of when deploying PVLAN in a VMware vSphere environment,:

PVLAN is supported only on distributed virtual switches with Enterprise Plus license. PVLAN is not supported on a standard vSwitch.
PVLAN is supported on vDS in vSphere 4.0 or later; or on Cisco Nexus 1000v version 1.2 or later.
All traffic between VMs in the same PVLAN on different ESXi hosts need to traverse the upstream physical switch. So the upstream physical switch must be PVLAN-aware and configured accordingly. Note that this required only if you are deploying PVLAN on s vSphere vDS since VMware applies PVLAN enforcement at the destination while Cisco Nexus 1000v applies enforcement at the source and therefore allowing PVLAN support without upstream switch awareness.

Next I’m going to demonstrate how to configure PVLAN on VMware vDS and Cisco Nexus 1000v. Stay tuned for that. In the meantime feel free to leave some comments below.

Share This:

Category: Virtualization

New Additions to My Home Lab: HP MicroServer & Synology NAS

Troubleshooting vMotion Connectivity Issues

Deploying Secure Hybrid Cloud Extension Using LISP For Workload Mobility – Part 2

Deploying Secure Hybrid Cloud Extension Using LISP For Workload Mobility – Part 1

Building A New Home Lab – Phase 1

Spin up Cisco CSR 1000v in VMware Fusion in 5 Minutes

How to Deploy Cisco Cloud Services Router (CSR) 1000v on Verizon Terremark Cloud

Private VLAN and How It Affects Virtual Machine Communication

Follow me

Search this blog

Subscribe to my blog

Recent Posts

Categories

Menu

Follow me

Search My Blog

NIC ID	Network	MAC	CSR Interface	IP/Mask	Default Gateway
1 (eth0)	INT
2 (eth1)	DMZ
3 (eth2)	INT

Follow me

Search this blog

Subscribe to my blog

Recent Posts

Categories

Tags

Menu

Follow me

Search My Blog