![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |
Figure 8 illustrates gateway configuration for redundant operation, and Figure 9 illustrates the behavior during failover.Task A Routing Table Entries
1.
2. Task B NAB LANsTask C NeighborsTask D GP LANDo not configure this local network for B2. To understand the reason, see the neighbor connection in Figure 9, which you added in Task C.Do not configure this local network for A2. To understand the reason, see the neighbor connection in Figure 9, which you added in Task C.Task E Subject Gating
15. Copy subject gating from A1 (see step 13) to B1 (not B2). To understand the reason, see the neighbor connection in Figure 9, which you added in Task C.
16. Copy subject gating from B1 (see step 14) to A1 (not A2). To understand the reason, see the neighbor connection in Figure 9, which you added in Task C.After steps 13–16, A1 and B1 should have identical subject gating configurations with respect to the GP LAN.
In steps 1 and 2, the router name of the backup gateway must be identical to the router name of its counterpart primary gateway. One might think this is illegal, because router names must be unique throughout a WAN (see Routing Table Entry in ).Figure 8 illustrates gateway operation in the normal situation, in which both P-7500s are available:
An idle gateway does not communicate with neighbors or local networks, and does not forward any data. You can configure it through its browser administration interface, but otherwise it is effectively invisible and inert. In this respect, an idle gateway behaves like an idle routing daemon.(In contrast, routing daemons, instances of rvrd, are in a redundant configuration, they are always running—rather than waiting idle. They can communicate with their neighbors and local networks, and they can forward data.)Figure 9 Gateway: Redundant FailoverFigure 9 illustrates failover when P-7500 B fails:
![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |