Attracting traffic to the active NAT node (from inside and outside) is based on the routing.
On the outside, the active pool address range is advertised. On the inside, the destination prefix or steering route (in case of filter based diversion to the NAT function) is advertised by the node with the active pool.
The advertisement of the routes is driven by the activity of the pools in the pool fate sharing group:
configure
router/service vprn
nat
outside
pool <name>
redundancy
export <ip-prefix/length>
monitor <ip-prefix/length>[no] shutdown
follow router <rtr-id> pool <master-pool>
For example:
router/service vprn
nat
outside
pool "nat0-pool" nat-group 1 type large-scale create
port-reservation ports 252
redundancy
follow router 500 pool "nat500-pool"
exit
address-range 192.168.12.0 192.168.12.10 create
exit
no shutdown
exit
exit
exit
A pool can be one of the following:
a leading pool (configure export- and monitor-route and put in no shutdown)
A following pool (configure follow)
Both sets of options are therefore mutually exclusive.
A leading pool redundancy is only enabled when the redundancy node is in no shutdown. For a following pool, the administrate has no effect, and the redundancy is only enabled when the leading pool is enabled.
Before a lead pool is enabled, consistency checks are performed to make sure that PFSG is properly configured and that the all pools in the PFSG belong to the same NAT ISA group. PFSG is implicitly enabled by configuring multiple pools to follow the same lead pool. Adding or removing pools from the fate-share-group is only possible when the leading pool is disabled.
For example in the case shown in Figure: Consistency check, the consistency check would fail because pool 1 is not part of the PFSG 1 (where it should be).
