From John.Weaver@motorola.com Tue Jul 5 17:31:16 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Tue, 5 Jul 2005 11:31:16 -0500 Subject: [Xorp-hackers] PIM and IGMP Message-ID: <0DFC73466514D41186B700508B9510410B253EA1@tx14exm04.ftw.mot.com> Hello all. I am a newbie to this project and looking for some info. I am a developer at Motorola and just recently got screwed over by a vendor on some protocol stacks and licensing issues. As opposed to fighting them on it, I proposed to find an open source project and try and integrate the software into our code. Our project is basically a DSLAM chip that we need to run PIM and IGMP on. We will be running Linux with the 2.6.10 kernel. One question I have is is PIM, IGMP, and the route manage stable enough to attempt this? Can PIM and IGMP be seperated from the rest of the functionality or would I have to load everything and just not start them? Anyone think of any big pitfalls of going down the XORP route? Thanks, John From pavlin@icir.org Tue Jul 5 21:48:40 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 05 Jul 2005 13:48:40 -0700 Subject: [Xorp-hackers] PIM and IGMP In-Reply-To: Message from Weaver John-JWEAVER1 of "Tue, 05 Jul 2005 11:31:16 CDT." <0DFC73466514D41186B700508B9510410B253EA1@tx14exm04.ftw.mot.com> Message-ID: <200507052048.j65Kmebl010682@possum.icir.org> > Hello all. I am a newbie to this project and looking for some info. I am a > developer at Motorola and just recently got screwed over by a vendor on some > protocol stacks and licensing issues. As opposed to fighting them on it, I > proposed to find an open source project and try and integrate the software > into our code. > Our project is basically a DSLAM chip that we need to run PIM and IGMP on. > We will be running Linux with the 2.6.10 kernel. One question I have is is > PIM, IGMP, and the route manage stable enough to attempt this? Can PIM and I believe they are reasonably stable with one small caveat (see below). Currently the lastest release is 1.1, but there are several bug fixes in the lastest PIM-SM code in CVS so in general I recommend to use the lastest CVS code. However, in the last 1 week or so we did a number of changes to the rtrmgr and in the process we probably introduced few bugs that are in process of being fixed. Therefore, I'd recommend to start playing with the 1.1 release code to get feeling how things are working (or with, say, 2 weeks old CVS code). By the time you are ready to start integrating XORP with your product we should have fixed and tested the rtrmgr code in CVS and then you can use the lastest CVS code (or the forthcoming 1.2 release). In general, I would highly recommend you that in your final product you use the lastest post-1.1 code from CVS because of the PIM-SM bug fixes (which usually are not noticeable, but should be applied if you are to build a high quality product). > IGMP be seperated from the rest of the functionality or would I have to load > everything and just not start them? Anyone think of any big pitfalls of > going down the XORP route? In general, the IGMP and PIM-SM modules are logically independent from the rest of XORP, and you can run them without running, say, static_routes, RIP or BGP. If you configure only the multicast-related modules in XORP, then the rtrmgr will start only the relevant modules: the FEA/MFEA, RIB, MLD/IGMP, PIM-SM and FIB2MRIB. The only pitfall that comes to mind is that currently we don't have IGMPv3/MLDv2 implemented in case you need it (we have only IGMPv1,2 and MLDv1). Implementing IGMPv3/MLDv2 is on our roadmap (http://www.xorp.org/roadmap.html), but we are not there yet. If you decide to use XORP, please let us know if you run into any issues so we can try to fix them. Pavlin From John.Weaver@motorola.com Tue Jul 5 22:14:18 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Tue, 5 Jul 2005 16:14:18 -0500 Subject: [Xorp-hackers] PIM and IGMP In-Reply-To: Checked Message-ID: <0DFC73466514D41186B700508B9510410B253EA2@tx14exm04.ftw.mot.com> Sounds great! Thanks! We will not be using IGMPv3 for a while so that will not be a problem. The other question is about seperating BGP, RIP, etc from the IGMP and PIM. Can we build the project without these? I am looking for ways to reduce code size and not sure if XORP can be picked apart? Little nervous about the whole C++ thing as I am a C developer and our last PIM/IGMP product was in C. Guess I am going to have to ramp up fairly quickly. My hope is through this experience I can become an active contributor. I have working with switch/router hardware and drivers for the last 5 years. Would really like to get some of the hardware we use and fire up and actual full fledged router with it. Thanks, John -----Original Message----- From: Pavlin Radoslavov To: Weaver John-JWEAVER1 Cc: xorp-hackers@icir.org Sent: 7/5/05 3:48 PM Subject: Re: [Xorp-hackers] PIM and IGMP > Hello all. I am a newbie to this project and looking for some info. I am a > developer at Motorola and just recently got screwed over by a vendor on some > protocol stacks and licensing issues. As opposed to fighting them on it, I > proposed to find an open source project and try and integrate the software > into our code. > Our project is basically a DSLAM chip that we need to run PIM and IGMP on. > We will be running Linux with the 2.6.10 kernel. One question I have is is > PIM, IGMP, and the route manage stable enough to attempt this? Can PIM and I believe they are reasonably stable with one small caveat (see below). Currently the lastest release is 1.1, but there are several bug fixes in the lastest PIM-SM code in CVS so in general I recommend to use the lastest CVS code. However, in the last 1 week or so we did a number of changes to the rtrmgr and in the process we probably introduced few bugs that are in process of being fixed. Therefore, I'd recommend to start playing with the 1.1 release code to get feeling how things are working (or with, say, 2 weeks old CVS code). By the time you are ready to start integrating XORP with your product we should have fixed and tested the rtrmgr code in CVS and then you can use the lastest CVS code (or the forthcoming 1.2 release). In general, I would highly recommend you that in your final product you use the lastest post-1.1 code from CVS because of the PIM-SM bug fixes (which usually are not noticeable, but should be applied if you are to build a high quality product). > IGMP be seperated from the rest of the functionality or would I have to load > everything and just not start them? Anyone think of any big pitfalls of > going down the XORP route? In general, the IGMP and PIM-SM modules are logically independent from the rest of XORP, and you can run them without running, say, static_routes, RIP or BGP. If you configure only the multicast-related modules in XORP, then the rtrmgr will start only the relevant modules: the FEA/MFEA, RIB, MLD/IGMP, PIM-SM and FIB2MRIB. The only pitfall that comes to mind is that currently we don't have IGMPv3/MLDv2 implemented in case you need it (we have only IGMPv1,2 and MLDv1). Implementing IGMPv3/MLDv2 is on our roadmap (http://www.xorp.org/roadmap.html), but we are not there yet. If you decide to use XORP, please let us know if you run into any issues so we can try to fix them. Pavlin From leclanch@enst.fr Tue Jul 5 22:16:21 2005 From: leclanch@enst.fr (Guillaume Leclanche) Date: Tue, 05 Jul 2005 23:16:21 +0200 Subject: [Xorp-hackers] PIM and IGMP In-Reply-To: <200507052048.j65Kmebl010682@possum.icir.org> References: <200507052048.j65Kmebl010682@possum.icir.org> Message-ID: <42CAF8A5.6000902@enst.fr> Pavlin Radoslavov a écrit : > The only pitfall that comes to mind is that currently we don't have > IGMPv3/MLDv2 implemented in case you need it (we have only IGMPv1,2 > and MLDv1). Implementing IGMPv3/MLDv2 is on our roadmap > (http://www.xorp.org/roadmap.html), but we are not there yet. I am currently modifying mldigmp in order for these protocols to be available. At the moment, the code is a battlefield, nothing usable yet :) I'm planing to "release" it around mid-August. Guillaume From bms@spc.org Tue Jul 5 22:25:22 2005 From: bms@spc.org (Bruce M Simpson) Date: Tue, 5 Jul 2005 22:25:22 +0100 Subject: [Xorp-hackers] PIM and IGMP In-Reply-To: <0DFC73466514D41186B700508B9510410B253EA2@tx14exm04.ftw.mot.com> References: <0DFC73466514D41186B700508B9510410B253EA2@tx14exm04.ftw.mot.com> Message-ID: <20050705212522.GB763@empiric.icir.org> On Tue, Jul 05, 2005 at 04:14:18PM -0500, Weaver John-JWEAVER1 wrote: > Sounds great! Thanks! > > We will not be using IGMPv3 for a while so that will not be a problem. The > other question is about seperating BGP, RIP, etc from the IGMP and PIM. Can > we build the project without these? I am looking for ways to reduce code > size and not sure if XORP can be picked apart? Absolutely they can be built without BGP and RIP. In fact in the Windows binary install I've been working on in 'skunkworks mode', both BGP and RIP are optionally installed components. If you're looking to further reduce code size, shared libraries may be an option, but currently there are issues with static constructors and data which prevent this, at least for linkage on ELF platforms; some of the library stuff needs to be reviewed for reentrancy, it's not something we currently have the resources to do. > Little nervous about the whole C++ thing as I am a C developer and our last > PIM/IGMP product was in C. Guess I am going to have to ramp up fairly > quickly. My hope is through this experience I can become an active > contributor. I have working with switch/router hardware and drivers for the > last 5 years. Would really like to get some of the hardware we use and fire > up and actual full fledged router with it. XORP won't deal with any of the idiosyncracies of PPPoE or PPPoA with your DSLAM, but it will provide control plane functionality for IGMP and PIM. XORP shouldn't have a problem controlling forwarding of multicast datagrams over the DSLAM's interfaces as long as each interface is visible to the Linux kernel as a regular point-to-point network interface -- that is, PPPoE/PPPoA encapsulation issues, AAL5 framing for DMT lite etc will be *your* problem. :-) Whilst I'd like to teach XORP to deal with ATM VCs directly I don't have time right now. :-) BMS From John.Weaver@motorola.com Tue Jul 5 22:34:53 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Tue, 5 Jul 2005 16:34:53 -0500 Subject: [Xorp-hackers] PIM and IGMP In-Reply-To: Checked References: Checked Message-ID: <0DFC73466514D41186B700508B9510410B253EA3@tx14exm04.ftw.mot.com> All of the PPPoE stuff should be transparent to the PIM/IGMP stacks. We are writing TAP devices that will interface all the IWF stuff to the stack. Great news on the seperation. Are you able to do simply through make options or are there code mods that had to be done? John -----Original Message----- From: Bruce M Simpson To: Weaver John-JWEAVER1 Cc: 'Pavlin Radoslavov '; xorp-hackers@icir.org Sent: 7/5/05 4:25 PM Subject: Re: [Xorp-hackers] PIM and IGMP On Tue, Jul 05, 2005 at 04:14:18PM -0500, Weaver John-JWEAVER1 wrote: > Sounds great! Thanks! > > We will not be using IGMPv3 for a while so that will not be a problem. The > other question is about seperating BGP, RIP, etc from the IGMP and PIM. Can > we build the project without these? I am looking for ways to reduce code > size and not sure if XORP can be picked apart? Absolutely they can be built without BGP and RIP. In fact in the Windows binary install I've been working on in 'skunkworks mode', both BGP and RIP are optionally installed components. If you're looking to further reduce code size, shared libraries may be an option, but currently there are issues with static constructors and data which prevent this, at least for linkage on ELF platforms; some of the library stuff needs to be reviewed for reentrancy, it's not something we currently have the resources to do. > Little nervous about the whole C++ thing as I am a C developer and our last > PIM/IGMP product was in C. Guess I am going to have to ramp up fairly > quickly. My hope is through this experience I can become an active > contributor. I have working with switch/router hardware and drivers for the > last 5 years. Would really like to get some of the hardware we use and fire > up and actual full fledged router with it. XORP won't deal with any of the idiosyncracies of PPPoE or PPPoA with your DSLAM, but it will provide control plane functionality for IGMP and PIM. XORP shouldn't have a problem controlling forwarding of multicast datagrams over the DSLAM's interfaces as long as each interface is visible to the Linux kernel as a regular point-to-point network interface -- that is, PPPoE/PPPoA encapsulation issues, AAL5 framing for DMT lite etc will be *your* problem. :-) Whilst I'd like to teach XORP to deal with ATM VCs directly I don't have time right now. :-) BMS From pavlin@icir.org Tue Jul 5 22:44:50 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 05 Jul 2005 14:44:50 -0700 Subject: [Xorp-hackers] PIM and IGMP In-Reply-To: Message from Weaver John-JWEAVER1 of "Tue, 05 Jul 2005 16:14:18 CDT." <0DFC73466514D41186B700508B9510410B253EA2@tx14exm04.ftw.mot.com> Message-ID: <200507052144.j65LioiR011294@possum.icir.org> > We will not be using IGMPv3 for a while so that will not be a problem. The > other question is about seperating BGP, RIP, etc from the IGMP and PIM. Can > we build the project without these? I am looking for ways to reduce code > size and not sure if XORP can be picked apart? This should be relatively easy: 1. Edit the top-level xorp/Makefile.am file and remove the directories you don't need compiled. For all practical purposes, the only directories you don't need should be from the following line: SUBDIRS += bgp pim rip rtrmgr static_routes 2. Run ./bootstrap to regenerate the top-level Makefile.in and after that you can run ./configure as usual. One thing you should be aware is that before running ./bootstrap you must have the right versions of the the autoconf/automake/libtool tools. Currently, we use the following versions (also listed in xorp/README): - autoconf version 2.53 - automake version 1.5 - libtool version 1.3.4 Those tools are notorious for behaving differently when the version changes, so try to install a version that is as close as possible to those listed above. > Little nervous about the whole C++ thing as I am a C developer and our last > PIM/IGMP product was in C. Guess I am going to have to ramp up fairly We all have C background, but learning to use C++ wasn't that scary as some would expect :) If you need book references, devnotes/c++refs.txt has a list. The first one on the list is the definite book on the subject: * The C++ Programming Language (3rd Edition), Bjarne Stroustrup, Addison-Wesley. Eventually, you could also start to pick-up things by reading and modifying existing code, but obviously you cannot learn everything only by reading existing code. > quickly. My hope is through this experience I can become an active > contributor. I have working with switch/router hardware and drivers for the > last 5 years. Would really like to get some of the hardware we use and fire > up and actual full fledged router with it. External contribution is always welcome, but first you may want to read the "Licensing and Copyright" section in http://www.xorp.org/contributing.html so you can avoid any legal/licensing issues upfront :) Pavlin From John.Weaver@motorola.com Thu Jul 7 17:29:49 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Thu, 7 Jul 2005 11:29:49 -0500 Subject: [Xorp-hackers] PIM and IGMP Message-ID: <0DFC73466514D41186B700508B9510411AF9723C@tx14exm04.ftw.mot.com> How hard would it be to hack the code so that I could get certain multicast addresses from being advertised across 2 different interfaces. Say I have 2 NIC cards and one is on an external network and one on the internal. 239.x.x.x multicast is external and needs to be seen by hosts internally and 238.x.x.x multicast is internal and should never be known externally. Would there be a particular file that I could put a filter in? Thanks, John -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin@icir.org] Sent: Tuesday, July 05, 2005 4:45 PM To: Weaver John-JWEAVER1 Cc: 'Pavlin Radoslavov '; xorp-hackers@icir.org Subject: Re: [Xorp-hackers] PIM and IGMP > We will not be using IGMPv3 for a while so that will not be a problem. > The other question is about seperating BGP, RIP, etc from the IGMP and > PIM. Can we build the project without these? I am looking for ways > to reduce code size and not sure if XORP can be picked apart? This should be relatively easy: 1. Edit the top-level xorp/Makefile.am file and remove the directories you don't need compiled. For all practical purposes, the only directories you don't need should be from the following line: SUBDIRS += bgp pim rip rtrmgr static_routes 2. Run ./bootstrap to regenerate the top-level Makefile.in and after that you can run ./configure as usual. One thing you should be aware is that before running ./bootstrap you must have the right versions of the the autoconf/automake/libtool tools. Currently, we use the following versions (also listed in xorp/README): - autoconf version 2.53 - automake version 1.5 - libtool version 1.3.4 Those tools are notorious for behaving differently when the version changes, so try to install a version that is as close as possible to those listed above. > Little nervous about the whole C++ thing as I am a C developer and our > last PIM/IGMP product was in C. Guess I am going to have to ramp up > fairly We all have C background, but learning to use C++ wasn't that scary as some would expect :) If you need book references, devnotes/c++refs.txt has a list. The first one on the list is the definite book on the subject: * The C++ Programming Language (3rd Edition), Bjarne Stroustrup, Addison-Wesley. Eventually, you could also start to pick-up things by reading and modifying existing code, but obviously you cannot learn everything only by reading existing code. > quickly. My hope is through this experience I can become an active > contributor. I have working with switch/router hardware and drivers > for the last 5 years. Would really like to get some of the hardware > we use and fire up and actual full fledged router with it. External contribution is always welcome, but first you may want to read the "Licensing and Copyright" section in http://www.xorp.org/contributing.html so you can avoid any legal/licensing issues upfront :) Pavlin From pavlin@icir.org Thu Jul 7 18:50:29 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 07 Jul 2005 10:50:29 -0700 Subject: [Xorp-hackers] PIM and IGMP In-Reply-To: Message from Weaver John-JWEAVER1 of "Thu, 07 Jul 2005 11:29:49 CDT." <0DFC73466514D41186B700508B9510411AF9723C@tx14exm04.ftw.mot.com> Message-ID: <200507071750.j67HoTwr096044@possum.icir.org> > How hard would it be to hack the code so that I could get certain multicast > addresses from being advertised across 2 different interfaces. Say I have 2 > NIC cards and one is on an external network and one on the internal. > 239.x.x.x multicast is external and needs to be seen by hosts internally and > 238.x.x.x multicast is internal and should never be known externally. Would > there be a particular file that I could put a filter in? There is some initial support for multicast scoping, but it is incomplete, and it doesn't cover what you need. Basically, what we have is: * A generic class PimScopeZoneTable that contains information about configured multicast filters per interfaces. * XRL interface to configure those filters: "add_config_scope_zone_by_*" and "delete_config_scope_zone_by_*" inside xrl/interfaces/pim.xif * Support in the PIM Bootstrap implementation to use the above scoping information. What we don't have is: * Hooks in the rtrmgr templates (etc/templates/pimsm4.tp and etc/templates/pimsm6.tp) to configure the multicast filters. Adding those hooks should be trivial. * Support in the handling of the PIM Join/Prune and Assert messages to consider the PimScopeZoneTable when accepting or transmitting those control messages. Adding support for this shouldn't be very difficult, but requires some careful considerations where exactly to put the mods. E.g., in case of PIM Join/Prune messages we need to filter out only some of the entries inside the message rather than the whole message. In any case, the existing code for the Bootstrap scoping per interface (search for pim_scope_zone_table) can help to understand the code. * Documentation to describe the configuration once it is implemented :) Hope that helps, Pavlin From pavlin@icir.org Thu Jul 7 19:12:18 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 07 Jul 2005 11:12:18 -0700 Subject: [Xorp-hackers] PIM and IGMP In-Reply-To: Message from Pavlin Radoslavov of "Thu, 07 Jul 2005 10:50:29 PDT." <200507071750.j67HoTwr096044@possum.icir.org> Message-ID: <200507071812.j67ICIsW096357@possum.icir.org> > > How hard would it be to hack the code so that I could get certain multicast > > addresses from being advertised across 2 different interfaces. Say I have 2 > > NIC cards and one is on an external network and one on the internal. > > 239.x.x.x multicast is external and needs to be seen by hosts internally and > > 238.x.x.x multicast is internal and should never be known externally. Would > > there be a particular file that I could put a filter in? > > There is some initial support for multicast scoping, but it is > incomplete, and it doesn't cover what you need. > Basically, what we have is: > > * A generic class PimScopeZoneTable that contains information about > configured multicast filters per interfaces. > > * XRL interface to configure those filters: > "add_config_scope_zone_by_*" and "delete_config_scope_zone_by_*" > inside xrl/interfaces/pim.xif > > * Support in the PIM Bootstrap implementation to use the above > scoping information. > > What we don't have is: > > * Hooks in the rtrmgr templates (etc/templates/pimsm4.tp and > etc/templates/pimsm6.tp) to configure the multicast filters. > Adding those hooks should be trivial. > > * Support in the handling of the PIM Join/Prune and Assert messages > to consider the PimScopeZoneTable when accepting or transmitting > those control messages. > Adding support for this shouldn't be very difficult, but requires > some careful considerations where exactly to put the mods. > E.g., in case of PIM Join/Prune messages we need to filter out > only some of the entries inside the message rather than the whole > message. > > In any case, the existing code for the Bootstrap scoping per > interface (search for pim_scope_zone_table) can help to > understand the code. > > * Documentation to describe the configuration once it is > implemented :) I forgot to add the following to the list: * Support inside PIM-SM to filter-out the add/delete MLD/IGMP group membership. This should be trivial and should be done inside the PimNode::add_membership() and PimNode::delete_membership() methods. * Support to the MLD/IGMP module for multicast scoping. Currently, the MLD/IGMP module doesn't have any support, but it can be implemented by following the model in the PIM-SM module. Pavlin From John.Weaver@motorola.com Thu Jul 7 21:30:16 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Thu, 7 Jul 2005 15:30:16 -0500 Subject: [Xorp-hackers] PIM and IGMP Message-ID: <0DFC73466514D41186B700508B9510411AF97688@tx14exm04.ftw.mot.com> Thanks. Sounds like I have some work to do. -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin@icir.org] Sent: Thursday, July 07, 2005 1:12 PM To: Pavlin Radoslavov Cc: Weaver John-JWEAVER1; xorp-hackers@icir.org Subject: Re: [Xorp-hackers] PIM and IGMP > > How hard would it be to hack the code so that I could get certain > > multicast addresses from being advertised across 2 different > > interfaces. Say I have 2 NIC cards and one is on an external network and one on the internal. > > 239.x.x.x multicast is external and needs to be seen by hosts > > internally and 238.x.x.x multicast is internal and should never be > > known externally. Would there be a particular file that I could put a filter in? > > There is some initial support for multicast scoping, but it is > incomplete, and it doesn't cover what you need. > Basically, what we have is: > > * A generic class PimScopeZoneTable that contains information about > configured multicast filters per interfaces. > > * XRL interface to configure those filters: > "add_config_scope_zone_by_*" and "delete_config_scope_zone_by_*" > inside xrl/interfaces/pim.xif > > * Support in the PIM Bootstrap implementation to use the above > scoping information. > > What we don't have is: > > * Hooks in the rtrmgr templates (etc/templates/pimsm4.tp and > etc/templates/pimsm6.tp) to configure the multicast filters. > Adding those hooks should be trivial. > > * Support in the handling of the PIM Join/Prune and Assert messages > to consider the PimScopeZoneTable when accepting or transmitting > those control messages. > Adding support for this shouldn't be very difficult, but requires > some careful considerations where exactly to put the mods. > E.g., in case of PIM Join/Prune messages we need to filter out > only some of the entries inside the message rather than the whole > message. > > In any case, the existing code for the Bootstrap scoping per > interface (search for pim_scope_zone_table) can help to > understand the code. > > * Documentation to describe the configuration once it is > implemented :) I forgot to add the following to the list: * Support inside PIM-SM to filter-out the add/delete MLD/IGMP group membership. This should be trivial and should be done inside the PimNode::add_membership() and PimNode::delete_membership() methods. * Support to the MLD/IGMP module for multicast scoping. Currently, the MLD/IGMP module doesn't have any support, but it can be implemented by following the model in the PIM-SM module. Pavlin From Ajay Mahimkar Mon Jul 11 05:51:13 2005 From: Ajay Mahimkar (Ajay Mahimkar) Date: Sun, 10 Jul 2005 23:51:13 -0500 Subject: [Xorp-hackers] Queries on iBGP and RIP Message-ID: <9486df4205071021512ff7f6c4@mail.gmail.com> ------=_Part_4236_20522068.1121057473472 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi: I am using XORP on the control plane of router to make routing decisions=20 using RIP, BGP. I have a couple of queries to the group. 1. The experiment I am trying to perform is three XORP routers in the same= =20 AS using iBGP to set up routes for some networks. Assume 3 routers A, B, C= =20 (completely connected), and B & C advertise for network X. So, given all=20 attributes to have the same value, A would have 2 routes (via B and C) to= =20 network X. In my setup I want to prefer B over C. This could be done by=20 having different local_pref values. Could someone please let me know how to= =20 achieve -> two routers in the same AS advertise different local_pref values= =20 thereby having preference of one router over other?=20 I have been looking into the C++ code and tried with modifying local_pref= =20 values in path_attribute.cc, .hh, bgp.hh, (enabling=20 add_localpref_insertion_filter in plumbing.cc for iBGP).=20 I also enabled if (ibgp() && !local_pref) XLOG_WARNING("%s Update packet from ibgp with no LOCAL_PREF", this->str().c_str()); However, it still gives the warning -> [ 2005/07/10 23:13:52 WARNING=20 xorp_bgp:3510 BGP +1427 peer.cc check_update_packet ] Peer-{128.83.140.131(= 179)=20 128.83.140.150(179)} Update packet from ibgp with no LOCAL_PREF and in the routing table of A, it shows valid routes for both B and C, but= =20 no best route... So, could someone please help me with this. For XORP developers, it should= =20 be relatively easy to figure this out.=20 2. I was trying to use re-advertising of iBGP routes via RIP. I added the= =20 following in the RIP configuration,=20 export bgp { metric: 0 tag: 10 } I tried this with different values of metric and tag 0, 5, 10.....=20 However, I am getting the following warning -> [ 2005/07/10 23:41:55 INFO= =20 xorp_rip XifRib ] Failed Redistribution enable protocol "bgp" - XRL failed:= =20 "102 Command failed Failed to enable route redistribution from protocol=20 "bgp" to XRL target "rip-be52aa17e6cd44b493ea2fc4564882d5@127.0.0.1"" Could someone also let me know how to fix this and how can we advertise BGP= =20 routes using RIP ? Thanks in advance for your time. - Ajay=20 (Graduate Student - UT Austin) ------=_Part_4236_20522068.1121057473472 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi:

I am using XORP on the control plane of router to make routing decisions using RIP, BGP. I have a couple of queries to the group.

1. The experiment I am trying to perform is three XORP routers in the same AS using iBGP to set up routes for some networks. Assume 3 routers A, B, C (completely connected), and B & C advertise for network X. So, given all attributes to have the same value, A would have 2 routes (via B and C) to network X. In my setup I want to prefer B over C. This could be done by having different local_pref values. Could someone please let me know how to achieve -> two routers in the same AS advertise different local_pref values thereby having preference of one router over other?

I have been looking into the C++ code and tried with modifying local_pref values in path_attribute.cc, .hh, bgp.hh, (enabling add_localpref_insertion_filter in plumbing.cc for iBGP).
I also enabled  if (ibgp() && !local_pref)
            XLOG_WAR= NING("%s Update packet from ibgp with no LOCAL_PREF",
            &nb= sp;            this->str().c_str());

However, it still gives the warning -> [ 2005/07/10 23:13:52  WARNING xorp_bgp:3510 BGP +1427 peer.cc check_update_packet ] Peer-{128.83.140.131(179) 128.83.140.150(179)} Update packet from ibgp with no LOCAL_PREF

and in the routing table of A, it shows valid routes for both B and C, but = no best route...

So, could someone please help me with this. For XORP developers, it should = be relatively easy to figure this out.


2. I was trying to use re-advertising of iBGP routes via RIP. I added the f= ollowing in the RIP configuration,

export bgp {
            metric: = 0
            tag: 10<= br>         }

I tried this with different values of metric and tag 0, 5, 10.....

However, I am getting the following warning -> [ 2005/07/10 23:41:55 INFO xorp_rip XifRib ] Failed Redistribution enable protocol "bgp"= ; - XRL failed: "102 Command failed Failed to enable route redistribution from protocol "bgp" to XRL target "rip= -be52aa17e6cd44b493ea2fc4564882d5@127.0.0.1""

Could someone also let me know how to fix this and how can we advertise BGP= routes using RIP ?

Thanks in advance for your time.

- Ajay
(Graduate Student - UT Austin)

------=_Part_4236_20522068.1121057473472-- From a.bittau@cs.ucl.ac.uk Tue Jul 12 01:59:16 2005 From: a.bittau@cs.ucl.ac.uk (Andrea Bittau) Date: Mon, 11 Jul 2005 17:59:16 -0700 Subject: [Xorp-hackers] Queries on iBGP and RIP In-Reply-To: <9486df4205071021512ff7f6c4@mail.gmail.com> References: <9486df4205071021512ff7f6c4@mail.gmail.com> Message-ID: <20050712005916.GA34314@tribal.sorbonet.org> On Sun, Jul 10, 2005 at 11:51:13PM -0500, Ajay Mahimkar wrote: > having different local_pref values. Could someone please let me know how to > achieve -> two routers in the same AS advertise different local_pref values > thereby having preference of one router over other? Use the latest CVS [about 30 mins from now---I think the public CVS needs time to sync, as I just commited]. Try this export policy: policy { policy-statement lp { term a { action { localpref: 123 } } } } protocols { bgp { export: "lp" } } Note that policy lp will simply overwrite the localpref to 123 on any route which is advertised by BGP. It will not cause explicit redistribution from say, static routes. Thus I assume you have routes in BGP somehow... perhaps obtained by another peering. If you want different peerings to have different localprefs try adding a dest block such as: dest { neighbor: 10.0.0.1 } This will cause only 10.0.0.1 to receive a localpref of 123. Note that the current code in BGP will overwrite the localpref to 100 on the input side i think. > 2. I was trying to use re-advertising of iBGP routes via RIP. I added the > following in the RIP configuration, Route re-distribution is in TODO. However it will look something like: policy-statement rdr { term a { source { protocol: "bgp" } } } protocols { rip { export: "rdr" } } I am currently heavily working on policy, and will do so for about 2 weeks. It is best if you check the status of the policy code in about two weeks. Certainly more things will work From Suresh Satapati Wed Jul 13 06:49:58 2005 From: Suresh Satapati (Suresh Satapati) Date: Tue, 12 Jul 2005 22:49:58 -0700 Subject: [Xorp-hackers] Netlink ethertap [Re: Fwd: Interface Management] In-Reply-To: <200506240013.j5O0Dew6055560@possum.icir.org> References: <98521892050623160772e7aa14@mail.gmail.com> <200506240013.j5O0Dew6055560@possum.icir.org> Message-ID: <9852189205071222493caf1754@mail.gmail.com> Can someone please explain in detail, how XORP works on TAP (ethertap) interfaces ? Does the XORP routing s/w listen on the userland TAP interface ? i.e. if some packets arrive on /dev/net/tap0 (kernel interface), those are sent to userspace TAP interface from where XORP s/w grabs the packet (??).. Is my understanding correct ? Since ethertap works with ethernet frames.. i.e. frames are sent upto userland TAP interface as layer 2 frames, do they enter TCP/IP stack (kernel) at all, before XORP grabs them from userland ?? This is the grey area to me.. whether packets arriving on TAP interface enter the TCP/IP stack at all (?).. how do packets sent by XORP into the userland TAP interface (Tx), go out on the wire ? TX packets will make it to kernel TAP (/dev/net/tap0) interface ? but where do they go from there ? do they enter the IP stack again .. for IP forwarding ?? this understanding is critical to the project I am working on. Will appreciate any help on these questions.. Thanks, Suresh.. On 6/23/05, Pavlin Radoslavov wrote: > > By Ether tap driver I meant :- > > http://vtun.sourceforge.net/tun/index.html > > > > -Suresh > > > > ---------- Forwarded message ---------- > > From: Suresh Satapati > > Date: Jun 23, 2005 4:01 PM > > Subject: Re: Interface Management > > To: Pavlin Radoslavov > > > > > > Hello Pavlin, > > > > I had to hold on to this question for a while due to the build > > problems, that we finally > > solved with your help. > > > > I will first try to explain what I am trying to do.. Hope you will be able to > > help me here.. > > > > I want a userland application to be able to create "ethX" like interfaces in > > Linux. And XORP should be able to identify those interfaces, and run > > RIP or any routing protocol.. > > > > How can I acheive this ? What modules do I need to use ? Would "ether" > > tap like driver be useful in my scenario ? > > I see. > Part of the problem is that on startup you cannot configure XORP > with those interfaces if they don't exist in the kernel. > Hence, after your userland application creates the tap interfaces > (or any other interfaces) in the kernel, then XORP needs to be > reconfigured so it can start using the new interfaces. > This applies also for the RIP (or any other protocol) configuration > that would use those new interfaces. > > Eventually, you can reconfigure XORP on the fly by running, say, a > Python script that invokes xorpsh and creates or loads the new > configuration. > > Below is a sample Python script from Atanu that probably you can > reuse (after some editing of course) for your need. > > ---------------------------------------- > #!/usr/bin/env python > > import pexpect > > def configuration(xorpsh, command, debug=0): > xorpsh.sendline(command) > xorpsh.expect('[edit]') > xorpsh.expect('XORP>') > if 1 == debug: > print xorpsh.before > print xorpsh.after > > xorpsh = pexpect.spawn('xorpsh') > xorpsh.expect('Xorp>') > > debug = 1 # Set to 0 if you don't want debugging output > # Commands below > configuration(xorpsh, 'configure', debug) # Go into configure mode > configuration(xorpsh, 'load /usr/local/xorp/config.boot', debug) # load config > xorpsh.sendline("quit") > xorpsh.close(1) > ---------------------------------------- > > Note that myself I am not familiar with Python and I haven't used > the above script. > > Regards, > Pavlin > > > > > Thanks, > > Suresh.. > > > > On 6/8/05, Pavlin Radoslavov wrote: > > > > Now that I got XORP up and running on my platform, here is what I want to > > > > do: > > > > > > Can you be a little bit more specific about what exactly you want to > > > do. In other words, please give me some real-world example what is > > > suppose to happen. > > > > > > > - My platform is linux based > > > > > > Is it standard kernel or modified with your own driver? > > > > > > > - Have XORP register a callback (handler) to my platform driver > > > > code. > > > > > > What kind of callback this is? Is it some callback from the > > > kernel to userland? > > > Also, what do you mean by "platform driver"? > > > Do you mean the netlink/ioctl FEA mechanisms to access the kernel, > > > or do you mean a device driver inside the kernel? > > > > > > I presume you don't mean the C++ callbacks we have in XORP. > > > If this is a kernel-to-userland callback mechanism, is it your own > > > add-on to the Linux kernel, or is it something that exists there > > > (e.g., the netlink mechanism). > > > > > > > - The XORP callback would essentially create (and bring up) interfaces > > > > based on information passed by platform code > > > > > > Something similar is done by the netlink mechanism already. > > > > > > E.g., see IfConfigObserverNetlink::receive_data() that itself calls > > > parse_buffer_nlm(). > > > > > > > - Platform driver code would call the handler appropriately > > > > > > > > Where would I add this code ? Would that be inside IfConfigSetIoctl ? > > > > I have done some C++ in the past, but haven't used extensive features > > > > like XORP does.. So, please bear with me. > > > > > > On Linux there are two mechanisms that can be used to access the > > > kernel: ioctl() and netlink. Inside the FEA in case of Linux the > > > netlink mechanism is the one that is used (if available), and only > > > if it is not available the ioctl() mechanism is used. If you have > > > the option to choose between ioctl() and netlink, I'd recommend > > > netlink, because it also provides a mechanism for kernel "upcalls" > > > to userland whenever something inside the kernel has changed. > > > > > > Regards, > > > Pavlin > > > > > > > From pavlin@icir.org Wed Jul 13 07:39:10 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 12 Jul 2005 23:39:10 -0700 Subject: [Xorp-hackers] Netlink ethertap [Re: Fwd: Interface Management] In-Reply-To: Message from Suresh Satapati of "Tue, 12 Jul 2005 22:49:58 PDT." <9852189205071222493caf1754@mail.gmail.com> Message-ID: <200507130639.j6D6dAtA069766@possum.icir.org> > Can someone please explain in detail, how XORP works on TAP (ethertap) > interfaces ? > > Does the XORP routing s/w listen on the userland TAP interface ? i.e. > if some packets arrive on /dev/net/tap0 (kernel interface), those are > sent to userspace TAP interface from where XORP s/w grabs the packet > (??).. > > Is my understanding correct ? XORP doesn't listen or send anything on the TAP interface. In fact it doesn't do anything special about the TAP interface. Pavlin > > Since ethertap works with ethernet frames.. i.e. frames are sent upto userland > TAP interface as layer 2 frames, do they enter TCP/IP stack (kernel) > at all, before > XORP grabs them from userland ?? > > This is the grey area to me.. whether packets arriving on TAP > interface enter the TCP/IP stack at all (?).. how do packets sent by > XORP into the userland TAP interface (Tx), go out on the wire ? TX > packets will make it to kernel TAP (/dev/net/tap0) interface ? but > where do they go from there ? do they enter the IP stack again .. for > IP forwarding ?? From atanu@ICSI.Berkeley.EDU Wed Jul 13 23:03:42 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 13 Jul 2005 15:03:42 -0700 Subject: [Xorp-hackers] Power outage Message-ID: <51196.1121292222@tigger.icir.org> Hi, The Pacific Gas and Electric Company are going to depriving us of power for a three and a half hours. Unusually we have been notified before the fact, typically they just cut the power. The main web server, cvs archive and email lists will be unavailable from 20:00PST today (13th July) and hopefully they will be powered back up at 8.00PST tomorrow (14th July). Mirrors of the web server (e.g. www2.xorp.org) will obviously be available, but the cvs archive and email lists will not. Sorry for the inconvenience. Atanu.