cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7356
Views
5
Helpful
13
Replies

What is the impact of disabling xlate in FWSM

Ganesh Hariharan
VIP Alumni
VIP Alumni

Hi All,

We have simple setup with 3 to 4 zones in FWSM with simple ip traffic flowing across the zones and no natting is configured also in the FWSM.I would like to know what would be the impact if we disable xlate in global configuration in FWSM and what is the command to do the same.

Is there any default count stored for xlate table in FWSM and what happens when we do clear xlate in FWSM.

Regards

Ganesh.H

1 Accepted Solution

Accepted Solutions

Eventhough there is no NAT configured, it still creates the xlate entry in the xlate table. That is why the "xlate-bypass" feature is useful in this case, to surpress the creation of the xlate in the fwsm hardware so it does not hit the hardware limitation withini the fwsm. There is no impact at all to the production traffic.

This feature is only available in fwsm because it's processed in hardware, whereas ASA or PIX firewall process the xlate in software.

Hope that answers your question.

View solution in original post

13 Replies 13

Jon Marshall
Hall of Fame
Hall of Fame

ganeshh.iyer wrote:

Hi All,

We have simple setup with 3 to 4 zones in FWSM with simple ip traffic flowing across the zones and no natting is configured also in the FWSM.I would like to know what would be the impact if we disable xlate in global configuration in FWSM and what is the command to do the same.

Is there any default count stored for xlate table in FWSM and what happens when we do clear xlate in FWSM.

Regards

Ganesh.H

Ganesh

The xlate table is used for NAT translations. If you are not doing any Natting then there won't be any entries in the xlate table. I'm not aware of a way to disable xlate on the FWSM but i'm not sure why you would want or need to do that anyway.

Not sure what you mean by default count, do you mean maximum number of allowed xlate entries ?

If you clear xlate on the FWSM or ASA then any existing connections that have entries in the xlate table will be torn down so it's not usually a thing you want to do during production hours. Note that the clear xlate command has an option to specify which actual xlate entry you want to remove.

Jon

Jennifer Halim
Cisco Employee
Cisco Employee

If you don't need translation, you can configure the "xlate-bypass" feature:

http://www.cisco.com/en/US/docs/security/fwsm/fwsm32/command/reference/uw.html#wp1306953

The maximum concurrent xlate in FWSM hardware is 262144

Hope that helps.

halijenn wrote:

If you don't need translation, you can configure the "xlate-bypass" feature:

http://www.cisco.com/en/US/docs/security/fwsm/fwsm32/command/reference/uw.html#wp1306953

The maximum concurrent xlate in FWSM hardware is 262144

Hope that helps.

I stand corrected. Many thanks for that link.

Ganesh - apologies for the misleading information, i have learnt something new today.

Jon

Jon - we all learn everyday

Ganesh Hariharan
VIP Alumni
VIP Alumni

Hi All,

We have simple setup with 3 to 4 zones in FWSM with simple ip traffic flowing across the zones and no natting is configured also in the FWSM.I would like to know what would be the impact if we disable xlate in global configuration in FWSM and what is the command to do the same.

Is there any default count stored for xlate table in FWSM and what happens when we do clear xlate in FWSM.

Regards

Ganesh.H

Guys,

Sorry for delay responce and thanks for suggestion and link,Just one query if there is no nat is configured between the zones then as per my understanding show xlate count should be zero is that right ?

But in my case i used to see good amount of count when ever i issue show xlate and if i issue a command for by pass the xlate what will be the impact on the traffic which is passing through firewall.

Regards

Ganesh.H

Eventhough there is no NAT configured, it still creates the xlate entry in the xlate table. That is why the "xlate-bypass" feature is useful in this case, to surpress the creation of the xlate in the fwsm hardware so it does not hit the hardware limitation withini the fwsm. There is no impact at all to the production traffic.

This feature is only available in fwsm because it's processed in hardware, whereas ASA or PIX firewall process the xlate in software.

Hope that answers your question.

Eventhough there is no NAT configured, it still creates the xlate entry in the xlate table. That is why the "xlate-bypass" feature is useful in this case, to surpress the creation of the xlate in the fwsm hardware so it does not hit the hardware limitation withini the fwsm. There is no impact at all to the production traffic.

This feature is only available in fwsm because it's processed in hardware, whereas ASA or PIX firewall process the xlate in software.

Hope that answers your question.

That Great !! Thanks for the confirmation..

Ganesh.H

Ganesh,

Pardon me for writing on this thread that has already been answered.  One of our customer's pointed out this link to me and asked a bunch of questions.  I thought I will list them here so, everyone who reads this thread would benefit from that.

A good % of our customers who implement this feature xlate-bypass are the ones who try to protect the internet!!  As bad as it sounds, it is true.  Due to bad design or other reasons they tend to have the internet on the higher security level than the other interfaces.  In this case xlate is built for each internet host/IP since it lives on the higher security interface.  Quickly the max xlates (261K) is reached and run into issues where no more translation can be created. http://www.cisco.com/en/US/docs/security/fwsm/fwsm40/configuration/guide/specs_f.html#wp1056716

Although, this command xlate-bypass is going to help them whereby we just do not create any translations or show them in the table, this design needs to be addressed and corrected if possible.

Also, the following should be true in order to enable this command:

- no nat-control should be enabled

- nat/global should not be configured

- static - even identity should not be configured

Also, there comes other questions - if the firewall really doesn't have to populate these xlates in the table, why wasn't this the default from the begining when the above conditions are true?

1. Well, this command was only introduced in 3.2.1, I believe only then we started to hear about running the limitation of the total xlates in the box or one context consuming all the xlates due to the fact the internet is on the inside or due to infected hosts or other reasons.

2. Also, sunrpc inpsection is not possible when xlate-bypass is implemented. This is documented here: http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtc54367

Symptom:
This is a documentation bug to get the documentation updated to indicate that
the 'inspect sunrpc' feature is not compatible with the xlate-bypass feature
present in FWSM code version 3.2 and later. The two features cannot co-exist as
the sunrpc inspection relies on xlates for functionality and xlate bypass may
prevent the inspection from functioning correctly.

Conditions:
This condition is present in FWSM code version 3.2 and later where xlate bypass
was first introduced.

Further problem description:
Where xlate-bypass is configured, remove sunrpc inspection and make sure to
allow permission for sunrpc traffic via acl as the inspection will not work and
open pinholes.

3. Besides that, some companies are required to document xlate build and teardown syslog messages (305010  and 305011) for audit purposes which will not be created when implemented.

4. sharing interfaces is very common with FWSM implementation in multiple context mode. Translation is a requirement in this case.

-KS

Hi KS,

not sure if I understood correctly, but following seems not to be true:

Also, the following should be true in order to enable this command:

- no nat-control should be enabled

- nat/global should not be configured

- static - even identity should not be configured

You can have NAT/STATIC/GLOBAL configured together with "xlate bypass" (we use it and it is working fine). This command disables NAT sessions ONLY for untranslated traffic. You will see entries in xlate table for translated traffic, which means that following is also not true

3. Besides that, some companies are required to document xlate build and teardown syslog messages (305010  and 305011) for audit purposes which will not be created when implemented.

4. sharing interfaces is very common with FWSM implementation in multiple context mode. Translation is a requirement in this case.

Regarding point 1

1. Well, this command was only introduced in 3.2.1, I believe only then we started to hear about running the limitation of the total xlates in the box or one context consuming all the xlates due to the fact the internet is on the inside or due to infected hosts or other reasons.

You can easily get out of xlates in service provide environment. Imagine that you have 100 contexts on FWSM. I guess this command was introduced to overcome this limitations.

FWSM# sh resource usage summary | i Res|Xla

Resource              Current         Peak      Limit        Denied Context

Xlates                  88891       168870     262144(S)          0 Summary

FWSM# sh context count

Total active Security Contexts: 79

BR

Juraj

Juraj,

May be I should have added a little more detail that we are talking about same source and destination IP.

You  cannot enable x-late bypass and expect it to "NOT SHOW" the xlates when  you have nat 0 with acl, nat/global or static identity configured for  the same src/dst combo between the same two interfaces.

Yes, xlate-bypass was introduced only in 3.2.1 to  mitigate running the xlate-limit issue.  I believe around the time is  when we saw many cases where the unit  exhausted all 256K xlate count.

-KS

Hi KS,

I also have some issue with xlate on our FWSM and thought that I will check it on this thread. we get lot of error messages on our firewall saying "%FWSM-3-305006: regular translation creation failed for icmp" although the resource limit has not exceded show below

fw01/act# sh resource usage summary resource Xlates

Resource              Current         Peak      Limit        Denied Context

Xlates                    815         5838  unlimited             0 System

we are running FWSM Firewall Version 4.0(5). Do you know whether this is a bug. any how to get around with this I thought of configuring "xlate-bypass" on the firewall. my question is when I do that will it drop the exisitng connections and re-establish or there wont be any effect on the exisitng connections. I just want to make sure whether i have to arrange a outage in the production networks to implement this

Thanks,

janaki

It could be this defect resolved in 4.0.9 or above..

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCta74788

I listed x-late bypass as a workaround for this problem.

Now if there are xlates that are in the table then it will continue using that.

So, once the command it implemented it is a good idea to issue "clear xlate" - which will clear all connections and xlates through the box. So, yes, downtime scheduling will be a good idea.

-KS

Hi,

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

"NAT from inside:177.26.99.10 to outside:177.26.99.10 flags Ii"

Expected NAT entry should as below :

"NAT from inside:177.26.99.10 to outside:111.111.111.111 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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: