Difference between disaster recovery and business continuity

The terms business continuity and disaster recovery are often mistakenly used interchangeably. And while cloud computing services can be used to address both business continuity and disaster recovery, you must have a fundamental understanding of the differences to do effective planning.

Disaster recovery (DR) refers to having the ability to restore the data and applications that run your business should your data center, servers, or other infrastructure get damaged or destroyed. One important DR consideration is how quickly data and applications can be recovered and restored. Business continuity (BC) planning refers to a strategy that lets a business operate with minimal or no downtime or service outage.

The design of both solutions must balance a company’s tolerance for time to restore full function against the budget available to fund protection. In almost all cases, utilizing an externally managed service to accomplish DR or BC will result in lower costs and usually higher performance – less waiting time at a lower cost.

Make data protection your no. 1 concern

Whichever strategy you pursue, protecting your company’s data is critical. If your company lost some or all of its data, you’d likely be unable to continue operations. You wouldn’t know what to bill to your customers, what they already owe you, and what you owe vendors and service providers. Inventory information, manufacturing processes, contractual obligations, and competitive intelligence would all be gone. 

The question isn’t whether or not to implement DR or BC solutions, but rather how to balance the two. Depending upon the transaction velocity of your business, you may want to focus on one more than the other. But there are other factors affecting your decision as to how much protection and how much loss you can afford.

Disaster recovery plans are developed so that everyone knows exactly what to do to help the business recover in the aftermath of a major catastrophic event. Earthquakes, hurricanes, floods, and acts of war have all caused big companies to either activate their DR plans or deeply regret not having one. IT elements include having recent off-site stored backups of all data available for restoration once a new data center has been established. The more recent the backups, the better, meaning that the planning, scheduling, and rotation of data to offsite facilities is an integral part of a good DR plan.

Disasters happen. And when they do, they can destroy or incapacitate entire buildings, towns, and cities. This is where the concept of redundancy becomes critical. You may backup your data locally, and should a server or storage device fail, you simply replace it and restore the local copy of your data. But when a major outage hits your building, your neighborhood, perhaps even your entire city or region, you’ll want to be sure company data is replicated far away in a remote data center, perhaps more than one, and is available for restoration as soon as you’ve secured a new physical location from which to operate.

Business continuity planning is much more granular. Even brief lapses in operation can threaten an enterprise’s existence. Highly transactional environments almost always require a BC plan.

BC measures need to be put into place at multiple levels. For example, redundant servers, redundant storage, even redundant data centers may be required to provide enough availability to support true continuity of the business. Anything that could fail must be backstopped. Even personnel and physical premises! Alternate personnel need to be ready to step in, and substitute locations must be designated where employees can work should a calamity befall the operation. There is clearly overlap here with DR.

You can see why people try to use these terms interchangeably. True continuity of business operations requires high availability, which is the lowest level of fault tolerance, and the ability to recover from a disaster almost instantly.

Beyond replicating your valuable data, if your company can’t afford to stop doing business, you’ll want to replicate your entire infrastructure. When an outage or disaster occurs, your network “fails over” to the redundant data center and your people continue working as if nothing has happened. Users unable to access the company’s network can connect to the secondary data center easily from wherever they can securely access the internet.

Need for speed vs. budget

You may be unsure of just how much you need to invest to achieve the level of resilience appropriate for your business. You don’t want to overspend, but you don’t want to under protect either. Begin your process by assessing the value of each critical data asset, and create a specific plan for each. Compare the approximate cost of each plan against the value of the asset to establish an acceptable ratio. From there, the rest of the process is one of logistics.

Differences between Rapid STP (802.1w) and the legacy STP(802.1d)

The following table outlines the main differences between Rapid STP (802.1w) and the legacy STP(802.1d):

STP (802.1d)	Rapid STP (802.1w)
In stable topology only the root sends BPDU and relayed by others.	In stable topology all bridges generate BPDU every Hello (2 sec) : used as “keepalives” mechanism.
Port states
DisabledBlockingListeningLearningForwarding	Discarding (replaces disabled, blocking and listening) LearningForwarding
To avoid flapping, it takes 3 seconds for a port to migrate from one protocol to another (STP / RSTP) in a mixed segment.
Port roles
Root (Forwarding) Designated (Forwarding) Non-Designated (Blocking)	Root (Forwarding) Designated (Forwarding) Alternate(Discarding)Backup (Discarding)
Additional configuration to make an end node port a port fast (in case a BPDU is received).	- An edge port (end node port) is an integrated Link type which depends on the duplex : Point-to-point for full duplex & shared for half duplex).
Topology changes and convergence
Use timers for convergence (advertised by the root): Hello(2 sec) Max Age(20 sec = 10 missed hellos) Forward delay timer (15 sec)	- Introduce proposal and agreement process for synchronization (< 1 sec).- Hello, Max Age and Forward delay timer used only for backward compatibility with standard STP
	Only RSTP port receiving STP (802.1d) messages will behaves as standard STP.
Slow transition (50sec): Blocking (20s) =>Listening (15s) =>Learning (15s) =>Forwarding	Faster transition on point-to-point and edge ports only:Less states – No learning state, doesn’t wait to be informed by others, instead, actively looks for possible failure by RLQ (Request Link Query) a feedback mechanism.
Use only 2 bits from the flag octet:Bit 7 : Topology Change Acknowledgment.Bit 0 : Topology Change	Use other 6 bits of the flag octet (BPDU type 2/version 2): Bit 1 : ProposalBit 2, 3 : Port roleBit 4 : LearningBit 5 : ForwardingBit 6 : AgreementBit 0, 7 : TCA & TCN for backward compatibility
The bridge that discover a change in the network inform the root, that in turns informs all others by sending BPDU with TCA bit set and instruct them to clear their DB entries after “short timer” (~Forward delay) expire.	TC is flooded through the network, every bridge generate TC (Topology change) and inform its neighbors when it is aware of a topology change and immediately delete old DB entries.
If a non-root bridge doesn’t receive Hello for 10*Hello (advertised from the root), start claiming the root role by generating its own Hello.	Wait for 3*Hello on a root port (advertised from the root) before deciding to act.
Wait until TC reach the root + short timer (~Forward delay) expires, then flash all root DB entries	Delete immediately local DB except MAC of the port receiving the topology changes (proposal)

 

Difference between T-MPLS & MPLS-TP

 

Evaluating Network Gear Performance

 

Choosing the right equipment for your network is hard. Even ignoring the ever-growing roster of features one must account for when evaluating candidate hardware, it's important not to overlook performance limitations. Below are some of the most crucial characteristics to consider when doing your research.

Throughput

Throughput is the rate at which a device can convert input to output. This is different from bandwidth, which is the rate at which data travels across a medium. An Ethernet switch, for example, might have 48 ports running at an individual bandwidth of 1 Gbps each but be able to switch only a total of 12 Gbps among the ports at any given time. This is said to be the switch's maximum throughput.

 

Throughput is measured in two units: bits per second (bps) and packets per second (pps). Most people are most familiar with bits per second. This is the amount of data which flows through a particular point within a duration of one second, typically expressed as megabits (Mbps) or gigabits (Gbps) per second. Capitalization is important here. A lowercase 'b' indicates bits, whereas an uppercase 'B' indicates bytes. Speed is always measured in bits per second, with a lowercase 'b' (Kbps or Mbps).

 

Packets per second, similarly expressed most often as Kpps or Mpps, is another way of evaluating throughput. It conveys the number of packets or frames which can be processed in one second. This approach to measuring throughput is used to expose limitations of the processing power of devices, as shorter packets demand more frequent forwarding decisions. For example, a router might claim a throughput of 30 Mbps per second using full-size packets. However, it might also be limited to processing 40 Kpps. If each packet received was the minimum size of 64 bytes (512 bits), the router would be limited to just 20.48 Mbps (512 * 40,000) of throughput.

 

Cisco maintains often cited baseline performance measurements for its most popular routers and switches. If you work out the math, you can see that the Mbps numbers listed in the router performance document were derived using minimum-length (64 byte) packets. These numbers thus present a worst case scenario. Packets on a production network typically vary widely in size, and larger packets will yield higher bits-per-second rates.

 

Keep in mind that these benchmarks were taken with no features other than IP routing enabled. Adding additional features and services such as access control lists or network address translation may reduce throughput. Unfortunately, it's impractical for a vendor to list throughput rates with and without myriad features enabled, so you'll have to do some testing yourself.

Oversubscription

Ethernet switches are often built with oversubscribed backplanes. Oversubscription refers to a point of congestion within a system where the potential rate of input is greater than the potential rate of output. For example, a switch with 48 1 Gbps ports might have a backplane throughput limitation of only 16 Gbps. This means that only 16 ports can transmit at wire rate (the physical maximum throughput) at any point in time. This isn't usually a problem at the network edge, where few users or servers ever need to transmit at these speeds for a prolonged time. However, oversubscription imposes much more critical considerations in the data center or network core.

 

As an example, let's look at the 16-port 10 Gbps Ethernet module WS-X6816-10G-2T for the Cisco Catalyst 6500 switch. Although the module provides an aggregate of 160 Gbps of potential throughput, its connection to the chassis backplane is only 40 Gbps. The module is oversubscribed at a ratio of 4:1. This module should only be used in situations where the aggregate throughput demand from all interfaces is not expected to exceed 40 Gbps.

IP Route Capacity

The maximum number of routes a router can hold in its routing table is limited by the amount of available content-addressable memory (CAM). Although a low-end router may be able to run BGP and exchange routes with BGP peers, it likely won't have sufficient memory to accept the full IPv4 Internet routing table, which comprises over 400 thousand routes. (Of course, low-end routers should never be implemented in a position where they would need to receive the full routing table.) Virtual routing contexts, in which a router stores multiple copies of a route in separate forwarding tables, increase routing table size exponentially, further elevating the importance of properly sizing routers for the role they play.

Maximum Concurrent Sessions

Firewalls and intrusion prevention systems perform stateful inspection of traffic transiting from one trust zone to another. These devices must be able to keep up with the demand for throughput not only in terms of bits per second and packets per second but also in the number of concurrent stateful sessions. A single web request might trigger the initiation of one or two dozen TCP connections to various content servers from an internal host. The firewall or IPS must be able to track the state of and inspect potentially thousands of sessions at any point in time. If the device's maximum capacity is reached, attempts to open new sessions may be rejected until a number of current sessions are closed or expire. Such devices are likewise limited in how fast they can create new sessions.

 

Basics: What’s the Difference Between STP BPDU Guard and Root Guard

Courtesy - Ethereal Mind


BPDU Guard and Root Guard are enhancements to Spanning Tree Protocol (STP) enhancements that improve the reliability of the protocol to unexpected events.

Why ?

Remember that the purpose of the the Spanning Tree algorithm is to create a single path through the network to prevent loops because the Ethernet frame has no loop prevention mechanism. As a result an Ethernet network is always designed like an inverted tree like this:


There are loops in this design that are implemented for resilience ie. STP will block a given path in planned operation but an alternate path can be activated if the primary path fails.

However, STP is susceptible to various failures due to poor network design 1 or certain types of operational problems. Both BPDU Guard and Root Guard are used to enforce design discipline and ensure that the STP protocol operates as designed.

BPDU Guard

BPDU guard disables the port upon BPDU reception if PortFast is enabled on the port. This effectively denies devices connected to these ports from participating in the desgined STP thus protecting your data centre core.

Note: In the event of the BPDU being received the port will typically be shutdown in “errdisable” state and will require manually reenabling the port. Alternately you can configure the port to attempt to re-enable by configuring the “errdisable timeout”

Root Guard

Root guard allows the device to participate in STP as long as the device does not try to become the root. If root guard blocks the port, subsequent recovery is automatic. Recovery occurs as soon as the offending device ceases to send superior BPDUs.

Where ?

Because BPDU Guard and Root Guard are primarily to ensure design enforcement ( integrity / security) , they must configured in specific locations in the networks.

---

1. By “design” I mean that people add new switches in the wrong places which breaks that controlled design as shown here.

 

Different Tiers in a Data Center

 

The days of having a ‘computerroom’ in your own company are fading. Nowadays most enterprises outsource their technical environment off-site to a professional datacenter. ICT at this point is business critical for almost any company and environments should be high available, secure and have a disaster recovery plan. Having said that, it’s important to know there is a quality difference among datacenters, qualified as Datacenter Tiers.

 

Several key components play a part in the quality of a datacenter such as :

 

• Electrical power redundancy
• Fire protection
• Physical security parameters
• Cooling redundancy
• Environmental control
• Carrier neutrality
• Carrier entry points

 

In 2005 it published ANSI/TIA-942, Telecommunications Infrastructure Standard for Data Centers, which defined four levels (called tiers) of data centers in a thorough, quantifiable manner.

 

Tier 1 = Non-redundant capacity components (single uplink and servers).
Tier 2 = Tier 1 + Redundant capacity components.
Tier 3 = Tier 1 + Tier 2 + Dual-powered equipments and multiple uplinks.
Tier 4 = Tier 1 + Tier 2 + Tier 3 + all components are fully fault-tolerant including uplinks, storage, chillers, HVAC systems, servers etc. Everything is dual-powered

 

Tier 1: Guaranteeing 99.671% availability.
Tier 2: Guaranteeing 99.741% availability.
Tier 3: Guaranteeing 99.982% availability.
Tier 4: Guaranteeing 99.995% availability.

 

It’s key to evaluate every possible failure scenario when choosing a datacenter partner and checking availibility. At minimum you should ask yourself :

 

• What about physical security, who is allowed in the datacenter ?
• Are people required to sign in ? Present their ID ?
• How is backup electricity managed ? By diesel engines ? Is this procedure tested on a regular basis ?
• Do they present redundant circuits in a rack ?
• How is carrier feeding managed ? Is there an intro at different locations of the datacenter building ? Are these carriers following the same path or redundant ?
• Which carriers are available in the datacenter ?
• How is cooling managed ? Cold-Warm corridor ? is it monitorred by the datacenter ?
• Is there an airport nearby ? (yes, this is about disasters! there are regulations about this)
• Is there a raised floor ? Is there moisure detection ?
• What about the roof ? Dual layered ? Moisure detection ?
• How is fire surpression managed ? By gas or water ?
• Is there overhead cabling ?

Security is a big topic, as network security has been improved over the years. When attacks come from the inside (eg : from a person on the console of your environment in the datacenter) network security is easily bypassed. It’s important your datacenter partner works in full confidentiality and has a strong physical security and security logging concerning who’s entering the datacenter at which time. It’s obvious only you should have access to your hosted racks by key, keycard or biometry.

 

Another important factor when choosing a datacenter partner is about communication. As it seems less important, this is one of those factors which can easily blow up a customer relationship. First of all there should be a communication channel concerning mayor outages or planned interventions inside the datacenter. Secondly you should be able to contact your datacenter partner 24/7 when your racks are down. While this seems obvious, it’s important to check and evaluate how the datacenter partner is handling these events. Related is the Service Level Agreement, which should be investigated carefully. If you provide services to your own customers, you should be able to allign your SLA’s to these of the datacenter (back2back).

 

Among all other technical questions, use your common sense. Have a chat with your account manager or the datacenter owner and put a list of questions together. Chat about outages, escalation procedures and innovation or datacenter growth. Ask for public references and give them a call!

Hope this helps when choosing your datacenter partner and clarifies datacenter tiers. Happy hunting!

 

Difference between HSRP and VRRP

HSRP stands for Hot Standby Routing Protocol. VRRP stands for Virtual Route Rendundancy Protocol. The differences between HSRP versus VRRP are very slight especially when looking at the basic configuration side by side. But under the covers there are some significant differences. The end result, however is still the same.

 

If a router fails you need a standby router to become the active gateway and forward packets to the next hop

Here's a break down that compares the major differences between the two protocols.

HSRP Versus VRRP Comparison Table

HSRP	VRRP
Propietary	Standards based
RFC 2281	RFC 3768
Separate IP Address needed for the Virtual	Can use the physical IP Address of the Virtual, if needed, saving IP space.
One Master, all other routers are backup	One Master, One Standby, all others are listening
More familiar to most network engineers	Less familiar - yet very similar
Can track an interface for failover	Can track an interface for failover (depending on operating system and version)
All HSRP routers use multicast hello packets to 224.0.0.2 (all routers) for version 1 or 224.0.0.102 for version 2.	All VRRP routers use IP protcol number 112 (vrrp) to communicate via multicast IP address 224.0.0.18
All virtual router must use MAC address 0000.0c07.acXX where XX is the group ID.	All virtual routers must use 00-00-5E-00-01-XX as its Media Access Control (MAC) address

Configuration differences between HSRP and VRRP

 

The differences between both VRRP and HSRP, especially on a Cisco router are very slight. If your familiar with Configuring HSRP you can easily understand VRRP commands. Configuring VRRP on Juniper as well as other network equipment can vary significantly depending on the devices. Many load balancers also support VRRP and their configuration is specific to each of these devices.

 

Here are some configuration examples as seen on a Cisco router:

 

HSRP Configuration Example

R1(config)# interface GigE 0/1
R1(config-if)# ip address 192.168.1.2 255.255.255.0
R1(config-if)# standby 1 ip 192.168.1.1
R1(config-if)# standby 1 priority 200
R1(config-if)# standby 1 preempt
R2(config-if)# ip address 192.168.1.3 255.255.255.0
R2(config-if)# standby 1 ip 192.168.1.1
R2(config-if)# standby 1 preempt

 
VRRP Configuration Example

R1(config)# interface GigE 0/1
R1(config-if)# ip address 192.168.1.2 255.255.255.0
R1(config-if)# vrrp 1 ip 192.168.1.1
R1(config-if)# vrrp 1 priority 110
R2(config)# interface GigE 0/1
R2(config-if)# ip address 192.168.1.3 255.255.255.0
R2(config-if)# vrrp 1 ip 192.168.1.1
Notice the lack of a preempt command. This isn't necessary for VRRP. It's enabled by default.
As you can see there sin't a big difference between the two protocols. The primary difference between HSRP versus VRRP would be that HSRP is proprietary to Cisco and can only be used on Cisco devices. VRRP is a standards based protocol and is vendor independant allow some flexibility when choosing network devices.
 

Difference between NX-OS and IOS

NX-OS is derived from the Cisco MDS (storage) switches and converted in order to make it work with Cisco Switching technology. It’s designed to support high performance and high realibility networks in the datacenter. It’s really based on MontaVista Software embedded Linux, which you can still discover when it boots up. NX-OS is still command line but some of the commands might be different comparing it to IOS.

One of the important differences is that NX-OS is driven by a license model whereas IOS just cared about which image you ran. in NX-OS all features are there, you just need to enable them and activate a valid license for it.

Interfaces behave a bit differently in NX-OS. In IOS you had a difference between FastEthernet, Ethernet and GigabitEthernet (even TenGigabitEthernet) interfaces. No more in NX-OS. You just have ‘Ethernet’ interfaces. Below you see a ‘show int brief’ on a Nexus 5000 series :

switch(config)# sh int brief

-------------------------------------------------------
Ethernet      VLAN   Type Mode   Status  Reason  Speed     Port
Interface                                                                   
--------------------------------------------------------
Eth1/1        1      eth  access down    SFP validation failed       10G(D) --
Eth1/2        1      eth  access down    SFP not inserted            10G(D) --
Eth1/3        1      eth  access down    SFP validation failed       10G(D) --
Eth1/4        1      eth  access down    SFP not inserted            10G(D) --
Eth1/5        1      eth  access down    SFP validation failed       10G(D) --
Eth1/6        1      eth  access down    SFP not inserted            10G(D) --
Eth1/7        1      eth  access down    SFP validation failed       10G(D) --
Eth1/8        1      eth  access down    SFP not inserted            10G(D) --
Eth1/9        1      eth  access down    SFP not inserted            10G(D) --
Eth1/10       1      eth  access down    SFP not inserted            10G(D) --
Eth1/11       1      eth  access down    SFP not inserted            10G(D) --
Eth1/12       1      eth  access down    SFP not inserted            10G(D) --
Eth1/13       1      eth  access down    SFP not inserted            10G(D) --
Eth1/14       1      eth  access down    SFP not inserted            10G(D) --
Eth1/15       1      eth  access down    SFP not inserted            10G(D) --
Eth1/16       1      eth  access down    SFP not inserted            10G(D) --
Eth1/17       1      eth  access down    SFP not inserted            10G(D) --
Eth1/18       1      eth  access down    SFP not inserted            10G(D) --
Eth1/19       1      eth  access down    SFP not inserted            10G(D) --
Eth1/20       1      eth  access down    SFP not inserted            10G(D) --
Eth2/1        1      eth  access down    SFP not inserted            10G(D) --
Eth2/2        1      eth  access down    SFP not inserted            10G(D) --
Eth2/3        1      eth  access down    SFP not inserted            10G(D) --
Eth2/4        1      eth  access down    SFP not inserted            10G(D) --
Eth2/5        1      eth  access down    SFP not inserted            10G(D) --
Eth2/6        1      eth  access down    SFP not inserted            10G(D) --

Notice all interfaces are marked ‘Ethx/x’.

There are some important points you need to know before deploying a Nexus in your switching environment :

• SVI command-line interface (CLI) configuration and verification commands are not available until you enable the SVI feature with the feature interface-vlan command.
• Tunnel interface command-line interface (CLI) configuration and verification commands are not available until you enable the Tunnel feature with the feature tunnel command.
• Interfaces support stateful and stateless restarts after a supervisor switchover for high availability.
• Only 802.1q trunks are supported, so the encapsulation command isn’t necessary when configuring a layer-2 switched trunk interface. (Cisco ISL is not supported)
• An IP subnet mask can be applied using /xx or xxx.xxx.xxx.xxx notation when configuring an IP address on a layer-3 interface. The IP subnet mask is displayed as /xx in the configuration and show interface command output regardless which configuration method is used.
• The CLI syntax for specifying multiple interfaces is different in Cisco NX-OS Software. The range keyword required in Cisco IOS Software has been omitted from the syntax (IE: interface ethernet 1/1-2), and the interface range can be configured in ascending or descending order. Cisco IOS Software requires the interface range to be configured in ascending order.
• When monitoring interface statistics with the show interface CLI command, a configurable load-interval can be configured per interface with the load-interval counters command to specify sampling rates for bit-rate and packet-rate statistics. The Cisco IOS Software supports the load-interval interface command, but doesn’t support multiple sampling rates.
• I/O modules have a locator-LED (beacon) that allows remote-hands-support personnel to easily identify a specific port. The beacon light can be enabled per interface in interface configuration mode with thebeacon CLI command.
• An administrator can configure port profiles as templates that can be applied to a large number of interfaces to simplify the CLI configuration process. Port profiles are “live” configuration templates, so modifications to a port profile are automatically applied to the associated interfaces. Cisco IOS uses port macros to simplify the CLI configuration process, but unlike Port Profiles they are applied one time.
• The supervisor module out-of-band management ethernet port located on the supervisor module is configured with the interface mgmt 0 CLI command.
• The supervisor module out-of-band Connectivity Management Processor (CMP) port is configured in the NX-OS with the interface cmp module <#> CLI command. The CMP port can also be configured by attaching to the CMP using the attach cmp CLI command.
• The NX-OS support Nexus 2000 (models 2224TP, 2248TP, 2232PP) Fabric Extender (FEX) connectivity. The parent Nexus 7000 manages Nexus 2000’s software and CLI configuration, so the Nexus 7000 is a single managed entity for all connected Nexus 2000′s. Nexus 2000 host ports are configured using the interface ethernet CLI command. A Nexus 2000 can only be connected to the 10GE M1, M1-XL and F2 modules (Please read the documentation on cisco.com to understand port connectivity restrictions.)
• Proxy ARP is disabled on all interfaces by default.

The following list provides some additional facts about the Cisco NX-OS that should be helpful when configuring interfaces.

• An interface can only be configured in 1 VDC at a time.
• When assigning interfaces to a VDC on the 48 port SFP/UTP M1 series modules there are no restrictions.
• When assigning interfaces to a VDC on the 32 port 10GE M1 series modules, all four interfaces in a port group (IE. group 1 =1,3,5,7 group 2 =2,4,6,8, etc.) must be assigned to the same VDC.
• When assigning interfaces to a VDC on the 32 port 1/10GE F1 Series module, both ports in a port group (IE. 1-2, 3-4, etc.) must be assigned to the same VDC.
• When assigning interfaces to a VDC on the 48 port 1/10GE F2 Series module, all four ports in a port group (IE. 1-4, 5-8, etc.) must be assigned to the same VDC.
• When assigning interfaces to a VDC on a Nexus 2224TP, 2248TP, 2232PP all interfaces must belong to the same VDC.
• One 10 GE interface per port group can be configured in dedicated mode using the rate-mode dedicated interface CLI command on the M1 series modules (The remaining three ports are disabled).
• The mgmt 0 port is associated to all configured VDCs allowing TELNET/SSH and IP management applications such as SNMP to access the VDC directly. All mgmt 0 ports must be configured in the same IP subnet.
• The default port type is configurable for L3 routed or L2 switched in the setup startup script. (L3 is the default port type prior to running the script)
• A layer-2 switched trunk port sends and receives traffic for all VLANs by default (This is the same as Cisco IOS Software). Use the switchport trunk allowed vlan interface CLI command to specify the VLANs allowed on the trunk.
• The clear counters interface ethernet CLI command resets the counters for a specific interface.
• An interface configuration can be reset to its default values with the default interface global configuration command.
• The 48 port UTP M1 series module supports Time Domain Reflectometry (TDR) cable diagnostics. All 12 ports in a port group must be shutdown prior to running the test cable-diagnostics tdr interface ethernet CLI command. The results can be verified with the show interface ethernet cable-diagnostics-tdr command.

Another big thing in the NX-OS software is the virtualization methods. In the Nexus 7000 series you are able to create VDC’s. These VDC’s stand for Virtual Device Contexts and in fact duplicate a complete switch seperated from your other VDC’s. Talk about virtualization! Every VDC has it’s own CAM table, own VLAN’s, own everything! The hardware itself is the only shared part of this solution.

Next to VDC’s, the NX-OS software introduced VPC technology. This stands for Virtual Portchannel. Using this technology you can build high available, non-blocking designs using all Nexus switches.
 

HP EVI vs. Cisco OTV: A Technical Look

 

HP announced two new technologies in the late summer, Multitenant Device Context (MDC) and Ethernet Virtual Interconnect (EVI), that target private clouds. Mike Fratto outlined the business and market positions, particularly in regard to Cisco's Overlay Transport Virtualization (OTV) and Virtual Device Context. However, the technology is also interesting because it's a little different than Cisco's approach. This post will drill into HP's EVI and contrast it with Cisco's OTV, as well as with VPLS.

 

HP EVI supports Layer 2 Data Center Interconnect (L2 DCI). L2 DCI technology is a broad term for technologies that deliver VLAN extension between data centers. Extending VLANs lets virtual machines move between data centers without changing a VM's IP address (with some restrictions). The use cases for such a capability include business continuity and disaster recovery. For a more extensive discussion of L2 DCI, please see the report The Long-Distance LAN.

 

HP EVI is a MAC-over-GRE-over-IP solution. Ethernet frames are encapsulated into GRE/IP at ingress to the switch. The GRE/IP packets are then routed over the WAN connection between the data centers.

 

EVI adds a software process to act as control plane to distribute the MAC addresses in each VLAN between the EVI-enabled switch. Thus, the switch in data center A updates the MAC address table in data center B and vice versa. By contrast, in traditional use, Ethernet MAC addresses are auto-discovered as frames are received by the switch.

 

Because GRE packets are TCP/IP packets they can be routed over any WAN connection, making it widely useful for customers. In a neat bit of synergy, the HP Intelligent Resilient Framework (IRF) chassis redundancy feature means that WAN connections are automatically load-balanced because switches that are clustered in an IRF configuration act as a single switch (a Borg architecture, not an MLAG architecture). Therefore, multiple WAN connections between IRF clusters are automatically load-balanced by the control plane either as LACP bundles or through ECMP IP routing, which is a potential improvement over Cisco's OTV L2 DCI solution.

 

However, note that load balancing of the end-to-end traffic flow is not straightforward because there are three connections to be considered: LAN-facing, to the servers using MLAG bundles; WAN-facing, where the WAN links go from data center edge switches to the service provider; and intra-WAN, or within the enterprise or service provider WAN. Establishing the load balancing capabilities of each will take some time.

Because HP has chosen to use point-to-point GRE, the EVI edge switch must perform packet replication. Ethernet protocols such as ARP rely heavily on broadcasts to function. In a two-site network this isn't problem, but for three sites or more, the EVI ingress switch needs to replicate a broadcast EVI frame to every site. HP assures me that this can be performed at line rate, for any speed, for any number of data centers. That may be so, but creating full mesh replication for n* (n-1) WAN circuits could result in poor bandwidth utilization in networks that have high volumes of Ethernet broadcasts.

 

Cisco's OTV is also MAC-over-GRE-over-IP (using EoMPLS headers), but it adds a small OTV label into the IP header. The OTV control plane acts to propagate the MAC address routing table.

 

Like HP's EVI, OTV can complicate load balancing. Cisco's Virtual Port Channel (vPC) shares the control plane, while HP's IRF shares the data plane. Although a vPC-enabled pair of Nexus 7000 switches run as autonomous control planes, NX-OS can load balance evenly using IP. OTV load balances by using a 5-tuple hash and will distribute traffic over multiple paths for the WAN.

 

OTV also supports the use of multicast routing in the WAN to deliver a much more efficient replication of Ethernet broadcasts in large-scale environments. Instead of meshing a large DCI core, a Source Specific Multicast (with good reasons) should be more efficient for multiple sites. Badly designed applications, such as Microsoft NLB, will be much more efficient using multicast.

 

EVI Compared To MPLS/VPLS

 

For many enterprises, MPLS is not a consideration. MPLS is a relatively complex group of protocols that requires a fair amount of time to learn and comprehend. However, building mission-critical business services that aren't MPLS is really hard. Service providers can offer L2 DCI using their MPLS networks with VPLS. Operationally, enterprise infrastructure is diverse and customised to each use case. Service provider networks tend toward homogeneity and simplicity because of the scale.

 

Some enterprises will buy managed VPLS services from service providers. They will also discover that such VPLS services are of variable quality, offer poor loop prevention, and can be expensive and inefficient. (For more, see the above-referenced report.) This is what drives Cisco and HP to deliver better options in OTV and EVI.

 

Other EVI Claims

 

HP notes that its solution doesn't require "multicast in the default configuration." HP wants to contrast itself to Cisco's OTV, which uses Source Specific Multicast in the WAN core, because many network engineers might think configuring multicast to be too hard. Building an SSM design over a Layer 3 WAN core is a substantial requirement and not a technology that most enterprise engineers would be comfortable configuring. On the other hand, configuring SSM over a Layer 2 WAN core (using Dark Fibre or DWDM) is trivial.

 

However, Cisco OTV has a unicast mode that works in a similar way to HP EVI, which most engineers would choose for simplicity. That said, the SSM WAN core offers scaling and efficiency if you need it, while HP's EVI does not.

 

The HP EVI approach is potentially more effective at load balancing WAN circuits than 5-tuple hashing in Cisco OTV, but it's unlikely to make much difference in deployment.

 

EVI's Enterprise Value

 

HP EVI is aimed at enterprises with private clouds. The technology looks like a good strategy. HP says EVI will be available in the A12500 switch in December. HP has a poor history of delivering on time (we're still waiting for TRILL and EVB), so plan accordingly. Cisco OTV is shipping and available in the Nexus 7000 and ASR products (for substantial license fees). HP says it won't charge for EVI.

 

Private clouds are shaping up to be a huge market in the next five years, and HP is addressing this space early by bringing L2 DCI capabilities to its products. HP EVI looks to be a good technology to meet customer needs. Combined with Multitenant Device Content, it should keep HP on competitive footing with Cisco. Of course, it's easy to make this kind of technology work in a PowerPoint. We'll have to wait and see how it works in real deployments.

 

 

Comparison and Difference between HSRP, VRRP and GLBP Protocols

HSRP, VRRP and GLBP are the main three first hop redundancy protocols. In order to take the right decision for your network you should know the basics regarding all three.

The following chart provides difference HSRP Vs VRRP Vs GLBP protocols.

Difference between HSRP, VRRP and GLBP Protocols

Protocol Features	HSRP	VRRP	GLBP
Scope	Cisco Proprietary	IEEE standard	Cisco proprietary
Standard	RFC2281	RFC3768	none
OSI Layer	Layer-3	Layer-3	Layer-2
Load Balancing	No	No	Yes
Multicast Group IP address	224.0.0.2 in version 1224.0.0.102 in version 2	224.0.0.18	224.0.0.102
Transport Port Number	UDP 1985	UDP 112	UDP 3222
Timers	Hello – 3 sec	Advertisement – 1 sec	Hello – 3sec
	Hold – 10 sec	Master down time = 3*Advertisement Time + Skew TimeSkew Time = (256- Priority)/256	Hold – 10sec
Election	Active Router:1.Highest Priority2. Highest IP address (Tiebreaker)	Master Router: (*) 1-Highest Priority 2-Highest IP (Tiebreaker)	Active Virtual Gateway: 1-Highest Priority 2-Highest IP (Tiebreaker)
Router Role	-One Active Router, one Standby Router-one or more listening Routers	- One Active Router- One or More Backup Routers	- One AVG (Active Virtual Gateway)- up to 4 AVF Routers on the group (Active Virtual Forwarder) passing traffic.- up to 1024 virtual Routers (GLBP groups) per physical interface.
Preempt	If Active Router(Highest Priority) is down and up again, Preempt should be configured to become a Active Router again	By default Preempt is ON in VRRP, If Active Router is down and up again, It will automatically become a Master Router	If Active Router(Highest Priority) is down and up again, Preempt should be configured to become a Active Router again.
Group Virtual Mac Address	0000.0c07.acxx	0000.5e00.01xx	0007.b4xx.xxxx
IPv6 support	Yes	No	Yes

Note: In VRRP group, Router which is configured group as a real IP will become a Active Router, IOS will manage to make the VRRP Router with the real IP, the master, by setting its priority to 255, knowing that the configurable range is [1-254].
 

MPLS vs VPLS

MPLS is the typical underlying plumbing for a carrier style network core that can support L3 VPNs, VPLS and various other services, although other "stuff" can be used.

MPLS is the common way to do this and seems to be "best common practice" right now.

The carriers need big, large scale, flexible core networks that can support traffic from lots of customers on a common set of equipment and resilient WAN links, but provide separation between them.

VPLS mainly assumes Ethernet delivery, so can be good where that is available for all your needed locations, but may be limiting.

VPLS emulates a switched Ethernet LAN and as such suffers from the related scaling and diagnostic issues - i would not want to use VPLS to connect more than a few dozen sites in a single network, and you will need routers to control traffic well before that point.

Some other "Ethernet over cloud" type systems give different sets of tradeoffs - Ethernet pseudowire services for example scale better but need more detail design and planning.

L3 VPNs will work with any type of access - conventional 1.5m and 2m links may be all you can get in some places / countries, or you might need VSAT for that location in Africa and so on....

Many carriers have NNI links to others for L3 VPNs, so you can get to places outside their geography. International broadcasters for example may want links to every continent.

L3 is easier to use with QoS, works better with multicast and various others services.

L3 means the carrier(s) are involved in the IP topology, and in turn that may limit what protocols you can use - that may work well for you or just cause more hassle.

None of these issues are black and white, but a specific set of requirements will "push" you towards 1 type of system.

And real life is complicated - you may end up using both for a big network.

Technical jargon aside, I would break down the CIO’s comparison of the two technologies into two main categories:

1) Immediate Impact on the Organization’s Strategy

a. How does each technology meet the organization’s short-term needs/requirements?

b. What value does each technology add to both the organization (and the IT group)?

c. What’s the immediate impact on application performance (i.e. User Experience, etc…)?

d. What’s the immediate impact as it relates to budget?

2) Long-Term support for changes to that Strategy

a. Which solution can easily support business changes?

i. Do both solutions scale geographically?

ii. Can both solutions support ancillary services?

b. Which solution best supports technological changes in the business?

i. Consolidation/Centralization Strategies

ii. Convergence Strategies

iii. Cloud / SaaS Strategies

c. What impact, if any, does either solution have on

i. Long-term revenue generation.…

ii. Long-term cost containment.…

In other words ... do a solid business case analysis. NOT just a technical review. Accomplishing this will also help you when it comes time to "sell it" to senior management.

Courtesy - Broadband Nation

What's the Difference Between Cloud and Managed Services?

Courtesy - MSPNews

It is often the case that before you gain mass acceptance of a new foundation, you first must destroy the old one. Consider the birth of application and managed services back in the 1990s. The success and adoption of these new service delivery models depended on convincing VARs that merely reselling products was no longer viable. Break/fix computing had to be debunked before managed services could truly be realized. This turned out to be very easy to do since many VARs during that time period were suffering from shrinking margins, decreased importance in front of the customer, and increased competition from distributors, online product hubs, and sometimes their own vendor partners. Today, some people are trying to marginalize managed services as a path to sell cloud. I would like to examine why I believe this is a wrong move and one that will ultimately be unsuccessful.

First, is it necessary to eliminate or lessen managed services in order for cloud to be successful? Absolutely not. Actually, cloud computing and managed services are tied at the hip in many regards and share a long and intertwined history. When application services were first introduced, many MSPs were created specifically to manage both the applications and the underlying infrastructure. From that starting point, many MSPs started to just offer infrastructure support. It is odd that today we seem to be completing the cycle and are back to MSPs becoming more interested in the application layer again.

Second, is there anything that really separates cloud and MSPs? I don’t think so for the following reasons. As I’ve already stated, application services and everything else that can be managed as a service are really one in the same. Historically, there is no separation between the two as they were really rungs on a ladder with applications being at or near the top. To say now that there is no need for infrastructure would be shortsighted indeed, given how much we rely on solid infrastructure and security for our cloud platforms (especially private cloud).

Cloud computing is simply a delivery mechanism for a managed service. According to Wikipedia “Cloud computing relies on sharing of resources to achieve coherence and economies of scale...” This is no different with managed services. MSPs aggregate tools, people, and develop processes which make the delivery of their service highly streamlined and efficient, both efficient in cost and delivery. So, if you accept this definition, why do we have two different terms for essentially the same business model?

Drum roll please. Cloud is an easy concept to explain. Whatever benefits managed services offer to organizations, cloud has been adopted for whatever reason as a ubiquitous term that everyone is using. It’s hip to be in the cloud. Non-technical people can easily grasp the meaning of cloud and start to define policies and strategies within their own organizations about how to best use cloud. Managed Services continues to be the dominant business model and will always be, in my opinion. But cloud does have a role to play in our industry as long as it is properly defined.

One thing is perfectly clear, and I’ll go ahead and BOLD THIS PARAGRAPH SO PEOPLE REALLY PAY ATTENTION HERE. While cloud may be really popular right now, I would caution everyone about being swept up too much in the hype. The following are all terms that have appeared (some have gone away) and tried to dethrone managed services but have been unsuccessful. Outsourcing, offshoring, business process outsourcing, strategic sourcing, thin client computing, Software as a Service, utility computing, and other terms have all unsuccessfully tried to challenge managed services as a dominant business model and marketing convention and yet managed services is still here. I have learned to be patient and let these trends play out before making any significant changes.

And, to be perfectly clear, I do believe in cloud, but only as a delivery mechanism for managed services. If cloud has a purpose in helping non-technical people understand the value of managed services, then even better. But, I do not think it will (or should) replace managed services. The two terms are simply two intertwined and will likely always be so.

Juniper EX versus Cisco

1. EX Switches have Frontal LCD panel for maintenance procedures, isn’t it crazy that you can reset switch to factory default just pushing one button!

2. Using LCD Panel, There’s an EZ setup mode, it sets juniper IP to 192.168.1.1 and acts as a DHCP for that subnet on GE0/0/0 (default username/password: root)

3. There’s a technology for stacking switches from back just like Cisco 3750s, Juniper calls it VC or Virtual Chassis, you can connect switches in any order with 128Gbps throughput. (64Gbps duplex)

4. 10 Boxes are supported in a VC, (Cisco supports up to 9 switches in one stack) and the good news is that you can use a Gigabit interface or a 10 GigE interface to connected to VC… so if your switch is far from other Stack members, now you can Stack several switches around campus with Fiber and no longer limited to the stupid short stack cables.

5. VC defines three roles: Master, Backup & Linecard – versus Cisco having Master and Member roles.

6. Highest priority wins mastership (1 to 255, default: 128) – Cisco has priority 1 to 15, default: 1

7. Juniper supports hot plug installation, so new members can be powered on and join to the current stack.

Difference Between HLR and VLR

HLR vs VLR

 Home Location Register (HLR) and Visitors Location Register (VLR) are databases that contain the mobile subscriber information as per the GSM architecture. In general there is one central HLR per mobile network operator and one VLR per each Mobile Services Switching Centre (MSC) but this can vary according to the different vendor implementations. Capacity of HLR and VLR can directly affect the subscriber capacity of the mobile network operator.

HLR

HLR contains entries for each and every subscriber (MSISDN Number) within a mobile network. Mostly HLR contains static and permanent information about a subscriber. For an example subscriber status, service subscriptions (Voice, Data, SMS etc.), supplementary services, permissions etc. Other than this static information, it has temporary information such as current VLR number and MSC number. HLR works as the central location to route calls within the respective mobile operator’s network. Most of the administrative activities regarding the subscribers are controlled and centralised around the HLR. In most vendor implementations Authentication Centre (another element in GSM architecture) is integrated to HLR to provide more efficient and effective mobile network design. In this case HLR contains authentication information as well.

VLR

VLR is a database that contains part of the data available in the HLR and other dynamic information about the mobile stations’ currently roaming in the administrative areas of the associated VLR. Data in the VLR are more dynamic than the other because of the mobility nature of the mobile stations. When a mobile station moves from one Location Area to another their information is updated in the VLR, so as to locate the mobile stations. When a subscriber moves out to new VLR area then HLR inform the old VLR to remove the information related to the given subscriber. Interface between HLR and VLR is called as D-Interface as per the GSM standard which help to share information between nodes. Information about location such as LAI (Location Area Information), attached status and Temporary Mobile Subscriber Identity (TMSI) are stored in the VLR. Also some of the authentication information is passed from HLR to VLR for the authentication requirements.

What is the difference between HLR and VLR?

HLR and VLR have their own functionality within the GSM architecture. There is also a communication interface between HLR and VLR as per the GSM architecture. Number of communications take place within HLR and VLR nodes to share their information. For an example when one subscriber move from one VLR area to another area their locations are updated in the VLR and new VLR information is updated in the HLR. But if a subscriber moves within the same VLR area no such interaction with the HLR is needed.

Both HLR and VLR store the subscriber information as per the GSM architecture to provide mobile communication services to subscribers registered within the network. In general HLR contains information about all subscribers within a network while VLR contains more dynamic information relevant to subscribers roaming within the VLR area. This can vary depending on the network architecture design because in most cases HLRs’ act as centralized nodes while VLRs are mostly geographically diversified nodes. HLR acts as a fixed reference point to a given mobile station (subscriber) while his VLR can vary depending on the mobility and network design.

Even though both HLR and VLR act as databases within the same mobile network, in most designs VLRs are assigned limited geographical area to handle all dynamic data about the subscribers within that area while HLR act as more centralized node that provide more static information about the subscribers within whole network. HLR handles the subscriber administration activities within the network while VLR supports the mobility function and other dynamic information about the subscribers.

Difference Between 4G and 3G Technology

What does “4G” mean? 4G is a marketing term that service providers are using to describe the “fourth generation” of wireless services.They typically offer between four and ten times the performance of 3G networks.

What technologies run 4G services ?

The two main technologies are Long Tenn Evolution (LTE) and WiMax. The IEEE (Institute of Electrical and Electronics Engineers) developed the WiMax standard; the 3GPP, an industry body for providers that use GSM (the leading technology for cellular communications), heads development of the LTE standard. WiMax and LTE use different types of wireless spectrum.

How fast ls 4G compared with 3G ?

WiMax providers are advertising download speeds of between 2 megabits per second and 6 mbps, with peak speeds of 10 mbps or more. Verizon, which will launch LTE networks in the United States later this year, is expecting to offer services with download speeds in the 5 mbps to 12 mbps range.may also be able to replace your home DSL or cable modem service with a 4G service you can use both at home and on the road.

Difference between 3G and 4G Network Technologies

1. Downlink data rates for 3G in around 2Mbps in stationary mode whilst 4G specifications it should be 1 Gbps and in highly mobile environment 3G downlink speed should be around 384Kbps and 100 Mbps in 4G networks.

2. Multiple access technique to be used by 3G is CDMA and its variations and in 4G both the technologies (LTE and WiMAX) using OFDMA (Orthogonal Frequency Division Multiple Access) in downlink.

3. In the uplink LTE uses SC – FDMA (Single Carrier FDMA) and WiMAX continue to use OFDMA whilst 3G networks use CDMA variations.

Difference Between WiMAX and WiMAX 2

WiMAX and WiMAX 2 both are wireless broadband technologies to deliver high data rate and low latency. WiMAX is already implemented and WiMAX 2 is in development phase. WiMAX belongs to IEEE 802.16 family and 802.16d and 802.16e is already in place. WiMAX 2 is building upon 802.16m and which is backward compatible with WiMAX. The expectation of WiMAX 2 is to deliver more than 100 Mbps on a device when on mobility of 500 km/h.

WiMAX 2 (Wireless Interoperability for Microwave Access, IEEE 802.16m)

WiMAX 2 is a successor of WiMAX and building upon IEEE 802.16m standard. WiMAX supposed to give more capabilities than 802.16 with backward compatibility with WiMAX Air Interface R 1.0 and R 1.5. WiMAX 2 expected to deliver more than 1000 Mbps with low or no mobility and more than 100 Mbps with mobility with low latency and increased VoIP capabilities.

It’s an ideal solution to provide high speed internet connections to rural areas and it’s a best option for backhauling the local offices or mobile stations. This is an end to end IP technology.

Typically it operates in 450 MHz to 3800 MHz.

WiMAX (IEEE 802.16)

WiMAX (802.16) (Wireless Interoperability for Microwave Access) is a 4th Generation mobile access technology for high speed access. The current version of this technology can provide around 40 Mbps in reality and the updated version is expected to deliver 1Gbps in fixed endpoints.

WiMAX falls under IEEE 802.16 family and 802.16e (1×2 SIMO,64 QAM,FDD) gives 144 Mbps download and 138 Mbps upload. 802.16m is the expected version to be delivered around 1Gbps in fixed endpoints.

WiMAX has fixed version and mobile version. The fixed WiMAX version (802.16d and 802.16e) could be used for broadband solutions for home and can be used for backhauling remote offices or mobile stations. The WiMAX mobile version (802.16m) could be used as the replacement of GSM and CDMA technologies with expected high throughput is referred as WiMAX 2.

WiMAX down Link Data rates:

Air Interface R1.0

2×2 MIMO 10 MHz TDD – Around 37 Mbps

Air Interface R1.5
2×2 MIMO 10 MHz TDD – Around 40 Mbps
2×2 MIMO 20 MHz TDD – Around 83 Mbps
2×2 MIMO 2×20 MHz FDD – Around 144 Mbps

Air Interface R2
2×2 MIMO 2×20 MHz FDD – Around 160 Mbps
4×4 MIMO 2×20 MHz FDD – Around 300 Mbps

Difference Between WiMAX and WiMAX 2 (1) Basically both come from same family IEEE 802.16 (2) WiMAX can offer maximum around 300 Mbps with 4×4 MIMO whereas WiMAX 2 supposed to offer around 1000 Mbps with less mobility or no mobility. (3) Latency will be lower in WiMAX 2 than WiMAX, since WiMAX comes with more VoIP capabilities. (4) WiMAX is already launched and WiMAX 2 is expected to be launched later 2011 or early 2012

 

Differences between 2G vs 3G Network Technology

2G and 3G technologies denote the second and third generation technologies used in wireless communication. In modern world increasing demand for communication has resulted in several standards for mobile communication. Among them 2G and 3G are dominant standards which revolutionize the mobile communication industry in past few years. Both standards emphasize on various targets and as a result various technologies have been introduced.

2G (GSM) Technology

Global System for Mobile communication is also known as 2G which is the first step towards the digital wireless communication over existing analog mobile communication prevailing. Technology standard was first introduced in 1991 and from that onwards number of subscribers has grown over 200 million during 1998. In this technology for the first time SIM (Subscriber Identity Module) is introduced and a more secured and clear communication was established. This has been widely adopted all over the world and currently the most area of the globe is covered with GSM. In GSM the multiple techniques used are TDMA (Time Division Multiple Access) and FDMA (Frequency Division Multiple Access) so that many subscribers are allowed to make calls at a given time. The cell concept is also introduced here and each cell is responsible for covering a small area. Spectrum utilization for GSM falls in to several bands like GSM 900 and GSM 1800 (DCS) used in areas like Asia, Europe etc and GSM 850 and GSM 1900 used mainly in USA and Canada. The bandwidth of the channel allocated per user is 200kHz and the GSM air interface data rate is 270kbps.

3G Technology

3G is the mobile standard specification released which are compatible with the IMT (International Mobile Telecommunications-2000) specifications for multimedia supporting. Since the GSM air interface data rates are not enough to provide high quality multimedia applications through mobile phones 3G specifications are released and paved way for the next generation standard. Applications like video calls, high speed internet, multimedia applications, video streaming, video conferencing, and location based services can be given to the mobile phones. The first commercial 3G network was launched in 2001 in Japan. Here the air interface technology which is also known as the multiple access technique is a variation of CDMA (Code Division Multiple Access) called as WCDMA which utilizes a bandwidth of 5MHz offering high data rates. Also the other CDMA technologies like CDMA2000, CDMA2000 1x EV-DO are used in various places over the world. The data rates for the 3G are a minimum of 2Mbps for stationary mobile users and 384Kbps for moving subscribers in downlink.

Difference between 2G and 3G Technologies 1. 2G is the GSM specification intended for providing mobile communication for voice and 3G is the specification for mobile communication with enhanced capabilities for mobile users other than voice. 2. GSM air interface data rate is 270Kbps and 3G allows a minimum of 2Mbps downlink in stationary mobile and 384Kbps while moving. 3. GSM uses TDMA and FDMA for multiple access technology and 3G utilizes variations of CDMA technology like WCDMA, CDMA2000, CDA2000 1X EV-DO. 4. A5 ciphering algorithm is used in 2G and a more secured KASUMI encryption is used in 3G mobile communication.