Wednesday, June 29, 2011

A Conceptual Introduction to Static Routing, RIP & OSPF

In large networks, Layer-3 Switches/ Routers are important and inevitable. They help contain the broadcast domain by sub-dividing the network in to various segments. But once a network is segmented, you need to route packets between the various sub-networks. Routing protocols / methodologies like Static Routing, RIP (Routing Information Protocol) & OSPF (Open Shortest Path First) help you to do just that.

Introduction:

Wouldn’t it be a simpler world if a whole campus could be put on a single network? It would, but it would be a very congested network too! So, when you are planning a network for an enterprise company (or) a huge campus it is a good practice to segment the network into multiple sub-networks.
Layer-2 Network Switches are enough to communicate within a network (sub-network) but they cannot pass on packets to other networks. That’s where you need Routers / Layer-3 Switches (L3 Switches with routing capabilities are used more these days).
If there are only two networks and one path between them, it is easy to specify the routing table to the L3 Switch/ Router – Just forward all packets with a certain destination IP address range to the other L3 Switch/ Router. That’s it! But practically, there are multiple sub-networks within a campus and multiple links to (and from) each sub-network. Multiple links are required for both reaching destination networks faster and also for redundancy in links (in case of primary link failure).
That’s why we need Routing Methodologies & Routing Protocols. L3 Switches/ Routers form something called as Routing Tables where they store information on the various nodes in the network and the best path to reach each node. These Routing Tables can be formed manually (for small networks) using Static Routing (or) can be formed automatically (for larger networks) by using dynamic routing protocols like RIP, OSPF, BGP, etc.
Another important function of the Dynamic Routing Tables is to automatically adapt to the change in network topologies (like link/ device failures, addition/ deletion of nodes, etc) by first identifying that change quickly and using alternate routes (links) / devices to reach the destinations.

Static Routing:

The process of specifying the routing tables for every router manually by a network administrator (in a small network) is called Static Routing. Basically, if there are only a couple of Layer3 Switches in the network, it is easy to specify the routes for packets to be delivered to the other network manually.
Static Routing is simple to implement and is fast as it doesn’t require any extra processing capacity / additional bandwidth. But it does not route packets around failed links/ devices and hence does not account for redundancy. So, a small network without any need for redundant links might find Static Routing useful.

Distance Vector Routing (Vs) Link State Routing:

Dynamic Routing is divided into two major categories – Distance Vector Routing & Link State Routing.
In Distance Vector Routing, each L3 Switch/ Router maintains a table of distances/ hops to every node from its perspective of the network and the least cost route between any two nodes is (mostly) the route with the minimum distance or minimum hops. In Distance Vector Routing, each node shares its table with its immediate neighbor more frequently (like every 30 seconds) and when there is a change in the network topology. Example: RIP
In Link State Routing, each L3 Switch/ Router maintains a complete network map of the local area that it is present in, with all the routers maintaining an identical database. The least cost route between any two nodes is calculated using many factors including maximum bandwidth, minimum delay, maximum throughput, etc. In Link State Routing, only the topology updates are exchanged between the routers when there is a change in network topology (or) every 30 minutes (less frequently). Example: OSPF

RIP (Routing Information Protocol):

* RIP is a open standards based distance vector routing protocol.
* RIP is an Intra-domain routing protocol used within an autonomous system – AS (where all routers are controlled by the same entity).
* In RIP, all the routers / L3 switches create a unique routing table with information like -  lowest cost links to each router in its network, next hop router(s), etc.
* RIP uses hop count/ distance as its link cost metric.
* RIP allows for convergence around failed links/ network topology changes, but recovery is in the order of minutes.
* Total number of nodes (Routers/ L3 Switches) supported by RIP is limited due to finite hop count restrictions in the protocol.
* Periodic updates of Routing Tables (every 30 seconds for example) happens even when there are no changes in the network topology.

OSPF (Open Shortest Path First):

* OSPF is an open and standards based routing protocol.
* OSPF is an Intra-domain routing protocol based on link state routing.
* In OSPF, the entire network is called an Autonomous System (as it is maintained by one entity). The Autonomous System is divided into different areas (sub-networks).
* In OSPF, there are some special types of routers based on their function – Area border routers connect two or more areas, Autonomous System boundary routers connect two or more Autonomous Systems, etc.
* The Router/ Layer 3 switch maintains the complete network map of all the nodes in the area that it is present in. The routing table is the same for all the routers in a given area.
* Link State Advertisements are exchanged between all the routers in an area – Every router receives the LSA’s of every other router within an area.
* OSPF updates the routing tables of all the routers in an area immediately when there is a change in the network topology – which is faster than RIP, and also periodically (every 30 minutes for example) – which is less frequent than RIP.
* OSPF calculates the link cost in terms of minimum delay, maximum throughput, maximum bandwidth etc. So, it is not strictly based on the hop count and OSPF gives higher priority for faster links (for example).
* OSPF supports Variable Length Subnet Masks (VLSM), which gives it the ability to work with different subnets and hence conserve IP addresses.
* OSPF provides for authentication of messages between the Routers/ L3 Switches (through MD5).
* QoS (Quality of Service) metrics can be applied to OSPF based on bandwidth calculations (for example), to avoid high latency paths.

Thursday, June 23, 2011

Create a PPPoE client connection

You can install the PPPoE client just like you install any other dial-up networking connection. To create a PPPoE client connection, follow these steps:
  1. Click Start, click Control Panel, and then double-click Network and Internet Connections.
  2. Click Network Connections, and then click Create a new connection in the Network Tasks pane.
  3. After the Network Connection Wizard starts, click Next.
  4. Click Connect to the Internet, and then click Next.
  5. Click Set up my connection manually, and then click Next.
  6. Click either Connect using a broadband connection that requires a user name and password or Connect using a broadband connection that is always on.
  7. Type the Internet service provider (ISP) name that your ISP provided, and then click Next.
  8. Type the user name that the ISP provided.
  9. Type the password that the ISP provided.
  10. Type the password one more time to confirm it, and then click Next.
  11. Click Add a shortcut to this connection to my desktop.
  12. Click Finish to complete the wizard.

Wednesday, June 8, 2011

Happy IPv6 Day, What Did You Get?

World IPv6 day, where Web properties around the world test drive their sites using the IPv6 protocol, is today. It's not a holiday by anyone's real stretch of the imagination, nor is it a full-on switch-out. But it will be a milestone in the ultimate, slow transition from current IPv4 addressing to IPv6 addressing.

According to the Internet Society's FAQ page on the event, "is a global-scale test flight of IPv6 sponsored by the Internet Society. On World IPv6 Day, major Web companies and other industry players will come together to enable IPv6 on their main Web sites for 24 hours. The goal is to motivate organizations across the industry -- Internet service providers, hardware makers, operating system vendors and Web companies -- to prepare their services for IPv6 to ensure a successful transition as IPv4 address space runs out."
Basically this is one big 24-hour awareness event to prepare us all for what life will be like after all the current 32-bit IP addresses run out.
Oh, wait, that already happened.

There is no sign of any kind of catastrophic collapse now that there's no more unallocated IPv4 addresses, but there is a little bit more urgency in the efforts to get people to pay more attention to IPv6. But the fact that there's no Year 2000-type disaster looming in the headlines seems to have put a damper on IPv6 network deployments.
The trick to implementing IPv6 may be not treating it as a upgrade migration project -- at least in traditional terms. When you upgrade software, for instance, the older version of the software is typically removed, and your organization must deal with the consequences -- good and bad -- of the new software version.
But when implementing IPv6, there's no reason to eliminate IPv4. In fact, you would not want to, because a vast majority of networked servers will still roll with IPv4 in a dual-stack or tunneling scenario for a long time. Instead, when you swap out existing infrastructure for any reason, all you need to do is just make sure the new equipment or software is IPv6-compliant. Then it's just a matter of taking a little extra time to make sure IPv6 is running alongside IPv4 for that new component.
That's a piecemeal way of solving the problem, of course. Even as you roll out IPv6-compatible components, you will also need to identify all of the components in your infrastructure that actually need IPv6. It could be a big list, depending on the size of your organization, because there's a lot of IT assets that are network enabled. Client computers, Web servers, file servers, printers, routers, WiFi, firewalls, switches... even any mobile device your organization for which has responsibility.
Without a complete inventory, there could come a day when your organization will switch over to IPv6 and discover gaping deadzones in your network topology because of one forgotten switch somewhere.

The new protocol is about more than just packets. You also need to make sure IPv6 can do the tasks you need it to do. IPv6 is a protocol that is still relatively immature as an application platform. There are still a lot of things that IPv4 can do that IPv6 users can't, because there may not be networking applications that are IPv6 ready.
In May, for instance, Cisco took a big step forward in solving this problem when it released a new version of its IOS platform with a reported 200 new IPv6 features.
"Our biggest goal in IOS now is to have parity between IPv4 and IPv6," Faraz Aladin, director, Marketing Cloud Switching and Services at Cisco told InternetNews.com. "Whatever you can do in IPv4, you should be able to do with IPv6."

Some of this is really basic stuff, too. The Cisco announcement in May highlighted the availability of the Network Time Protocol in IPv6. But in truth, any application that uses IP addresses will need to be updated.
Finally, you will need to make a plan on how to handle network security. There are some experts who are suggesting that you won't need network allocation tables (NATs) at the edges of your network anymore. With 2128 addresses available, you don't need an internal set of IP addresses contained behind firewalls. Each machine or device can have their own IP address. But if your network is on the same topology level as the entire Internet, what does that mean for security?
Right now, security is probably the biggest question mark for IPv6 deployment, because network security relies in well-defined network edges, ideally guarded by the firewall. If NATs went away, the firewall would have to maintain security across a fuzzier boundary. It's been suggested that with the huge network segments available in IPv6, malicious hackers would have to scan your network segment for years to find a potentially vulnerable target. Great, but what if you have to run the same kind of scan for internal vulnerabilities?
Another potential angle of attack: IP options in IPv6 like destination or authentication information aren't found in the main header, but in extension headers. This means an IPv6 packet is roughly put together like this: Main header and extension headers and packet content. Malicious packets could contain specific extension information or just a ton of junk extension data that might potentially choke the target device.
Security, then, will be the space to watch as you start moving towards IPv6. You must make sure you have efficient security tools in place that follow the best practices--which are even now being put together. Until these issues are solved, start making that inventory, and analyze which applications use IP addressing. Then you will be ready to swim into IPv6 when the lifeguards say the water is safe.

Thanks to Author
Author-Brian Proffitt , Internet news

Sunday, June 5, 2011

Why you need to implement a Storage Area Network using iSCSI over an IP Network

what is iSCSI and why it makes a good storage area network (SAN)
advantages of storage area network (SAN)
The first image defines what is iSCSI and what exactly its role is, in Storage Area Networks. Convergence is happening over IP everywhere (one reason why IP is exciting!), and even the Storage Area Network is expected to converge over IP networks through iSCSI especially with the anticipation of lossless Converged Enhanced Ethernet. The other popular convergence option being FCOE (Fiber Channel Over Ethernet).
The second image lists the advantages of Storage Area Networks, in general. If you have been hesitating to implement/ upgrade to a Storage Area Network (SAN) because of cost, complexity, or any other reason, iSCSI SAN now offers you lot of advantages in addition to the ones mentioned above. Let us look at some of them:
  • With iSCSI, a separate network for SAN is not required as it uses the existing IP Networks and components (NIC, Switches, Cables etc) to create the Storage Area Network.
  • The cost of creating a iSCSI SAN is very less when compared to the cost of creating a FC(Fiber Channel) SAN.
  • iSCSI based SAN can co-exist with the existing FC based SAN. Customers have the option of retaining their existing investments on FC SAN’s and still expand by adding additional storage capacity using iSCSI SAN.
  • iSCSI SAN does not have any distance limitation. You can have a Data Center anywhere in the world and still back up/ restore the data remotely (over WAN/Internet) to your Local Area Network/ vice versa.
  • Since iSCSI SAN can be located anywhere, they are very useful for disaster recovery objectives.
  • iSCSI SAN can use either a specialized HBA (Host Bus Adapter) to connect the servers to the SAN (or) just use the standard NIC Cards/ Ethernet ports for the same. This enables server I/O consolidation and reduces complexity/ cost.
  • Gigabit Server Adapters (NIC Cards) are normally available in the market, and iSCSI can use them to connect to the network at Gigabit speeds today. They are available in Single Port/ Dual Port/ Quad Port etc, and connect to the server using PCI Express slots. Very soon, even 10 Gigabit Ethernet NIC Cards are expected to become popular, which offers much more capacity/ speed for SAN performance.
  • Since iSCSI uses the normal IP based network components, its easy to learn, implement and maintain. Contrast this with Fiber Channel (FC) based SAN which requires a high level of expertise to create and maintain them.
  • iSCSI is very much suitable for implementation of SAN in virtual server environments as it supports software initiators that make such integration easier. Also, since iSCSI supports whatever bandwidths supported by IP Networks, it can support 10 GE which might be required for virtual server environments.
  • iSCSI allows direct backup’s to tape or disks, even from certain virtual servers.
Limitations / Disadvantages of iSCSI SAN:
  • The IP network, currently is a best effort network. Hence it may drop packets or deliver them out of order during network congestion. But these attributes are not favorable for storage area networks as they need to be highly reliable. So, till the lossless Converged Enhanced Ethernet technologies are standardized and implemented, iSCSI SAN may still not be the most reliable option when compared to FC SAN.
  • Server CPU’s may be burdened with iSCSI and TCP/IP Stack processing if HBA/ NIC cannot offload that function. This may result in the server processor cycles not working to their capacity for application processing, which is what they are primarily supposed to do.
  • Since iSCSI is generally not run on a separate network (but is mixed with the IP network traffic), there may be networks congestion/ bandwidth constraints during peak hours especially if the network is not designed to support the bandwidth required for both the applications.
  • iSCSI operates on clear text protocol (normally) and hence there is a chance that it might be exposed to hackers who are more familiar with the widely used IP Networks.
Salient points/ Good practices for iSCSI SAN that might be useful:
  • CHAP (Challenge Handshake Authentication Protocol) can be provisioned for authentication of iSCSI messages for security. Encryption, even if possible, may not be feasible – currently.
  • Some specialized HBA’s/ NIC Cards can offload processor hungry processes like iSCSI and TCP/ IP Stack processing. This can make the server processor work more efficiently.
  • Major Operating Systems (Including Windows and Linux) provide built-in software initiator drivers for iSCSI which makes their integration with IP network components, easy.
  • Its better to have a dedicated port for iSCSI SAN connection from a server (instead of sharing one network port). Better still, redundant ports can be provided for High Availability/ Link Aggregation.
  • Its a good practice to have iSCSI packets flow on a separate VLAN so that the storage traffic can be logically separated from the general network traffic. Better still, if iSCSI can be operated on its own physical network segment (with dedicated switches/ cables, etc).