Future Network Considerations | OSPF Network Design Solutions

Table of Contents

Fragment Headers

As of this writing, when you send a particularly long datagram, your ISP might fragment it and send it as many smaller datagrams. With the fragment header of IPv6, you decide when to fragment your message and if so, where to do it, so that loss of data is minimized. The Fragment Header can be added to an IP header to enable a machine to fragment a large datagram into smaller parts. This was built into IPv6 to facilitate better use of fragmentation. If a particular datagram is very large, the fragmentation can be enabled to pass the datagram along the network quicker, they also allow for better use of WAN (Wide Area Network) bandwidth.

Hop-by-Hop Headers

Hop-by-Hop headers are used to instruct, via IP options, every machine the datagram passes through. There are three options included in the Hop-by-Hop header field. These all have a standard format of a Type Value, a Length, and a Value. To further confuse you, there are three types of Hop-by-Hop headers, including: Pad1, PadN, and Jumbo Payload

The Pad1 option is the simplest, by far. It is a single byte with a value of 0, no length, and no value. It is used primarily in the alteration of the order and position of other options in the header when necessary. This is usually determined by the application the user is using and is transparent. The PadN option is very similar. The only difference being that the PadN has N zeros placed in the Value field and a calculated value for the length. Finally, there is the Jumbo Payload extension option. This is used for datagrams that exceed 65,535 bytes. To handle these larger datagram lengths, the IP header’s length field is set to 0. This will then redirect the routers to the extension to pick-up a correct length value. The Length field is defined in the extension header using 32-bits. This is in excess of 4 terabytes.

Chapter Summary

This chapter explored the features that made SNMPv2 unique. These features include the new Alarm and Event groups that enable you have quick and easy access to information concerning the state of your network. When properly utilized, they can also provide the Network manager with a powerful tool. By utilizing SNMPv2, you, as the network manager, have a one-click access to all components on your network. If your network is geographically separated, the distributed manager has the capability to have the error messages sent directly to your NMS. The newly developed Alarm and Event Groups in the SNMP MIBII do this. Overall, this manager-friendly protocol will save both time and money. In addition, you were also given a brief peek under the covers concerning the soon to be released SNMPv3.

RMON is the fastest growing network management tool around. Its ability to monitor the performance of the entire network as opposed to just the components brings a new and powerful tool to both network engineers and managers. This section covered both RMON1 and RMON2 so you gained an understanding of how when combined they cover every layer of the OSI model. This chapter discussed how RMON enables you, the manager, to monitor traffic at all layers of your network by providing host and matrix tables. In addition this chapter discussed how RMON allows you to monitor by host, or conversation, various network protocols.

This chapter then covered IPv6 and removed some of the myths and mystery surrounding it. This section allowed you to explore some of the new features surrounding this protocol and how it has improved over IPv4. IPv6 has a newly designed header format that allows for easier transmission across your network, and it also frees up the bandwidth by eliminating the need for all IP datagrams to be transmitted over the entire network.

Case Study: Implementing IPv6 in Your Network

This case study will briefly describe one way of slowly implementing IPv6 in your network if your network has a large number of users whose connectivity requirements focus primarily on access to local e-mail, database, and applications servers.

When considering how to implement IPv6, it might be best to initially upgrade only isolated workgroups and departments to IPv6, and implement backbone router upgrades at a slower rate. This is an excellent way for enterprise networks to gracefully transition to IPv6.

As enterprise routing protocols such as OSPF for IPv6 mature, the core backbone IPv6 connections can be deployed. After the first few IPv6 routers are in place, it might be desirable to connect the various IPv6 workgroups with router-to-router tunnels. In this case, one or more routers providing IPv6 connectivity would need to be configured as tunnel endpoints.

From a routing protocol standpoint, tunnels appear as a single IPv6 hop, even if the tunnel is comprised of many IPv4 hops across different types of media. IPv6 routers running OSPF can propagate link-state advertisements through tunnels, just as they would across conventional point-to-point links. In an IPv6 environment, OSPF will have the advantage of flexible metrics for tunnel routes, to ensure that each tunnel is given its proper weight within the topology. In general, routers make packet-forwarding decisions in a tunneling environment in the same way that they make decisions in the IPv6-only network. The underlying IPv4 connections are essentially transparent to IPv6 routing protocols.

Table of Contents