Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

What is the impact of disabling xlate in FWSM 4.0.8

What is the impact of disabling xlate in FWSM


We have dynamic NAT configured from inside to outside interface, but still it is showing NAT entry as below.

"NAT from inside: to outside: flags Ii"

Expected NAT entry should as below :

"NAT from inside: to outside: flags Ii"

Can you please explain this behaviour, and suggest if xlate-bypass can help here. We were considering implementing "ip verify revert-path" .Hence here i am thinking whether xlate-bypass is the issue here and implementing same with "ip verify revert-path" woud be a good idea.




What is the impact of disabling xlate in FWSM 4.0.8

Hi Rahul,

The xlate bypass and uRPF check features are unrelated but are often both used to workaround the problem of invalid xlates being built by the FWSM.

The xlate bypass command will simply prevent the FWSM from building identity xlates (i.e. the first xlate you referenced) for all traffic that doesn't match a NAT rule. There shouldn't be an impact on traffic if you enable this feature and it will help reduce your xlate count if you are close to the max limit.

Reverse path verification will not allow the FWSM to build a connection if the source of the packet is not reachable via the interface the packet was received on. As far as xlates go, this would only be useful if the FWSM was building incorrect xlates due to traffic received on a wrong interface (the larger cause of which is a routing problem elsewhere in the network). It does, however, add benefit for security reasons if your routing table is built properly.