I've been using IOU Web for network emulation.
"Cloud" device is the bridge between internal devices (such as routers within IOU) and external devices (such as PCs, a real/virtual router outside of IOU, etc.).
I'm not going to get into the details of how to set up VMware network or IOU. There are plenty of documents online about that.
What I'm going to share is the solution to a weird problem.
I wanted to build a simple lab as shown below. Two LAN segments are connected via two routers back-to-back.
NETMAP file and device config as below.
Pretty straight forward, right? But the problem is - I cannot turn on device 1 (LAN1). Notice that device "LAN1" stays in red below which means it's off.
I scratched my head for quite a while. Tried to tweak the parameters, device ID, naming, IOU host, VMware Network Editor. No avail.
Then I looked at the logs and noticed the following:
Why it asked me check the NETMAP file? I don't see any error there. What is "instance"? Why is it not found?
After a little bit research, I realized "instance" is the same as "device". As shown in the diagram above, we have four instances - 1, 2, 3 and 4.
We have problem with instance 1 (LAN1), which is connecting (referencing) instance 2 (R1). If the system was complaining about "instance not found", it can only be 1 or 2.
I also noticed that instance 4 (LAN2) always works. What's the difference between 1 and 4?
It turns out that in NETMAP file (connection definition), the "cloud" device cannot be the preceding one. The "correct" NETMAP should be written like this:
Notice that instead of "1:0/0 2:0/0", I swap them and make it "2:0/0 1:0/0". Then try to start the LAN1 device. There we go:
This seems to be a software bug. But the point is - a good engineer should be able to recognize the pattern from the symptom, perform deductive reasoning, and propose possible solution. :)
Tuesday, September 30, 2014
Tuesday, September 23, 2014
UC 10.5, ESXi 5.5U2, DL380 G5
My home lab has been collecting dust for a while. During the weekend, I wanted to refresh it with the latest and greatest, which means:
1) Upgrade the server (MCS7845-H2 a.k.a. HP DL380 G5) BIOS and firmware.
2) Upgrade VMware ESXi 5.0 to 5.5U2.
3) Upgrade UC 7.0 to UC 10.5.
It turned out that upgrading a system that's been collecting dust is VERY different from upgrading a system that's been up and running.
First of all, the system won't boot. Just gives me long beeps and the "Internal Health" and "External Health" LEDs are both red. Pull all memory chips out and resit them solves the problem.
Then iLO configuration seems to be lost due low power level of the system battery. I can't log into iLO at all (the 'default password' is system specific with unique numbers). Set the "System Maintenance Switch" S1 to "On" bypasses the iLO password.
When trying to upgrade to ESXi 5.5 U2, I got the following error:
I know what it is. But how could this be not enabled while I have ESXi 5.0 on it before? Maybe it's also due to the motherboard battery? Anyway, go into BIOS and enable the "No-Execute Memory Protection".
After ESXi upgrade, I noticed that VMware persuade move from native VM client (based on C#) to "Web Client" (based on Adobe Flash). The initiative is to move from "fat client" to "thin client" so all new features can be hosted on the vCenter server. You may still use the "native client" but some of the features will be missing. Features as basic as editing a version 10 VM settings.
In order to use the "Web Client", you'll have to set up a vCenter server. Also, to view VM console from web browser, you'll need to install a plug-in, which doesn't work with Internet Explorer (as of today).
When installing UCM 10.5, it took extremely long (> 10 hours). Further investigation revealed that the array controller battery died. Without battery, the array controller will disable cache, which makes it very, very slow on a RAID5 (slower than my laptop).
I have multiple options:
Option 1: Order one from eBay. It's not expensive (~ $12 a piece). The problem is - this kind of batteries are obsolete. Thus the ones on eBay are all used ones, which were manufactured a couple years ago. Who knows how long they'll last.
Option 2: Make my own battery like this: http://opensource.wrenhill.com/?p=63. Then I can use cheap AA or AAA batteries instead of buying proprietary ones.
Neither of the above options is quick enough for me. Thus I choose...
Option 3: "Enable Cache Without Battery".
To do this, you'll need ACU (Array Configuration Utility). You can do it with the ROM-based interface (BIOS).
With VMware ESXi, the easiest way is to download the "offline ACU", which is a CD you boot from. Then configure the array controller from there.
For a RAID, it's the write operation that takes more time. Thus you want to make sure the write cache is not zero.
Last but not the least, download HP SPP DVD to update all firmwares and BIOS.
P.S. DHCP doesn't work on UCM 10.5 in case you want to use UCM as a DHCP server. https://supportforums.cisco.com/discussion/12224526/cucm-105-dhcp-not-working
1) Upgrade the server (MCS7845-H2 a.k.a. HP DL380 G5) BIOS and firmware.
2) Upgrade VMware ESXi 5.0 to 5.5U2.
3) Upgrade UC 7.0 to UC 10.5.
It turned out that upgrading a system that's been collecting dust is VERY different from upgrading a system that's been up and running.
First of all, the system won't boot. Just gives me long beeps and the "Internal Health" and "External Health" LEDs are both red. Pull all memory chips out and resit them solves the problem.
Then iLO configuration seems to be lost due low power level of the system battery. I can't log into iLO at all (the 'default password' is system specific with unique numbers). Set the "System Maintenance Switch" S1 to "On" bypasses the iLO password.
When trying to upgrade to ESXi 5.5 U2, I got the following error:
I know what it is. But how could this be not enabled while I have ESXi 5.0 on it before? Maybe it's also due to the motherboard battery? Anyway, go into BIOS and enable the "No-Execute Memory Protection".
After ESXi upgrade, I noticed that VMware persuade move from native VM client (based on C#) to "Web Client" (based on Adobe Flash). The initiative is to move from "fat client" to "thin client" so all new features can be hosted on the vCenter server. You may still use the "native client" but some of the features will be missing. Features as basic as editing a version 10 VM settings.
In order to use the "Web Client", you'll have to set up a vCenter server. Also, to view VM console from web browser, you'll need to install a plug-in, which doesn't work with Internet Explorer (as of today).
When installing UCM 10.5, it took extremely long (> 10 hours). Further investigation revealed that the array controller battery died. Without battery, the array controller will disable cache, which makes it very, very slow on a RAID5 (slower than my laptop).
I have multiple options:
Option 1: Order one from eBay. It's not expensive (~ $12 a piece). The problem is - this kind of batteries are obsolete. Thus the ones on eBay are all used ones, which were manufactured a couple years ago. Who knows how long they'll last.
Neither of the above options is quick enough for me. Thus I choose...
Option 3: "Enable Cache Without Battery".
To do this, you'll need ACU (Array Configuration Utility). You can do it with the ROM-based interface (BIOS).
With VMware ESXi, the easiest way is to download the "offline ACU", which is a CD you boot from. Then configure the array controller from there.
For a RAID, it's the write operation that takes more time. Thus you want to make sure the write cache is not zero.
Last but not the least, download HP SPP DVD to update all firmwares and BIOS.
P.S. DHCP doesn't work on UCM 10.5 in case you want to use UCM as a DHCP server. https://supportforums.cisco.com/discussion/12224526/cucm-105-dhcp-not-working
Subscribe to:
Posts (Atom)