VRRP MC does not require a dedicated interface. You
can configure VRRP traffic on an internal interface,
rather than a dedicated one with a crossover cable.
Also, the cross over cable only works when VRRP is
setup for an HA pair, not a cluster.
--- Paul Keser <[EMAIL PROTECTED]> wrote:
> My VRRP comments. While I do not work for Nokia I
> have allot of experience
> configuring VRRP V2 & VRRP MC on the Nokia
> platform...
>
> > -----Original Message-----
> > From: McMeekin, Scott [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, May 22, 2000 5:52 PM
> > To: 'hermit1';
> [EMAIL PROTECTED]
> > Subject: RE: [FW1] Nokia failover
> >
> >
> >
> > > -----Original Message-----
> > > From: hermit1 [SMTP:[EMAIL PROTECTED]]
> > > Sent: Monday, May 22, 2000 9:29 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: [FW1] Nokia failover
> > >
> > >
> > > *** Warning : This message originates from the
> Internet ***
> > >
> > >
> > >I was looking at the system failure notification
> section of the
> > Nokia to
> > >set up the email alert when failover happens.
> What
> > happens if the
> > >interface that fails is the one that connects to
> the
> > smtp server? I
> > assume
> > Yeah I see what you're saying. Your internal
> interface
> > fails - well
> > if you're running VRRP monitored circuits then
> there should
> > be a problem
> > since if a monitored interface fails, all traffic
> for that
> > firewall should
> > be failed over to the other firewall. The backup
> firewall
> > would send an
> > email/smtp trap depending on your config, on to
> the place you
> > configured it
> > to do so. If you are running just normal VRRP
> however, the
> > firewall will
> > have no other choice but to search its routing
> tables for an
> > alternative
> > route to the smtp server. If your network config
> is such that
> > there's no
> > alternate route then you're stuffed.
> >
> > >no alert arrives anywhere, but can someone
> confirm this? That
> > implies I
> > >would need an external monitoring point to check
> that
> > the firewall
> > is healthy.
> > Out of band monitoring is an option sure, but
> it's not
> > required in
> > this case. OBM is more secure, if more expensive
> due to the
> > extra network
> > links required, plus if someone is filling your
> bandwidth
> > with DoS traffic
> > and its saturating your in-band management links,
> an out of band
> > monitoring/management channel is a godsend.
>
> Nokia recommends configuring a 100BT interface with
> a crossover cable for
> firewall synchronization. You could use a hub
> instead and use this for OBM.
>
>
> > >The second question appears: what do people do
> to
> > monitor their
> > >Nokias? Do most people use the failover Nokia
> to ping the
> > interfaces on
> > >the first one and send an alert if an interface
> fails
> > to respond?
> > Or is
> > >there a built-in alert function that get
> activated when the
> > failover system
> > >assumes the virtual IP? Or do most people use
> an unrelated
> > (non-firewall)
> > >monitoring system?
> > Primary system, backup system. SNMP traps or
> emails can be sent
> > automatically if an interface fails with the newer
> IPSOs
> > (3.2.x) - you can
> > build user-defined events in fw-1 that with a
> little bit of
> > thought, you can
> > have automatically gathering info as to where the
> problem
> > lies and emailing
> > it (if possible) to your first second or third
> line support
> > channel. The
> > Nokia IPSO system is evolving nicely at an
> appreciable rate
> > too - in it's
> > current state at 3.2.x it's all you need - there's
> no further
> > requirement
> > for third party failover products like rainwall or
> stonebeat.
> > It's one of
> > the really nice things about the Nokia boxes. A
> minor gripe
> > tho is the no
> > ping response from the virtual address for an
> interface. We
> > can ping HSRP
> > addresses, why can't the firewall currently
> holding control
> > of the VIP spoof
> > a reply on behalf of the VRRP address?
>
> The Nokia line on this is that it isn't supported by
> RFC 2338
> (http://sunsite.auc.dk/RFC/rfc/rfc2338.html)
>
> the closest I could find in the RFC was:
>
> 6.4.3 Master
>
> While in the {Master} state the router functions
> as the forwarding
> router for the IP address(es) associated with the
> virtual router.
>
> While in this state, a VRRP router MUST do the
> following:
>
> - MUST respond to ARP requests for the IP
> address(es) associated
> with the virtual router.
>
> - MUST forward packets with a destination link
> layer MAC address
> equal to the virtual router MAC address.
>
> - MUST NOT accept packets addressed to the IP
> address(es) associated
> with the virtual router if it is not the IP
> address owner.
>
> I believe what they are talking about is the MUST
> NOT line. In a VRRP MC
> config there won't be an IP address owner of the
> VRRP ip address. It is
> purely a virtual IP.
>
> Since HSRP is private Cisco can do anything they
> want with it.
>
>
>
> *********************************************
> Paul Keser
> Network Security Engineer
> [EMAIL PROTECTED]
> tel: 415.351.4037
> fax: 415.474.6017
>
> ShopExpert.com
> 1375 Sutter Street, Suite 400
> San Francisco, CA 94109
> *********************************************
>
>
__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================
