TMS zl Management and Configuration Guide ST.1.1.100430

10-113
Troubleshooting
Troubleshooting the TMS zl Module in Routing Mode
OSPF
When you enable OSPF, the TMS zl Module uses version 2. Again, your access
policies must allow the appropriate multicast and unicast traffic for OSPF.
The following command is a good starting point when troubleshooting OSPF:
hostswitch(tms-module-C)# show ip ospf neighbor
If two TMS zl Modules are installed in separate switches and are OSPF
neighbors, they will not see all link-down events because they are connected
through two switches. If a disconnect occurs, a TMS zl Module will not learn
about this event until OSPF updates timeout.
If two TMS zl Modules do not establish adjacency, ensure that they are using
unique router IDs:
hostswitch(tms-module-C)# show ip ospf general
Troubleshooting High Availability
High availability (HA) sets up redundancy for the TMS zl Module, providing
extended uptime and reliability. HA communication occurs primarily on the
TMS zl Module’s port 2. If the TMS zl Module is in slot C, for example, the port
is C2.
The HA port is an important consideration when setting up an inter-switch
link between two TMS zl Modules (modules in separate switch chassis). You
must make the TMS <slot letter> port 2 a member of your inter-switch link.
When you enable HA, both master and participant modules require a manual
reboot. Once the participant reboots, you manage the cluster—both the
master and the participant—through the master’s Web browser interface.
When you make changes to the master’s Web browser interface, you must
synchronize the cluster.
Note that after the cluster is formed, you cannot access the participant’s Web
browser interface. If necessary, however, you can access the participant’s CLI
using the switch pass-thru interface.