Firewall – Dual Cisco Router Stateful Firewall

1.) A given BGP-speaking router is presented the same prefix from multiple peers then it will propagate only the best of those paths (as per BGP's path selection rules). In your case, this means that if some remote router sees both the plain and the prepended route that it will only pass on the plain route to its neighbors. The announcing router will have both paths in "sh ip bgp a.b.c.d" but its neighbors will not.

1a.) The fact that you can't see the prepended route doesn't mean that the backup won't work. The router that has both the prepended and non-prepended route in table will normally only advertise the non-prepended, but if the non-prepended route is withdrawn/times out then the prepended route will immediately be offered.

Try this command on your backup router: sh ip bgp neighbors x.y.z.q advertised-routes to see exactly what is being sent to your provider.

2.) It's hard to say what effect the iBGP peering will have without knowing how you're originating (and processing) your prefix. Is there a reason you need an iBGP peer between these routers?

3.) The advertise-map command will cause a particular prefix to be advertised based on the presence of another prefix. An example might be to advertise 10.128.0.0/16 whenever 10.0.0.0/8 is present. Similarly, non-exist-map will advertise a particular prefix when another prefix is not present. Neither should be required for a basic multi-homing setup.

Ultimately the best test is going to be taking time to shut down your primary route to confirm that the backup will take the traffic.

Oh - and BTW - are you advertising truly PI space or is the prefix in question part of one of the provider's aggregates? Longest-match trumps everything else.

As an obsolete ex-PIX/ASA admin I of course found this irresistible. I have no appliance (but an old PIX 506E running 6.3) to try it on, so it's kind of totally lame. But this is what I found in the online documentation for 9.1 and through some random Googling. Reference links are provided at the bottom of the post. So fingers crossed...

Assuming all other config is correct such as routing, access-lists etc, you would still need to use the command

same-security-traffic permit intra-interface

in order to have traffic from an inside client to an externally mapped address allowed to re-translate towards an internal server address, i.e. having it "hairpinned".

To port map the internal address i.i.i.i to the external address x.x.x.x you would prior to 8.3 have used the command

static (inside,inside) x.x.x.x i.i.i.i

in order to allow nat hairpinning for an internal host to the inside server using the external address gotten from dns. This differs from the regular "un-hairpinned" syntax which would be

static (inside,outside) x.x.x.x i.i.i.i

and which naturally also would be present to allow for external clients calling the server using the public ip.

In ver 8.3 and onward this syntax has been rewritten and the corresponding hairpinning-port map instruction to the ASA would look like this as one feeds it in:

asa-box(config)# object network my-outside-address-obj
asa-box(config-network-object)# host x.x.x.x
asa-box(config-network-object)# object network my-inside-address-obj
asa-box(config-network-object)# host i.i.i.i
asa-box(config-network-object)# nat (inside,inside) static my-outside-address-obj

This would be complemented with a regular "un-hairpinned" instruction too.

That seems to be the only real difference I can find, but am of course terribly curious as to how it works in practice.

I found the 9.1 command syntax for port address translation (i.e. corresponding to the old static command) here: http://www.cisco.com/en/US/docs/security/asa/asa91/configuration/firewall/nat_objects.html#wp1106703

I found an absolutely outstanding historical guide to the hairpinning syntax, showing the same example design as it would be configured throughout the different versions here: http://nat0.net/cisco-asa-hairpinning/

Best of luck!