headers
Nick Hilliard | 2 Sep 2011 16:48
Picon

[quagga-users 12436] Re: Software caused connection abort

On 30/08/2011 16:52, Jiri Mikulas wrote:
> Hi,
> I have running
> FreeBSD 8.2-STABLE #0: Tue Aug 30 13:48:54 CEST 2011
> with Quagga 0.99.18
> 
> BGPD is configured as RouteServer, so we have about 120 IPv4 neighbors and
> 80 IPv6 neighbors
> bgpd.conf file size is about 12MB

I'm running 8.1-RELEASE/amd64 + quagga-0.99.17 with ~60 neighbors, and do
not see these problems.  However, on a separate instance of freebsd 8.2
(completely unrelated to route servers), I saw some odd pf related
firewalling issues caused by changes in how pf behaves which were
introduced some time between 7.x and 8.2.

tcpdump might be useful here?  Are you using MD5?  This can be a cause of
anxiety on freebsd.

Also, have you tried the euro-ix branch?

Nick
Permalink | Reply | 0 comments |
headers
Steve Clark | 4 Sep 2011 02:57

[quagga-users 12437] ospfd stuck in Loading/DROther

I have a FreeBSD 6.3 box running quagga_99.15_5 talking to a cisco.

The FreeBSD is stuck in Loading/DROther the cisco thinks things are fine.
doing a show ip os data give me 400 routes - on another FreeBSD box in the
same network and area I get 398 routes - why does quagga think it is missing
something?

--
Stephen Clark
NetWolves
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark-HKs6b5iW9l2akBO8gow8eQ@public.gmane.org
http://www.netwolves.com
_______________________________________________
Quagga-users mailing list
Quagga-users@...
http://lists.quagga.net/mailman/listinfo/quagga-users
Permalink | Reply | 16 comments |
headers
Paul Jakma | 6 Sep 2011 16:34

[quagga-users 12438] Re: ospfd stuck in Loading/DROther

On Sat, 3 Sep 2011, Steve Clark wrote:

> I have a FreeBSD 6.3 box running quagga_99.15_5 talking to a cisco.
>
> The FreeBSD is stuck in Loading/DROther the cisco thinks things are fine.
> doing a show ip os data give me 400 routes - on another FreeBSD box in the
> same network and area I get 398 routes - why does quagga think it is missing
> something?

Please try reproduce it with a more recent version of Quagga.

regards,
--

-- 
Paul Jakma  paul@...  twitter:  <at> pjakma  PGP: 64A2FF6A
Fortune:
Zombie processes haunting the computer
Permalink | Reply | 15 comments |
headers
Steve Clark | 6 Sep 2011 18:48

[quagga-users 12439] Re: ospfd stuck in Loading/DROther

On 09/06/2011 10:34 AM, Paul Jakma wrote:
On Sat, 3 Sep 2011, Steve Clark wrote:
I have a FreeBSD 6.3 box running quagga_99.15_5 talking to a cisco. The FreeBSD is stuck in Loading/DROther the cisco thinks things are fine. doing a show ip os data give me 400 routes - on another FreeBSD box in the same network and area I get 398 routes - why does quagga think it is missing something?
Please try reproduce it with a more recent version of Quagga. regards,
Thanks for the response I'll see if I can get a new package built.

Just some additional info we have over 300 units with
quagga_99.15_5 in this network and I only see this behavior on a couple of units.

Also when I turn on debugging I see quagga sending ls-request to the cisco but the cisco sometimes
takes many seconds to respond about 45 in the capture below. Not being a Cisco guy I don't
know if this is correct but it seems like it is slower than it should be.

2011/09/04 18:31:31 OSPF: Link State Request sent to [224.0.0.5] via [gre1:10.255.13.174]   <<<<<<<<<.
2011/09/04 18:31:32 OSPF: Link State Acknowledgment sent to [224.0.0.5] via [gre1:10.255.13.174].
2011/09/04 18:31:33 OSPF: Link State Request sent to [224.0.0.5] via [gre2:10.255.14.174].
2011/09/04 18:31:36 OSPF: Link State Request sent to [224.0.0.5] via [gre1:10.255.13.174].
2011/09/04 18:31:38 OSPF: Link State Request sent to [224.0.0.5] via [gre2:10.255.14.174].
2011/09/04 18:31:41 OSPF: Link State Request sent to [224.0.0.5] via [gre1:10.255.13.174].
2011/09/04 18:31:43 OSPF: Link State Request sent to [224.0.0.5] via [gre2:10.255.14.174].
2011/09/04 18:31:46 OSPF: Link State Request sent to [224.0.0.5] via [gre1:10.255.13.174].
2011/09/04 18:31:48 OSPF: Link State Request sent to [224.0.0.5] via [gre2:10.255.14.174].
2011/09/04 18:31:51 OSPF: Link State Request sent to [224.0.0.5] via [gre1:10.255.13.174].
2011/09/04 18:31:53 OSPF: Link State Request sent to [224.0.0.5] via [gre2:10.255.14.174].
2011/09/04 18:31:56 OSPF: Link State Request sent to [224.0.0.5] via [gre1:10.255.13.174].
2011/09/04 18:31:58 OSPF: Link State Request sent to [224.0.0.5] via [gre2:10.255.14.174].
2011/09/04 18:32:01 OSPF: Link State Request sent to [224.0.0.5] via [gre1:10.255.13.174].
2011/09/04 18:32:03 OSPF: Link State Request sent to [224.0.0.5] via [gre2:10.255.14.174].
2011/09/04 18:32:06 OSPF: Link State Request sent to [224.0.0.5] via [gre1:10.255.13.174].
2011/09/04 18:32:08 OSPF: Link State Request sent to [224.0.0.5] via [gre2:10.255.14.174].
2011/09/04 18:32:11 OSPF: Link State Request sent to [224.0.0.5] via [gre1:10.255.13.174].
2011/09/04 18:32:13 OSPF: Link State Request sent to [224.0.0.5] via [gre2:10.255.14.174].
>>>>> update finally received
2011/09/04 18:32:15 OSPF: Link State Update received from [172.16.10.45] via [gre1:10.255.13.174] 
2011/09/04 18:32:15 OSPF:  src [10.255.13.173],
2011/09/04 18:32:15 OSPF:  dst [224.0.0.5]
2011/09/04 18:32:15 OSPF: Link State Update sent to [224.0.0.5] via [gre2:10.255.14.174].
2011/09/04 18:32:15 OSPF: Link State Update received from [172.16.10.47] via [gre2:10.255.14.174]


This is from the cisco side:

inc 10.254.43.97

*Sep  3 22:09:31.490: %OSPF-5-ADJCHG: Process 1, Nbr 10.254.43.97 on Tunnel346 from FULL to DOWN, Neighbor Down: Dead timer expired

*Sep  3 22:09:52.618: OSPF: Rcv DBD from 10.254.43.97 on Tunnel346 seq 0x4E640552 opt 0x2 flag 0x7 len 32  mtu 1200 state INIT

*Sep  3 22:09:52.618: OSPF: 2 Way Communication to 10.254.43.97 on Tunnel346, state 2WAY

*Sep  3 22:09:52.618: OSPF: Send DBD to 10.254.43.97 on Tunnel346 seq 0xFBB opt 0x52 flag 0x7 len 32

*Sep  3 22:09:52.722: OSPF: Rcv DBD from 10.254.43.97 on Tunnel346 seq 0xFBB opt 0x2 flag 0x2 len 1172  mtu 1200 state EXSTART

*Sep  3 22:09:52.722: OSPF: Send DBD to 10.254.43.97 on Tunnel346 seq 0xFBC opt 0x52 flag 0x3 len 1152

*Sep  3 22:09:52.830: OSPF: Rcv DBD from 10.254.43.97 on Tunnel346 seq 0xFBC opt 0x2 flag 0x2 len 1172  mtu 1200 state EXCHANGE

*Sep  3 22:09:52.830: OSPF: Send DBD to 10.254.43.97 on Tunnel346 seq 0xFBD opt 0x52 flag 0x3 len 1152

*Sep  3 22:09:52.934: OSPF: Rcv DBD from 10.254.43.97 on Tunnel346 seq 0xFBD opt 0x2 flag 0x2 len 1172  mtu 1200 state EXCHANGE

*Sep  3 22:09:52.934: OSPF: Send DBD to 10.254.43.97 on Tunnel346 seq 0xFBE opt 0x52 flag 0x3 len 1152

*Sep  3 22:09:53.042: OSPF: Rcv DBD from 10.254.43.97 on Tunnel346 seq 0xFBE opt 0x2 flag 0x2 len 1172  mtu 1200 state EXCHANGE

*Sep  3 22:09:53.042: OSPF: Send DBD to 10.254.43.97 on Tunnel346 seq 0xFBF opt 0x52 flag 0x3 len 1152

*Sep  3 22:09:53.150: OSPF: Rcv DBD from 10.254.43.97 on Tunnel346 seq 0xFBF opt 0x2 flag 0x2 len 1172  mtu 1200 state EXCHANGE

*Sep  3 22:09:53.150: OSPF: Send DBD to 10.254.43.97 on Tunnel346 seq 0xFC0 opt 0x52 flag 0x3 len 1152

*Sep  3 22:09:53.258: OSPF: Rcv DBD from 10.254.43.97 on Tunnel346 seq 0xFC0 opt 0x2 flag 0x2 len 1172  mtu 1200 state EXCHANGE

*Sep  3 22:09:53.258: OSPF: Send DBD to 10.254.43.97 on Tunnel346 seq 0xFC1 opt 0x52 flag 0x3 len 1152

*Sep  3 22:09:53.362: OSPF: Rcv DBD from 10.254.43.97 on Tunnel346 seq 0xFC1 opt 0x2 flag 0x0 len 612  mtu 1200 state EXCHANGE

*Sep  3 22:09:53.362: OSPF: Send DBD to 10.254.43.97 on Tunnel346 seq 0xFC2 opt 0x52 flag 0x3 len 772

*Sep  3 22:09:53.362: OSPF: Send LS REQ to 10.254.43.97 length 12 LSA count 1

*Sep  3 22:09:53.458: OSPF: Rcv DBD from 10.254.43.97 on Tunnel346 seq 0xFC2 opt 0x2 flag 0x0 len 32  mtu 1200 state EXCHANGE

*Sep  3 22:09:53.458: OSPF: Send DBD to 10.254.43.97 on Tunnel346 seq 0xFC3 opt 0x52 flag 0x1 len 32

*Sep  3 22:09:53.458: OSPF: Rcv LS UPD from 10.254.43.97 on Tunnel346 length 100 LSA count 1

*Sep  3 22:09:53.550: OSPF: Rcv DBD from 10.254.43.97 on Tunnel346 seq 0xFC3 opt 0x2 flag 0x0 len 32  mtu 1200 state EXCHANGE

*Sep  3 22:09:53.550: OSPF: Exchange Done with 10.254.43.97 on Tunnel346

*Sep  3 22:09:53.550: OSPF: Synchronized with 10.254.43.97 on Tunnel346, state FULL

*Sep  3 22:09:53.550: %OSPF-5-ADJCHG: Process 1, Nbr 10.254.43.97 on Tunnel346 from LOADING to FULL, Loading Done

 



--
Stephen Clark
NetWolves
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark-HKs6b5iW9l2akBO8gow8eQ@public.gmane.org
http://www.netwolves.com
_______________________________________________
Quagga-users mailing list
Quagga-users@...
http://lists.quagga.net/mailman/listinfo/quagga-users
Permalink | Reply | 0 comments |
headers
Steve Clark | 7 Sep 2011 01:48

[quagga-users 12440] Re: ospfd stuck in Loading/DROther

On 09/06/2011 10:34 AM, Paul Jakma wrote:
On Sat, 3 Sep 2011, Steve Clark wrote:
I have a FreeBSD 6.3 box running quagga_99.15_5 talking to a cisco. The FreeBSD is stuck in Loading/DROther the cisco thinks things are fine. doing a show ip os data give me 400 routes - on another FreeBSD box in the same network and area I get 398 routes - why does quagga think it is missing something?
Please try reproduce it with a more recent version of Quagga. regards,
This is with FreeBSD port quagga_0.99.17_9

OSPFd 0.99.17 starting:

    Neighbor ID Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
172.16.10.45      1 Loading/DROther   39.964s 10.255.13.173   gre1:10.255.13.174       0     2     0
172.16.10.47      1 Loading/DROther   37.225s 10.255.14.173   gre2:10.255.14.174       2     2     0

Any particular info that would be helpful let me know.

Thanks,


--
Stephen Clark
NetWolves
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark-HKs6b5iW9l2akBO8gow8eQ@public.gmane.org
http://www.netwolves.com
_______________________________________________
Quagga-users mailing list
Quagga-users@...
http://lists.quagga.net/mailman/listinfo/quagga-users
Permalink | Reply | 13 comments |
headers
Steve Clark | 7 Sep 2011 04:15

[quagga-users 12441] Re: ospfd stuck in Loading/DROther

On 09/06/2011 07:48 PM, Steve Clark wrote:
On 09/06/2011 10:34 AM, Paul Jakma wrote:
On Sat, 3 Sep 2011, Steve Clark wrote:
I have a FreeBSD 6.3 box running quagga_99.15_5 talking to a cisco. The FreeBSD is stuck in Loading/DROther the cisco thinks things are fine. doing a show ip os data give me 400 routes - on another FreeBSD box in the same network and area I get 398 routes - why does quagga think it is missing something?
Please try reproduce it with a more recent version of Quagga. regards,
This is with FreeBSD port quagga_0.99.17_9

OSPFd 0.99.17 starting:

    Neighbor ID Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
172.16.10.45      1 Loading/DROther   39.964s 10.255.13.173   gre1:10.255.13.174       0     2     0
172.16.10.47      1 Loading/DROther   37.225s 10.255.14.173   gre2:10.255.14.174       2     2     0

Any particular info that would be helpful let me know.

Thanks,


I managed to get .18 compiled - same thing:
2011/09/06 21:12:00 OSPF: OSPFd 0.99.18 starting: vty <at> 2604
2011/09/06 21:12:00 OSPF: interface 10.255.13.174 [9] join AllSPFRouters Multicast group.
2011/09/06 21:12:00 OSPF: interface 10.255.14.174 [10] join AllSPFRouters Multicast group.
2011/09/06 21:12:00 OSPF: interface 10.254.43.97 [1] join AllSPFRouters Multicast group.
2011/09/06 21:12:00 OSPF: setsockopt_multicast_ipv4 attempting to drop and re-add (fd 8, ifaddr 10.254.99.129, mcast 224.0.0.5, ifindex 1)
2011/09/06 21:12:00 OSPF: interface 10.254.99.129 [1] join AllSPFRouters Multicast group.
2011/09/06 21:12:00 OSPF: Packet[DD]: Neighbor 172.16.10.45 Negotiation done (Slave).
2011/09/06 21:12:00 OSPF: Packet[DD]: Neighbor 172.16.10.47 Negotiation done (Slave).

^C
H101103:/smb
$ sudo vtysh -c 'sh ip os ne'

    Neighbor ID Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
172.16.10.45      1 Loading/DROther   31.870s 10.255.13.173   gre1:10.255.13.174       1    67     0
172.16.10.47      1 Loading/DROther   36.862s 10.255.14.173   gre2:10.255.14.174       1    67     0


--
Stephen Clark
NetWolves
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark-HKs6b5iW9l2akBO8gow8eQ@public.gmane.org
http://www.netwolves.com
_______________________________________________
Quagga-users mailing list
Quagga-users@...
http://lists.quagga.net/mailman/listinfo/quagga-users
Permalink | Reply | 0 comments |
headers
Jerry Scharf | 7 Sep 2011 09:21

[quagga-users 12442] getting FINs on connection setup for peers

Hi,

I must be doing something simple here that is wrong. I have something 
that is not a normal BGP peer trying to connect to quagga. At times, the 
connection will work fine, other times I will get a FIN back on the 
connection very quickly (in the order of 1 millisecond as seen from 
tcpdump.) Netstat shows the port is opening and listening, and the 3 way 
handshake to start works fine. Sometimes it works and sometimes it 
doesn't and nothing I have been able to find had seemed to make it reliable.

I understand that in the real world, things would try again if this 
happened.

I see this problem on both FreeBSD8.2 stable and linux 
(2.6.38-11-server) on an x_64 box. I am running 0.99.18 with a 
completely generic make (configure --enable-vtysh --enable-user=root)

My setup is dirt simple, and I have added a bunch of things to try to 
reduce the complexity of the connection process as much as possible. I 
have gone to the extreme of loading the arp entries in manually to 
remove that from the equation.

I hops someone can shed light on what is going on.

thanks,
jerry

Here is my config

Building configuration...

Current configuration:
!
hostname TR2
hostname bgpd
log file bgpd.log
!
password zebra
enable password zebra
!
interface eth0
  ipv6 nd suppress-ra
!
interface eth1
  ipv6 nd suppress-ra
!
interface eth2
  ipv6 nd suppress-ra
!
interface eth3
  ipv6 nd suppress-ra
!
interface eth4
  ipv6 nd suppress-ra
!
interface lo
!
router bgp 500
  bgp router-id 172.18.208.202
  neighbor 172.18.208.36 remote-as 501
  neighbor 172.18.208.36 passive
  neighbor 172.18.208.36 ebgp-multihop 255
  neighbor 172.18.208.36 timers 15 180
  neighbor 172.18.209.36 remote-as 502
  neighbor 172.18.209.36 passive
  neighbor 172.18.209.36 ebgp-multihop 255
  neighbor 172.18.209.36 timers 15 180
!
ip forwarding
!
line vty
!
end
Permalink | Reply | 0 comments |
headers
Paul Jakma | 7 Sep 2011 12:21

[quagga-users 12443] Re: ospfd stuck in Loading/DROther

On Tue, 6 Sep 2011, Steve Clark wrote:

> This is with FreeBSD port quagga_0.99.17_9

I guess I should have been more explicit, by recent I mean 0.99.18. 
There's a good few important ospfd bug fixes in that release.

regards,
--

-- 
Paul Jakma	paul@...	Key ID: 64A2FF6A
Fortune:
You know, Callahan's is a peaceable bar, but if you ask that dog what his
favorite formatter is, and he says "roff! roff!", well, I'll just have to...
Permalink | Reply | 11 comments |
headers
Steve Clark | 7 Sep 2011 12:31

[quagga-users 12444] Re: ospfd stuck in Loading/DROther

On 09/07/2011 06:21 AM, Paul Jakma wrote:
On Tue, 6 Sep 2011, Steve Clark wrote:
This is with FreeBSD port quagga_0.99.17_9
I guess I should have been more explicit, by recent I mean 0.99.18. There's a good few important ospfd bug fixes in that release. regards,

I managed to get .18 compiled - same thing:
2011/09/06 21:12:00 OSPF: OSPFd 0.99.18 starting: vty <at> 2604
2011/09/06 21:12:00 OSPF: interface 10.255.13.174 [9] join AllSPFRouters Multicast group.
2011/09/06 21:12:00 OSPF: interface 10.255.14.174 [10] join AllSPFRouters Multicast group.
2011/09/06 21:12:00 OSPF: interface 10.254.43.97 [1] join AllSPFRouters Multicast group.
2011/09/06 21:12:00 OSPF: setsockopt_multicast_ipv4 attempting to drop and re-add (fd 8, ifaddr 10.254.99.129, mcast 224.0.0.5, ifindex 1)
2011/09/06 21:12:00 OSPF: interface 10.254.99.129 [1] join AllSPFRouters Multicast group.
2011/09/06 21:12:00 OSPF: Packet[DD]: Neighbor 172.16.10.45 Negotiation done (Slave).
2011/09/06 21:12:00 OSPF: Packet[DD]: Neighbor 172.16.10.47 Negotiation done (Slave).

^C
H101103:/smb
$ sudo vtysh -c 'sh ip os ne'

    Neighbor ID Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
172.16.10.45      1 Loading/DROther   31.870s 10.255.13.173   gre1:10.255.13.174       1    67     0
172.16.10.47      1 Loading/DROther   36.862s 10.255.14.173   gre2:10.255.14.174       1    67     0


--
Stephen Clark
NetWolves
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark-HKs6b5iW9l2akBO8gow8eQ@public.gmane.org
http://www.netwolves.com
_______________________________________________
Quagga-users mailing list
Quagga-users@...
http://lists.quagga.net/mailman/listinfo/quagga-users
Permalink | Reply | 10 comments |
headers
Steve Clark | 7 Sep 2011 18:20

[quagga-users 12445] Re: ospfd stuck in Loading/DROther

Magically neighbors formed this morning!

2011/09/07 09:56:26 OSPF: nsm_change_state(172.16.10.45, Loading -> Full): scheduling new router-LSA origination
2011/09/07 09:56:26 OSPF: nsm_change_state(172.16.10.47, Loading -> Full): scheduling new router-LSA origination


On 09/07/2011 06:31 AM, Steve Clark wrote:
On 09/07/2011 06:21 AM, Paul Jakma wrote:
On Tue, 6 Sep 2011, Steve Clark wrote:
This is with FreeBSD port quagga_0.99.17_9
I guess I should have been more explicit, by recent I mean 0.99.18. There's a good few important ospfd bug fixes in that release. regards,

I managed to get .18 compiled - same thing:
2011/09/06 21:12:00 OSPF: OSPFd 0.99.18 starting: vty <at> 2604
2011/09/06 21:12:00 OSPF: interface 10.255.13.174 [9] join AllSPFRouters Multicast group.
2011/09/06 21:12:00 OSPF: interface 10.255.14.174 [10] join AllSPFRouters Multicast group.
2011/09/06 21:12:00 OSPF: interface 10.254.43.97 [1] join AllSPFRouters Multicast group.
2011/09/06 21:12:00 OSPF: setsockopt_multicast_ipv4 attempting to drop and re-add (fd 8, ifaddr 10.254.99.129, mcast 224.0.0.5, ifindex 1)
2011/09/06 21:12:00 OSPF: interface 10.254.99.129 [1] join AllSPFRouters Multicast group.
2011/09/06 21:12:00 OSPF: Packet[DD]: Neighbor 172.16.10.45 Negotiation done (Slave).
2011/09/06 21:12:00 OSPF: Packet[DD]: Neighbor 172.16.10.47 Negotiation done (Slave).

^C
H101103:/smb
$ sudo vtysh -c 'sh ip os ne'

    Neighbor ID Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
172.16.10.45      1 Loading/DROther   31.870s 10.255.13.173   gre1:10.255.13.174       1    67     0
172.16.10.47      1 Loading/DROther   36.862s 10.255.14.173   gre2:10.255.14.174       1    67     0


--
Stephen Clark
NetWolves
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark-HKs6b5iW9l2akBO8gow8eQ@public.gmane.org
http://www.netwolves.com
_______________________________________________ Quagga-users mailing list Quagga-users-UOy77sIEA+cAd7ICUelF/Q@public.gmane.org http://lists.quagga.net/mailman/listinfo/quagga-users


--
Stephen Clark
NetWolves
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark-HKs6b5iW9l2akBO8gow8eQ@public.gmane.org
http://www.netwolves.com
_______________________________________________
Quagga-users mailing list
Quagga-users@...
http://lists.quagga.net/mailman/listinfo/quagga-users
Permalink | Reply | 9 comments |

Gmane