From tkunz@sce.carleton.ca Wed Aug 20 16:38:15 2003 From: tkunz@sce.carleton.ca (Thomas Kunz) Date: Wed, 20 Aug 2003 11:38:15 -0400 Subject: [Xorp-users] Defining a new module, xorp 0.3 Message-ID: <3F4395E7.42BB32E6@crc.ca> This is a multi-part message in MIME format. --------------D4316E12AC8EE315E0E5A49F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am trying to define a new module (routing protocol) in Xorp and am running into the following problem. The module is called BCAST, and I defined a template description in etc/templates, attached to this e-mail... I then define an instance of the protocol in a very minimal config.boot, also attached. When running rtrmgr, the module dependencies are discovered correctly, and I get a line that says Module Order: fea rib bcast Rtrmgr then goes about creating a new module fea. Eventually rtrmgr abort with an error message: [ 2003/08/20 11:33:10 FATAL rtrmgr:9023 RTRMGR +939 task.cc find task ] Assertion (_module_commands.find(modname) != _module_commands.end()) failed While I think I understand what that means (module bcast has not been created yet), what do I have to do in the config file (or elsewhere) to get bcast (or anything else besides fea) created. If I take the parameters to bcast out of the template file (and the config.boot file), rtrmgr does not abort, but it only seems to start fea, not RIB or BCAST (and there are executables for both modules in the indicated locations in the template file). In case it makes a difference, these results were obtained under Linux Redhat 7.2, kernel 2.4.7-10 Thomas Kunz --------------D4316E12AC8EE315E0E5A49F Content-Type: text/plain; charset=us-ascii; name="bcast.tp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bcast.tp" protocols { bcast { hello-int: uint = 1; /* by default, send hello message every second */ buffer-size: uint = 10; /* by default, buffer last 10 packets */ } } protocols { bcast { %modinfo: provides bcast; %modinfo: depends rib; %modinfo: path "../bcast/bcast"; %modinfo: statusmethod xrl; %modinfo: shutdownmethod xrl; hello-int { %set: xrl "bcast/bcast/1.0/set_hello_interval?int:u32=$(@)"; %get: xrl "bcast/bcast/1.0/get_hello_interval->int:u32"; } buffer-size { %set: xrl "bcast/bcast/1.0/set_buffer_size?buf:u32=$(@)"; %get: xrl "bcast/bcast/1.0/get_buffer_size->buf:u32"; } } } --------------D4316E12AC8EE315E0E5A49F Content-Type: text/plain; charset=us-ascii; name="config.boot" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="config.boot" interfaces { interface eth0 { description: "routing interface" } } protocols { bcast { hello-int: 1 buffer-size: 10 } } --------------D4316E12AC8EE315E0E5A49F-- From everton@lab.ipaccess.diveo.net.br Thu Aug 21 17:15:53 2003 From: everton@lab.ipaccess.diveo.net.br (Everton da Silva Marques) Date: Thu, 21 Aug 2003 13:15:53 -0300 Subject: [Xorp-users] Is this list alive? Message-ID: <20030821161553.GA26174@netflow.ipaccess.diveo.net.br> Hi. Is this list alive? Thanks, Everton From atanu@ICSI.Berkeley.EDU Thu Aug 21 17:30:38 2003 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 21 Aug 2003 09:30:38 -0700 Subject: [Xorp-users] Is this list alive? In-Reply-To: Your message of "Thu, 21 Aug 2003 13:15:53 -0300." <20030821161553.GA26174@netflow.ipaccess.diveo.net.br> Message-ID: <84914.1061483438@tigger.icir.org> Everton> Hi. Everton> Is this list alive? Yes. Atanu. From pavlin@icir.org Wed Aug 27 08:02:03 2003 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 27 Aug 2003 00:02:03 -0700 Subject: [Xorp-users] Defining a new module, xorp 0.3 In-Reply-To: Message from Thomas Kunz of "Wed, 20 Aug 2003 11:38:15 EDT." <3F4395E7.42BB32E6@crc.ca> Message-ID: <200308270702.h7R723am009118@possum.icir.org> Thomas, First, I'd like to apologize for not answering your email much earlier. We got hit with the email virus/spam and while dealing with it we neglected responding to legitimate email :( I think we were able to reproduce the problem you had. It appears that the problem is in the parsing of the configuration or template files, but we are yet to confirm that and to apply the appropriate solution. We will try to fix this as soon as we can. In the mean time, could you send us the complete log message when you start the rtrmgr. Thanks, Pavlin > I am trying to define a new module (routing protocol) in Xorp and am > running into the following problem. The module is called BCAST, and I > defined a template description in etc/templates, attached to this > e-mail... I then define an instance of the protocol in a very minimal > config.boot, also attached. When running rtrmgr, the module dependencies > are discovered correctly, and I get a line that says > Module Order: fea rib bcast > > Rtrmgr then goes about creating a new module fea. Eventually rtrmgr > abort with an error message: > [ 2003/08/20 11:33:10 FATAL rtrmgr:9023 RTRMGR +939 task.cc find task ] > Assertion (_module_commands.find(modname) != _module_commands.end()) > failed > > While I think I understand what that means (module bcast has not been > created yet), what do I have to do in the config file (or elsewhere) to > get bcast (or anything else besides fea) created. If I take the > parameters to bcast out of the template file (and the config.boot file), > rtrmgr does not abort, but it only seems to start fea, not RIB or BCAST > (and there are executables for both modules in the indicated locations > in the template file). > > In case it makes a difference, these results were obtained under Linux > Redhat 7.2, kernel 2.4.7-10 > > Thomas Kunz > --------------D4316E12AC8EE315E0E5A49F > Content-Type: text/plain; charset=us-ascii; > name="bcast.tp" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename="bcast.tp" > > protocols { > bcast { > hello-int: uint = 1; /* by default, send hello message every second */ > buffer-size: uint = 10; /* by default, buffer last 10 packets */ > } > } > > > protocols { > bcast { > %modinfo: provides bcast; > %modinfo: depends rib; > %modinfo: path "../bcast/bcast"; > %modinfo: statusmethod xrl; > %modinfo: shutdownmethod xrl; > hello-int { > %set: xrl "bcast/bcast/1.0/set_hello_interval?int:u32=$(@)"; > %get: xrl "bcast/bcast/1.0/get_hello_interval->int:u32"; > } > buffer-size { > %set: xrl "bcast/bcast/1.0/set_buffer_size?buf:u32=$(@)"; > %get: xrl "bcast/bcast/1.0/get_buffer_size->buf:u32"; > } > } > } > > > --------------D4316E12AC8EE315E0E5A49F > Content-Type: text/plain; charset=us-ascii; > name="config.boot" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename="config.boot" > > interfaces { > interface eth0 { > description: "routing interface" > } > } > > protocols { > bcast { > hello-int: 1 > buffer-size: 10 > } > } > > > --------------D4316E12AC8EE315E0E5A49F-- > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From atanu@ICSI.Berkeley.EDU Thu Aug 28 22:06:48 2003 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 28 Aug 2003 14:06:48 -0700 Subject: [Xorp-users] Announcing XORP Release 0.4 Message-ID: <75604.1062104808@tigger.icir.org> On behalf of the entire XORP team, I'm delighted to be able to announce XORP release 0.4, now available from www.xorp.org. Main highlight since our last release in June include: - The SNMP interface to XORP and the BGP4 MIB (including traps) is complete. Full release notes are included below. In general, work is progressing very well, although we would not yet recommend running XORP in production routing environments. However, as the architecture is basically complete though, this release of XORP might be useful as the basis for research. If you're interested in the cutting edge, the current snapshot is always available by anonymous CVS. This release indicates a stable point where the documentation matches the code and all the isolation tests are known to succeed on our supported platforms. As always we'd welcome your comments - xorp-users@xorp.org is the right place for general discussion, and private feedback to the XORP core team can be sent to feedback@xorp.org. - The XORP Team ------------------------------------------------------------------ XORP RELEASE NOTES Release 0.4 (2003/08/28) ======================== ALL: - Rename all process names from "foo" to "xorp_foo": bgp -> xorp_bgp fea -> xorp_fea fea_dummy -> xorp_fea_dummy finder -> xorp_finder ospfd -> xorp_ospf rib -> xorp_rib rtrmgr -> xorp_rtrmgr - Added support for "gmake install" that installs the required XORP pieces under /usr/local/xorp. Currently, the installed subdirectories and files follow the organization in the XORP source code tree. Only the following binaries are installed in subdirectory "bin": call_xrl, xorp_rtrmgr, xorpsh. - Removed old directory "mfea", because it is not needed anymore (all the MFEA code has been merged with the FEA). - The code does not compile anymore on MacOS X 10.2.x (or earlier), due to compiler issues. After Apple starts distributing a better compiler (probably with MacOS X 10.3.x?), then attempt will be made to keep the code compiling again on MacOS X. LIBXORP: - Added pre-order iterators for Trie and RefTrie. LIBXIPC: - Addition of virtual methods in XrlRouter to provide processes with an opportunity to detect finder connection, registristration, and disconnection events. XRL: - Minor changes to clnt-gen that changes the names of some typedefs. RTRMGR: - Now all relative paths to templates, xrl files, configuration files, etc are computed relative to the root of the XORP tree. The root is computed in the following order: 1. The shell environment XORP_ROOT (if exists). 2. The parent directory the rtrmgr is run from (only if it contains the etc/templates and the xrl/targets directories). 3. The XORP_ROOT value as defined in config.h (currently this is the installation directory, and it defaults to /usr/local/xorp). XORPSH: - Now all relative paths to executable commands are computed relative to the root of the XORP tree. The root is computed similar to the rtrmgr root (see above), except that in step (2) we consider the parent directory the xorpsh is run instead. FEA/MFEA: - Bug fix: if the multicast protocol to start/stop is PIM, then start/stop PIM multicast routing in the kernel. - Bug fix (Linux-specific): if IGMP/MLD is enabled, then the multicast router will properly receive all IGMP/MLD messages. - Added support to enable/disable unicast forwarding in the kernel via the FEA. Currently, the support is only for FreeBSD, but is not used yet. Hence, the user must explicitly enable unicast forwarding before starting XORP. E.g., in case of FreeBSD run `sysctl net.inet.ip.forwarding=1` as root. In case of Linux run `echo 1 > /proc/sys/net/ipv4/ip_forward` as root. - Fix a compilation problem for NetBSD (courtesy Hitoshi Asaeda and Jun-ichiro itojun Hagino ). - Initial support for Linux /proc parsing to return network interface information (work in progress). - Bug fixes in setting the broadcast or p2p flags and addresses in the FEA internal interface tree (IfTree). - Bug fix in computing the minimum size of a message received on a routing socket. - Change the MFEA configuration scripts so now the IPv4/IPv6 setup is controlled by a single variable IP_VERSION that should be either IPV4 or IPV6. Note that those configuration scripts are temporary solution until the MFEA is integrated with the rtrmgr. RIB: - No significant changes. BGP: - Update packets with unknown path attributes are now correctly handled. MLD/IGMP: - Change the "RX" log messages to include the vif name a message was received on. - Initial support for returning the process status via get_status XRL. - Change the MLD/IGMP configuration scripts so now the IPv4/IPv6 setup is controlled by a single variable IP_VERSION that should be either IPV4 or IPV6. Note that those configuration scripts are temporary solution until the MLD/IGMP is integrated with the rtrmgr. PIM-SM: - Change the "RX" log messages to include the vif name a message was received on. - Change the PIM configuration scripts so now the IPv4/IPv6 setup is controlled by a single variable IP_VERSION that should be either IPV4 or IPV6. Note that those configuration scripts are temporary solution until the PIM is integrated with the rtrmgr. - Implement Join/Prune items fragmentation across Join/Prune messages when generating Join/Prune messages. - Fix some of the XRL names related to static RP configuration in the configuration shell scripts. - Fix the generation of Assert messages when data packets are received on the wrong interface; in addition, the Assert messages triggered by data packets are rate-limited to one Assert message/s (on average, per (S,G) or (*,G) routing entry). - Implement an optimization when generating Assert messages triggered by the data packets received on the wrong interface: suppress the second Assert message that is a duplicate. - Implement bandwidth-prorated SPT switch triggering: The SPT switch can be triggered at the last-hop router if the bandwidth from a given source is above a configured threshold. In addition, the same mechanism is implemented in the RP as well (not in the spec, where the SPT switch in the RP is always triggered by the first packet). - Keep various PIM-related statistics (e.g., number of sent or received PIM control messages per interface, etc), and add the appropriate XRL interface to get or reset those statistics. - Modify slightly the "show pim join" CLI output. E.g., print "Could assert WC:" for all entries, print "Could assert SG:" for (S,G,rpt) as well, etc. - Bug fix: when receiving IPv6 PIM packets, use the IPv6-specific pseudo-header to compute the checksum. CLI: - On exit, restore the original terminal flags in case of stdio-based CLI access. This should fix a bug when running xorpsh from sh/bash and pressing Ctrl-D leaves sh/bash in non-echo mode. - Reverse the key binding of 'j' and 'k' in page mode. Now the binding is same as in "vi/more/less": 'j' scroll down one line, while 'k' scroll up one line. SNMP: - Full implementation of BGP4-MIB module (RFC 1657) including traps. RIP: - Implementation functionally operational save communication with the RIB for injecting routes, the FEA to send and receive packets, FEA interface monitoring code, and an XRL interface for configuration.