..Cisco juju needed for this answer..

 Greets to list!

         Noticed a few cisco folks hanging here, can anyone answer me
this;
  If you have a trans-proxy setup utilizing a route-map redirection,
talking latest IOS12.x here, you can end up with a statement like this
in the config:
set ip next-hop 192.168.1.1 192.168.1.2
  Assuming squids at both those ip_addr, it would appear that the
cisco (as5300) applys a measure of 'reverse polish' , so that the LAST
ip_addr in the next-hop statement is delivered the packets, subsequent
to the access-list governing what gets pushed that way.
     What I noticed, is for whatever reason, if this proxy dies @
192.168.1.2, the cisco seemingy 'twigs' this has taken place, and
starts forking the packets to the squid at the first ip_addr in the
next-hop statement, ie; 192.168.1.1
   At first, I thought maybe this was just shear replication, but I
can detect no evidence that this is so, it appears to act for all the
world like a 'one hit' fallover mechanism, and by 'one hit', I mean
this action doesn't 'toggle' back to it's original state...ie; if the
dead squid is revived, the cisco doesn't 'twig' that event and go back
to the way it was, and keeps forwarding the packets to the ip_addr it
fell back to, even though the original squid has revived. It would
appear that manually going back in and reassigning the next-hop
statements can bring about this precondition again no worries...ie; in
as much as saying this is akin to 'setting the fallover trigger'
again.
      Anyone know exactly what mechanism is at play here in the cisco?
(I got lost @ 'cco trying to find it..)

         Cheers!
       
    
Received on Tue Jul 25 2000 - 21:21:01 MDT