From tdurack@gmail.com  Mon Dec  5 18:25:37 2005
From: tdurack@gmail.com (Tim Durack)
Date: Mon, 5 Dec 2005 13:25:37 -0500
Subject: [Xorp-hackers] OSPF Failures
Message-ID: <9e246b4d0512051025h55e99afeue55d0662a5daa0e1@mail.gmail.com>

------=_Part_2401_6103843.1133807137127
Content-Type: multipart/alternative; 
	boundary="----=_Part_2402_11391249.1133807137127"

------=_Part_2402_11391249.1133807137127
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I have created a basic network of four XORP routers, meshed together (gre
tunnels built outside of XORP.)
All the adjacencies come up, but OSPF is randomly dying with the following
error:

[ 2005/12/05 13:08:23  FATAL xorp_ospfv2:4327 OSPF +465 routing_table.cc
add_entry ] Assertion (0 =3D=3D _entries.count(area)) failed
[ 2005/12/05 13:08:23  INFO xorp_rtrmgr:4322 RTRMGR +668 module_manager.cc
killed ] Module abnormally killed: ospf4
[ 2005/12/05 13:08:23  WARNING xorp_rtrmgr:4322 XrlFinderTarget +406
../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed
Target "ospfv2" does not exist or is not enabled.
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol
ospfv2 shutting down -------
OriginTable: ospf
IGP
next table =3D Redist:ospf
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol
ospfv2 shutting down -------
OriginTable: ospf
IGP
next table =3D Redist:ospf
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol
ospfv2 shutting down -------
OriginTable: ospf
IGP
next table =3D Redist:ospf
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol
ospfv2 shutting down -------
OriginTable: ospf
IGP
next table =3D Redist:ospf


Not sure why this is happening. I have attached the configs in case it
helps.

Tim:>

------=_Part_2402_11391249.1133807137127
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I have created a basic network of four XORP routers, meshed together (gre t=
unnels built outside of XORP.)<br>
All the adjacencies come up, but OSPF is randomly dying with the following =
error:<br>
<br>
[ 2005/12/05 13:08:23&nbsp; FATAL xorp_ospfv2:4327 OSPF +465
routing_table.cc add_entry ] Assertion (0 =3D=3D _entries.count(area))
failed<br>
[ 2005/12/05 13:08:23&nbsp; INFO xorp_rtrmgr:4322 RTRMGR +668 module_manage=
r.cc killed ] Module abnormally killed: ospf4<br>
[ 2005/12/05 13:08:23&nbsp; WARNING xorp_rtrmgr:4322 XrlFinderTarget
+406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ]
Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102
Command failed Target &quot;ospfv2&quot; does not exist or is not enabled.<=
br>
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol=
 ospfv2 shutting down -------<br>
OriginTable: ospf<br>
IGP<br>
next table =3D Redist:ospf<br>
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol=
 ospfv2 shutting down -------<br>
OriginTable: ospf<br>
IGP<br>
next table =3D Redist:ospf<br>
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol=
 ospfv2 shutting down -------<br>
OriginTable: ospf<br>
IGP<br>
next table =3D Redist:ospf<br>
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol=
 ospfv2 shutting down -------<br>
OriginTable: ospf<br>
IGP<br>
next table =3D Redist:ospf<br>
<br>
<br>
Not sure why this is happening. I have attached the configs in case it help=
s.<br>
<br>
Tim:&gt;<br>
<br>

------=_Part_2402_11391249.1133807137127--

------=_Part_2401_6103843.1133807137127
Content-Type: application/octet-stream; name=xen1.config
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen1.config"

/*XORP Configuration File, v1.0*/
rtrmgr {
    load-http-command: "curl"
    targetname: "rtrmgr"
    config-directory: ""
    load-file-command: "fetch"
    load-file-command-args: "-o"
    load-ftp-command: "fetch"
    load-ftp-command-args: "-o"
    load-http-command-args: "-o"
    load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    load-tftp-command-args: ""
    save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-file-command-args: ""
    save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-ftp-command-args: ""
    save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-http-command-args: ""
    save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-tftp-command-args: ""
}
fea {
    unicast-forwarding4 {
        disable: false
    }
    targetname: "fea"
}
plumbing {
    rib {
        targetname: "rib"
    }
}
interfaces {
    interface dummy0 {
        vif dummy0 {
            address 10.0.0.1 {
                prefix-length: 32
                disable: false
            }
            disable: false
        }
        disable: false
        discard: false
        description: ""
    }
    interface tun0 {
        vif tun0 {
            address 10.0.0.5 {
                prefix-length: 30
                disable: false
            }
            disable: false
        }
        disable: false
        discard: false
        description: ""
    }
    interface tun1 {
        vif tun1 {
            address 10.1.0.9 {
                prefix-length: 30
                disable: false
            }
            disable: false
        }
        disable: false
        discard: false
        description: ""
    }
    interface tun2 {
        vif tun2 {
            address 10.1.0.13 {
                prefix-length: 30
                disable: false
            }
            disable: false
        }
        disable: false
        discard: false
        description: ""
    }
    targetname: "fea"
    restore-original-config-on-shutdown: false
}
protocols {
    ospf4 {
        router-id: 10.0.0.1
        targetname: "ospfv2"
        ip-router-alert: false
        area 0.0.0.0 {
            interface tun0 {
                vif tun0 {
                    address 10.0.0.5 {
                        disable: false
                        priority: 128
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        transit-delay: 1
                    }
                }
                link-type: "broadcast"
            }
            interface dummy0 {
                vif dummy0 {
                    address 10.0.0.1 {
                        disable: false
                        priority: 128
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        transit-delay: 1
                    }
                }
                link-type: "broadcast"
            }
            interface tun1 {
                vif tun1 {
                    address 10.1.0.9 {
                        disable: false
                        priority: 128
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        transit-delay: 1
                    }
                }
                link-type: "broadcast"
            }
            interface tun2 {
                vif tun2 {
                    address 10.1.0.13 {
                        disable: false
                        priority: 128
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        transit-delay: 1
                    }
                }
                link-type: "broadcast"
            }
            area-type: "normal"
        }
    }
}

------=_Part_2401_6103843.1133807137127
Content-Type: application/octet-stream; name=xen2.config
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen2.config"

/*XORP Configuration File, v1.0*/
rtrmgr {
    load-http-command: "curl"
    targetname: "rtrmgr"
    config-directory: ""
    load-file-command: "fetch"
    load-file-command-args: "-o"
    load-ftp-command: "fetch"
    load-ftp-command-args: "-o"
    load-http-command-args: "-o"
    load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    load-tftp-command-args: ""
    save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-file-command-args: ""
    save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-ftp-command-args: ""
    save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-http-command-args: ""
    save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-tftp-command-args: ""
}
fea {
    unicast-forwarding4 {
        disable: false
    }
    targetname: "fea"
}
plumbing {
    rib {
        targetname: "rib"
    }
}
interfaces {
    interface dummy0 {
        vif dummy0 {
            address 10.0.0.2 {
                prefix-length: 32
                disable: false
            }
            disable: false
        }
        disable: false
        discard: false
        description: ""
    }
    interface tun0 {
        vif tun0 {
            address 10.0.0.6 {
                prefix-length: 30
                disable: false
            }
            disable: false
        }
        disable: false
        discard: false
        description: ""
    }
    interface tun1 {
        vif tun1 {
            address 10.1.0.17 {
                prefix-length: 30
                disable: false
            }
            disable: false
        }
        disable: false
        discard: false
        description: ""
    }
    interface tun2 {
        vif tun2 {
            address 10.1.0.21 {
                prefix-length: 30
                disable: false
            }
            disable: false
        }
        disable: false
        discard: false
        description: ""
    }
    targetname: "fea"
    restore-original-config-on-shutdown: false
}
protocols {
    ospf4 {
        router-id: 10.0.0.2
        targetname: "ospfv2"
        ip-router-alert: false
        area 0.0.0.0 {
            interface tun0 {
                vif tun0 {
                    address 10.0.0.6 {
                        disable: false
                        priority: 128
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        transit-delay: 1
                    }
                }
                link-type: "broadcast"
            }
            interface dummy0 {
                vif dummy0 {
                    address 10.0.0.2 {
                        disable: false
                        priority: 128
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        transit-delay: 1
                    }
                }
                link-type: "broadcast"
            }
            interface tun1 {
                vif tun1 {
                    address 10.1.0.17 {
                        disable: false
                        priority: 128
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        transit-delay: 1
                    }
                }
                link-type: "broadcast"
            }
            interface tun2 {
                vif tun2 {
                    address 10.1.0.21 {
                        disable: false
                        priority: 128
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        transit-delay: 1
                    }
                }
                link-type: "broadcast"
            }
            area-type: "normal"
        }
    }
}

------=_Part_2401_6103843.1133807137127
Content-Type: application/octet-stream; name=xen3.config
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen3.config"

/*XORP Configuration File, v1.0*/
rtrmgr {
    load-http-command: "curl"
    targetname: "rtrmgr"
    config-directory: ""
    load-file-command: "fetch"
    load-file-command-args: "-o"
    load-ftp-command: "fetch"
    load-ftp-command-args: "-o"
    load-http-command-args: "-o"
    load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    load-tftp-command-args: ""
    save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-file-command-args: ""
    save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-ftp-command-args: ""
    save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-http-command-args: ""
    save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-tftp-command-args: ""
}
fea {
    unicast-forwarding4 {
        disable: false
    }
    targetname: "fea"
}
plumbing {
    rib {
        targetname: "rib"
    }
}
interfaces {
    interface dummy0 {
        vif dummy0 {
            address 10.1.0.1 {
                prefix-length: 32
                disable: false
            }
            address 10.1.1.1 {
                prefix-length: 24
                disable: false
            }
            disable: false
        }
        disable: false
        discard: false
        description: ""
    }
    interface tun0 {
        vif tun0 {
            address 10.1.0.5 {
                prefix-length: 30
                disable: false
            }
            disable: false
        }
        disable: false
        discard: false
        description: ""
    }
    interface tun1 {
        vif tun1 {
            address 10.1.0.10 {
                prefix-length: 30
                disable: false
            }
            disable: false
        }
        disable: false
        discard: false
        description: ""
    }
    interface tun2 {
        vif tun2 {
            address 10.1.0.18 {
                prefix-length: 30
                disable: false
            }
            disable: false
        }
        disable: false
        discard: false
        description: ""
    }
    targetname: "fea"
    restore-original-config-on-shutdown: false
}
protocols {
    ospf4 {
        router-id: 10.1.0.1
        targetname: "ospfv2"
        ip-router-alert: false
        area 0.0.0.0 {
            interface dummy0 {
                vif dummy0 {
                    address 10.1.0.1 {
                        disable: false
                        priority: 128
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        transit-delay: 1
                    }
                }
                link-type: "broadcast"
            }
            interface tun0 {
                vif tun0 {
                    address 10.1.0.5 {
                        disable: false
                        priority: 128
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        transit-delay: 1
                    }
                }
                link-type: "broadcast"
            }
            interface tun1 {
                vif tun1 {
                    address 10.1.0.10 {
                        disable: false
                        priority: 128
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        transit-delay: 1
                    }
                }
                link-type: "broadcast"
            }
            interface tun2 {
                vif tun2 {
                    address 10.1.0.18 {
                        disable: false
                        priority: 128
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        transit-delay: 1
                    }
                }
                link-type: "broadcast"
            }
            area-type: "normal"
        }
    }
    bgp {
        bgp-id: 10.1.0.1
        targetname: "bgp"
        local-as: 65001
        peer "10.1.0.2" {
            as: 65001
            peer-port: 179
            local-port: 179
            local-ip: "10.1.0.1"
            holdtime: 90
            client: false
            confederation-member: false
            disable: false
            ipv4-unicast: true
            ipv4-multicast: false
            ipv6-unicast: false
            ipv6-multicast: false
            next-hop: 10.1.0.2
        }
    }
}

------=_Part_2401_6103843.1133807137127
Content-Type: application/octet-stream; name=xen4.config
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen4.config"

/*XORP Configuration File, v1.0*/
rtrmgr {
    load-http-command: "curl"
    targetname: "rtrmgr"
    config-directory: ""
    load-file-command: "fetch"
    load-file-command-args: "-o"
    load-ftp-command: "fetch"
    load-ftp-command-args: "-o"
    load-http-command-args: "-o"
    load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    load-tftp-command-args: ""
    save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-file-command-args: ""
    save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-ftp-command-args: ""
    save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-http-command-args: ""
    save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-tftp-command-args: ""
}
fea {
    unicast-forwarding4 {
        disable: false
    }
    targetname: "fea"
}
plumbing {
    rib {
        targetname: "rib"
    }
}
interfaces {
    interface dummy0 {
        vif dummy0 {
            address 10.1.0.2 {
                prefix-length: 32
                disable: false
            }
            address 10.1.2.1 {
                prefix-length: 24
                disable: false
            }
            disable: false
        }
        disable: false
        discard: false
        description: ""
    }
    interface tun0 {
        vif tun0 {
            address 10.1.0.6 {
                prefix-length: 30
                disable: false
            }
            disable: false
        }
        disable: false
        discard: false
        description: ""
    }
    interface tun1 {
        vif tun1 {
            address 10.1.0.14 {
                prefix-length: 30
                disable: false
            }
            disable: false
        }
        disable: false
        discard: false
        description: ""
    }
    interface tun2 {
        vif tun2 {
            address 10.1.0.22 {
                prefix-length: 30
                disable: false
            }
            disable: false
        }
        disable: false
        discard: false
        description: ""
    }
    targetname: "fea"
    restore-original-config-on-shutdown: false
}
protocols {
    ospf4 {
        router-id: 10.1.0.2
        targetname: "ospfv2"
        ip-router-alert: false
        area 0.0.0.0 {
            interface dummy0 {
                vif dummy0 {
                    address 10.1.0.2 {
                        disable: false
                        priority: 128
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        transit-delay: 1
                    }
                }
                link-type: "broadcast"
            }
            interface tun0 {
                vif tun0 {
                    address 10.1.0.6 {
                        disable: false
                        priority: 128
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        transit-delay: 1
                    }
                }
                link-type: "broadcast"
            }
            interface tun1 {
                vif tun1 {
                    address 10.1.0.14 {
                        disable: false
                        priority: 128
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        transit-delay: 1
                    }
                }
                link-type: "broadcast"
            }
            interface tun2 {
                vif tun2 {
                    address 10.1.0.22 {
                        disable: false
                        priority: 128
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        transit-delay: 1
                    }
                }
                link-type: "broadcast"
            }
            area-type: "normal"
        }
    }
    bgp {
        bgp-id: 10.1.0.2
        targetname: "bgp"
        local-as: 65001
        peer "10.1.0.1" {
            as: 65001
            peer-port: 179
            local-port: 179
            local-ip: "10.1.0.2"
            holdtime: 90
            client: false
            confederation-member: false
            disable: false
            ipv4-unicast: true
            ipv4-multicast: false
            ipv6-unicast: false
            ipv6-multicast: false
            next-hop: 10.1.0.1
        }
    }
}

------=_Part_2401_6103843.1133807137127--

From caddisconsulting@yahoo.com  Mon Dec  5 19:00:30 2005
From: caddisconsulting@yahoo.com (Mike Horn)
Date: Mon, 5 Dec 2005 12:00:30 -0700
Subject: [Xorp-hackers] OSPF Failures
In-Reply-To: <9e246b4d0512051025h55e99afeue55d0662a5daa0e1@mail.gmail.com>
Message-ID: <200512051900.jB5J0g0T069778@wyvern.icir.org>

This is a multi-part message in MIME format.

------=_NextPart_000_02A3_01C5F993.80289860
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Tim,
 
Take a look at XORP bug 383, your issue looks similar but is for different
LSA type, however I think it may have the same root cause.  Before the crash
did you lose your neighbor adjacency and then reestablish it?  Atanu, should
a new bug be entered or do you think 383 covers this issue as well?
 
Also Tim, there are a number of known issues with the current OSPF code, it
might be worth quickly perusing the bug database to see what you might run
into in a test environment.
 
-mike

  _____  

From: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] On
Behalf Of Tim Durack
Sent: Monday, December 05, 2005 11:26 AM
To: xorp-users@xorp.org; xorp-hackers@xorp.org
Subject: [Xorp-hackers] OSPF Failures


I have created a basic network of four XORP routers, meshed together (gre
tunnels built outside of XORP.)
All the adjacencies come up, but OSPF is randomly dying with the following
error:

[ 2005/12/05 13:08:23  FATAL xorp_ospfv2:4327 OSPF +465 routing_table.cc
add_entry ] Assertion (0 == _entries.count(area)) failed
[ 2005/12/05 13:08:23  INFO xorp_rtrmgr:4322 RTRMGR +668 module_manager.cc
killed ] Module abnormally killed: ospf4
[ 2005/12/05 13:08:23  WARNING xorp_rtrmgr:4322 XrlFinderTarget +406
../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed
Target "ospfv2" does not exist or is not enabled.
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol
ospfv2 shutting down -------
OriginTable: ospf
IGP
next table = Redist:ospf
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol
ospfv2 shutting down -------
OriginTable: ospf
IGP
next table = Redist:ospf
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol
ospfv2 shutting down -------
OriginTable: ospf
IGP
next table = Redist:ospf
[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol
ospfv2 shutting down -------
OriginTable: ospf
IGP
next table = Redist:ospf


Not sure why this is happening. I have attached the configs in case it
helps.

Tim:>



------=_NextPart_000_02A3_01C5F993.80289860
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2769" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D667315318-05122005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Tim,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D667315318-05122005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D667315318-05122005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Take a look at XORP bug 383, your issue looks =
similar but=20
is for different LSA type, however I think it may have the same root=20
cause.&nbsp; Before the crash did you lose your neighbor adjacency and =
then=20
reestablish it?&nbsp; </FONT></SPAN><SPAN =
class=3D667315318-05122005><FONT=20
face=3DArial color=3D#0000ff size=3D2>Atanu, should a new bug be entered =
or do you=20
think 383 covers this issue as well?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D667315318-05122005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D667315318-05122005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Also Tim, there are a number of known issues =
with the=20
current OSPF code, it might be worth quickly perusing the bug database =
to see=20
what you might run into in a test environment.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D667315318-05122005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D667315318-05122005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>-mike</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> xorp-hackers-admin@icir.org=20
[mailto:xorp-hackers-admin@icir.org] <B>On Behalf Of </B>Tim=20
Durack<BR><B>Sent:</B> Monday, December 05, 2005 11:26 AM<BR><B>To:</B>=20
xorp-users@xorp.org; xorp-hackers@xorp.org<BR><B>Subject:</B> =
[Xorp-hackers]=20
OSPF Failures<BR></FONT><BR></DIV>
<DIV></DIV>I have created a basic network of four XORP routers, meshed =
together=20
(gre tunnels built outside of XORP.)<BR>All the adjacencies come up, but =
OSPF is=20
randomly dying with the following error:<BR><BR>[ 2005/12/05 =
13:08:23&nbsp;=20
FATAL xorp_ospfv2:4327 OSPF +465 routing_table.cc add_entry ] Assertion =
(0 =3D=3D=20
_entries.count(area)) failed<BR>[ 2005/12/05 13:08:23&nbsp; INFO=20
xorp_rtrmgr:4322 RTRMGR +668 module_manager.cc killed ] Module =
abnormally=20
killed: ospf4<BR>[ 2005/12/05 13:08:23&nbsp; WARNING xorp_rtrmgr:4322=20
XrlFinderTarget +406 ../xrl/targets/finder_base.cc =
handle_finder_0_2_resolve_xrl=20
] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 =
Command=20
failed Target "ospfv2" does not exist or is not enabled.<BR>[ 2005/12/05 =

13:08:23 INFO xorp_rib RIB ] Received death event for protocol ospfv2 =
shutting=20
down -------<BR>OriginTable: ospf<BR>IGP<BR>next table =3D =
Redist:ospf<BR>[=20
2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for =
protocol ospfv2=20
shutting down -------<BR>OriginTable: ospf<BR>IGP<BR>next table =3D=20
Redist:ospf<BR>[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death =
event=20
for protocol ospfv2 shutting down -------<BR>OriginTable: =
ospf<BR>IGP<BR>next=20
table =3D Redist:ospf<BR>[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] =
Received death=20
event for protocol ospfv2 shutting down -------<BR>OriginTable:=20
ospf<BR>IGP<BR>next table =3D Redist:ospf<BR><BR><BR>Not sure why this =
is=20
happening. I have attached the configs in case it=20
helps.<BR><BR>Tim:&gt;<BR><BR></BODY></HTML>

------=_NextPart_000_02A3_01C5F993.80289860--



From tdurack@gmail.com  Mon Dec  5 20:16:08 2005
From: tdurack@gmail.com (Tim Durack)
Date: Mon, 5 Dec 2005 15:16:08 -0500
Subject: [Xorp-hackers] OSPF Failures
In-Reply-To: <200512051900.jB5J0g0T069778@wyvern.icir.org>
References: <9e246b4d0512051025h55e99afeue55d0662a5daa0e1@mail.gmail.com>
 <200512051900.jB5J0g0T069778@wyvern.icir.org>
Message-ID: <9e246b4d0512051216p7fd7c426t4ae6627fb54c7f2@mail.gmail.com>

------=_Part_4188_25978545.1133813768724
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 12/5/05, Mike Horn <caddisconsulting@yahoo.com> wrote:
>
> Hi Tim,
>
> Take a look at XORP bug 383, your issue looks similar but is for differen=
t
> LSA type, however I think it may have the same root cause.  Before the cr=
ash
> did you lose your neighbor adjacency and then reestablish it?  Atanu,
> should a new bug be entered or do you think 383 covers this issue as well=
?
>

The adjacency had just been brought up, after starting xorp_rtrmgr and
loading the config.
It seems to happen randomly to all four of the routers in my lab setup.

Also Tim, there are a number of known issues with the current OSPF code, it
> might be worth quickly perusing the bug database to see what you might ru=
n
> into in a test environment.
>

I know XORP is still very much beta, but it shows a lot of promise.
I'm using it in a Xen laptop based router lab, to teach and test various
routing protocols and configurations.

-mike
>
>  ------------------------------
> *From:* xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] =
*On
> Behalf Of *Tim Durack
> *Sent:* Monday, December 05, 2005 11:26 AM
> *To:* xorp-users@xorp.org; xorp-hackers@xorp.org
> *Subject:* [Xorp-hackers] OSPF Failures
>
> I have created a basic network of four XORP routers, meshed together (gre
> tunnels built outside of XORP.)
> All the adjacencies come up, but OSPF is randomly dying with the followin=
g
> error:
>
> [ 2005/12/05 13:08:23  FATAL xorp_ospfv2:4327 OSPF +465 routing_table.cc
> add_entry ] Assertion (0 =3D=3D _entries.count(area)) failed
> [ 2005/12/05 13:08:23  INFO xorp_rtrmgr:4322 RTRMGR +668 module_manager.c=
c
> killed ] Module abnormally killed: ospf4
> [ 2005/12/05 13:08:23  WARNING xorp_rtrmgr:4322 XrlFinderTarget +406
> ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed
> Target "ospfv2" does not exist or is not enabled.
> [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for
> protocol ospfv2 shutting down -------
> OriginTable: ospf
> IGP
> next table =3D Redist:ospf
> [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for
> protocol ospfv2 shutting down -------
> OriginTable: ospf
> IGP
> next table =3D Redist:ospf
> [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for
> protocol ospfv2 shutting down -------
> OriginTable: ospf
> IGP
> next table =3D Redist:ospf
> [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for
> protocol ospfv2 shutting down -------
> OriginTable: ospf
> IGP
> next table =3D Redist:ospf
>
>
> Not sure why this is happening. I have attached the configs in case it
> helps.
>
> Tim:>
>
>

------=_Part_4188_25978545.1133813768724
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 12/5/05, <b class=3D"gmail_sendername">Mike Horn</b> &lt;<a href=3D"mail=
to:caddisconsulting@yahoo.com">caddisconsulting@yahoo.com</a>&gt; wrote:<di=
v><span class=3D"gmail_quote"></span><blockquote class=3D"gmail_quote" styl=
e=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; =
padding-left: 1ex;">
<span class=3D"q">




<div align=3D"left" dir=3D"ltr"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">Hi Tim,</font></span></div>
<div align=3D"left" dir=3D"ltr"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2"></font></span>&nbsp;</div>
<div align=3D"left" dir=3D"ltr"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">Take a look at XORP bug 383, your issue looks similar but=20
is for different LSA type, however I think it may have the same root=20
cause.&nbsp; Before the crash did you lose your neighbor adjacency and then=
=20
reestablish it?&nbsp; </font></span><span><font color=3D"#0000ff" face=3D"A=
rial" size=3D"2">Atanu, should a new bug be entered or do you=20
think 383 covers this issue as well?</font></span></div></span></blockquote=
><div><br>
The adjacency had just been brought up, after starting xorp_rtrmgr and load=
ing the config.<br>
It seems to happen randomly to all four of the routers in my lab setup.<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><span c=
lass=3D"q"><div align=3D"left" dir=3D"ltr"><span><font color=3D"#0000ff" fa=
ce=3D"Arial" size=3D"2">
Also Tim, there are a number of known issues with the=20
current OSPF code, it might be worth quickly perusing the bug database to s=
ee=20
what you might run into in a test environment.</font></span></div></span></=
blockquote><div><br>
I know XORP is still very much beta, but it shows a lot of promise.<br>
I'm using it in a Xen laptop based router lab, to teach and test various ro=
uting protocols and configurations.<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><span c=
lass=3D"q"><div align=3D"left" dir=3D"ltr"><span><font color=3D"#0000ff" fa=
ce=3D"Arial" size=3D"2">
-mike</font></span></div><br>
<div align=3D"left" dir=3D"ltr" lang=3D"en-us">
<hr>
<font face=3D"Tahoma" size=3D"2"><b>From:</b> <a href=3D"mailto:xorp-hacker=
s-admin@icir.org" target=3D"_blank" onclick=3D"return top.js.OpenExtLink(wi=
ndow,event,this)">xorp-hackers-admin@icir.org</a>=20
[mailto:<a href=3D"mailto:xorp-hackers-admin@icir.org" target=3D"_blank" on=
click=3D"return top.js.OpenExtLink(window,event,this)">xorp-hackers-admin@i=
cir.org</a>] <b>On Behalf Of </b>Tim=20
Durack<br><b>Sent:</b> Monday, December 05, 2005 11:26 AM<br><b>To:</b>=20
<a href=3D"mailto:xorp-users@xorp.org" target=3D"_blank" onclick=3D"return =
top.js.OpenExtLink(window,event,this)">xorp-users@xorp.org</a>; <a href=3D"=
mailto:xorp-hackers@xorp.org" target=3D"_blank" onclick=3D"return top.js.Op=
enExtLink(window,event,this)">
xorp-hackers@xorp.org</a><br><b>Subject:</b> [Xorp-hackers]=20
OSPF Failures<br></font><br></div>
<div></div></span><div><span class=3D"e" id=3D"q_107fc53464179d87_1">I have=
 created a basic network of four XORP routers, meshed together=20
(gre tunnels built outside of XORP.)<br>All the adjacencies come up, but OS=
PF is=20
randomly dying with the following error:<br><br>[ 2005/12/05 13:08:23&nbsp;=
=20
FATAL xorp_ospfv2:4327 OSPF +465 routing_table.cc add_entry ] Assertion (0 =
=3D=3D=20
_entries.count(area)) failed<br>[ 2005/12/05 13:08:23&nbsp; INFO=20
xorp_rtrmgr:4322 RTRMGR +668 module_manager.cc killed ] Module abnormally=
=20
killed: ospf4<br>[ 2005/12/05 13:08:23&nbsp; WARNING xorp_rtrmgr:4322=20
XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolv=
e_xrl=20
] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Comman=
d=20
failed Target &quot;ospfv2&quot; does not exist or is not enabled.<br>[ 200=
5/12/05=20
13:08:23 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutt=
ing=20
down -------<br>OriginTable: ospf<br>IGP<br>next table =3D Redist:ospf<br>[=
=20
2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol o=
spfv2=20
shutting down -------<br>OriginTable: ospf<br>IGP<br>next table =3D=20
Redist:ospf<br>[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death eve=
nt=20
for protocol ospfv2 shutting down -------<br>OriginTable: ospf<br>IGP<br>ne=
xt=20
table =3D Redist:ospf<br>[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received=
 death=20
event for protocol ospfv2 shutting down -------<br>OriginTable:=20
ospf<br>IGP<br>next table =3D Redist:ospf<br><br><br>Not sure why this is=
=20
happening. I have attached the configs in case it=20
helps.<br><br>Tim:&gt;<br><br>

</span></div></blockquote></div><br>

------=_Part_4188_25978545.1133813768724--

From tdurack@gmail.com  Wed Dec  7 21:48:53 2005
From: tdurack@gmail.com (Tim Durack)
Date: Wed, 7 Dec 2005 16:48:53 -0500
Subject: [Xorp-hackers] OSPF Failures
In-Reply-To: <9e246b4d0512051216p7fd7c426t4ae6627fb54c7f2@mail.gmail.com>
References: <9e246b4d0512051025h55e99afeue55d0662a5daa0e1@mail.gmail.com>
 <200512051900.jB5J0g0T069778@wyvern.icir.org>
 <9e246b4d0512051216p7fd7c426t4ae6627fb54c7f2@mail.gmail.com>
Message-ID: <9e246b4d0512071348y2c848a87u42c045a1f9075d7f@mail.gmail.com>

------=_Part_15257_13731909.1133992133864
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Looks like OSPF crashes right after router receives following LSA:

LS age 3600 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
State ID 10.1.0.13 Advertising Router 10.0.0.1 LS sequence number 0x8000000=
1
LS checksum 0xdc45 length 32
Link State Acknowledgement Packet:
        Version 2
        Type 5
        Router ID 10.1.0.2
        Area ID 0.0.0.0
        Auth Type 0

        LS age 3600 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2
Link State ID 10.1.0.13 Advertising Router 10.0.0.1 LS sequence number
0x80000001 LS checksum 0xdc45 length 32
[ 2005/12/07 13:26:52  FATAL xorp_ospfv2:4320 OSPF +465 routing_table.cc
add_entry ] Assertion (0 =3D=3D _entries.count(area)) failed

Maybe related to some of the other outstanding OSPF bugs.

Tim:>

On 12/5/05, Tim Durack <tdurack@gmail.com> wrote:
>
> On 12/5/05, Mike Horn <caddisconsulting@yahoo.com> wrote:
> >
> >  Hi Tim,
> >
> > Take a look at XORP bug 383, your issue looks similar but is for
> > different LSA type, however I think it may have the same root cause.  B=
efore
> > the crash did you lose your neighbor adjacency and then reestablish it?=
  Atanu,
> > should a new bug be entered or do you think 383 covers this issue as we=
ll?
> >
>
> The adjacency had just been brought up, after starting xorp_rtrmgr and
> loading the config.
> It seems to happen randomly to all four of the routers in my lab setup.
>
> Also Tim, there are a number of known issues with the current OSPF code,
> > it might be worth quickly perusing the bug database to see what you mig=
ht
> > run into in a test environment.
> >
>
> I know XORP is still very much beta, but it shows a lot of promise.
> I'm using it in a Xen laptop based router lab, to teach and test various
> routing protocols and configurations.
>
> -mike
> >
> >  ------------------------------
> > *From:* xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org=
]
> > *On Behalf Of *Tim Durack
> > *Sent:* Monday, December 05, 2005 11:26 AM
> > *To:* xorp-users@xorp.org; xorp-hackers@xorp.org
> > *Subject:* [Xorp-hackers] OSPF Failures
> >
> > I have created a basic network of four XORP routers, meshed together
> > (gre tunnels built outside of XORP.)
> > All the adjacencies come up, but OSPF is randomly dying with the
> > following error:
> >
> > [ 2005/12/05 13:08:23  FATAL xorp_ospfv2:4327 OSPF +465 routing_table.c=
c
> > add_entry ] Assertion (0 =3D=3D _entries.count(area)) failed
> > [ 2005/12/05 13:08:23  INFO xorp_rtrmgr:4322 RTRMGR +668
> > module_manager.cc killed ] Module abnormally killed: ospf4
> > [ 2005/12/05 13:08:23  WARNING xorp_rtrmgr:4322 XrlFinderTarget +406
> > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command faile=
d
> > Target "ospfv2" does not exist or is not enabled.
> > [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for
> > protocol ospfv2 shutting down -------
> > OriginTable: ospf
> > IGP
> > next table =3D Redist:ospf
> > [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for
> > protocol ospfv2 shutting down -------
> > OriginTable: ospf
> > IGP
> > next table =3D Redist:ospf
> > [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for
> > protocol ospfv2 shutting down -------
> > OriginTable: ospf
> > IGP
> > next table =3D Redist:ospf
> > [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for
> > protocol ospfv2 shutting down -------
> > OriginTable: ospf
> > IGP
> > next table =3D Redist:ospf
> >
> >
> > Not sure why this is happening. I have attached the configs in case it
> > helps.
> >
> > Tim:>
> >
> >
>

------=_Part_15257_13731909.1133992133864
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Looks like OSPF crashes right after router receives following LSA:<br>
<br>
LS age 3600 Options&nbsp; 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2
Link State ID <a href=3D"http://10.1.0.13">10.1.0.13</a> Advertising Router=
 <a href=3D"http://10.0.0.1">10.0.0.1</a> LS sequence number
0x80000001 LS checksum 0xdc45 length 32<br>
Link State Acknowledgement Packet:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Version 2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Type 5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Router ID <a href=3D"http://10.1=
.0.2">10.1.0.2</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Area ID <a href=3D"http://0.0.0.=
0">0.0.0.0</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Auth Type 0<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LS age 3600 Options&nbsp;
0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID <a href=3D"http=
://10.1.0.13">10.1.0.13</a>
Advertising Router <a href=3D"http://10.0.0.1">10.0.0.1</a> LS sequence num=
ber 0x80000001 LS checksum
0xdc45 length 32<br>
[ 2005/12/07 13:26:52&nbsp; FATAL xorp_ospfv2:4320 OSPF +465
routing_table.cc add_entry ] Assertion (0 =3D=3D _entries.count(area))
failed<br><br>
Maybe related to some of the other outstanding OSPF bugs.<br>
<br>
Tim:&gt;<br>
<br><div><span class=3D"gmail_quote">On 12/5/05, <b class=3D"gmail_senderna=
me">Tim Durack</b> &lt;<a href=3D"mailto:tdurack@gmail.com">tdurack@gmail.c=
om</a>&gt; wrote:</span><blockquote class=3D"gmail_quote" style=3D"border-l=
eft: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:=
 1ex;">
<span class=3D"q">On 12/5/05, <b class=3D"gmail_sendername">Mike Horn</b> &=
lt;<a href=3D"mailto:caddisconsulting@yahoo.com" target=3D"_blank" onclick=
=3D"return top.js.OpenExtLink(window,event,this)">caddisconsulting@yahoo.co=
m</a>&gt; wrote:
</span><div><span class=3D"q"><span class=3D"gmail_quote"></span><blockquot=
e class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204);=
 margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span>




<div align=3D"left" dir=3D"ltr"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">Hi Tim,</font></span></div>
<div align=3D"left" dir=3D"ltr"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2"></font></span>&nbsp;</div>
<div align=3D"left" dir=3D"ltr"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">Take a look at XORP bug 383, your issue looks similar but=20
is for different LSA type, however I think it may have the same root=20
cause.&nbsp; Before the crash did you lose your neighbor adjacency and then=
=20
reestablish it?&nbsp; </font></span><span><font color=3D"#0000ff" face=3D"A=
rial" size=3D"2">Atanu, should a new bug be entered or do you=20
think 383 covers this issue as well?</font></span></div></span></blockquote=
></span><div><br>
The adjacency had just been brought up, after starting xorp_rtrmgr and load=
ing the config.<br>
It seems to happen randomly to all four of the routers in my lab setup.<br>
</div><span class=3D"q"><br><blockquote class=3D"gmail_quote" style=3D"bord=
er-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-l=
eft: 1ex;"><span><div align=3D"left" dir=3D"ltr"><span><font color=3D"#0000=
ff" face=3D"Arial" size=3D"2">

Also Tim, there are a number of known issues with the=20
current OSPF code, it might be worth quickly perusing the bug database to s=
ee=20
what you might run into in a test environment.</font></span></div></span></=
blockquote></span><div><br>
I know XORP is still very much beta, but it shows a lot of promise.<br>
I'm using it in a Xen laptop based router lab, to teach and test various ro=
uting protocols and configurations.<br>
</div><div><span class=3D"e" id=3D"q_107fc9121af7ecdc_6"><br><blockquote cl=
ass=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); mar=
gin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><span><div align=3D"left" dir=
=3D"ltr">
<span><font color=3D"#0000ff" face=3D"Arial" size=3D"2">
-mike</font></span></div><br>
<div align=3D"left" dir=3D"ltr" lang=3D"en-us">
<hr>
<font face=3D"Tahoma" size=3D"2"><b>From:</b> <a href=3D"mailto:xorp-hacker=
s-admin@icir.org" target=3D"_blank" onclick=3D"return top.js.OpenExtLink(wi=
ndow,event,this)">xorp-hackers-admin@icir.org</a>=20
[mailto:<a href=3D"mailto:xorp-hackers-admin@icir.org" target=3D"_blank" on=
click=3D"return top.js.OpenExtLink(window,event,this)">xorp-hackers-admin@i=
cir.org</a>] <b>On Behalf Of </b>Tim=20
Durack<br><b>Sent:</b> Monday, December 05, 2005 11:26 AM<br><b>To:</b>=20
<a href=3D"mailto:xorp-users@xorp.org" target=3D"_blank" onclick=3D"return =
top.js.OpenExtLink(window,event,this)">xorp-users@xorp.org</a>; <a href=3D"=
mailto:xorp-hackers@xorp.org" target=3D"_blank" onclick=3D"return top.js.Op=
enExtLink(window,event,this)">

xorp-hackers@xorp.org</a><br><b>Subject:</b> [Xorp-hackers]=20
OSPF Failures<br></font><br></div>
<div></div></span><div><span>I have created a basic network of four XORP ro=
uters, meshed together=20
(gre tunnels built outside of XORP.)<br>All the adjacencies come up, but OS=
PF is=20
randomly dying with the following error:<br><br>[ 2005/12/05 13:08:23&nbsp;=
=20
FATAL xorp_ospfv2:4327 OSPF +465 routing_table.cc add_entry ] Assertion (0 =
=3D=3D=20
_entries.count(area)) failed<br>[ 2005/12/05 13:08:23&nbsp; INFO=20
xorp_rtrmgr:4322 RTRMGR +668 module_manager.cc killed ] Module abnormally=
=20
killed: ospf4<br>[ 2005/12/05 13:08:23&nbsp; WARNING xorp_rtrmgr:4322=20
XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolv=
e_xrl=20
] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Comman=
d=20
failed Target &quot;ospfv2&quot; does not exist or is not enabled.<br>[ 200=
5/12/05=20
13:08:23 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutt=
ing=20
down -------<br>OriginTable: ospf<br>IGP<br>next table =3D Redist:ospf<br>[=
=20
2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol o=
spfv2=20
shutting down -------<br>OriginTable: ospf<br>IGP<br>next table =3D=20
Redist:ospf<br>[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death eve=
nt=20
for protocol ospfv2 shutting down -------<br>OriginTable: ospf<br>IGP<br>ne=
xt=20
table =3D Redist:ospf<br>[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received=
 death=20
event for protocol ospfv2 shutting down -------<br>OriginTable:=20
ospf<br>IGP<br>next table =3D Redist:ospf<br><br><br>Not sure why this is=
=20
happening. I have attached the configs in case it=20
helps.<br><br>Tim:&gt;<br><br>

</span></div></blockquote></span></div></div><br>

</blockquote></div><br>

------=_Part_15257_13731909.1133992133864--

From tdurack@gmail.com  Thu Dec 15 02:30:34 2005
From: tdurack@gmail.com (Tim Durack)
Date: Wed, 14 Dec 2005 21:30:34 -0500
Subject: [Xorp-hackers] OSPF Failures
In-Reply-To: <9e246b4d0512071348y2c848a87u42c045a1f9075d7f@mail.gmail.com>
References: <9e246b4d0512051025h55e99afeue55d0662a5daa0e1@mail.gmail.com>
 <200512051900.jB5J0g0T069778@wyvern.icir.org>
 <9e246b4d0512051216p7fd7c426t4ae6627fb54c7f2@mail.gmail.com>
 <9e246b4d0512071348y2c848a87u42c045a1f9075d7f@mail.gmail.com>
Message-ID: <9e246b4d0512141830v38159eaaj38e95b41bbe1106b@mail.gmail.com>

------=_Part_19534_14780805.1134613834185
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I "fixed" the problem by commenting out ospf/routing_table.cc line 465:

    // xxx XLOG_ASSERT(0 =3D=3D _entries.count(area));

This might not be the correct way to fix things, but it works for me...

Tim:>


On 12/7/05, Tim Durack <tdurack@gmail.com> wrote:
>
> Looks like OSPF crashes right after router receives following LSA:
>
> LS age 3600 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
> State ID 10.1.0.13 Advertising Router 10.0.0.1 LS sequence number
> 0x80000001 LS checksum 0xdc45 length 32
> Link State Acknowledgement Packet:
>         Version 2
>         Type 5
>         Router ID 10.1.0.2
>         Area ID 0.0.0.0
>         Auth Type 0
>
>         LS age 3600 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x=
2
> Link State ID 10.1.0.13 Advertising Router 10.0.0.1 LS sequence number
> 0x80000001 LS checksum 0xdc45 length 32
> [ 2005/12/07 13:26:52  FATAL xorp_ospfv2:4320 OSPF +465 routing_table.cc
> add_entry ] Assertion (0 =3D=3D _entries.count(area)) failed
>
> Maybe related to some of the other outstanding OSPF bugs.
>
> Tim:>
>
> On 12/5/05, Tim Durack <tdurack@gmail.com> wrote:
> >
> > On 12/5/05, Mike Horn <caddisconsulting@yahoo.com> wrote:
> > >
> > >  Hi Tim,
> > >
> > > Take a look at XORP bug 383, your issue looks similar but is for
> > > different LSA type, however I think it may have the same root cause. =
 Before
> > > the crash did you lose your neighbor adjacency and then reestablish i=
t?  Atanu,
> > > should a new bug be entered or do you think 383 covers this issue as =
well?
> > >
> >
> > The adjacency had just been brought up, after starting xorp_rtrmgr and
> > loading the config.
> > It seems to happen randomly to all four of the routers in my lab setup.
> >
> > Also Tim, there are a number of known issues with the current OSPF code=
,
> > > it might be worth quickly perusing the bug database to see what you m=
ight
> > > run into in a test environment.
> > >
> >
> > I know XORP is still very much beta, but it shows a lot of promise.
> > I'm using it in a Xen laptop based router lab, to teach and test variou=
s
> > routing protocols and configurations.
> >
> >  -mike
> > >
> > >  ------------------------------
> > > *From:* xorp-hackers-admin@icir.org [mailto:
> > > xorp-hackers-admin@icir.org] *On Behalf Of *Tim Durack
> > > *Sent:* Monday, December 05, 2005 11:26 AM
> > > *To:* xorp-users@xorp.org; xorp-hackers@xorp.org
> > > *Subject:* [Xorp-hackers] OSPF Failures
> > >
> > > I have created a basic network of four XORP routers, meshed together
> > > (gre tunnels built outside of XORP.)
> > > All the adjacencies come up, but OSPF is randomly dying with the
> > > following error:
> > >
> > > [ 2005/12/05 13:08:23  FATAL xorp_ospfv2:4327 OSPF +465
> > > routing_table.cc add_entry ] Assertion (0 =3D=3D _entries.count(area)=
) failed
> > > [ 2005/12/05 13:08:23  INFO xorp_rtrmgr:4322 RTRMGR +668
> > > module_manager.cc killed ] Module abnormally killed: ospf4
> > > [ 2005/12/05 13:08:23  WARNING xorp_rtrmgr:4322 XrlFinderTarget +406
> > > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handlin=
g
> > > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command fai=
led
> > > Target "ospfv2" does not exist or is not enabled.
> > > [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for
> > > protocol ospfv2 shutting down -------
> > > OriginTable: ospf
> > > IGP
> > > next table =3D Redist:ospf
> > > [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for
> > > protocol ospfv2 shutting down -------
> > > OriginTable: ospf
> > > IGP
> > > next table =3D Redist:ospf
> > > [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for
> > > protocol ospfv2 shutting down -------
> > > OriginTable: ospf
> > > IGP
> > > next table =3D Redist:ospf
> > > [ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for
> > > protocol ospfv2 shutting down -------
> > > OriginTable: ospf
> > > IGP
> > > next table =3D Redist:ospf
> > >
> > >
> > > Not sure why this is happening. I have attached the configs in case i=
t
> > > helps.
> > >
> > > Tim:>
> > >
> > >
> >
>

------=_Part_19534_14780805.1134613834185
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I &quot;fixed&quot; the problem by commenting out ospf/routing_table.cc lin=
e 465:<br>
<br>
&nbsp;&nbsp;&nbsp; // xxx XLOG_ASSERT(0 =3D=3D _entries.count(area));<br>
<br>
This might not be the correct way to fix things, but it works for me...<br>
<br>
Tim:&gt;<br>
<br><br><div><span class=3D"gmail_quote">On 12/7/05, <b class=3D"gmail_send=
ername">Tim Durack</b> &lt;<a href=3D"mailto:tdurack@gmail.com">tdurack@gma=
il.com</a>&gt; wrote:</span><blockquote class=3D"gmail_quote" style=3D"bord=
er-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-l=
eft: 1ex;">
Looks like OSPF crashes right after router receives following LSA:<br>
<br>
LS age 3600 Options&nbsp; 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2
Link State ID <a href=3D"http://10.1.0.13" target=3D"_blank" onclick=3D"ret=
urn top.js.OpenExtLink(window,event,this)">10.1.0.13</a> Advertising Router=
 <a href=3D"http://10.0.0.1" target=3D"_blank" onclick=3D"return top.js.Ope=
nExtLink(window,event,this)">
10.0.0.1</a> LS sequence number
0x80000001 LS checksum 0xdc45 length 32<br>
Link State Acknowledgement Packet:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Version 2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Type 5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Router ID <a href=3D"http://10.1=
.0.2" target=3D"_blank" onclick=3D"return top.js.OpenExtLink(window,event,t=
his)">10.1.0.2</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Area ID <a href=3D"http://0.0.0.=
0" target=3D"_blank" onclick=3D"return top.js.OpenExtLink(window,event,this=
)">0.0.0.0</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Auth Type 0<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LS age 3600 Options&nbsp;
0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID <a href=3D"http=
://10.1.0.13" target=3D"_blank" onclick=3D"return top.js.OpenExtLink(window=
,event,this)">10.1.0.13</a>
Advertising Router <a href=3D"http://10.0.0.1" target=3D"_blank" onclick=3D=
"return top.js.OpenExtLink(window,event,this)">10.0.0.1</a> LS sequence num=
ber 0x80000001 LS checksum
0xdc45 length 32<br>
[ 2005/12/07 13:26:52&nbsp; FATAL xorp_ospfv2:4320 OSPF +465
routing_table.cc add_entry ] Assertion (0 =3D=3D _entries.count(area))
failed<br><br>
Maybe related to some of the other outstanding OSPF bugs.<br><span class=3D=
"sg">
<br>
Tim:&gt;</span><div><span class=3D"e" id=3D"q_1080732c5ac47524_2"><br>
<br><div><span class=3D"gmail_quote">On 12/5/05, <b class=3D"gmail_senderna=
me">Tim Durack</b> &lt;<a href=3D"mailto:tdurack@gmail.com" target=3D"_blan=
k" onclick=3D"return top.js.OpenExtLink(window,event,this)">tdurack@gmail.c=
om</a>
&gt; wrote:</span><blockquote class=3D"gmail_quote" style=3D"border-left: 1=
px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"=
>
<span>On 12/5/05, <b class=3D"gmail_sendername">Mike Horn</b> &lt;<a href=
=3D"mailto:caddisconsulting@yahoo.com" target=3D"_blank" onclick=3D"return =
top.js.OpenExtLink(window,event,this)">caddisconsulting@yahoo.com</a>&gt; w=
rote:
</span><div><span><span class=3D"gmail_quote"></span><blockquote class=3D"g=
mail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt=
 0pt 0pt 0.8ex; padding-left: 1ex;">
<span>




<div align=3D"left" dir=3D"ltr"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">Hi Tim,</font></span></div>
<div align=3D"left" dir=3D"ltr"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2"></font></span>&nbsp;</div>
<div align=3D"left" dir=3D"ltr"><span><font color=3D"#0000ff" face=3D"Arial=
" size=3D"2">Take a look at XORP bug 383, your issue looks similar but=20
is for different LSA type, however I think it may have the same root=20
cause.&nbsp; Before the crash did you lose your neighbor adjacency and then=
=20
reestablish it?&nbsp; </font></span><span><font color=3D"#0000ff" face=3D"A=
rial" size=3D"2">Atanu, should a new bug be entered or do you=20
think 383 covers this issue as well?</font></span></div></span></blockquote=
></span><div><br>
The adjacency had just been brought up, after starting xorp_rtrmgr and load=
ing the config.<br>
It seems to happen randomly to all four of the routers in my lab setup.<br>
</div><span><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px=
 solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><=
span><div align=3D"left" dir=3D"ltr"><span><font color=3D"#0000ff" face=3D"=
Arial" size=3D"2">


Also Tim, there are a number of known issues with the=20
current OSPF code, it might be worth quickly perusing the bug database to s=
ee=20
what you might run into in a test environment.</font></span></div></span></=
blockquote></span><div><br>
I know XORP is still very much beta, but it shows a lot of promise.<br>
I'm using it in a Xen laptop based router lab, to teach and test various ro=
uting protocols and configurations.<br>
</div><div><span><br><blockquote class=3D"gmail_quote" style=3D"border-left=
: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1e=
x;"><span><div align=3D"left" dir=3D"ltr">
<span><font color=3D"#0000ff" face=3D"Arial" size=3D"2">
-mike</font></span></div><br>
<div align=3D"left" dir=3D"ltr" lang=3D"en-us">
<hr>
<font face=3D"Tahoma" size=3D"2"><b>From:</b> <a href=3D"mailto:xorp-hacker=
s-admin@icir.org" target=3D"_blank" onclick=3D"return top.js.OpenExtLink(wi=
ndow,event,this)">xorp-hackers-admin@icir.org</a>=20
[mailto:<a href=3D"mailto:xorp-hackers-admin@icir.org" target=3D"_blank" on=
click=3D"return top.js.OpenExtLink(window,event,this)">xorp-hackers-admin@i=
cir.org</a>] <b>On Behalf Of </b>Tim=20
Durack<br><b>Sent:</b> Monday, December 05, 2005 11:26 AM<br><b>To:</b>=20
<a href=3D"mailto:xorp-users@xorp.org" target=3D"_blank" onclick=3D"return =
top.js.OpenExtLink(window,event,this)">xorp-users@xorp.org</a>; <a href=3D"=
mailto:xorp-hackers@xorp.org" target=3D"_blank" onclick=3D"return top.js.Op=
enExtLink(window,event,this)">


xorp-hackers@xorp.org</a><br><b>Subject:</b> [Xorp-hackers]=20
OSPF Failures<br></font><br></div>
<div></div></span><div><span>I have created a basic network of four XORP ro=
uters, meshed together=20
(gre tunnels built outside of XORP.)<br>All the adjacencies come up, but OS=
PF is=20
randomly dying with the following error:<br><br>[ 2005/12/05 13:08:23&nbsp;=
=20
FATAL xorp_ospfv2:4327 OSPF +465 routing_table.cc add_entry ] Assertion (0 =
=3D=3D=20
_entries.count(area)) failed<br>[ 2005/12/05 13:08:23&nbsp; INFO=20
xorp_rtrmgr:4322 RTRMGR +668 module_manager.cc killed ] Module abnormally=
=20
killed: ospf4<br>[ 2005/12/05 13:08:23&nbsp; WARNING xorp_rtrmgr:4322=20
XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolv=
e_xrl=20
] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Comman=
d=20
failed Target &quot;ospfv2&quot; does not exist or is not enabled.<br>[ 200=
5/12/05=20
13:08:23 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutt=
ing=20
down -------<br>OriginTable: ospf<br>IGP<br>next table =3D Redist:ospf<br>[=
=20
2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death event for protocol o=
spfv2=20
shutting down -------<br>OriginTable: ospf<br>IGP<br>next table =3D=20
Redist:ospf<br>[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received death eve=
nt=20
for protocol ospfv2 shutting down -------<br>OriginTable: ospf<br>IGP<br>ne=
xt=20
table =3D Redist:ospf<br>[ 2005/12/05 13:08:23 INFO xorp_rib RIB ] Received=
 death=20
event for protocol ospfv2 shutting down -------<br>OriginTable:=20
ospf<br>IGP<br>next table =3D Redist:ospf<br><br><br>Not sure why this is=
=20
happening. I have attached the configs in case it=20
helps.<br><br>Tim:&gt;<br><br>

</span></div></blockquote></span></div></div><br>

</blockquote></div><br>

</span></div></blockquote></div><br>

------=_Part_19534_14780805.1134613834185--

From hasso@linux.ee  Sun Dec 18 18:20:09 2005
From: hasso@linux.ee (Hasso Tepper)
Date: Sun, 18 Dec 2005 20:20:09 +0200
Subject: [Xorp-hackers] -Werror
Message-ID: <200512182020.09422.hasso@linux.ee>

I tried to compile CVS with gcc-4.0.2 optimise enabled and failed. 
Bugzilla entry will follow shortly, but I think that -Werror usage should 
be discussed though.

There have been several discussions about using it in KDE project for 
example, but core developers always objected - many of these warnings are 
compiler and preprocessor bugs actually and it'd be insane to fix all 
these. In the situation where parsers and optimisers are rewritten with 
every gcc release (okok, not with every release), it's even more insane - 
warnings are even different with different optimise flags used.

Some examples ... Many fea classes don't compile with -Os with gcc-4.0.2, 
but do with -O2:

fticonfig_entry_get_dummy.cc: In destructor 
'FtiConfigEntryGetDummy::~FtiConfigEntryGetDummy()':
fticonfig_entry_get_dummy.cc:47: warning: control may reach end of 
non-void function 'virtual int 
FtiConfigEntryGetDummy::stop(std::string&)' being inlined

What it doesn't like, is:

return (XORP_OK);
UNUSED(error_msg);

Switch places (put return after UNUSED()) and it will compile.

OSPF peer.cc doesn't compile with -Os and -O2:

peer.cc:4446: warning: statement has no effect
peer.cc:4449: warning: statement has no effect
peer.cc:4451: warning: statement has no effect
peer.cc:4452: warning: statement has no effect

What it doesn't like is htonl(). Should this be removed?

Btw, linking bgp fails with (real) error with -Os, but it links with -O2. 
I'm investigating, but should I report it at all? Or is there policy 
which compiler flags are supported?


regards,

-- 
Hasso Tepper

From pavlin@icir.org  Sat Dec 24 05:26:43 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Fri, 23 Dec 2005 21:26:43 -0800
Subject: [Xorp-hackers] -Werror
In-Reply-To: Message from Hasso Tepper <hasso@linux.ee>
 of "Sun, 18 Dec 2005 20:20:09 +0200." <200512182020.09422.hasso@linux.ee>
Message-ID: <200512240526.jBO5QhgP060024@possum.icir.org>

> I tried to compile CVS with gcc-4.0.2 optimise enabled and failed. 
> Bugzilla entry will follow shortly, but I think that -Werror usage should 
> be discussed though.
> 
> There have been several discussions about using it in KDE project for 
> example, but core developers always objected - many of these warnings are 
> compiler and preprocessor bugs actually and it'd be insane to fix all 
> these. In the situation where parsers and optimisers are rewritten with 
> every gcc release (okok, not with every release), it's even more insane - 
> warnings are even different with different optimise flags used.
> 
> Some examples ... Many fea classes don't compile with -Os with gcc-4.0.2, 
> but do with -O2:
> 
> fticonfig_entry_get_dummy.cc: In destructor 
> 'FtiConfigEntryGetDummy::~FtiConfigEntryGetDummy()':
> fticonfig_entry_get_dummy.cc:47: warning: control may reach end of 
> non-void function 'virtual int 
> FtiConfigEntryGetDummy::stop(std::string&)' being inlined
> 
> What it doesn't like, is:
> 
> return (XORP_OK);
> UNUSED(error_msg);
> 
> Switch places (put return after UNUSED()) and it will compile.
> 
> OSPF peer.cc doesn't compile with -Os and -O2:
> 
> peer.cc:4446: warning: statement has no effect
> peer.cc:4449: warning: statement has no effect
> peer.cc:4451: warning: statement has no effect
> peer.cc:4452: warning: statement has no effect
> 
> What it doesn't like is htonl(). Should this be removed?
> 
> Btw, linking bgp fails with (real) error with -Os, but it links with -O2. 
> I'm investigating, but should I report it at all? Or is there policy 
> which compiler flags are supported?

Thanks for the detailed investigation and for the fixes of the
compilation issues. Most of the compilation issues are fixed in CVS
(see  Bugzilla entry #435 and #448 for details).
In general, bugzilla is the best way to report such bugs (which is
exactly what you did).

About -Werror in general, we are strongly in its support, because
it is very helpful in discovering various bugs.
Indeed, occasionally we come across compiler bugs (e.g., the
ntohl()/htonl() issue inside ospf/peer.cc), but those are isolated
cases so it is still worth dealing with those cases and keep using
-Werror.

Pavlin

From hasso@linux.ee  Sun Dec 25 16:29:03 2005
From: hasso@linux.ee (Hasso Tepper)
Date: Sun, 25 Dec 2005 18:29:03 +0200
Subject: [Xorp-hackers] -Werror
In-Reply-To: <200512240526.jBO5QhgP060024@possum.icir.org>
References: <200512240526.jBO5QhgP060024@possum.icir.org>
Message-ID: <200512251829.03942.hasso@linux.ee>

Pavlin Radoslavov wrote:
> About -Werror in general, we are strongly in its support, because
> it is very helpful in discovering various bugs.

OK.

> Indeed, occasionally we come across compiler bugs (e.g., the
> ntohl()/htonl() issue inside ospf/peer.cc), but those are isolated
> cases so it is still worth dealing with those cases and keep using
> -Werror.

I'm not really sure whether it's worth of it, but if it's decided to be 
so, OK. But one part of my question wasn't answered - is there policy 
which compiler flags are supported? Most of these warnings I reported 
appear only with -Os and or -O3.

-- 
Hasso Tepper

From pavlin@icir.org  Sun Dec 25 19:46:35 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Sun, 25 Dec 2005 11:46:35 -0800
Subject: [Xorp-hackers] -Werror
In-Reply-To: Message from Hasso Tepper <hasso@linux.ee>
 of "Sun, 25 Dec 2005 18:29:03 +0200." <200512251829.03942.hasso@linux.ee>
Message-ID: <200512251946.jBPJkZW9077031@possum.icir.org>

> > Indeed, occasionally we come across compiler bugs (e.g., the
> > ntohl()/htonl() issue inside ospf/peer.cc), but those are isolated
> > cases so it is still worth dealing with those cases and keep using
> > -Werror.
> 
> I'm not really sure whether it's worth of it, but if it's decided to be 
> so, OK. But one part of my question wasn't answered - is there policy 
> which compiler flags are supported? Most of these warnings I reported 
> appear only with -Os and or -O3.

Optimization-wise -O2 is the only compiler flag that is added by the
"configure" script (by the --enable-optimization command line
option).
However, as you may know already you can use CFLAGS and CXXFLAGS
shell environments to add any compilation flags.
Hence, our aim is to have XORP compile with any (legal) compilation
flags. Obviously, we cannot check for all possible compiler flags
combinations with our automated tinderbox runs so this is where the
user/developer input is needed to find such issues.

Nevertheless it looks like that -Os and -O3 trigger even more
compilation warnings than -O2 so it may be worth changing the
automated tinderbox scripts to consider those flags as well.

Pavlin