Review/Perspective: Changes to a Network

1.2.a Evaluate proposed changes to a network

  • 1.2.a [i] Changes to routing protocol parameters
  • 1.2.a [ii] Migrate parts of a network to IPv6
  • 1.2.a [iii] Routing protocol migration
  • 1.2.a [iv] Adding multicast support
  • 1.2.a [v] Migrate spanning tree protocol
  • 1.2.a [vi] Evaluate impact of new traffic on existing QoS design

 

Evaluation of network changes should always be done to fully understand the scope of work being done, the impact changes to the network can cause to existing network routing, and planning to ideally cause the least amount of network downtime should network changes require downtime.

Changes to routing protocol parameters

Each routing protocol IOS supports can be configured with very high granularity to manipulate what routes are advertised, which neighbors they are allowed to become neighbors with, metrics and weights of prefix’s can be manipulated to make them better or worse, and even advertise equal cost routes.  Routing protocol changes usually require an overall understanding of the routing of the entire network so if changes are imposed there is little to no impact on existing routing.

Migrate parts of a network to IPv6

If you intend of servicing IPv6 in only portions of a network you can do so, however the question then becomes if you intend those IPv6 networks to be able to communicate with your other IPv4 networks.

If not, then network configuration becomes easy as IPv6 can be configured on top of IPv4 in what’s known as a Dual Stack Environment, making the transition to IPv6 very smooth since it can be built and tested on top of the existing IPv4 network. With the underlying IPv4 networks being phased out/removed over time as needed.

If you intend on the IPv6 networks to communicate with other IPv4 prefixes on your network then it would be required to implement some method of 6to4 network translation to facilitate inter-protocol communications.

Routing protocol migration

This can be typically done in a number of different ways.  If two separate networks needs to be merged together into one and each uses its own IGP for routing, temporarily redistributing routes into each network is an option provided no subnet overlap exists.  If it does then some form of network address translation would be needed for the two networks to be able to communicate with each other temporarily until a new IP addressing scheme can be devised and implemented.  Careful consideration on multiple interconnects into the same network need to be considered and accounted for if network advertisement and redistribution is used so routing loops aren’t imposed on the network at multiple interconnect points between the two.  This allows the initial communication between the two separate networks.

As for the migration, to another protocol you can systematically begin configuring the new IGP on top of the old IGP provided you’ve adjusted the global Administrative Distance of the protocol so routing decisions are not accounted for in the IPv4 RIB for that protocol.  Once all routes have been advertised/learned properly by the IGP process you can begin adjusting Administrative distance of the new IGP down to a preferred metric so it begins to take over and adjusts the IPv4 RIB with the new IGP best path routes.  At which point you can remove the old IGP configuration completely.

Adding multicast support

When considering multicast functionality it’s useful to determine which method of multicast is ideal for the network.  If its a small network with no congestion then PIM can be used to PIM-DM between routers to send multicast traffic.  If there are congestion issues or you prefer more efficient multicast traffic processes PIM-SM can be used between routers.  IGMP is typically used on LANS for multicast between hosts.

Migrate spanning tree protocol

Spanning tree protocol migration is simpls if its a migration from PVST+ to RSTP.  RSTP is compatible and works with PVST+ however you can still encounter convergence issues if you don’t migrate all devices at once if a link error occurred.  Also, all VLANs will essentially bounce all port connectivity once switched over while the devices go through their process of Root determination, and learning the designated network paths to forward/block.

Transitioning from PVST or RSTP to MST can be simple if the device you’re implementing MST on is a transport device in between other PVST or RSTP routers.  All thats needed is an MST instances to the appropriate ingress/egress interfaces to reconnect them to the rest of the PVST/RSTP network.  This method could also be used as a systematic approach to replacing or consolidating VLANs throughout the network to an MST only solution if migrating to MST.

Evaluate impact of new traffic on existing QoS design

If new traffic classes are introduced to a network that already has pre-defined QoS design it depends how its introduced to how it would impact existing QoS.

If the new traffic is plentiful and saturates the network then a decision would need to be made to adjust the QoS design to accommodate the new traffic so it can pass, or rate limit it in a low queue so it has least priority.

You can use Netflow and Top Talkers in routers to determine the exact kind of traffic is traversing an interface in either direction.  You can also use netflow exporters to export this data to applications that can read it and keep track of it historically so network flows can be reported on and analyzed so network engineers can make informed decisions on how to service the traffic.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s