Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
3195
Views
0
Helpful
21
Replies

ASA 5510 - UDP packets bouncing to the wrong interface

Catriona Macmillan
Level 1
Level 1

‎11-19-2010 08:42 AM - edited ‎03-11-2019 12:11 PM

Hello folks,

Looking for some help on a problem we are having on a Cisco 5510 running 8.0(5) that we have on a remote site.  We have three interfaces configured on the device. Inside as 172.19.19.*, Outside as 172.16.34.* and the voice interface 10.253.253.*.  The voice interface is there for our IPT solution.  Under normal usage there is UDP traffic coming from the inside interface and being routed to the voice interface as per the RIP routing table which we know is correct.  However if there voice interface goes down we start to see the the firewall routing UDP packets out the Outside interface.  Once the voice interface comes back up the traffic continues to be pushed out the Outside interface and so the IPT equipment never recovers as the traffic is being pushed out the wrong interface.  The Sh Conn output shows that the UDP traffic is indeed being directed out the outside interface.  Issuing the Clear Conn command gets everything working again as it should but is not ideal.

What am i missing so that the UDP stream never jumps to the outside interface for traffic destined for the Voice interface?

Labels:
0 Helpful
21 Replies 21

Catriona Macmillan
Level 1
Level 1
In response to Federico Coto Fajardo

‎11-19-2010 11:07 AM

fw-cnes-harbourview# packet-tracer input inside udp 10.10.19.2 1024 10.10.0.2 $

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd6786bb0, priority=1, domain=permit, deny=false

        hits=792305, user_data=0x0, cs_id=0x0, l3_type=0x8

        src mac=0000.0000.0000, mask=0000.0000.0000

        dst mac=0000.0000.0000, mask=0100.0000.0000

Phase: 2

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 3

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

Phase: 4

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group CSM_FW_ACL_inside in interface inside

access-list CSM_FW_ACL_inside extended permit ip 10.0.0.0 255.0.0.0 10.0.0.0 255.0.0.0

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd6a839c0, priority=12, domain=permit, deny=false

        hits=13753, user_data=0xd6a83980, cs_id=0x0, flags=0x0, protocol=0

        src ip=10.0.0.0, mask=255.0.0.0, port=0

        dst ip=10.0.0.0, mask=255.0.0.0, port=0, dscp=0x0

Phase: 5

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd6788d50, priority=0, domain=permit-ip-option, deny=true

        hits=34924, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0

        src ip=0.0.0.0, mask=0.0.0.0, port=0

        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 6

Type: INSPECT

Subtype: inspect-sip

Result: ALLOW

Config:

class-map inspection_default

match default-inspection-traffic

policy-map global_policy

class inspection_default

  inspect sip

service-policy global_policy global

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd72770e0, priority=70, domain=inspect-sip, deny=false

        hits=14, user_data=0xd7274d08, cs_id=0x0, use_real_addr, flags=0x0, protocol=17

        src ip=0.0.0.0, mask=0.0.0.0, port=0

        dst ip=0.0.0.0, mask=0.0.0.0, port=5060, dscp=0x0

Phase: 7

Type: NAT-EXEMPT

Subtype:

Result: ALLOW

Config:

  match ip inside any outside any

    NAT exempt

    translate_hits = 18073, untranslate_hits = 8690

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd6ac3dd0, priority=6, domain=nat-exempt, deny=false

        hits=18087, user_data=0xd6ac3d30, cs_id=0x0, use_real_addr, flags=0x0, protocol=0

        src ip=0.0.0.0, mask=0.0.0.0, port=0

        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 8

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Reverse Flow based lookup yields rule:

in  id=0xd67472a0, priority=0, domain=permit-ip-option, deny=true

        hits=21921, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0

        src ip=0.0.0.0, mask=0.0.0.0, port=0

        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 9

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 40151, packet dispatched to next module

Module information for forward flow ...

snp_fp_inspect_ip_options

snp_fp_punt

snp_fp_adjacency

snp_fp_fragment

snp_fp_tracer_drop

snp_ifc_stat

Module information for reverse flow ...

snp_fp_inspect_ip_options

snp_fp_punt

snp_fp_adjacency

snp_fp_fragment

snp_fp_tracer_drop

snp_ifc_stat

Phase: 10

Type: ROUTE-LOOKUP

Subtype: output and adjacency

Result: ALLOW

Config:

Additional Information:

found next-hop 172.16.34.1 using egress ifc outside

adjacency Active

next-hop mac address 0002.b3cd.9874 hits 304

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: allow

fw-cnes-harbourview#

0 Helpful

Federico Coto Fajardo
VIP Alumni
VIP Alumni
In response to Catriona Macmillan

‎11-19-2010 12:40 PM

It's clearly using the GW of the ASA via the outside interface.

The question is:

Why is it choosing this route when it has the RIP route?

Can you add a static route and run the test again?

route voice 10.10.0.2 255.255.255.255 10.253.253.1

Federico.

0 Helpful

manish arora
Level 6
Level 6
In response to Federico Coto Fajardo

‎11-19-2010 02:49 PM

Hi Guys,

This is a very interesting discussion going on , so  I wanted to join in as well. I did some research and found out that there was BUG in code CSCso42904 which has been fixed in the release that you are running. So, now as it appears the traffic shifts back for Ping etc but the flow is never cleared for the UDP VOICE traffic which is also subjected to the Inspection engine.

so, If Federico can answer ( since is far more experienced then me ) that  could there be any reason for the flow not being dropped for inspected traffic ?

Manish

0 Helpful

Kureli Sankar
Cisco Employee
Cisco Employee
In response to manish arora

‎11-19-2010 05:13 PM

Wow ! you guys have done an amzing job in this thread. Pls. read this defect CSCsy19222. This is still not resolved yet.

Symptom:
If a routing table entry is removed from the ASA's routing table and there are no routes out an interface to reach a destination, connections built through the firewall with that foreign destination will be deleted by the ASA, so that they can be built again using a different interface with routing entries for the destination present. However, if more-specific routes are added back to the table, the connections will not be updated to use the new, more specific routes, and will continue to use the less-optimal interface.

For example, consider that the firewall has two interfaces that face the internet, "outside" and "backup". These two routes exist in the ASA's configuration:

route outside 0.0.0.0 0.0.0.0 192.168.1.2 1
route backup 0.0.0.0 0.0.0.0 10.0.0.1 254

If both the outside and backup interfaces are "up", then connections built outbound through the firewall will use the outside interface, as it has the preferred metric of 1. If the outside interface is shutdown (or the cable unplugged) connections using the outside interface would be torn down, and re-built using the backup interface, as the backup interface is the only interface with a route to the destination. 

The problem appears if the outside interface is brought back up; the connections will continue to exist on the ASA and traverse the backup interface, and NOT be deleted and recreated on the outside interface with the more-preferred metric,  because the backup default route still exists in the backup interface's routing table. This might cause problems for long-lived connections, such as external SIP registrations or other UDP connections.

Conditions:
This issue can be encountered when the ASA has two egress interfaces that have routes to a destination subnet, and the preferred route to the destination is removed for some time, then re-added. This can occur due to route SLA tracking, network topology changes, and routing changes due to routing protocol re-convergence.
   
Workaround:
none

-KS


0 Helpful

Catriona Macmillan
Level 1
Level 1
In response to Federico Coto Fajardo

‎11-22-2010 02:05 AM

Federico,

That's me back at work so i will give this a try with the static route.  I think the posts after yours are very interesting about the known bug as that looks like what exactly is happening as the routing for both TCP and UDP work perfectly before the Voice interface connection is lost.

0 Helpful

Catriona Macmillan
Level 1
Level 1
In response to Catriona Macmillan

‎11-22-2010 02:30 AM

Everyone,

Is there a way to stop the traffic trying to exit using the other interface at all? So in the event of the voice interface not getting RIP updates and being down the TCP\UDP traffic does not try to get out using the outside interface through the static route of 0.0.0.0 0.0.0.0 on that interface.

0 Helpful

Kureli Sankar
Cisco Employee
Cisco Employee
In response to Catriona Macmillan

‎11-22-2010 06:59 AM

Until the defect gets resolved. The only way now is to "clear local x.x.x.x" for the IP address in question.

-KS

0 Helpful
Customers Also Viewed These Support Documents
Review Cisco Networking for a $25 gift card