[quagga-users 510] VRRP + static redistribute to OSPF?

Hi,

I have a setup with a couple of routers that run VRRP to provide a 
resiliant default gateway (or few), as well as running OSPF amongst 
themselves and other routers.

I would like to be able to configure them so that whichever is the VRRP 
master (and has that IP assigned to its interface) announces the route 
to that network into OSPF.

I have been told this is possible (in IOS) by setting a static for the 
network with next-hop being the VRRP address and then redistributing 
statics into OSPF. However this does not seem to work (the static 
obviously doesn't go into the FIB and this may be what is precluding it 
getting announced).

I currently have an OSPF network statement for each of said networks and
set passive-interface (which is not ideal) to get the announcement out.

I want to know that if VRRP (keepalived) dies (or if I shut it down for 
maintenance) traffic will not be trying to flow through that interface 
to get onto the network.

FWIW I'm using Zebra 0.93b with RHL9.

Any URLs / pointers greatly appreciated. I've had a google and search 
through mail archives, but not been able to work out a decent search 
string or just not found an answer :(

Cheers

[quagga-users 517] Re: VRRP + static redistribute to OSPF?

This is a good question...

One way to do it, that is not elegant, is to use the scripting capabilities
in VRRP to bring up/shutdown ospfd on machines as they failover to each
other.  So OSPF is only running on the machine that is acting as the VRRP
gateway.

If you need OSPF running on both machines for other reasons, you could have
the VRRP scripts restart zebra with two sets of configuration files, one of
which does not have a 'default-information originate' statement in it.

This is a kludgy way to do it, but should work.

I would be interested in seeing an elegant solution to this question too.

Really VRRP and OSPF are two totally different ways to solve a similar
problem so there are inherent conflicts.

- Mike

On 10/2/03 5:54 PM, "Ivan A. Beveridge" <ivan=PCQ3tqBD4cnNLxjTenLetw <at> public.gmane.org> wrote:

> Hi,
> 
> I have a setup with a couple of routers that run VRRP to provide a
> resiliant default gateway (or few), as well as running OSPF amongst
> themselves and other routers.
> 
> I would like to be able to configure them so that whichever is the VRRP
> master (and has that IP assigned to its interface) announces the route

[quagga-users 519] Re: VRRP + static redistribute to OSPF?

On Fri, Oct 03, 2003 at 10:28:16AM -0700, Michael DeMan wrote:
> One way to do it, that is not elegant, is to use the scripting capabilities
> in VRRP to bring up/shutdown ospfd on machines as they failover to each
> other.  So OSPF is only running on the machine that is acting as the VRRP
> gateway.
> 
> If you need OSPF running on both machines for other reasons, you could have
> the VRRP scripts restart zebra with two sets of configuration files, one of
> which does not have a 'default-information originate' statement in it.

It is this latter point (the routers are OSPFing for more than just these 
couple of VRRP'd network).

The thing that puzzles me is that this must be _so_ common (I can't 
believe that I've just hit something totally new).

Does HSRP/ESRP get round the issue by sharing a single IP address on 
the network (ie the routers that HSRP share the default-gw address and 
don't have their own independant address on that network), whereas VRRP 
routers have their own individual addresses on the network aswell?

If the above is the case, it (I assume) explains why this isn't a problem 
for cisco / extreme (etc). If not, then it must have cropped up with other 
routing hardware/environments, surely?

The scripting is something I had been thinking (but it just feels a 
horrible kludge to me). The other thing I would like to be able to do is 
kill VRRP if ospfd dies (or it doesn't see a default route or summat), 
but I expect that's a question for the keepalived people (eg process 
monitoring within the keepalived checking).

[quagga-users 520] Re: VRRP + static redistribute to OSPF?

HSRP takes care of all of this by yes sharing a VIP, that's tossed back and 
forth.

Though you usually still do have an IP on that network for each router (or 
you pass the HSRP information on a private link).

--On Saturday, October 04, 2003 03:37 +0100 "Ivan A. Beveridge" 
<ivan=PCQ3tqBD4cnNLxjTenLetw <at> public.gmane.org> wrote:

> On Fri, Oct 03, 2003 at 10:28:16AM -0700, Michael DeMan wrote:
>> One way to do it, that is not elegant, is to use the scripting
>> capabilities in VRRP to bring up/shutdown ospfd on machines as they
>> failover to each other.  So OSPF is only running on the machine that is
>> acting as the VRRP gateway.
>>
>> If you need OSPF running on both machines for other reasons, you could
>> have the VRRP scripts restart zebra with two sets of configuration
>> files, one of which does not have a 'default-information originate'
>> statement in it.
>
> It is this latter point (the routers are OSPFing for more than just these
> couple of VRRP'd network).
>
> The thing that puzzles me is that this must be _so_ common (I can't
> believe that I've just hit something totally new).
>
> Does HSRP/ESRP get round the issue by sharing a single IP address on
> the network (ie the routers that HSRP share the default-gw address and
> don't have their own independant address on that network), whereas VRRP
> routers have their own individual addresses on the network aswell?

[quagga-users 522] Re: VRRP + static redistribute to OSPF?

On Fri, 3 Oct 2003, Ivan A. Beveridge wrote:

> Hi,
> 
> I have a setup with a couple of routers that run VRRP to provide a 
> resiliant default gateway (or few), as well as running OSPF amongst 
> themselves and other routers.
> 
> I would like to be able to configure them so that whichever is the VRRP 
> master (and has that IP assigned to its interface) announces the route 
> to that network into OSPF.
> 
> I have been told this is possible (in IOS) by setting a static for the 
> network with next-hop being the VRRP address and then redistributing 
> statics into OSPF. However this does not seem to work (the static 
> obviously doesn't go into the FIB and this may be what is precluding it 
> getting announced).

I dont know about VRRP, but i did similar with heartbeat. heartbeat
adds the virtual IP and ospfd can then announce it via redistribute
connected.

If VRRP adds an address to an existing interface, redistribute 
connected should be all you need.

regards,
--

-- 
Paul Jakma	paul=p3WKshh8b8w <at> public.gmane.org	paul <at> jakma.org	Key ID: 64A2FF6A
	warning: do not ever send email to spam=YO+z8i/CF6JQ+HMy2YlzRA <at> public.gmane.org
Fortune:

[quagga-users 526] Re: VRRP + static redistribute to OSPF?

On Sat, Oct 04, 2003 at 01:50:44PM +0100, Paul Jakma wrote:
> I dont know about VRRP, but i did similar with heartbeat. heartbeat
> adds the virtual IP and ospfd can then announce it via redistribute
> connected.
> 
> If VRRP adds an address to an existing interface, redistribute 
> connected should be all you need.

Hrm - the "problem" is that it already has an IP on the interface (eg 
10.1.1.252) and VRRP adds another one (eg 10.1.1.254). AIUI this is the 
way VRRP normally works, no? If I redistribute connected then it will add 
that network all the time, no?

I guess I could add in a route-map to allow connected routes to get added 
only if they match a specific IP (?) [1] but the mask on the VRRP'd address 
is a /32, so I guess only the /32 would get announced (not much use).

Am I missing something? (probably ;)

I may need to take another look at alternatives (to keepalived / VRRP) 
and investigate heartbeat again. I like the ability for the router to be 
on the network (but not announce the route if it is not VRRP master).

Cheers

Ivan
[1] I would have to use a routemap on a "redistribute connected" as I don't 
     want them announcing out their non-vrrp-side interfaces (ie the 
     interfaces that talk to the OSPF cloud) as externals. This is one 
     reason I have tried to stay away from "redistribute connected" ;^)

file not closed in zebra/ipforward_proc.c - int ipforward()

	- Zebra version: 0.93a, 0.93b, 0.94 (CVS);
	- OS Full Name: RedHat Linux (7.3, 8.0, 8.0.94, 9, 9.0.93), 
Slackware Linux (8.0, 9.0, 9.1).
	Compiled on RedHat Linux with the following options:

	./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu 
--target=i386-redhat-linux --program-prefix= --prefix=/usr 
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin 
--sysconfdir=/etc/zebra --datadir=/usr/share --includedir=/usr/include 
--libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var 
--sharedstatedir=/usr/com --mandir=/usr/share/man 
--infodir=/usr/share/info --disable-dependency-tracking --enable-one-vty 
--enable-ipv6 --enable-netlink --enable-vtysh --with-libpam 
--enable-nssa --enable-opaque-lsa --enable-ospf-te

	Compiled on Slackware Linux with the following options:

./configure  --program-prefix= --prefix=/usr --exec-prefix=/usr 
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc/zebra 
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib 
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com 
--mandir=/usr/share/man --infodir=/usr/share/info 
--disable-dependency-tracking --enable-one-vty --enable-ipv6
--enable-netlink --enable-vtysh --enable-opaque-lsa --enable-ospf-te

	Problem description: to figure out if the IP Forwarding is on or
off zebra opens /proc/net/snmp for reading (why is not sysctl used to do
this??), reads the second line and then returns a value (1 - forwarding
is on, 2 - forwarding is off). This is performed in

Re: file not closed in zebra/ipforward_proc.c - int ipforward()

	I forgot to attach the patch.

-- 
Any views or opinions presented within this e-mail are solely those of
the author and do not necessarily represent those of any company, unless
otherwise expressly stated.

diff -Nur zebra-0.94-CVS/zebra/ipforward_proc.c zebra-0.94-CVS-1BB/zebra/ipforward_proc.c
--- zebra-0.94-CVS/zebra/ipforward_proc.c	2000-01-11 09:11:49.000000000 +0200
+++ zebra-0.94-CVS-1BB/zebra/ipforward_proc.c	2003-10-04 17:23:00.000000000 +0300
 <at>  <at>  -55,6 +55,8  <at>  <at> 
   pnt = fgets (buf, 6, fp);
   sscanf (buf, "Ip: %d", &ipforwarding);
 
+  fclose(fp);
+  
   if (ipforwarding == 1)
     return 1;
 

_______________________________________________
Bug-zebra mailing list
Bug-zebra <at> gnu.org
http://mail.gnu.org/mailman/listinfo/bug-zebra

[quagga-users 528] Re: [zebra 20474] Hardware Spec for a route server

I'd recommend staying away from RedHat.....I've been having some nasty 
kernel problems with them lately.  Switching to a self-rolled kernel seems 
to have cleared most of it up thankfully.

--On Friday, September 26, 2003 13:36 +0100 Moyaze Shivji 
<moyaze=Ijrc5eNNHE0NcMfx0sn7ct73F7V6hmMc <at> public.gmane.org> wrote:

>
> Hi there
>
> I would be greatful if any Zebra/Quagga users who run route-servers can
> tell me what type of hardware spec they are using.
>
> I am currenlty buliding a route-server to accomadate say 250 peers on a
> worst case scernario. I know I could use a normal built PC with Redhat but
> was curious to know if any of the Zebra/Quagga users run any commercially
> built machines.
>
> Thanks
>
> Mo
> _______________________________________________
> Zebra mailing list
> Zebra=4Lz6L6C/05hg9hUCZPvPmw <at> public.gmane.org
> http://ml.zebra.org/mailman/listinfo/zebra

--
GPG/PGP --> 0xE736BD7E 5144 6A2D 977A 6651 DFBE 1462 E351 88B9 E736 BD7E 

[quagga-users 529] Re: [zebra 20474] Re: Hardware Spec for a route server

On Fri, Sep 26, 2003 at 09:31:32AM -0400, Daniel Corbe wrote:
> 
> > -----Original Message-----
> > From: quagga-users-bounces=UOy77sIEA+cAd7ICUelF/Q <at> public.gmane.org
> > [mailto:quagga-users-bounces=UOy77sIEA+cAd7ICUelF/Q <at> public.gmane.org]On Behalf Of Moyaze Shivji
> > Sent: Friday, September 26, 2003 8:36 AM
> > To: zebra=vFwD9omhKpvYtjvyW6yDsg <at> public.gmane.org; quagga-users <at> lists.quagga.net
> > Subject: [quagga-users 482] Hardware Spec for a route server
> >
> >
> >
> > Hi there
> >
> > I would be greatful if any Zebra/Quagga users who run route-servers can
> > tell me what type of hardware spec they are using.
> >
> > I am currenlty buliding a route-server to accomadate say 250 peers on a
> > worst case scernario. I know I could use a normal built PC with Redhat but
> > was curious to know if any of the Zebra/Quagga users run any commercially
> > built machines.
> >
> > Thanks
> >
> > Mo
>
> I'm using two PIII 1.0Ghz boxes with 512Meg of RAM per.  But these boxes are
> also doing a *LOT* of work.
> 
> As far as what you acctually need, that's kind of a hard question to answer
> because we have no information to go on such as expected traffic, operating