This post is about Box-to-Box NAT. Box to Box NAT is an evolution of NAT and HA.
Let me begin the topic by reviewing how NAT has evolved.
First there was plain NAT,
then two routers were added to the mix and HSRP was used. Both the routers were configured with plain NAT and in case one router failed, other took over. Well, this is all HSRP. All existing sessions dropped and re-formed.
Then there was Stateful NAT in 12.2 T releases. Stateful NAT used stateful NAT static rules on both the routers with redundancy keywords. And the active translator router synced all the translations (but, only the ones based on static NAT rules with redundancy keyword .. Please note NOT the dynamic translations) to the standby router.
hmmm . Comes into scenario Box to Box NAT with Cisco IOS-XE release 3S. This provides a resilient failover from the Active to the Standby Router incase the Active fails or the WAN link goes down (Yeahh, you can use advanced IP SLAs of course too) with the existing streams take the new path via the Standby Router to the Internet with no sessions/packets drop.
Cool ! Isn't it ! Voice/Video, yo .. you are gonna feel heavenly !
Lets gear up for the config. Here's the topology :
This is the topology that I have used to simulate LAN to WAN deployment of B2B NAT. I have used two ASR1002-X for RG-INFRA (Redundancy Group Infrastructure). RG-INFRA is the base code that provides/handles Box to Box HA support. NAT and ZBFW are just applications that use this infrastructure and run on top of it.
B2B NAT can not be simulated on GNS3 as of today.
1) Configure RG-INFRA globally.
You need two interfaces between both the routers. Actually, you can use one interface with subinterfaces also. But, two are preferred and port-channel (subinterfaces) are recommended. I am gonna use what's recommended, bundled Gig0/0/0 and Gi0/0/1 under Port-Channel 1.
KP-Active#show run | s redundancy$
redundancy
mode sso
application redundancy
group 1
name rg1
preempt
priority 200
control Port-channel1.2 protocol 1
data Port-channel1.3
Notice that the priority on KP_Active is more making it the Active RG Router.
Similar config goes on KP_Standby but, with lower priority (150, default is 100).
KP-Standby#show run | s redundancy$
redundancy
mode sso
application redundancy
group 1
name rg1
preempt
priority 150
control Port-channel1.2 protocol 1
data Port-channel1.3
All the B2B verification commands start with 'show redundancy application'. Here's one . . This one verifies that KP_Active Router comes up as Active, sees the KP_Standby Router as Peer (which is STANDBY and in STANDBY HOT state, which means it is just waiting for its turn desperately wanting the Active Router to go down .. If the state is STANDBY COLD, it means it is not desperate because translations are still syncing from Active to Standby)
KP-Active#show redundancy application group 1
Group ID:1
Group Name:rg1
Administrative State: No Shutdown
Aggregate operational state : Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes
RF Domain: btob-one
RF state: ACTIVE
Peer RF state: STANDBY HOT
2) Configure RG interfaces.
The inside interfaces on both the routers should have the same RII (redundancy interface identifier). This helps RG-INFRA routers determine which two interfaces work together, so that only one VMAC (Virtual MAC) address is used in replies to ARPs sent by the hosts to that interface. If the LAN (or WAN) interface on one router goes down, the corresponding LAN (or WAN) interface owns the role of RG activities, such as replying to ARPs with VMACs etc. So, 'redundancy rii' should be similar on interfaces facing the LAN. Similarly, it should also be configured and same on interfaces facing the WAN. Considering the diagram, I have configured 'redundancy rii 2' on interfaces TenGigabitEthernet0/2/0 on both the routers, and 'redundancy rii 17' on WAN interfaces.
Additionally, on the LAN interface (on both routers), 'redundancy group ip ' should be configured. This IP is the one that is VIP (Virtual IP) and the default gateway of the hosts on the LAN.
You may use the command 'show redundancy application if-mgr group 1' to know about the VIP and VMACs assigned to the interfaces.
3) Well, add NAT to the config.
Assuming that we all know how to configure NAT rules (using overload, route-maps, ACLs, VRFs etc), just add " redundancy mapping-id " in every NAT rule. This is the only addition, but make sure that the NAT rules are configured identical on both the routers.
Here are sample NAT rules. Everything is configured identical on the other router, whether it is NAT pool or NAT rules or NAT timeouts, or ALG settings. On the interfaces, ancient ip nat inside and ip nat outside statements are added on both the routers.
ip nat inside source list ACL_NAT pool POOL_NAT redundancy 1 mapping-id 2 overload
ip nat inside source list acl-linux pool pool-linux redundancy 1 mapping-id 95 vrf VRF-LAN overload
ip nat outside source static 15.15.0.2 16.16.0.2 redundancy 1 mapping-id 16 add-route
ip nat outside source static 1.0.50.132 11.0.50.132 vrf VRF-LAN redundancy 1 mapping-id 97
ip nat inside source route-map rmap-cv pool pool-cv redundancy 1 mapping-id 10 vrf TEST_VRF overloadnat64 v6v4 list NAT64_ACL pool POOL_NAT64_1 overload redundancy 2 mapping-id 10
I think you get the context, how to configure NAT but it is worth a mention again that NAT rules should be identical on both the RG routers.
4) Configure ZBFW normally.
Yes, configure ZBFW normally as you would do without RG and it will work. Just make sure that the config is identical on both the routers.
Done !! See yaa . . . Happy Learning ! :)
Let me begin the topic by reviewing how NAT has evolved.
First there was plain NAT,
then two routers were added to the mix and HSRP was used. Both the routers were configured with plain NAT and in case one router failed, other took over. Well, this is all HSRP. All existing sessions dropped and re-formed.
Then there was Stateful NAT in 12.2 T releases. Stateful NAT used stateful NAT static rules on both the routers with redundancy keywords. And the active translator router synced all the translations (but, only the ones based on static NAT rules with redundancy keyword .. Please note NOT the dynamic translations) to the standby router.
hmmm . Comes into scenario Box to Box NAT with Cisco IOS-XE release 3S. This provides a resilient failover from the Active to the Standby Router incase the Active fails or the WAN link goes down (Yeahh, you can use advanced IP SLAs of course too) with the existing streams take the new path via the Standby Router to the Internet with no sessions/packets drop.
Cool ! Isn't it ! Voice/Video, yo .. you are gonna feel heavenly !
Lets gear up for the config. Here's the topology :
This is the topology that I have used to simulate LAN to WAN deployment of B2B NAT. I have used two ASR1002-X for RG-INFRA (Redundancy Group Infrastructure). RG-INFRA is the base code that provides/handles Box to Box HA support. NAT and ZBFW are just applications that use this infrastructure and run on top of it.
B2B NAT can not be simulated on GNS3 as of today.
1) Configure RG-INFRA globally.
You need two interfaces between both the routers. Actually, you can use one interface with subinterfaces also. But, two are preferred and port-channel (subinterfaces) are recommended. I am gonna use what's recommended, bundled Gig0/0/0 and Gi0/0/1 under Port-Channel 1.
KP-Active#show run | s redundancy$
redundancy
mode sso
application redundancy
group 1
name rg1
preempt
priority 200
control Port-channel1.2 protocol 1
data Port-channel1.3
Notice that the priority on KP_Active is more making it the Active RG Router.
Similar config goes on KP_Standby but, with lower priority (150, default is 100).
KP-Standby#show run | s redundancy$
redundancy
mode sso
application redundancy
group 1
name rg1
preempt
priority 150
control Port-channel1.2 protocol 1
data Port-channel1.3
All the B2B verification commands start with 'show redundancy application'. Here's one . . This one verifies that KP_Active Router comes up as Active, sees the KP_Standby Router as Peer (which is STANDBY and in STANDBY HOT state, which means it is just waiting for its turn desperately wanting the Active Router to go down .. If the state is STANDBY COLD, it means it is not desperate because translations are still syncing from Active to Standby)
KP-Active#show redundancy application group 1
Group ID:1
Group Name:rg1
Administrative State: No Shutdown
Aggregate operational state : Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes
RF Domain: btob-one
RF state: ACTIVE
Peer RF state: STANDBY HOT
2) Configure RG interfaces.
The inside interfaces on both the routers should have the same RII (redundancy interface identifier). This helps RG-INFRA routers determine which two interfaces work together, so that only one VMAC (Virtual MAC) address is used in replies to ARPs sent by the hosts to that interface. If the LAN (or WAN) interface on one router goes down, the corresponding LAN (or WAN) interface owns the role of RG activities, such as replying to ARPs with VMACs etc. So, 'redundancy rii
Additionally, on the LAN interface (on both routers), 'redundancy group
You may use the command 'show redundancy application if-mgr group 1' to know about the VIP and VMACs assigned to the interfaces.
3) Well, add NAT to the config.
Assuming that we all know how to configure NAT rules (using overload, route-maps, ACLs, VRFs etc), just add " redundancy
Here are sample NAT rules. Everything is configured identical on the other router, whether it is NAT pool or NAT rules or NAT timeouts, or ALG settings. On the interfaces, ancient ip nat inside and ip nat outside statements are added on both the routers.
ip nat inside source list ACL_NAT pool POOL_NAT redundancy 1 mapping-id 2 overload
ip nat inside source list acl-linux pool pool-linux redundancy 1 mapping-id 95 vrf VRF-LAN overload
ip nat outside source static 15.15.0.2 16.16.0.2 redundancy 1 mapping-id 16 add-route
ip nat outside source static 1.0.50.132 11.0.50.132 vrf VRF-LAN redundancy 1 mapping-id 97
ip nat inside source route-map rmap-cv pool pool-cv redundancy 1 mapping-id 10 vrf TEST_VRF overloadnat64 v6v4 list NAT64_ACL pool POOL_NAT64_1 overload redundancy 2 mapping-id 10
I think you get the context, how to configure NAT but it is worth a mention again that NAT rules should be identical on both the RG routers.
4) Configure ZBFW normally.
Yes, configure ZBFW normally as you would do without RG and it will work. Just make sure that the config is identical on both the routers.
Done !! See yaa . . . Happy Learning ! :)
I'm going to be trying this NAT Box2Box HA. In some documentation is says it doesn't support nat overload, do you know if this is true?
ReplyDelete