Correct, but how did it know to use the other static route? There was no dynamic routing, the loopbacks were not obviously not directly attached so the router had no way of knowing I had downed them on the remote router and hence original route should still be in route table. But traffic was going to other less preferred router. No sign of icmp redirect, and router would not react to pings not responding to change route table???
I'm sure I'm having a brain fart here but it's making me think I am misunderstanding something. I knocked it up at the end of a rack session and lost config when session ended. I'll knock up again and play Sent from my iPhone On 9 Jan 2011, at 03:09, "Jason Maynard" <[email protected]> wrote: > If I am understanding this correctly > -2 spokes have loopbacks with the same IP address for ex: 1.1.1.1/32 > - default static route to spoke 1 administrative distance is low and this is > in the routing table > - default static route to spoke 2 administrative distance is higher > > Once the 1 static route with the better admin distance was not available it > leveraged the other static route and was able to ping the secondary spoke > with ip address 1.1.1.1 > > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Mark Beynon > Sent: January-08-11 5:42 PM > To: [email protected] > Subject: [OSL | CCIE_RS] Fwd: Real basic explanation that I am having > trouble with... > > >> > >> Sorry, didn't mean to send unfinished. My assumption is that it was icmp > redirect, but I couldn't stop it by disabling them?? >> >> I'm sure I was missing something. >> >> Sent from my iPhone >> >> On 8 Jan 2011, at 22:38, Mark Beynon <[email protected]> wrote: >> >>> I was toying around with a topology that I created to experiment with > OER. I had a Y shaped topology, with a central router that had three spokes. > The bottom router would originate pings to a Loopback address that was > configured on both the other spoke routers. The central router had a default > route via spoke 1 and a default route with a worse AD via spoke 2. pings > responded fine and debug ip packet showed all packets going to router on > spoke 1 as expected. I downed the Loopback interface expecting pings to > fail, with the idea being I could then set up oer to fix this. However the > pings failed over seamlessly. I had not configured any thing clever to > achieve this. >>> >>> Experimenting more I re-enabled the Loopback, I set the default routes to > the same AD. No load balancing was observed but I assumed this was due to > it load balancing via src and dst ip that were consistent. It still however > failed over seamlessly. >>> >>> Where is this intelligence coming from? >>> >>> >>> O bi c c >>> >>> >>> Sent from my iPhone > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
