I added this new tool that I have been writing on my blog pages linked above (IPv6) and here IPv6-Long-Number-Tool.
The idea was that every time I read about IPv6 they always speak to the astronomically large number of hosts that the new standard provides. 2^128, or 3.4*10^38 or even 340282366920938463463374607431768211456… but you can never truly get the magnitude of that number until you see it spelled out. This tool really is pretty much useless for anything other than a visualization, but I couldn’t find anything like it out on the web, so … I made my own. I may hack it out and modify it more later, but for now I am happy with what it does.
So when we did our voice upgrade about a month ago, we had a problem when we got to the final step of upgrading to 8.6. I just found this article while going through some older content on the blogosphere, and thought…hmmm, why didn’t I see this before?!. Thanks to ‘NetworkingNerd’ (Tom) for putting this one out there (even if it did take me 6 months to find it). http://networkingnerd.net/2011/12/12/moving-to-cucm-8-6-youll-never-upgrade-me-alive-coppers
I have been having some fun with www.he.net and the ipv6 certification. I also completed a free tunnel with www.tunnelbroker.net and setup the connection to the HE ipv6 network on my linksys E4200 router at home via the 6rd Tunnel configuration. More to come, I will get the guru and sage certification soon too.
I would like to send out a big congrats to Kevin Wallace on passing his CCIE Voice Lab on his second attempt!!!! I spoke with Kevin at Cisco Live 2011, and we were both still going for our lab. This video that he just put out describes some strategies that he used to pass. I myself did use the device-based approach, and even the dial-plan idea…but I need to refine them, and practice practice practice.
Most of the upgrade has gone pretty well…but there are those little hiccups that tend to spin your wheels for hours. I thought it would be good to list a couple of the top gotchas on my blog, for anyone else who may be doing migrations from Cisco MCS platforms to the UCS and Vmware environments.
Plan Plan Plan….and then don’t be surprised when you have to change some of that plan on the fly due to unforseen issues.
When you first build a VM with an OVA file so that you can build it out later (say for a subscriber). Make sure the network interface card is still connected to the vlan or physical interface that you need. We had a last minute change of the actual production Vlan number from what was built in our staging lab, and even though we changed it in the Configuration -> networking -> properties tab… it didn’t change the vNic on the VM host…and after 18 hours of building …you can very easily miss something like that and just keep spinning your wheels. Not to mention the poor network admin who was remoted in trying to figure out why traffic wasn’t passing on the etherchannel he built.
If you plan on adding any new subscribers because the new capabilities and licensing allows a more robust design (for no cost) … then make sure the IP’s you pick are not used by anything else….and don’t just take someone else’s word for it…check it yourself.
Speaking of checking yourself, the VLAN numbers from the second bullet could have also been avoided with better planning and double checking.
When you get an error from a subscriber about NTP from the primary not working correctly, be very careful about changing NTP settings. I added a better NTP source server to the Publisher, and the License MAC changed breaking all of our licenses. Now in our case we need the better NTP reference, so we will just have to re-license, but this one could cause hours of headache not knowing why the license is reporting that the Communications Manager will shut down after a 30 day grace period!
Etherchannel configuration into the UCS server. Do your homework, there are ways that work, but it can be a pain if not configured exactly correctly.
Probably the most important is to give yourself time for the upgrade (if at all possible…if not see the first bullet). When you are on hour 18 on the second day….and fatigue is setting in….solutions just don’t come to you as easily. Go home and sleep it off to start again fresh (if you can) and you will find the solutions jump out at you that had eluded you the previous night.
That is all for now, but we are still cleaning some things up right now…so maybe more later. I may do a post on my etherchannel experiences and what does and doesn’t work and why.
So I have been burning the fuel today… we are finally upgrading our systems at work to new UCS platforms, and going from CUCM 7.1 to 8.6.
I am on approx. hour 13, and it is coming together good. Why so long? Well if anyone else out there has done one of these you will know all of the pains in going on a MCS bridge server and upgrading each phase in steps with DRS imports, license uploads, then upgrades…DRS exports..then finally getting to the UCS VM server… well lets just say it is not all quick.
I am excited though, because it has been awhile since we had a full upgrade, and I think this is great learning. I have learned alot about etherchannel configs on the new UCS servers. I am going to post very detailed steps later when all is done, because I think it would be great for anyone else out there that is going to go through the same upgrades.
–More later.
So, I have been pretty preoccupied at work lately trying to solve an engineering problem with a requirement of having a remote operations facility connect in the same broadcast domain as the one in our HQ site. I have tried several designs using L2TPv3 technologies, and even though I got some basic things working, I am still trying to solve how to encrypt across that link. Any ideas from any network guru’s out there would be very much appreciated. Contact me, if you think you can help. I am also really curious about getting this running so that I can connect to my home lab remotely with a layer 2 connection similar to what the CCIE voice lab actually uses. I will keep researching, and when I figure something out, I will post it here for everybody.
Ohhh and Happy Leap year.
Thanks
Now I know that alot of you out there have heard of the Laws being proposed here in the US that could be very detrimental to the whole web community in ways that are very far reaching. I just wanted to take this one little post to say that I do not support SOPA or PIPA, and I am posting this link for everyone else who stumbles on my site to click and join in the fight.
Thanks
So one of the topics that I have had a fair amount of trouble with in the past and even on my first attempt, was Globalization and Localization of calling numbers. I think I have finally mastered at least part of that now. My only gap that I have now is more of a route pattern for international…which I am sure I will figure out soon.
So what is globalization and localization? When a call comes in from the PSTN, it can (and should) be marked as a particular type of call (National, International, subscriber, or unknown). In the ISDN world that is pretty common, and most carrier’s / providers send that information with the call. The way to test and see what type of call is coming in on a particular gateway, is to run a debug isdn q931 command and you should start to see information like the one below in figure 1.1.
FIGURE 1.1
The output of debug isdn q931 with an incoming call shows the plan type for both calling and called numbers. So the next step is to do something with that information. This is where the inbound gateway settings in CUCM come in handy. When you ‘Globalize’ a number, you are making it into a compatible E.164 format number an example from the figure above would be to make the calling number ‘+16178632683′. In this example we have an h.323 gateway, but the same rules would apply if it was an MGCP gateway, just a little different looking window. In the next figure 1.2 you will see the menu which you can make the rules for ‘Globalization’ of inbound numbers.
FIGURE 1.2
Notice that National is prefixing a ‘+1′ to all calling numbers, International is just prefixing a + and subscriber is prefixing a +1617. This would need to be verified by the type of calls coming in and what they display from the carrier. In the example we have below, the number is actually coming in as a ‘National’ number so it only has to prefix a ‘+1′ if it were coming in as a 7 digit ‘subscriber’ call type, then it would have to prefix a ‘+1617′. The display on the phone shows the call coming in in figure 1.3.
FIGURE 1.3
Now the numbers have been “Globalized”… but most people get confused with that number displaying on their phone, especially if they are used to just seeing ’617863XXXX’ . So this is where ‘Localization’ comes into play. Localization is taking that presentation of the E.164 (+) number and making it display back in a local format…now you may be asking, why would I want to do that when I just globalized it, and why globalize it at all then. Well when you ‘Localize’ the number, it just displays as the number is calling, the real trick is that it leaves the Globalized E.164 number in the missed or recieved call directory logs. So when you can make a route pattern later to just dial from any + number and have it route the call automatically. Most numbers that need an outside access code like 9 have to push edit dial once in the directory to call back our from a missed call, this eliminates that need. Figure 1.4 shows a Localized call coming in, and figure 1.5 shows the same missed call from the directory.
FIGURE 1.4
FIUGRE 1.5
(notice this was taken from a 7970 phone…IP communicator does not show the + number correctly in the missed calls directory).
I just read a couple of interesting articles from Matthew Berry, and Chesapeake Netcraftsmen about SQL queries on the CUCM for various data dumps. So as not to repeat too much of what has already been said, I will just post a link to the netcraftsmen page, and pay homage to those who have already done the hard work.
