I hope one of you techies can help me with this problem.
I need to put in additional resilience into our network due to a problem we recently experienced.
We currently have routes out our network via two pix's (in a failover config) which connect to our providers two devices. The provider routes unfortunately come into our network via a single duct so a jcb on that single duct will cause an outage on both routes, as has happened in the past.
In addition we have another route via a 1Gb LES to a sister site and I want to configure my devices to send outbound traffic via this connection in the unfortunate but not altogether unlikely event our dual provider links were taken out.
Our sister site also has a similar configuration to ours -
The core/edge devices send all outbound traffic (via a default route) to the firewalls which have been configured with a static default route out to the providers devices.
Please advice as to how I would configure my devices.
1. Would I configure a second default route on my edge switches with a different metric?
2. Presumably the Pix would inform the Edge devices that the provider link had gone down, how? There is no routing protocol on the Pix's although there is OSPF on the edge devices. Would I need any additional configuration on my Pix's?
3. What configuration do I need to add to my LES switches? At the moment there is no connection from either LES switch to the provider devices as they are simply in place for intersite traffic.
4. On the sister site, what would I need to configure? Would I need an additional static route on their Pix's sending the failover traffic back.
I'm sorry I've asked so many questions, I am a bit confused and as always know I can rely on some good answers from this forum.
Please let me know if you require any further clarification.
if I remember correctly we had already talked about the double fault of the pix pair.
About your questions:
i), ii) without a routing protocol running pix can say nothing to edge switches.
However, new features include the association of object tracking to static routes:
so you can have a primary default static route pointing to the pix pair and tracking ip reachability of some well chosen ip address (ISP ip address for example) that can be a meaningful test of path health.
the secondary default route can point to the sister site
Thanks Giuseppe as always for the great advice. I will read up on the link sent and see how I can apply it to our set up. How about traffic inbound at Site 2 destined for site 1?
Can I just assume that since Site 2 Pix's sent out the traffic , it will of course return to Site 2 Pix's and then use the LES to send it back to Site 1? Is there any config I need to add to the Site 2 Pix?
Thanks I have read the document and I have created the config below and the questions and points I require clarification with follow:
Configure primary and secondary interfaces
desc pix interface (primary)
ip address 10.17.1.250
desc LES interface (backup)
ip address 10.20.1.250
Configuring Cisco IOS IP SLAs
type echo protocol ipIcmpEcho
rtr schedule 1 life forever start-time now
track 123 rtr 1 reachability
configuring policy routing for static routing (primary interface)
access-list 101 permit icmp any host echo
route-map MY-LOCAL-POLICY permit 10
match ip address 101
ip local policy route-map MY-LOCAL-POLICY
Configure default route for pri int using static routing
ip route 0.0.0.0 0.0.0.0 10.17.1.254 track 123
Configure floating static default route on sec interface
ip route 0.0.0.0 0.0.0.0 10.20.1.254 254
Verify state of tracked object for reliable static routing backup using object tracking
show ip route track-table
I have pretty much copied the example given in the link you sent me but a bit of confusion has arisen in terms of the fact that the example seems to be pointing to a single host 172.16.23.7
and I'm not sure what address I should be using here.
I apologise if the question sounds silly, I just want to make sure I am doing the right thing.
To recap, the desire is for all outbound traffic to go via the LES to Site 2 in the event of the provider link failure.
The IP addresses are
Edge switch 1
fa0/20 - 10.17.1.250 (primary interface)
fa0/25 - 10.20.1.250 (secondary interface)
In the example given, they used type echo protocol ipIcmpEcho 172.16.23.7
the address is also the destination address defined in the access list. What should I have here and also when I configure my set interface command in my route map, should I use the primary interface here.
I suppose asking all these questions show I have very little understanding of what is going on here but I really just have to get this working ASAP.
Thanks so much for all your assistance, it is much appreciated.
>> the desire is for all outbound traffic to go via the LES to Site 2 in the event of the provider link failure.
So a possible choice for the ip address to be tracked is the ip address of the ISP router on the link to SiteA.
Or also an ip address inside the ISP network this can be useful when a BGP session is running to distinguish when the link is up but the BGP session is down.
I'm not sure the route-map is needed in your case I will review the document.
I've given a look at the example at the end of the document.
The route-map is used to locally redirect the icmp packets of the SLA probe so the set interface has to be towards the primary interface (the one used by the primary default route) in your case interface to the pix.
>> Can I just assume that since Site 2 Pix's sent out the traffic , it will of course return to Site 2 Pix's and then use the LES to send it back to Site 1? Is there any config I need to add to the Site 2 Pix?
if we are speaking of internet facing links pix of site2 needs to perform NAT to send traffic to the internet. The public ip address block used by pix of site2 should be enough to have return traffic to come back on site2. (if the public address blocks are different)
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...