#
# $XORP: xorp/ERRATA,v 1.12 2004/07/09 03:56:05 atanu Exp $
#

		XORP ERRATA

  ALL:
    - Parallel building (e.g., "gmake -j 4") may fail on multi-CPU machines.
      The simplest work-around is to rerun gmake or not to use the -j flag.

    - Building with the optimizer ("./configure --enable-optimize")
      will cause the build to fail. The build fails because some
      warnings are generated by the compiler and we treat warnings as
      fatal. This problem was discovered too late to be fixed for this
      release.

  LIBXORP:
    - No known issues.

  LIBXIPC:
    - No known issues.

  LIBFEACLIENT:
    - No known issues.

  XRL:
    - No known issues.

  RTRMGR:
    - There are several known issues, but none of them is considered critical.
      The list of known issues is available from
      http://www.xorp.org/bugzilla/query.cgi

  XORPSH:
    - A problem was noticed very late in the release process; rather
      than delay the release we have choosen to document the
      problem. The xorpsh provides the command line to the XORP
      router. The router configuration is structured as a tree,
      for instance configuring a new protocol essentially adds a new
      node to the tree. Removing a protocol involves deleting a node
      from the tree. In some cases deleting a node does not remove all
      the associated state; worse putting the same node back seems to
      fail in the majority of cases.

  FEA/MFEA:
    - On Linux, the following error message may appear during graceful
      shutdown (if PIM-SM is also running):

        [ 2004/06/09 14:50:40  ERROR xorp_fea:14359 MFEA +1676
        mfea_mrouter.cc get_sg_count ] ioctl(SIOCGETSGCNT, (10.10.10.10
        224.0.1.20)) failed: Bad file descriptor

      The error is harmless and can be ignored.

    - If a vif has been enabled with the startup configuration file,
      and then is disabled and enabled again via xorpsh, then
      the enabling will not start the operations on that vif.
      E.g., the "show mfea interface" xorpsh command will show the
      vif status as DOWN, and its status cannot be changed to UP.
      The problem is caused by a mismatch between how the enable/disable
      state is handled by the rtrmgr and by the MFEA module itself.
      This will be fixed for XORP Release-1.1.
      Currently, there is no work-around except that restarting the
      rtrmgr with all enabled interfaces again.

    - On Linux with kernel 2.6 (e.g., RedHat FC2 with kernel 2.6.5-1.358),
      some of the tests may fail (with or without an error message),
      but no coredump image. Some of those failures can be contributed
      to a kernel problem. E.g., running "dmesg can show kernel
      "Oops" messages like:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
02235532
*pde = 00000000
Oops: 0000 [#15]
CPU:    0
EIP:    0060:[<02235532>]    Not tainted
EFLAGS: 00010202   (2.6.5-1.358) 
EIP is at __dev_get_by_index+0x14/0x2b
eax: 022db854   ebx: 1ae7aef8   ecx: 00000001   edx: 00000000
esi: 00000000   edi: 00008910   ebp: fee43e9c   esp: 1ae7aef0
ds: 007b   es: 007b   ss: 0068
Process test_finder_eve (pid: 2026, threadinfo=1ae7a000 task=1406d7b0)
Stack: 022365c7 00000000 009caffc 009cc780 0969ef28 fee43edc 00000001 009cc780 
       0969ef28 fee43ed8 00008910 00000000 00008910 fee43e9c 02236e50 fee43e9c 
       07aa4e00 3530355b 5d303637 00000000 0227a55b 021536b6 022cfa00 00000001 
Call Trace:
 [<022365c7>] dev_ifname+0x30/0x66
 [<02236e50>] dev_ioctl+0x83/0x283
 [<0227a55b>] unix_create1+0xef/0xf7
 [<021536b6>] alloc_inode+0xf9/0x175
 [<0227c090>] unix_ioctl+0x72/0x7b
 [<022301a5>] sock_ioctl+0x268/0x280
 [<0223054f>] sys_socket+0x2a/0x3d
 [<0214ea0e>] sys_ioctl+0x1f2/0x224

Code: 0f 18 02 90 2d 34 01 00 00 39 48 34 74 08 85 d2 89 d0 75 ea 

      This appears to be a kernel bug triggered by ioctl(SIOCGIFNAME)
      which itself is called by if_indextoname(3). Currently, there
      is no known solution of the problem except to use a kernel that does
      not have the problem (at this stage it is not known whether all
      2.6 Linux kernels are affected or only specific versions).
      It seems that a very similar problem has been reported to the
      Linux kernel developers, but the problem is still unsolved:

      https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121697

  RIB: 
    - If an interface address is deleted, the RIB may trigger the following
      error in the FEA:

        [ 2004/06/07 16:08:57  ERROR xorp_fea:1605 FEA +259
        fticonfig_entry_set_rtsock.cc delete_entry ] error writing to
        routing socket: No such process
        [ 2004/06/07 16:08:57  ERROR xorp_fea:1605 FEA +61 fti_transaction.cc
        operation_result ] FTI transaction commit failed on DeleteEntry4: net =
        172.16.124.0/24 gateway = 0.0.0.0 ifname =  vifname
        =  metric = 0 admin_distance = 0 xorp_route = false is_deleted = false
        [ 2004/06/07 16:08:57  ERROR xorp_fea:1605 FEA +259

      This error has no side effects, and can be ignored.

    - In some rare cases, the RIB may fail to delete an existing route
      (See http://www.xorp.org/bugzilla/show_bug.cgi?id=62).
      We are aware of the issue and will attempt to fix it in the near future.

  RIP:
    - No known issues.

  BGP:
    - Once BGP selects a route it is taking too long to install it in
      the kernel.

    - If the RIB bug above (failure to delete an existing route) is
      triggered by BGP, then the deletion failure error received by
      BGP from the RIB is considered by BGP as a fatal error.
      This is not a BGP problem, but a RIB problem that will be fixed
      after the XORP Release-1.0.

  STATIC_ROUTES:
    - If the FEA or RIB exit unexpected, then STATIC_ROUTES may start
      printing lots of error messages.
      
  MLD/IGMP:
    - If MLD/IGMP is started with a relatively large number of interfaces
      (e.g., on the order of 20), then it may fail with the following error:

        [ 2004/06/14 12:58:56  ERROR test_pim:16548 MFEA +666
        mfea_proto_comm.cc join_multicast_group ] Cannot join group 224.0.0.2
        on vif eth8: No buffer space available

      The solution is to increase the multicast group membership limit.
      E.g., to increase the value from 20 (the default) to 200, run as a root:

        echo 200 > /proc/sys/net/ipv4/igmp_max_memberships

    - If a vif has been enabled with the startup configuration file,
      and then is disabled and enabled again via xorpsh, then
      the enabling will not start the operations on that vif.
      E.g., the "show igmp interface" xorpsh command will show the
      vif status as DOWN, and its status cannot be changed to UP.
      The problem is caused by a mismatch between how the enable/disable
      state is handled by the rtrmgr and by the MLD/IGMP module itself.
      This will be fixed for XORP Release-1.1.
      Currently, there is no work-around except that restarting the
      rtrmgr with all enabled interfaces again.

  PIM-SM:
    - If the kernel does not support PIM-SM, or if PIM-SM is not enabled
      in the kernel, then running PIM-SM will fail with the following
      error message:
        [ 2004/06/12 10:26:41  ERROR xorp_fea:444 MFEA +529 mfea_mrouter.cc
        start_mrt ] setsockopt(MRT_INIT, 1) failed: Operation not supported

    - On Linux, if the unicast Reverse Path Forwarding information is
      different from the multicast Reverse Path Forwarding information,
      the Reverse Path Filtering should be disabled. E.g., as root:

        echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
      OR
        echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
        echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
        ...

      Otherwise, the router will ignore packets if they don't arrive on
      the reverse-path interface.
      For more information about Reverse Path Filtering see
      http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html

    - If a vif has been enabled with the startup configuration file,
      and then is disabled and enabled again via xorpsh, then
      the enabling will not start the operations on that vif.
      E.g., the "show pim interface" xorpsh command will show the
      vif status as DOWN, and its status cannot be changed to UP.
      The problem is caused by a mismatch between how the enable/disable
      state is handled by the rtrmgr and by the PIM-SM module itself.
      This will be fixed for XORP Release-1.1.
      Currently, there is no work-around except that restarting the
      rtrmgr with all enabled interfaces again.

    - Very late in the release process a problem was found with scheduling
      the internal PIM-SM tasks for state dependency tracking. The result of
      it is that if the router is heavy loaded and if it has lots of multicast
      routing state, then any change that affects many multicast routing
      entries (e.g., MRIB changes, etc) in some cases may result in incorrect
      recomputation of the result multicast routing state. This problem
      will be fixed in the CVS repository right after the XORP Release-1.0.

  FIB2MRIB:
    - If the FEA or RIB exit unexpected, then STATIC_ROUTES may start
      printing lots of error messages.

  CLI:
    - No known issues.

  SNMP:
    - On some versions of Linux, there are some bugs in net-snmp versions
      5.0.8 and 5.0.9, which prevent dynamic loading from working.
      See http://www.xorp.org/snmp.html for links to the net-snmp patches
      that solve the problems.

    - Version 5.1 of net-snmp requires a simple modification, otherwise
      XORP will fail to compile.
      See http://www.xorp.org/snmp.html for a link to the net-snmp patch
      that solves the problems.
