Correct, I shut down the loop on the spoke. Your results are what I expected, but didn't see.
I'll try set up again if I can reproduce Sent from my iPhone On 9 Jan 2011, at 19:10, "Jason Maynard" <[email protected]> wrote: > Hey Mark > > I thought I would quickly lab this up and the only way I can get it to work > transparently is when I shut the interface down on the hub router. If I shut > down any interface on the spoke (preferred spoke in my case was spoke1) then > I get unreachable. I am not sure how this worked for you if you shut down > the loopback on the spoke (after rereading your post I realized it was NOT > the hub interface you shut down). It would be interesting to know how you > had things configured. > > > SPOKE1(config-if)#do sh ip int br > Interface IP-Address OK? Method Status > Protocol > FastEthernet0/0 10.0.1.2 YES manual up > up > FastEthernet0/1 unassigned YES TFTP administratively down > down > Loopback1 1.1.1.1 YES manual administratively down > down > > SPOKE2#sh ip int br > Interface IP-Address OK? Method Status > Protocol > FastEthernet0/0 10.0.2.2 YES manual up > up > FastEthernet0/1 unassigned YES unset up > up > Loopback1 1.1.1.1 YES manual up > up > > HUB(config)#do sh ip int br > Interface IP-Address OK? Method Status > Protocol > FastEthernet0/0 10.0.1.1 YES manual up > up > FastEthernet0/1 10.0.2.1 YES manual up > up > > > HUB(config)#do ping 1.1.1.1 repeat 1000 > Type escape sequence to abort. > Sending 1000, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: > .!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!U.U.U.U.U.U.U.U.U.U.U. > U.U.U.U.U.U.U.U. > > HUB(config)#do sh run | sec ip route > ip route 0.0.0.0 0.0.0.0 10.0.1.2 > ip route 0.0.0.0 0.0.0.0 10.0.2.2 250 > > HUB(config)#do sh ip route > > Gateway of last resort is 10.0.1.2 to network 0.0.0.0 > > 1.0.0.0/32 is subnetted, 1 subnets > S 1.1.1.1 [1/0] via 10.0.1.2 > 10.0.0.0/24 is subnetted, 2 subnets > C 10.0.2.0 is directly connected, FastEthernet0/1 > C 10.0.1.0 is directly connected, FastEthernet0/0 > S* 0.0.0.0/0 [1/0] via 10.0.1.2 > > At the very least we are on the same page now (I hope) so you may be able to > dismiss the brain fart unless it is contagious. > > Jason > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Mark Beynon > Sent: January-09-11 11:59 AM > Cc: <[email protected]> > Subject: Re: [OSL | CCIE_RS] Fwd: Real basic explanation that I am having > trouble with... > > 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 > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
