There are very few technologies that come along which actually make things easier for IT staff. This is particularly true with new technology introductions. Very often, the introduction of a new technology is problematic from a systems service up time perspective. With networking technologies in particular, new introductions often involve large amounts of intermittent down time and a huge amount of human resources to properly plan the outages and migration processes to assure minimal down time. More so than any other, network core technologies tend to be the most disruptive due to their very nature and function. Technologies like MPLS are a good example. It requires full redesign of the network infrastructure as well very detailed design within the network core itself to provide connectivity. While some argue that things like MPLS-TP helps to alleviate this, it is not without cost – and the distruption remains.
IEEE 802.1aq or Shortest Path Bridging (SPB for short) is one of those very few technologies that can introduced in a very seamless fashion with minimal disruption or down time. It can also be introduced with minimal redesign of the existing network if so desired. A good case point example is a recent project that we have been working on with a large health care provider up in the northeast US. This was a long time Avaya networking customer who had an installed base of existing ERS 8600 routing switches. There was particular portion of the topology that interconnected the customer’s two data centers which were located in separate geographic loctions. This was the portion of the network topology that they chose to upgrade and introduce shortest path bridging.
The original intention was to upgrade the existing backbone switches to code that could support shortest path bridging (v7.1). They would then build out a parallel routed core in the resulting new ISIS routing plane. The ISIS environment would be kept latent and secondary by the resetting of its global priority to something lower than OSPF. Typically, this value is set at 130 (the default for ISIS is 7). Once the parallel routed core is built out as a mirror to OSPF, the systems are checked for validity and then once assured of stability, the priority of ISIS is then reset back to its default value of 7. ISIS then becomes the primary routed plane and OSPF is relagated to a secondary role. After system checks and validation, the OSPF network can be kept as secondary for as long as required. Then, at a later point in time, it can be decommissioned to leave ISIS as the sole core routing protocol for the enterprise core. This is a very seamless migration that provides for zero downtime to the overall networking core.
After a survey of the equipment however, it became obvious that due to its age and slot density requirements (circa- 2000-2001) would need to be completely upgraded – including the switch chassis. Rather than view it as an impediment we quickly realized that by implementing a parallel routed core infrastructure the upgrade and migration of the critical path could be accomplished with little or no down time to the network core. This was in comparison to a gradual swap out and upgrade of the existing core which would have meant multiple outage occurances for each chassis swap out.
The theory was based on the diagram below, which shows the existing OSPF routed core running in parallel to a new SPB based ISIS routed core. By using a series of migration techniques which we will cover shortly, both routed cores would work in tandem with networks gradually migrated over to the new ISIS routed core in a controlled and phased approach.
Figure 1. Parallel OSPF and ISIS routed cores
The first step in the project was to account for the various VLAN’s that were provisioned in the existing OSPF routed core. Part of this was to also identify if they were one of two types. The first being VLAN’s that did not traverse the routed core by the use of Q-tagged trunks. These we identified as ‘peripheral VLAN’s’ in that the only Q-Tagged tunks that they ran over were along the edge and over the SMLT ‘Inter-Switch Trunks’. The second type was a VLAN that existed in multiple places in the routed core and hence traversed the routed core by the use of Q-tagged trunks. These we labeled as ‘traversal VLAN’s’. Figure 2 illustrates the difference between the two VLAN types. This was an important step in the investigation because as one will see it largely determined the migration method for a given VLAN.
As is noted in other white papers, SPB offers various provisioning options. These are listed below for the convenience of the reader.
L2 Virtual Service Network
This is a provisioned path across SPB, known as an I-SID in IEEE terms that inter-connects VLAN’s at the SPB edge. Taken as such it can be termed as a VLAN extension method somehwat anologous to Q-tagged extensions.
L3 Virtual Service Network
This is a provisioned path across SPB, known as an I-SID in IEEE terms that inter-connects VRFs at the SPB edge. Taken as such it can be termed as a IP VPN method somewhat anologous to VRF lite.
Inter-VSN routing
This is a method of interconnecting Virtual Service Networks by the use of external routers or other devices. A good usage example is in a data center topology where user or ‘dirty’ VSN’s interconnect to data center or ‘clean VSN’s by the use of security perimeter technolgies such as firewalls and intrusion protection type devices.
IP Shortcuts
This final method does not involve the use of VSN’s at all but instead works on the injection of IP routing directly into ISIS and utilizing ISIS as an actual internal gateway routing protocol or IGP.
For the purposes of the migration we chose to use a combination of IP shortcuts in order to implement ISIS as the replacement core routed topology and L2 VSN’s to facilitate the connectivity to support the ‘traversal VLAN’s’ which would require multiple points of presence across the routed core.
In essence the network core migration involved three major steps:
1). Build out parallel network segments that match in almost every sense topologically. The new segment will run ISIS/SPBm as its core protocol. A migration link will be set up between the two routed domains to provide for a communication path during the migration. This link will be a MLT configuration for both bandwidth capacity and resiliency.
2). Redistribute VLAN’s and IP routes into the SPBm ISIS core on a switch by switch and VLAN by VLAN basis. Both ISIS and OSPF routing domains will be utilized throughout the migration process.
3). After all network migrations are completed the OSPF network core is to be dismantled.
If properly orchestrated and implemented, we strongly felt that this could be accomplished with zero network downtime for the local core network. There would however be short outages for each switch as it is migrated over to the SPBm/ISIS core. There would also be short outages for the individual VLAN’s during the final migration steps over to the new ISIS core. These however would be minimal and could also be scheduled during opportune windows that the IT staff had on a regular basis. The rest of this document will provide a more detailed outline of the three project phases listed above.
The diagram below illustrates the various types of VLAN’s and how they relate to the overall parallel routed cores. Note that with the introduction of SPB there is an additional type of VLAN (subnet) that is introduced which is a traversal VLAN that is in the process of migrating to the new routed core but still uses OSPF as its IGP. This required a number of items to work successfully. First we need to interconnect the VLAN by the use of L2VSN’s (I-SIDs) across the SPB ISIS routed core. This provided for connectivity, but due to the L2 nature that provides extension back into the OSPF environment, NOT the use of ISIS in an L3 sense. Additionally, we added in OSPF to ISIS and ISIS to OSPF redistribution at the migration link interface between the new and existing cores. This provided for the ability for the migrating VLAN (subnet) to have routed connectivity into the new ISIS routed core via redistribution but still use OSPF as its IGP. As the resident switches and systems were migrated over, the VLAN (subnet) would eventually be redistributed direct into ISIS and effectively decommisioned from the OSPF routed core. Again, by the use of the OSPF to ISIS and ISIS to OSPF redistribution the completely migrated network would still have connectivity over to the older OSPF routed core and visa versa. With the exception of the actual movement of switches and decommissioning of the subnet from OSPF and redistribution into ISIS the network downtime would be zero. More importantly, there would never be a time when the network core was not functional in a holistic sense.
Figure 2. Various migration VLAN types
Taking a closer look at the ISIS side in the illustration below will provide a better feel for the actual topology in action. As noted in the diagram, we show the three VLAN types in the new SPB ISIS environment. First, for the completely migrated dual homed VLAN; it is simply redistributed into ISIS and routed accordingly. Due to the fact that it is provisioned as a Q-Tagged VLAN over the edge SMLT IST there is no use of VSN’s, the peripheral VLAN is simply redistributed direct into ISIS by the use of IP shortcuts.
In the case of the traversal VLAN’s the illustration shows VLAN A which is a completely migrated traversal VLAN that is set up with VRRP Master Backup at various points for router redundancy. The VLAN (subnet) is then redistributed direct into the ISIS routed core by the use of IP shortcuts. This provides for the multiple points of presence required in the routed core by the use of L2 VSN’s and for the IP connectivity into the ISIS routed core by the use of IP shortcuts. The third VLAN type (VLAN C) is a migrating VLAN (subnet). As pointed out above, this is a VLAN that is extended over from the old routed core by the use of Q-tagging (old side) and L2 VSN’s (new side). As the diagram also shows, the migrating VLAN C (subnet) will continue to use OSPF as its routing protocol until all systems are moved over to the new core. At that point in time, the subnet is decommisioned in OSPF and redistributed direct into ISIS and will mirror VLAN A with the exception that there will be four VRRP instances and not two.
Figure 3. A closer view of the new ISIS core and various VLAN types
Normally is such a scenario, one would have to deal with prefix lists and route policies to suppress the advertisment of the networks on one side or the other as they are co-resident in both routed cores. We were able to avoid this by simply not assigning IP addresses to the VLAN’s in the new core during the migration. By not doing this, the VLAN’s would simply not be distributed direct into ISIS and all systems connected to the subnet would use OSPF for all IP routing until the final migration step.
Prior to the actual migration project we thought it prudent to test out the migration scenario as well as use the environment to provide knowledge transfer to the customer. As a result we set up an OSPF environment in the lab prior to actual deployment that looked like the toplogy below in figure 4. Note that both VLAN types (peripheral and traversal) are represented in the diagram. The switch in the lower left hand portion of the illustration shows a switch that provided for the OSPF routed environment in the lab test. Note that OSPF also is supported on the SPB core in the form of an ASBR function. In this example, IP network 10.0.12.0/24 has connectivity to 10.0.11.0/24 via OSPF. (10.0.11.0/24 serves as the redistribution subnet). 10.0.12.0/24 also has connectivity to 10.16.110.0/24and 10.16.111.0/24 respectively by the use of OSPF to ISIS and ISIS to OSPF redistribution. In summary, all IP subnets have routed connectivity to one another.
Figure 4. Existing provisioned SPB ISIS core.
The next step was to introduce a migration VLAN into the lab test. We did this by creating a new VLAN on the OSPF side and gave it the IP address of 10.0.13.0/24. As the figure below shows, we were able to extend that VLAN out across the migration link by the use of Q-tags on the OSPF side and L2 VSN’s in the new SPB ISIS core. We then emulated system moves over to the new core. Note that during this time 10.0.13.0/24 utilized the OSPF protocol as its IGP. As a final step to the migration, the VLAN was deleted from the OSPF environment including any Q-tag extensions and then assigned IP addresses, VRRP Master Backup on the ISIS side and redistributed direct into ISIS.
Figure 5. Migration VLAN case point example
In summary, the migration steps can be summarized as follows:
1). VLAN is extended over migration MLT from OSPF side
2). VLAN is assigned at required points of presence. NO IP addresses configured yet!
3). Add port members as required and create I-SID to connect VLAN’s togther
4). Migration can now proceed (systems are moved over to new core)
5). Upon completion, decommission network from legacy OSPF side (short outage)
6). Assign IP addresses at required VLAN POP’S , set up & enable VRRP Master Backup
7). Remove VLAN from migration MLT (clean up)
The following shows the CLI sequence to perform these steps. Note that ISIS redistribute direct is already set up in the environment. For clarity and reference, the redistribution method for DC3-8800-1 is shown below:
#
# IP REDISTRIBUTION CONFIGURATION – GlobalRouter
#
|
ISIS to OSPF redistribution. |
ip ospf redistribute isis create
ip ospf redistribute isis enable
ip ospf redistribute direct create
|
Direct to OSPF redistribution.The “supress_IST” route policy is used to not advertise the IST subnet |
ip ospf redistribute direct route-policy “suppress_IST”
ip ospf redistribute direct enable
|
OSPF to ISIS redistribution. |
ip isis redistribute ospf create
ip isis redistribute ospf metric 1
ip isis redistribute ospf enable
ip isis redistribute direct create
ip isis redistribute direct metric 1
|
Direct to ISIS redistribution. The “supress_NETS” route policy is used to not advertise the IST subnet as well as others that may require suppression during migration |
ip isis redistribute direct route-policy “suppress_NETS”
ip isis redistribute direct enable
#
# OSPF ACCEPT CONFIGURATION – GlobalRouter
|
Simple accept policy to ignore advertisements coming from its IST peer (DC3-8800-2). This avoids less than optimal IP routes |
#
ip ospf accept adv-rtr 10.6.28.2 create
ip ospf accept adv-rtr 10.6.28.2 enable
ip ospf accept adv-rtr 10.6.28.2 route-policy “reject”
As a result to the above, as soon as the VLAN is assigned IP addressing and VRRP Master Backup it will have routed connectivity into ISIS, no other steps are required. Also note that the 10.0.13.0/24 network needs to be decommisioned in OSPF BEFORE being provisioned into the ISIS environment. This will involve a short outage (minutes) for the given subnet.
10.0.13.0/24 will then have connectivity back into the OSPF side by the use of the route redistribution occuring at the migration link point which again has already been configured as per the above.
1). Set up VID 3 on the MLT (new side) both DC3-8800-1 & DC3-8800-2 (assuming this is done on the 5510)
config vlan 3 create byport 1 name “TEST_MIG1″
config vlan 3 add-mlt 2
2). Set up port & I-SID configuration. Both DC3-8800-1&2
config vlan 3 ports add <members> (i.e. 10/9-10/10)
config vlan 3 i-sid 3
3). Set up port & I-SID configuration on each required DC1-8800-1 & DC1-8800-2.
config vlan 3 create byport 1 name “TEST_MIG1″
config vlan 3 ports add <members> (i.e. 10/9-10/10)
config vlan 3 i-sid 3
4). Migrate systems as appropriate (note – during migration 10.0.13.0 still uses OSPF due to the fact that no IP addresses are yet assigned on ISIS side)
5). Once migration is complete 10.0.13.0/24 (VID3) is decommissioned from 5510 (legacy OSPF environment)
6). Assign IP addresses. Enable VRRP Master Backup and VRRP on DC3-8800-1&2, DC1-8800-1&2
config vlan 3 ip create 10.0.13.*/255.255.255.0
config vlan 3 ip dhcp-relay enable
config vlan 3 ip vrrp 3 address 10.0.13.1
config vlan 3 ip vrrp 3 backup-master enable
config vlan 3 ip vrrp 3 enable
* Is 10.0.13.2,3,4 or 5 as required.
MIGRATION IS COMPLETE! 10.0.13.0/24 should now be visible to the 5510 across the OSPF-ISIS Redistribution on 10.0.12.0/24. Every subnet will have routed connectivity to the other.
Summary
As can be seen by the example provided here, what can be a very complex migration project is now greatly simplified into a concise set of simple steps by the use of Shortest Path Bridging and VENA. OP/EX improvements when compared to other network virtualization technologies like MPLS are incomparible. Moreover, network downtime is predicatable, controllable and very short in comparison.
Avaya’s VENA architecture facilitates a flexible yet powerful infrastructure that allows for this type of capability. It is also important to note that only a subset of the network services offered by VENA is used in this case point example. Very few technologies can claim such ease of introduction and actually ease the migration that they themselves require in order to be effectively used.
For more information please feel free to visit http://www.avaya.com/networking
Also please visit our VENA video on YouTube that provides further detail and insight. you can find this at: http://www.youtube.com/watch?v=ZSbycaOvy5I
Happy Holidays to all!
With the very best wishes for the New Year!
Ed Koehler's Blog 