Article ID: 9430
Products
Matrix N-Series DFE, firmware 6.01.01.0020 and higher
Discussion
It is always recommended to read the
release notes and to save the configuration (
5035), before performing a firmware upgrade (
5040). This provides the most accurate expectation of what will likely be encountered upon upgrade, and also permits a ready recovery should some element of the configuration be unexpectedly modified or missing as a result of the upgrade.
This "best practice" guideline is even more important when upgrading to firmware version 6.x (
6.01.01.0020 or higher), which implements a number of potentially high-profile changes. High availability, VRRP, router MAC address, router memory requirements, SNMP router contexts, system login, and DHCP limits are among the many topics discussed in the release notes.
6.x firmware represents a large-scale change in the way we deploy high availability at Layer 3 in the N-Series. There is now a maximum of one logical router instance rather than two, and any slot can become the router. If there is a DFE Diamond in the system, that will default to being the router before a DFE Platinum will. The slot running router services can be determined by means of the 'show router' command ("Router Services are currently running on module
x").
Thought should be given to how a two-router chassis (e.g. 'router 1' and 'router 2') will work after it is converted to a one-router chassis (i.e. 'router'):
- Any VRRP redundant gateway protocol running on the two routers for slot redundancy is no longer needed for high availability, and should be removed from the configuration either before or after upgrade (9964).Any VRRP redundant gateway protocol running on either router as part of a larger VRRP infrastructure will need to be reconsidered, and potentially modified to accommodate one less router within the chassis.
- Static ARP entries or policies that use the router's MAC address will no longer work, because that address will have changed.
- PIM-related system memory requirements are now true of all modules in the chassis, since any module could be the router (5299).
- Slot-referencing community names (e.g. 'public.router1') tied to SNMP router contexts (5232) may still, but need no longer, reference a slot (e.g. 'public.router').
- Using LAGs (5203) in different slots will allow for better high availability and make graceful restart possible as the router virtual entity moves from one slot to the next.
These changes unrelated to router instancing should also be considered:
- New options have been added to the 'set system login' command (10316).
- Locally defined DHCP Server pool limits of 1024 IP addresses each are now enforced (10499).
