James | 1 May 05:32 2004

[quagga-users 1857] IPv6 igp cost metric

hello,

is this just me, or does anyone else see similar issue? here we go...

basically, in IPv4, the cost to reach a specific route in OSPF will show the
following when you type 'show ip route ospf' in zebra:
 Route_to_destination [110/METRIC] via NEXTHOP, NEXTIF, UPTIME

Now let's take a look at the [110/METRIC] part. the 110 is default admin dist
for OSPF, and METRIC would be replaced by the ospf cost to reach that route.

for example:
O>* 65.126.230.186/32 [110/15] via 65.126.230.161, gre0, 3d19h41m

where '15' is the ospf cost to reach that route.

Now, if I do show ip bgp command in bgpd for a prefix adviertised thru 
65.126.230.186, i would see this:
    65.126.230.186 (metric 15) from 65.126.230.141 (65.126.230.141)
                     ^^^^^^
                This should be the IGP metric.

okay, anyway, enough of the background info.

Here is my problem. While we see the IGP metric in zebra and bgpd for OSPF under
IPv4, IPv6 seems to be a whole different animal..

show ipv6 route ospf6 shows:
O>* 3ffe:401d:ff:1641::1/128 [110/0] via fe80::210:dcff:feca:3dfd, gif0, 05:19:14
O>* 3ffe:401d:ff:1641::2/128 [110/0] via fe80::210:dcff:feca:3dfd, gif0, 06:56:31
(Continue reading)

Vladimir Ivaschenko | 2 May 17:55 2004

[quagga-users 1858] Quagga OSPF weird behavior on system clock change


Sometimes I get weird behavior from Quagga OSPF when I change system 
clock on one of the routers (a few months, 20 years etc). What happens 
is that everywhere all routes coming from some of the neighbors 
completely disappear after that. Note that the router on which the 
clock was changed appears to be ok, it's the neighbors which fail.

Sh "ip ospf neigh" does not show anything strange.

Most of my routers do not have clock battery, so I need to do time 
synchronization. Is there any way to fix the problem?

--

-- 
Best Regards,
Vladimir Ivashchenko
ThunderWorx - www.thunderworx.com
Senior Systems Designer/Engineer
Vladimir Ivaschenko | 2 May 18:00 2004

[quagga-users 1859] Re: Quagga OSPF weird behavior on system clock change


Correction: the networks behind the router on which the clock changes 
also disappear from OSPF and restart of Quagga is required to fix the 
problem. Quagga version 0.96.4.

Vladimir Ivaschenko wrote:
> 
> Sometimes I get weird behavior from Quagga OSPF when I change system 
> clock on one of the routers (a few months, 20 years etc). What happens 
> is that everywhere all routes coming from some of the neighbors 
> completely disappear after that. Note that the router on which the clock 
> was changed appears to be ok, it's the neighbors which fail.
> 
> Sh "ip ospf neigh" does not show anything strange.
> 
> Most of my routers do not have clock battery, so I need to do time 
> synchronization. Is there any way to fix the problem?
> 

--

-- 
Best Regards,
Vladimir Ivashchenko
ThunderWorx - www.thunderworx.com
Senior Systems Designer/Engineer
Paul Jakma | 3 May 00:03 2004
Picon

[quagga-users 1860] Re: Quagga OSPF weird behavior on system clock change

On Sun, 2 May 2004, Vladimir Ivaschenko wrote:

> 
> Sometimes I get weird behavior from Quagga OSPF when I change system clock on
> one of the routers (a few months, 20 years etc). 

Forward or backward? backward will definitely cause problems, esp if
by a large amount (timer threads are scheduled by absolute time),
forward should not cause permanent problems.

> What happens is that everywhere all routes coming from some of the
> neighbors completely disappear after that. Note that the router on
> which the clock was changed appears to be ok, it's the neighbors
> which fail.

In what way? What happens?

> Sh "ip ospf neigh" does not show anything strange.
> 
> Most of my routers do not have clock battery, so I need to do time
> synchronization. Is there any way to fix the problem?

dont change the time in huge increments when the machine is fully up
and running: either leave the time alone, or set it at boot and/or
run an NTP client.

regards, 
--

-- 
Paul Jakma     paul@...     paul@...    Key
ID: 64A2FF6A
(Continue reading)

Vladimir Ivaschenko | 3 May 14:15 2004

[quagga-users 1861] Re: Quagga OSPF weird behavior on system clock change


I think that I tested mostly backward.

Is there a way for ospfd to detect that time went back and 
reinitialize the OSPF session?

Paul Jakma wrote:
> On Sun, 2 May 2004, Vladimir Ivaschenko wrote:
> 
> 
>>Sometimes I get weird behavior from Quagga OSPF when I change system clock on
>>one of the routers (a few months, 20 years etc). 
> 
> 
> Forward or backward? backward will definitely cause problems, esp if
> by a large amount (timer threads are scheduled by absolute time),
> forward should not cause permanent problems.
> 
> 
>>What happens is that everywhere all routes coming from some of the
>>neighbors completely disappear after that. Note that the router on
>>which the clock was changed appears to be ok, it's the neighbors
>>which fail.
> 
> 
> In what way? What happens?
>  
> 
>>Sh "ip ospf neigh" does not show anything strange.
>>
(Continue reading)

Paul Jakma | 3 May 14:32 2004
Picon

[quagga-users 1862] Re: Quagga OSPF weird behavior on system clock change

On Mon, 3 May 2004, Vladimir Ivaschenko wrote:

> I think that I tested mostly backward.

That explains it so.

> Is there a way for ospfd to detect that time went back and
> reinitialize the OSPF session?

Not very reliably, nor is it worth the effort. Run ntpdate or rdate
-s at boot, and an ntp client.

regards,
--

-- 
Paul
Jakma	paul@...	paul@...	Key
ID: 64A2FF6A
	warning: do not ever send email to spam@...
Fortune:
In a museum in Havana, there are two skulls of Christopher Columbus,
"one when he was a boy and one when he was a man."
		-- Mark Twain
Paul Jakma | 3 May 14:45 2004
Picon

[quagga-users 1863] Please test latest snapshot

Hi,

We'll hopefully be releasing 0.96.5 very soon (next day or two). 
Would be very helpful to have people compile on all the various odd 
combinations of kernel's and userland that are out there.

regards,
--

-- 
Paul
Jakma	paul@...	paul@...	Key
ID: 64A2FF6A
	warning: do not ever send email to spam@...
Fortune:
Youth.  It's a wonder that anyone ever outgrows it.
Sangeeta Misra | 3 May 15:24 2004
Picon

[quagga-users 1864] Query on Zebra bgp on Solaris

Has anyone been running Zebra's bgp on Solaris  ( same question for  
Quagga) ? If so, I would like to get some feedback on any Solaris 
specific bug that you may have found

Thanks in advance
Sangeeta
Vladimir Ivaschenko | 3 May 15:38 2004

[quagga-users 1865] Re: Quagga OSPF weird behavior on system clock change

Paul Jakma wrote:

>>Is there a way for ospfd to detect that time went back and
>>reinitialize the OSPF session?
> 
> Not very reliably, nor is it worth the effort. Run ntpdate or rdate
> -s at boot, and an ntp client.

That's unfortunate, as failure of OSPF on all the routers when time 
goes back on one of them is more a bug than a feature IMHO.

Isn't it possible to have the thread to compare the last known time() 
with the current one and refork if needed?

I can't do NTP before ospfd starts, as there won't be any routing in 
place. Of course it is possible to set a static route to the NTP 
server, but this is not a nice solution and will require a lot of 
manual configuration on all of the routers (100+).

--

-- 
Best Regards,
Vladimir Ivashchenko
ThunderWorx - www.thunderworx.com
Senior Systems Designer/Engineer
Arnold Nipper | 3 May 15:47 2004
Picon

[quagga-users 1866] Re: Query on Zebra bgp on Solaris

On 03.05.2004 15:24 Sangeeta Misra wrote:

> Has anyone been running Zebra's bgp on Solaris  ( same question for  
> Quagga) ? If so, I would like to get some feedback on any Solaris 
> specific bug that you may have found
> 

I've run Zebra's bgpd on Solaris for a while but did only use it as
route-server. I.e. there was no forwarding between any inetrfaces. It
compiled out of the box without any problems.

There is also a real Solaris port done by some Dutch guy of University
of Amsterdam or so (have a look in the archives). I've never tested that
port.

I stopped to use Solaris (did it on Netra/V100) because of performance
problems (actually bgpd was not able to run through its tables before
keepalive timers to peers expired). I have to say that my config is/was
not necessarily standard as I have/had 100+ peers with full prefix and
bgp-path lists.

Arnold

Gmane