Hi Pavlin, Thanks for the tips. I did what you advised me and it worked fine! Learned routes through the OSPF process are stored in the RIB but are not installed in the FEA (as I wanted).
The next step that I'm looking to do is to access the RIB database. I'm not 100% sure if accessing to the RIB has to be done through the use of XRLs or not. For this, I'm planning to write an application (I guess a sort of XORP Process) which needs to have the capability to speak to XORP processes, in this case the RIB, and that make other tasks no related with XORP. Any insight that you could give me to start this will be much appreciated. Regards, Francisco -----Original Message----- From: Pavlin Radoslavov [mailto:[EMAIL PROTECTED] Sent: 15 February 2008 18:00 To: Francisco Rodriguez Cc: [email protected] Subject: Re: [Xorp-hackers] Dummy Fea Matters > I'm trying to use XORP to do some experiments and I'm a little bit confused > on where should I start in other to achieve my goal. What I'm looking to do > is to use XORP using the dummy FEA but having the capability to send and > receive IPv4/IPv6 raw packets. Currently I'm not interested in using the > interface management neither the forwarding table management nor the TCP/UDP > I/O packets. I want to use XORP OSPF process with the capacity to exchange > routing packets with other devices (routing packets and in XORP case IPv4/6 > raw packets) but without needing to set any packet forwarding features (at > least not in the machine running the OSPF process). > > > > My idea is to use the dummy FEA but modifying its behavior in the case of a > process request to send an IPv4/6 raw packet (OSPF LSA packets) as well as > to any subscription of the process to claim an IPv4/6 raw packet. Any hint > on where could I start would be much appreciated. It looks like you want to use a mixture of "real" and "dummy" FEA; currently that is not possible. You could use the real FEA with a minor modification: * You need to configure the network interfaces you want to use with the "default-system-config" statement. This will tell the FEA to pick-up the existing system config of the interfaces. * You don't need to include the "fea" section which enables/disables the forwarding in the kernel. * If you want to prevent the OSPF routes reaching the forwarding table in the kernel, off the top of my head I don't think it is possible to do only by using some configuration statements. The simplest solutiont that comes to mind is to modify the following methods inside fea/xrl_fea_target.cc : XrlFeaTarget::redist_transaction4_0_1_add_route() XrlFeaTarget::redist_transaction4_0_1_delete_route() XrlFeaTarget::redist_transaction6_0_1_add_route() XrlFeaTarget::redist_transaction6_0_1_delete_route() In each of those methods you need to add the following statement right in the beginning: return XrlCmdError::OKAY(); I think that's all you need to do that comes to mind. Please let us know if it doesn't help you. Regards, Pavlin _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
