Data Center is our focus

We help to build, access and manage your datacenter and server rooms

Structure Cabling

We help structure your cabling, Fiber Optic, UTP, STP and Electrical.

Get ready to the #Cloud

Start your Hyper Converged Infrastructure.

Monitor your infrastructures

Monitor your hardware, software, network (ITOM), maintain your ITSM service .

Our Great People

Great team to support happy customers.

Saturday, October 23, 2010

Selamat kepada Plasa Telkom Pahlawan, Semarang

Selamat atas dipasangnya sistem antrian multimedia di Plasa Telkom Pahlawan, Semarang, Jawa Tengah.

Kami bangga melayani Anda.

Infrastructure-Application-ManagedServices.Visit for details..

Sunday, October 17, 2010

Five ways for IPv6 and IPv4 to peacefully co-exist

By Steven J. Vaughan-Nichols | October 14, 2010, 11:48am PDT

It would have been so easy if the early Internet and TCP/IP network designers had made IPv6 backward compatible with IPv4. They didn't. In 1981, IPv4's 32-bit 4.3 billion addresses look more than enough addresses for the ARPANet/Internet. That was the Internet then, this is the Internet now.

Oh, network professionals saw the Internet address shortage coming and knew it would be a problem. I can't do better than to quote, Leslie Daigle, Chief Internet Technology Officer for the Internet Society, who admitted at a June 2009 meeting that "IPv6's lack of real backwards compatibility for IPv4 was [its] single critical failure." It's too late now to cry over spilled standards. We need to work on getting the two fundamental network standards to peacefully co-operate today.

There are several ways of handling this issue. Let me warn you right now, none of them are perfect, but one, or more of them, should work for your company. Before buying into any of these technologies though you must throughly test Ipv6-to-IPv4 and back again component interoperability before deploying them. There's a lot that go wrong, and you don't want any of it happening during business hours on your production network.

IPv4/IPv6 co-existence can take one of three forms.. One is dual stack, where your network hardware runs IPv4 and IPv6 simultaneously. Next is when you "tunnel" one protocol within another. Usually, this means taking IPv6 packets and encapsulating them in IPv4 packets. The technical basics for these are outlined in the RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. Finally, there's Network Address Translation-Protocol Translation (NAT-PT) aka RFC-2766. This works just like the name says, software or a device translates IPv6 packets into IPv4 packets.

While Network Address Translation (NAT) fans might like this at first glance, it comes with its own set of problems. As Cisco points out in its excellent white paper, "Network Address Translator-Protocol Translator," "The application of each area must be well understood, as the protocol does not represent a generic mechanism that would be universally applicable." In short, you'd better know your way around Application Level Gateways (ALG) if you plan on deploying NAT-PT.

In addition, a core difference between NAT-PT and IPv4 NAT is that address translations must be done for both incoming and outgoing traffic. This can get complicated in a hurry. You could use static, bi-directional mapping, but that will get out of date quickly and it doesn't scale worth a damn. Of course, you could use Domain Name System (DNS), but old-style DNS servers don't support IPv6's AAAA records. And, again, I see real scaling problems as those DNS servers that do support IPv6 get constantly bombarded by address requests.

With Dual-IP stacks, your computers, routers, switches, and other devices run both protocols, but IPv6 will be the preferred protocol. A common procedure is to start by enabling both TCP/IP protocol stacks on the wide area network (WAN) core routers, then perimeter routers and firewalls, followed by your data-center routers and finally the desktop access routers. As the public Internet transitions to IPv6, your network administrators may need to deploy dual-stack capable switches on your; edges earlier.

The upside of this approach is that Dual-IP stacks are supported by all the major operating system and network vendors. The downside is that most legacy networking hardware and servers don't support IPv6. This can lead to such problems as dual-stack edge switches running into DNS (Domain Name Server) problems while users are trying to get to various Internet sites. In addition, many versions of Internet applications, even such commonplace ones as File Transfer Protocol (FTP), won't work with IPv6.

One way to answer these problems is to use Dual Stack Application Level Gateways (DS-ALG) These gateways are commonly used as proxies that translates between the two protocols over the IPv4 Internet.

The bad news with this approach is that it will only work for specific applications. It also has the potential to slow traffic down as every packet has to be inspected to see if it needs DS-ALG services.

In tunneling, one protocol is carrying inside another. Usually, that's going to be IPv6 in IPv4. These tunnels can move your IPv6 packets across both your internal IPv4 WAN and the mainly IPv4 Internet, Someday, when IPv6 becomes the top Internet protocol, we'll use IPv6 tunnels to carry IPv4 traffic.

There are two kinds of tunnels: manual, aka static, and dynamic. Manually configured IPv6 tunneling requires configuration at both ends of the tunnel. The manual approach is best just for connecting say corporate IPv6 intranets over the Internet. It's not a good answer to any other IPv6 Internet problem.

Dynamic tunnels use a variety of techniques to establish packet destination address and routing on the fly. This makes them far easier to create and maintain. I

The most popular dynamic tunneling technique is 6to4. It has the advantage of not requiring an explicit tunnel set-up. Instead, it uses dedicated relay routers to forward encapsulated IPv6 packets over IPv4 links. A significant advantage of 6to4, is that it lets you set up Ipv6/V4 tunnels without requiring a lot of manual effort. 6To4 uses IPv4 unicast to create point-to-point links over the IPv4 backbone for transmission.

To be used safely, your vendor and network engineers must be sure to set its security up carefully. It's all too easy to hide bad traffic inside the encapsulated packets and to spoof addresses within the IPv4 and IPv6 headers, which can lead to Denial of Service (DoS) attacks.

These are some of the most popular ways to get IPv6 and IPv4 on the same network. There are many others. Want to know what the worst news about all of them is? None of them are very compatible with the others. As I've said before, like it or lump it you are going to need to move to IPv6.

In the meantime, you're almost certain to need one, or more, of these technologies in the next few years. Again, Before deploying any IPv4/IPv6 bridging solutions, you're going to need to spend a lot of time having your network engineers and vendors making sure that everything in your new network stacks can interoperate. It' all too easy to mix and match equipment and methods in ways that will slow your network down to a crawl.

I will also add that you must test out the hardware and software before signing off on it. I've already found that a lot of stuff, which says it's IPv6 ready isn't really, but that's a story for another day.
Infrastructure-Application-ManagedServices.Visit for details..

Five ways to be profitable in IT consulting

The last thing any IT consultant wants to do is get caught up in a consulting engagement that costs him lots of time and effort and makes him very little money. It's frustrating, counter-productive, and almost certainly ensures you won't have return business with that customer. In order to safeguard the profitability of the engagement, you need to keep five key things in mind when you're: discussing the project with the customer, scoping and pricing the project, and executing on the project.

1: Have a spine

What I mean by "having a spine" is that you need to be able to do the following:

Say no to the customer when necessary.

Stand firm for what you believe to be the necessary tasks.

Be confident and unwavering when directing the activities of others.

Stand firm to prices quoted.

Stand behind your estimate and the work involved.

Some of these items may be especially challenging when you're just starting out in IT consulting, but in the end, you'll be more profitable, and you'll have customers who truly need your expertise and are willing to pay you for it.

2: Know your cost of doing business

Many years ago, I was responsible for creating a coupon booklet for a fundraiser in a small town in the Midwest. My team and I went around to area businesses and explained the purpose of the booklet and asked them to suggest coupons that their business could honor in the books. The very nice gentleman who owned the only full service gas station offered 20% off a full set of tires. Then he hesitated and said he needed to think about it for a while. I told him that I certainly didn't want him to lose money on the offering. He was nice but not a very good businessman (this wasn't the only evidence, but that's another story) -- he had no idea what his cost of doing business was and what his profit margin was on a set of tires. In order to be a profitable IT consultant, you absolutely must know your cost of doing business. You should figure in your overhead expenses, travel expenses (air travel and driving), supplies, phone time, and more. You should also build some wiggle room in the scope that you know you may need to give away without putting up a fight. Once you calculate your cost of doing business, you'll know what you need to bring in per hour to make a consulting engagement profitable.

3: Understand your Peter Principle

An independent contractor spoke with me recently about their frustrating situation. The contractor works in a small town in Nebraska, and he receives $500 for his service offering. We both knew that in other parts of the country, especially in larger and more affluent markets, he could receive much more money for this service package. Since he had no plans to move, his options were to change his offerings or include more or different services in the package. The contractor's research indicated that they risked losing business. In effect, he found his "Peter Principle" in terms of what he could get for the type of service he was offering in that location. The Peter Principle applies to IT consultants as well. We have to understand what the ceiling is we're going to get in terms of rate, or price, or contract. We also need to understand our earnings limitations within our main client base and work with those limitations. If we fail to understand all of that, we risk alienating current and new clients and decreasing our earning potential and profitability.

4: Don't let the customer change the scope

Scope management is always an issue when managing a customer and a consulting engagement. You document the work with one estimate (perhaps even in the signed contract), yet throughout the project, the customer may try to insert new "must haves." Analyze these requirements changes carefully and, if the changes are outside the original scope, let the customer decide if it's something they need and they will pay for it, or if it's something they can do without.

5: Advertise strategically

No cost advertising that actually works equals increased profitability. These advertising strategies can be huge boosts to your consulting business and likely won't cost you a penny.

Get testimonials from satisfied customers and post those prominently on your website.

Write press releases about your offerings and then post them to free press release sites on a regular basis.

Become a subject matter expert and write articles for industry sites.

Ask satisfied clients to recommend your work to other local businesses.

posted by Brad Egeland
October 16, 2010 @ 12:00 am
Infrastructure-Application-ManagedServices.Visit for details..