RE: 3550 port-security and HSRP.

From: John Matus (john_matus@hotmail.com)
Date: Thu Jul 07 2005 - 22:03:22 GMT-3


ok, i was a bit late to read this thread.....
jerry... where was the 192.168.10.10 address located? behind R3?
i'm assuming from the debug, that this proves that if you are trying to
reach an address @ r3 but R1 is the active standby that there will be no
redirects b/c R1 does not have a path to the destination. but will the
addition of the second standby group, R2 is now an active router for gateway
.254. which leads me to ask a question. if you have these 2 standby
groups, the clients on that subnet will either be have .1 as the DG, or .254
set as the DG....they can't have both. i'm assuming that this lab
experiment was just set up to prove that there will be no ip redirects for
an unrachable destination, but there will be redirects if the active router
has a next-hop address in it's routing table for it....yeah? what was the
question again?? :-P

>From: "ccie2be" <ccie2be@nyc.rr.com>
>Reply-To: "ccie2be" <ccie2be@nyc.rr.com>
>To: <hulbertj@comcast.net>, "'Tom Lijnse'"
><Tom.Lijnse@globalknowledge.nl>, "'Spyros Kranis'"
><skranis@algosystems.gr>
>CC: <ccielab@groupstudy.com>
>Subject: RE: 3550 port-security and HSRP.
>Date: Wed, 6 Jul 2005 12:50:42 -0400
>
>Jerry,
>
>Good going!!!
>
>Your experiment proves that a requirement for mHSRP could be implied by
>other configuration tasks.
>
>I'm going to be taking the lab very soon and another question popped up in
>my mind. I don't expect to see this but I also don't put anything beyond
>Cisco to trick us up.
>
>What do you think we should do if the lab directions prohibit us from
>adding
>or changing ip addresses and we need to configure HRSP?
>
>I don't think there's a way to config hsrp without adding an ip address.
>While I'm aware of alternatives to HSRP such as VRRP and GLBP, I don't know
>them well enough to know if any alternative to HSRP would satisfy these
>constraints.
>
>Any thoughts?
>
>Thanks for trying this out and letting us know.
>
>Tim
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>hulbertj@comcast.net
>Sent: Wednesday, July 06, 2005 11:54 AM
>To: ccie2be; 'Tom Lijnse'; 'Spyros Kranis'
>Cc: ccielab@groupstudy.com
>Subject: RE: 3550 port-security and HSRP.
>
>I just labbed this real quick....it looks as if redirects works fine with
>the standby use-bia command.
>
>R1 R2 -----> R3-loopback
>e0 e0
> |----hsrp----|
>
>R1 config:
>interface Ethernet0/0
> ip address 192.168.10.2 255.255.255.0
> half-duplex
> standby 1 ip 192.168.10.1
> standby 1 priority 105
> standby 1 preempt
>
>R2 config:
>interface Ethernet0/0
> ip address 192.168.10.3 255.255.255.0
> half-duplex
> standby 1 ip 192.168.10.1
> standby 1 preempt
>
>Rack1R1#sho standby brief
> P indicates configured to preempt.
>|
>Interface Grp Prio P State Active Standby Virtual IP
>
>Et0/0 1 105 P Active local 192.168.10.3
>192.168.10.1
>
>
>When a host on this segment tries to reach a destination reachable through
>R2, this is what the debug on R1 show's;
>
>Rack1R1#debug ip icmp
>ICMP packet debugging is on
>Rack1R1#
>*Mar 4 17:31:29.385: ICMP: redirect not sent to 192.168.10.10 for dest
>150.1.3.3
>*Mar 4 17:31:29.385: ICMP: 192.168.10.3 does not contain an active HSRP
>group
>*Mar 4 17:31:30.383: ICMP: redirect not sent to 192.168.10.10 for dest
>150.1.3.3
>*Mar 4 17:31:30.387: ICMP: 192.168.10.3 does not contain an active HSRP
>group
>Rack1R1#
>*Mar 4 17:31:32.386: ICMP: redirect not sent to 192.168.10.10 for dest
>150.1.3.3
>*Mar 4 17:31:32.386: ICMP: 192.168.10.3 does not contain an active HSRP
>group
>
>Added a second HSRP group to R1 & R2(Active):
>R1
>interface Ethernet0/0
> ip address 192.168.10.2 255.255.255.0
> half-duplex
> standby use-bia
> standby 1 ip 192.168.10.1
> standby 1 priority 105
> standby 1 preempt
> standby 2 ip 192.168.10.254
> standby 2 preempt
>
>R2
>interface Ethernet0/0
> ip address 192.168.10.3 255.255.255.0
> half-duplex
> standby 1 ip 192.168.10.1
> standby 1 preempt
> standby 2 ip 192.168.10.254
> standby 2 priority 105
> standby 2 preempt
>
>Now I can see this on R1's debug.
>Rack1R1#
>*Mar 4 17:38:13.111: ICMP: HSRP changing redirect sent to 192.168.10.10
>for
>dest 150.1.3.3
>*Mar 4 17:38:13.111: ICMP: gw 192.168.10.3 -> 192.168.10.254, src
>192.168.10.1
>*Mar 4 17:38:13.111: ICMP: Use HSRP virtual address 192.168.10.1 as ICMP
>src
>*Mar 4 17:38:13.111: ICMP: redirect sent to 192.168.10.10 for dest
>150.1.3.3, use gw 192.168.10.254
>
>Rack1R1#sho standby
>Ethernet0/0 - Group 1
> State is Active
> 4 state changes, last state change 00:03:23
> Virtual IP address is 192.168.10.1
> Active virtual MAC address is 00b0.6405.3100
> Local virtual MAC address is 00b0.6405.3100 (bia)
> Hello time 3 sec, hold time 10 sec
> Next hello sent in 0.657 secs
> Preemption enabled
> Active router is local
> Standby router is 192.168.10.3, priority 100 (expires in 8.722 sec)
> Priority 105 (configured 105)
> IP redundancy name is "hsrp-Et0/0-1" (default)
>Ethernet0/0 - Group 2
> State is Standby
> 1 state change, last state change 00:00:18
> Virtual IP address is 192.168.10.254
> Active virtual MAC address is 0030.94bc.3320
> Local virtual MAC address is 00b0.6405.3100 (bia)
> Hello time 3 sec, hold time 10 sec
> Next hello sent in 2.424 secs
> Preemption enabled
> Active router is 192.168.10.3, priority 105 (expires in 7.007 sec)
> Standby router is local
> Priority 100 (default 100)
>
>
>-------------- Original message --------------
>
> > One more thing to think about. With the below statement from the link
>Tom
> > provided (thanks):
> >
> > "In certain configurations, such as the use of the standby use-bia
>interface
> > configuration command specified on an interface, redirects cannot be
>sent.
>In
> > this case, the HSRP groups use the interface MAC address as their
>virtual
>MAC
> > address. The router now cannot determine if the default gateway of the
>host is
> > the real IP address or one of the HSRP virtual IP addresses that are
>active on
> > the interface."
> >
> > I would take this as meaning, that if I wanted optimal operation, I
>would
>not
> > implement 'standby use-bia', and I would have to rethink my
>port-security
> > configuration. Does anyone agree or disagree?
> >
> > I will try to lab this up later today.
> >
> > Thanks,
> > Jerry
> >
> > -------------- Original message --------------
> >
> > > Hi Tom,
> > >
> > > Thanks again for your response.
> > >
> > > I read the link you sent me and see I was wrong on at least one point.
> > >
> > > Per this link, "When running HSRP, it is important to prevent hosts
>from
>
> > > discovering the interface (or real) MAC addresses of routers in the
>HSRP
>
> > > group. If a host is redirected by ICMP to the real MAC address of a
>router,
> > > and that router later fails, then packets from the host will be lost."
> > >
> > > But, given the above, how could a packet get to net 3 if R1 is the
>active
> > > router and R1 and R2 are in the same group?
> > >
> > > R1 R2 -----> R3 net3
> > > e0 e0
> > > |----hsrp----|
> > > |
> > > other hosts
> > >
> > > It seems to me that this isn't possible. To solve this problem it
>seems
> > > that 2 groups must be configured and R2 must be the active router for
>the
> > > other group. This way for hosts that use R1 as their default gateway
>will
> > > be redirected to the virtual mac address of the other group.
> > >
> > > Am I on the right track now?
> > >
> > > TIA, Tim
> > >
> > > -----Original Message-----
> > > From: Tom Lijnse [mailto:Tom.Lijnse@globalknowledge.nl]
> > > Sent: Wednesday, July 06, 2005 9:18 AM
> > > To: ccie2be; Spyros Kranis
> > > Cc: ccielab@groupstudy.com
> > > Subject: RE: 3550 port-security and HSRP.
> > >
> > > Hi Tim,
> > >
> > > Okay, let's see if I can answer your questions:
> > >
> > > - "When HSRP is configured this way with the use-bia command, is the
> > > failover fast enough that any active sessions that hosts might have at
> > > the time of switch over remain intact?"
> > >
> > > As far as I know 'use-bia' has similar convergence to normal HSRP. The
> > > only extra step is that when the Standby becomes Active it has to send
> > > out the gratuitous arp-replies and the hosts need to update their
> > > arp-caches, but as far as I can see that should only add milliseconds
>to
>
> > > the convergence time. I haven't tested very extensively, but when I
>did
> > > use it, it never seemed slower than normal HSRP.
> > >
> > > - "I'm wondering if it's possible to config port security on the 3550
> > > and the use-bia on the routers such that a failover is transparent to
> > > hosts sessions maybe by lowering hsrp timers?"
> > >
> > > As far as I can see this comes down to the same issue. (This depends
>on
> > > what you mean by transparent). Convergence time for HSRP is determined
> > > by the time it takes for the Standby to discover that the Active
>Router
> > > disappeared, so this is mainly determined by the hello and holdtime.
> > > Setting these to lower values will decrease the convergence time.
> > > Whether or not you're using 'use-bia' seems negligible to me.
> > >
> > > - " Suppose your topology was like this:
> > >
> > >
> > > R1 R2 -----> R3 net3
> > > e0 e0
> > > |----hsrp----|
> > > |
> > > other hosts
> > >
> > >
> > > R1 is the active router. R2 is the standby router but packets must get
> > > to
> > > R3 to get to net3.
> > >
> > > How should HSRP be configured such that the hosts use R1 for all
> > > destinations except for net3?"
> > >
> > > The whole story about ICMP unreachables being disabled when you enable
> > > HSRP isn't entirely true anymore. You may want to read the following
>bit
>
> > > on the Doc-CD:
> > >
> > >
>http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/
>
> > > fipr_c/ipcprt1/1cfip.htm#wp1044507
> > >
> > > After reading this and possibly quickly labbing it up I think you
>should
>
> > > be able to come up with an answer to your own question. In the end I
> > > think this would be more educational than me just giving you the
>answer,
>
> > > but let me know when you need a hint.
> > >
> > > Regards,
> > >
> > > Tom Lijnse
> > >
> > > CCIE #11031
> > > Global Knowledge
> > >
> > >
>_______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:00:29 GMT-3