Neighbor state remains in exchange or loading

Vonlanthen, Elmar Elmar.Vonlanthen at united-security-providers.ch
Wed Dec 9 10:49:43 CET 2009


Hello Ondrej

Thanks for your help.

> > If I dump the traffic, I see these LS packets again and again:
> > 08:11:42.636071 IP 10.254.1.10 > 10.254.10.1: OSPFv2, 
> LS-Request, length: 36
> > 08:11:42.637017 IP 10.254.10.1 > 10.254.1.10: OSPFv2, 
> LS-Update, length: 244
> > 08:11:42.640274 IP 10.254.1.10 > 10.254.10.1: OSPFv2, 
> LS-Ack, length: 44
> 
> 10.254.1.10 is the side that reports a neighbor state in 
> exchange or loading?

Yes, that is right.

> Perhaps the best thing would be to use debugging dumps in
> ospf_lsreq_send() (lsreq.c:66, DBG("Requesting ...)
> and in ospf_lsupd_receive() (lsupd.c:413, DBG("Update Type:  ...)
> to see what was requested and what was received.
> 
> One way to not lost in tons of debug messages it to not 
> enable it, just replace
> DBG("xxx", yyy) with log(L_WARN "xxx", yyy) for interesting 
> debug messages.

Here I have the problem again. One neighbor state remains in state
"loading". I activated some debug messages.

2009-12-09 10:23:54 chgut1fw01 bird: Requesting 109th LSA: Type: 1, ID:
172.16.101.1, RT: 172.16.101.1, SN: 0x7fffffff, Age 3600
2009-12-09 10:23:54 chgut1fw01 bird: Update Type: 1 ID: 172.16.101.1 RT:
172.16.101.1, Sn: 0x80000003 Age: 289, Sum: 19615
2009-12-09 10:23:59 chgut1fw01 bird: Requesting 109th LSA: Type: 1, ID:
172.16.101.1, RT: 172.16.101.1, SN: 0x7fffffff, Age 3600
2009-12-09 10:23:59 chgut1fw01 bird: Update Type: 1 ID: 172.16.101.1 RT:
172.16.101.1, Sn: 0x80000003 Age: 293, Sum: 19615
2009-12-09 10:24:04 chgut1fw01 bird: Requesting 109th LSA: Type: 1, ID:
172.16.101.1, RT: 172.16.101.1, SN: 0x7fffffff, Age 3600
2009-12-09 10:24:04 chgut1fw01 bird: Update Type: 1 ID: 172.16.101.1 RT:
172.16.101.1, Sn: 0x80000003 Age: 299, Sum: 19615
2009-12-09 10:24:09 chgut1fw01 bird: Requesting 109th LSA: Type: 1, ID:
172.16.101.1, RT: 172.16.101.1, SN: 0x7fffffff, Age 3600
2009-12-09 10:24:09 chgut1fw01 bird: Update Type: 1 ID: 172.16.101.1 RT:
172.16.101.1, Sn: 0x80000003 Age: 303, Sum: 19615
2009-12-09 10:24:14 chgut1fw01 bird: Requesting 109th LSA: Type: 1, ID:
172.16.101.1, RT: 172.16.101.1, SN: 0x7fffffff, Age 3600
2009-12-09 10:24:14 chgut1fw01 bird: Update Type: 1 ID: 172.16.101.1 RT:
172.16.101.1, Sn: 0x80000003 Age: 309, Sum: 19615
2009-12-09 10:24:19 chgut1fw01 bird: Requesting 109th LSA: Type: 1, ID:
172.16.101.1, RT: 172.16.101.1, SN: 0x7fffffff, Age 3600
2009-12-09 10:24:19 chgut1fw01 bird: Update Type: 1 ID: 172.16.101.1 RT:
172.16.101.1, Sn: 0x80000003 Age: 313, Sum: 19615
2009-12-09 10:24:24 chgut1fw01 bird: Requesting 109th LSA: Type: 1, ID:
172.16.101.1, RT: 172.16.101.1, SN: 0x7fffffff, Age 3600
2009-12-09 10:24:24 chgut1fw01 bird: Update Type: 1 ID: 172.16.101.1 RT:
172.16.101.1, Sn: 0x80000003 Age: 319, Sum: 19615
2009-12-09 10:24:29 chgut1fw01 bird: Requesting 109th LSA: Type: 1, ID:
172.16.101.1, RT: 172.16.101.1, SN: 0x7fffffff, Age 3600
2009-12-09 10:24:29 chgut1fw01 bird: Update Type: 1 ID: 172.16.101.1 RT:
172.16.101.1, Sn: 0x80000003 Age: 323, Sum: 19615
2009-12-09 10:24:34 chgut1fw01 bird: Requesting 109th LSA: Type: 1, ID:
172.16.101.1, RT: 172.16.101.1, SN: 0x7fffffff, Age 3600
2009-12-09 10:24:34 chgut1fw01 bird: Update Type: 1 ID: 172.16.101.1 RT:
172.16.101.1, Sn: 0x80000003 Age: 327, Sum: 19615
2009-12-09 10:24:39 chgut1fw01 bird: Requesting 109th LSA: Type: 1, ID:
172.16.101.1, RT: 172.16.101.1, SN: 0x7fffffff, Age 3600
2009-12-09 10:24:39 chgut1fw01 bird: Update Type: 1 ID: 172.16.101.1 RT:
172.16.101.1, Sn: 0x80000003 Age: 333, Sum: 19615
2009-12-09 10:24:44 chgut1fw01 bird: Requesting 109th LSA: Type: 1, ID:
172.16.101.1, RT: 172.16.101.1, SN: 0x7fffffff, Age 3600

As you can see, the sequence numbers don't match. Is that the problem?
Der Router ID 172.16.101.1 is the LAN ip address of host "chgut1fw01".
The neighbor state, which is not ok is the one of the interface
"gABchgut5". See below for explaination.

The setup is a little bit complicated. And it doesn't always happen with
the same neighbor.

This is our setup:

We have some gateways with ipsec transport connections to each other. If
a gateway has two WAN links, it has connections over both links (called
linkA and linkB). So between two doublelink-gateways I have four
connections (A-A, A-B, B-A, B-B). Over these transport connections we
have GRE-tunnels and trough the GRE-tunnels we use OSPF routing. A
gateway can have multiple OSPF interfaces to another gateway.

In the attachment you will find the bird.conf on gateway 1. The
interfaces "g[AB][AB]<name>" are the GRE-interfaces.

Normally everything is working great! But sometimes, after bird restart,
a neighborstate remains in exchange or loading. It can be resolved with
bird restart or waiting a long time (it seems everytime after some
hours, the state is full again).

I know, it is not easy to understand the setup and locate the error.
Do I have a problem with the sequence numbers?

Best regards
Elmar

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bird.conf
Type: application/octet-stream
Size: 4421 bytes
Desc: bird.conf
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20091209/c82b95d1/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5234 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20091209/c82b95d1/attachment-0001.bin>


More information about the Bird-users mailing list