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
