cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4812
Views
0
Helpful
46
Replies

Internet Failover via MPLS Cisco 2800

Adam Hudson
Level 1
Level 1

Currently I'm looking for a way to failover our internet connection from one site to another site over our MPLS line, should that internet connection go down.

My layout: Internet > Cable internet modem (Site B) > ASA 5510 (Site B) > 2821 Router (Site B) > MPLS Line > 2821 Router (Site A) > ASA5510 (Site A) > ISP provider internet router (Site A) > Internet

Facts:

Site B is the one with the internet issues.

The MPLS line is routed using BGP.

I think I'm on the right track with these posts:

https://supportforums.cisco.com/thread/2106249

http://brain.pobudz.net/?p=65

But there's not enough for me to go on. Any config help is appreciated.

Thanks in advance.

46 Replies 46

Currently looking up some forms of packet capture to see if that will help me pinpoint the issue.

Found the packet tracer tool on the ASDM, trying to trace ICMP traffic...I found the ICMP code I need, but I cannot find any reference on the ID number/letter I need.

I put in an ID of 1, that seemed to get it going. Here's my results, everything looks good until the NATing, then this step gets a red X:

Type - NAT  Action - DROP

Config

nat (inside) 1 255.255.255.0

nat-control

match ip inside 255.255.255.0 outside any

dynamic translation to pool 1 ( [Interface PAT] )

translate_hits = 1747, untranslate_hits = 96

Checking it again this morning I'm getting the "4 good pings, 2 bad pings" pattern I was getting with the other site. At least the issue is consistent. Still checking on why that nat statement would cause a problem. Although some posts I've read claim packet tracer doesn't always point to the correct cause of the problem so I may be barking up the wrong tree.

Currently looking at other ways to debug/troubleshoot NAT if it is indeed a problem with my translation.

More confusing results, I don't see any drops here. Results from a packet trace run at the CLI:

SiteAFirewall(config)# packet-tracer input outside icmp 8 0

Phase: 1

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in      255.255.255.240 outside

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group outside_access_in in interface outside

access-list outside_access_in extended permit icmp any any

Additional Information:

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type:

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

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

Result:

input-interface: outside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: allow

As you can see in my attached file, I'm looking at rules 10 and 11. Shouldn't those be outside and inside, not outside and dmz. Is this my problem?

Trying some captures on the outside and inside interfaces, hopefully this will shed some light on the problem.

Here's my capture code:

Code

access-list capturetest permit ip host host 4.2.2.2

access-list capturetest permit ip host 4.2.2.2 host

access-list capturetest permit icmp host host 4.2.2.2

access-list capturetest permit icmp host 4.2.2.2 host

capture cap1 access-list capturetest interface inside

capture cap2 access-list capturetest interface outside

Results

sh capture cap1

1: 17:56:00.801746 > 4.2.2.2: icmp: echo request

   2: 17:56:00.811054 4.2.2.2 > : icmp: echo reply

   3: 17:56:01.802845 > 4.2.2.2: icmp: echo request

   4: 17:56:01.811969 4.2.2.2 > : icmp: echo reply

   5: 17:56:02.803882 > 4.2.2.2: icmp: echo request

   6: 17:56:02.813129 4.2.2.2 > : icmp: echo reply

sh capture cap2

0 packet captured

0 packet shown

This makes me lean strongly towards something being wrong at the ASA concerning the outside interface. Has anyone else seen something like this? Any help is appreciated.

Thanks in advance.

Something else to mention from one of my earlier posts, nat control is currently turned on on my ASA, someone else who's taken a look at this issue mentioned that might cause some issues.

Turning off nat-control had no effect.

For those curious but have just skimmed the replies, this is my clearest lead on what the problem is but I haven't really been able make heads or tails of it.


These are the results when I run packet tracer on the ASDM, from a PC on Site C, going out to the ISP's router on Site A:


Type - NAT  Action - DROP

Config

nat (inside) 1 255.255.255.0

nat-control

match ip inside 255.255.255.0 outside any

dynamic translation to pool 1 ( [Interface PAT] )

translate_hits = 1747, untranslate_hits = 96


If that nat (inside) line is the problem, I'm not sure what to put there instead.

Results of "show nat" on Site A ASA pertaining to Site C traffic:

  match ip inside 255.255.255.0 dmz any

    static translation to

    translate_hits = 0, untranslate_hits = 0

  match ip inside 255.255.255.0 inside any

    dynamic translation to pool 1 (No matching global)

    translate_hits = 0, untranslate_hits = 0

match ip inside 255.255.255.0 dmz any

    dynamic translation to pool 1 ( [Interface PAT])

    translate_hits = 0, untranslate_hits = 0

  match ip inside 255.255.255.0 outside any

    dynamic translation to pool 1 ( [Interface PAT])

    translate_hits = 62, untranslate_hits = 0

  match ip inside 255.255.255.0 management any

    dynamic translation to pool 1 (No matching global)

    translate_hits = 0, untranslate_hits = 0

If I was going to try and interpret this I would say it seems like there's a problem with the ASA translating my Site C addresses using Site A's pool. Not sure why, it's not like the ASA can only translate one internal subnet.

Subnets along with sanitized config for Site A ASA for those that want to take a look:


Site A:

11.2.1

11.1.1

11.2.100

11.2.70

173.16.1


Site B:

11.2.2

173.18.2


Site C:

11.8

After running over the issue with some other folks it looks like the ASA config is good. We'll be going over the router configs next.