From ratul@cs.washington.edu Wed Aug 3 02:32:28 2005 From: ratul@cs.washington.edu (Ratul Mahajan) Date: Tue, 02 Aug 2005 18:32:28 -0700 Subject: [Xorp-hackers] BGP community support Message-ID: <42F01EAC.2040106@cs.washington.edu> hi - from the user manual "We also have limited support for: RFC 1997: BGP Communities Attribute." could someone briefly tell me what support is currently available? thanks. From zec@icir.org Wed Aug 3 16:28:28 2005 From: zec@icir.org (Marko Zec) Date: Wed, 3 Aug 2005 17:28:28 +0200 Subject: [Xorp-hackers] BGP community support In-Reply-To: <42F01EAC.2040106@cs.washington.edu> References: <42F01EAC.2040106@cs.washington.edu> Message-ID: <200508031728.28375.zec@icir.org> On Wednesday 03 August 2005 03:32, Ratul Mahajan wrote: > hi - > > from the user manual > "We also have limited support for: > RFC 1997: BGP Communities Attribute." > > could someone briefly tell me what support is currently available? Hi Ratul, the current code from CVS includes a more or less functional policy framework, which among other things allows one to look at the community attributes. Based on a received community tag, one can decide to accept or reject the route, or change some of its attributes, including the communities themselves. As an example, the following config will match all the inbound routes that are tagged with both the communities 65000:1 and 65000:2, on such routes remove the 65000:2 tag, set the localpref value to 1001, and accept the route. protocols { bgp { ... import: "bgp-in" } } policy { policy-statement bgp-in { term a { from { community >= "65000:1,65000:2" } then { community-del: "65000:2" localpref = 1001 accept } } } } Another example - unconditionally set community tags to 65001:101,NO_EXPORT on all received routes: policy { policy-statement bgp-in { term a { then { community = "65001:101,NO_EXPORT" accept } } } } Hope this helps, Marko From ratul@cs.washington.edu Sat Aug 6 04:58:45 2005 From: ratul@cs.washington.edu (Ratul Mahajan) Date: Fri, 05 Aug 2005 20:58:45 -0700 Subject: [Xorp-hackers] is this right? Message-ID: <42F43575.1060807@cs.washington.edu> hi - i am experimenting with a new interdomain routing protocol, as part of which i need to do keep track of - the sums of the MEDs received from each ebgp peer. - the sums of the MEDs sent to each ebgp peer. (its actually a custom attribute but pretty much like MEDs) since i am not intimately familiar with xorp code, it'll be great if someone verified what i am doing is correct. i do the following: 1. add member variables sum_in and sum_out to PeerData which are updated through Rib[In,Out]->PeerHandler->Peer->PeerData 2. update sum_in in RibIn 2a. subtract in add_route() and delete_route() the MED of existing route, if any* 2b. add the MED value of the new route in add_route() 3. update sum_out in RibOut 3a. subtract in delete_route(), using the MED attached to rtmsg, the route passed in the argument* 3b. add in add_route() the current MED * 2a and 3a are based on the following assumptions: - 2a: the routes stored in RibIn are never changed or deleted from what is originally received, no matter what the input filters do. (i realize that this might change in the future) - 3a: the rtmsg in delete_route() contains the correct old MED value, since the filtertable re-applies the filters to old route passed through the fanout table are the following assumptions correct? are there cases when the above procedure will break, e.g., peerings up/down or too many routes in the queue? thanks! From kristian@juniks.net Sat Aug 6 18:28:22 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sat, 6 Aug 2005 19:28:22 +0200 Subject: [Xorp-hackers] Counter application Message-ID: <20050806172822.GA10848@juniks.net> Hi! I've written a small program which does "interface counting". It's meant to be integrated with XORP in the future, first it needs to mature a bit ;) It's split up into two parts, a daemon and client part. The daemon polls the interfaces at a regular interval so to overcome the 32 bit counter problem. GRUC (as the program is called - the GRand Unified Counter) uses 64 bit counters (though not as of yet). The two programs communicate via TCP much like the rtrmgr and xorpsh and this would integrate smoothly with the xorp architecture and running on separate machines. The general idea is for it to, in the future, be a general counter with which you could count just about anything - like hits in an ACL or similar. Perhaps that's not efficient and we'll just keep it as an interface counter. I thought there was a need to have a program like this somewhat integrated with xorp, so that one can easily monitor network traffic from the xorpsh. The look and feel is inspired from Extreme Networks ExtremeWare 'show port statistics' command. The program is in it's very early alpha stage and lacks a _LOT_ of functionality. I write mostly to inform and to receive feedback and ideas of what more could be implemented. The program can be found at http://skalman.juniks.net/xorp/gruc-0.1.1.tar.gz Please comment/complain to me at kristian@juniks.net I would also like to say that it's with delight I read the CVS commit, as they are rather frequent. The policy part is taking place and I have done some testing and it seems quite good. Also the Windows port seems to be progressing, Bruce is doing quite a lot of work there. Good work although I am somewhat pussled over the need of a windows port, does anyone actually need BGP on Windows? Anyway, keep up the good work. Regards, Kristian From kristian@juniks.net Sat Aug 6 20:37:51 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sat, 6 Aug 2005 21:37:51 +0200 Subject: [Xorp-hackers] Counter application In-Reply-To: <42F50FEC.2020802@cs.washington.edu> References: <20050806172822.GA10848@juniks.net> <42F50FEC.2020802@cs.washington.edu> Message-ID: <20050806193751.GB10848@juniks.net> I don't know how I do it, but somehow I always messes up URLs! The correct one is: http://skalman.juniks.net/~ply/xorp/gruc-0.1.1.tar.gz I'm currently working on 64 bit counters - the current lack of it makes the program almost useless IMHO. //Kristian On Sat, Aug 06, 2005 at 12:30:52PM -0700, Ratul Mahajan wrote: > > kristian - > > this is very useful indeed and i'd like to play with it. > > > The program can be found at > > http://skalman.juniks.net/xorp/gruc-0.1.1.tar.gz > > but i get "file not found" error. > > thanks. > > Kristian Larsson wrote: > >Hi! > > > >I've written a small program which does "interface counting". > >It's meant to be integrated with XORP in the future, first it needs to > >mature > >a bit ;) > > > >It's split up into two parts, a daemon and client part. The daemon polls > >the > >interfaces at a regular interval so to overcome the 32 bit counter problem. > >GRUC (as the program is called - the GRand Unified Counter) uses 64 bit > >counters (though not as of yet). > >The two programs communicate via TCP much like the rtrmgr and xorpsh and > >this > >would integrate smoothly with the xorp architecture and running on separate > >machines. > >The general idea is for it to, in the future, be a general counter with > >which > >you could count just about anything - like hits in an ACL or similar. > >Perhaps that's not efficient and we'll just keep it as an interface > >counter. > >I thought there was a need to have a program like this somewhat integrated > >with xorp, so that one can easily monitor network traffic from the xorpsh. > > > >The look and feel is inspired from Extreme Networks ExtremeWare 'show port > >statistics' command. > > > >The program is in it's very early alpha stage and lacks a _LOT_ of > >functionality. I write mostly to inform and to receive feedback and ideas > >of > >what more could be implemented. > > > >The program can be found at > >http://skalman.juniks.net/xorp/gruc-0.1.1.tar.gz > >Please comment/complain to me at kristian@juniks.net > > > > > >I would also like to say that it's with delight I read the CVS commit, as > >they are rather frequent. The policy part is taking place and I have done > >some testing and it seems quite good. > >Also the Windows port seems to be progressing, Bruce is doing quite a lot > >of > >work there. Good work although I am somewhat pussled over the need of a > >windows port, does anyone actually need BGP on Windows? > >Anyway, keep up the good work. > > > >Regards, > >Kristian > > > >_______________________________________________ > >Xorp-hackers mailing list > >Xorp-hackers@icir.org > >http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From atanu@ICSI.Berkeley.EDU Tue Aug 9 18:17:56 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 09 Aug 2005 10:17:56 -0700 Subject: [Xorp-hackers] is this right? In-Reply-To: Message from Ratul Mahajan of "Fri, 05 Aug 2005 20:58:45 PDT." <42F43575.1060807@cs.washington.edu> Message-ID: <33984.1123607876@tigger.icir.org> Hi, I'm not absolutely clear on what you are attempting here. The assumptions with respect to the RIB-IN are correct the unmodified route is held here and the delete_route() should contain the original med. When a peering is taken down all the the routes are withdrawn. If there is a large number of routes in the RIB-IN (we see around 160K routes) when a peering goes down we can't atomically delete the routes in the RIB-IN remove the winning routes from the routing table and inform all of our peers. We therefore dynamically create a deletion table with the old trie after the RIB-IN. The old routes can then be deleted and a new peering can be accepted immediately. Therefore old routes can continue to flow through the system even though a new peering is in effect. The routes contain a generation ID that it may be necessary for you to track. Atanu. >>>>> "Ratul" == Ratul Mahajan writes: Ratul> hi - Ratul> i am experimenting with a new interdomain routing protocol, as part of Ratul> which i need to do keep track of Ratul> - the sums of the MEDs received from each ebgp peer. Ratul> - the sums of the MEDs sent to each ebgp peer. Ratul> (its actually a custom attribute but pretty much like MEDs) Ratul> since i am not intimately familiar with xorp code, it'll be great if Ratul> someone verified what i am doing is correct. Ratul> i do the following: Ratul> 1. add member variables sum_in and sum_out to PeerData which are Ratul> updated through Rib[In,Out]->PeerHandler->Peer->PeerData Ratul> 2. update sum_in in RibIn Ratul> 2a. subtract in add_route() and delete_route() the MED of Ratul> existing route, if any* Ratul> 2b. add the MED value of the new route in add_route() Ratul> 3. update sum_out in RibOut Ratul> 3a. subtract in delete_route(), using the MED attached to rtmsg, Ratul> the route passed in the argument* Ratul> 3b. add in add_route() the current MED Ratul> * 2a and 3a are based on the following assumptions: Ratul> - 2a: the routes stored in RibIn are never changed or deleted from Ratul> what is originally received, no matter what the input filters Ratul> do. (i realize that this might change in the future) Ratul> - 3a: the rtmsg in delete_route() contains the correct old MED Ratul> value, since the filtertable re-applies the filters to old route Ratul> passed through the fanout table Ratul> are the following assumptions correct? Ratul> are there cases when the above procedure will break, e.g., peerings Ratul> up/down or too many routes in the queue? Ratul> thanks! Ratul> _______________________________________________ Ratul> Xorp-hackers mailing list Ratul> Xorp-hackers@icir.org Ratul> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From imipak@yahoo.com Wed Aug 10 07:24:08 2005 From: imipak@yahoo.com (Jonathan Day) Date: Tue, 9 Aug 2005 23:24:08 -0700 (PDT) Subject: [Xorp-hackers] IGMPv3 and related Message-ID: <20050810062408.2269.qmail@web31508.mail.mud.yahoo.com> Hi, I notice that IGMPv3 is on the roadmap and that there were posts last month about someone getting ready to add IGMPv3 to the CVS tree. However, I recognize that until it has been thoroughly beaten up by testers, it is not going to be in any kind of final form and so any answers will be slightly speculative. If I recall correctly, the last time I looked at the IGMPv3 RFC I noted that it supported extensions to the basic protocol, and that there was at least one draft extension for authentication. Will the Xorp IGMPv3 implementation be just the raw IGMPv3 protocol, the raw protocol with hooks to allow for extensions, or will draft extensions be included? On a related note, I see that the IETF has a number of multicast security protocols (RFCs 3547, 3740, 3830, 4046 and 4082). They also seem to have a number of drafts in circulation. Are there any plans to add any of these in (assuming they're not there already)? I didn't notice them on the roadmap, so wasn't sure what the current status was. Out of the multicast arena and into the mobility. The IETF seems to have three areas of development, at the moment - mobile IP (manet), mobile networks (nemo) and mobile IPSec (mobike). In addition, they have IPv4-specific (mip4) and IPv6-specific (mip6 and mipshop) mobility work. How much of this is going to end up being implemented in Xorp? There seems to be an awful lot defined, but using Freshmeat as an extremely crude form of popularity poll, I'm not seeing as much interest as I'd have expected in it. Next up are the router redundancy protocols - VRRP and CARP. CARP seems to be the "truly free" protocol, with some questions as to the usability of VRRP in open software. What (if any) plans on fail-over support are in the air? QoS seems to be a hot area at the moment, too - nothing much on the IETF website, but citeseer indicates that the number of methods tried and tested number in the upper 20s, lower 30s. There WILL be others I've missed, so this is a low-end figure. What sort of QoS support is Xorp likely to have in future? And finally, a bugbear that seems to be widely used by major ISPs but where the Linux implementation seems to be dead - MPLS. As with some of the others, there seems to be a vast amount defined for it - it's not a simple thing. Most seems to be in the MPLS working group's pages, but there's some in the BFD (bi-directional forwarding detection) and CCAMP (Common Control and Measurement Plane) groups. There's even a L1VPN group - no RFCs or drafts yet - for really low-level tunneling for it. There are probably other relevent(ish) papers out in the wild blue yonder not included in those three. How much - if any - is going to make it into Xorp? At this point, having extended the roadmap by a couple of centuries, it might be prudent for me to hide under the computer desk. :) (Either that, or if anyone knows of any research group that would fund the development of any of these, I'd be very interested.) Jonathan ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From kristian@juniks.net Wed Aug 10 09:05:38 2005 From: kristian@juniks.net (Kristian Larsson) Date: Wed, 10 Aug 2005 10:05:38 +0200 Subject: [Xorp-hackers] IGMPv3 and related In-Reply-To: <20050810075345.GA6333@juniks.net> References: <20050810062408.2269.qmail@web31508.mail.mud.yahoo.com> <20050810075345.GA6333@juniks.net> Message-ID: <20050810080538.GA6526@juniks.net> On Tue, Aug 09, 2005 at 11:24:08PM -0700, Jonathan Day wrote: > Hi, > > I notice that IGMPv3 is on the roadmap and that there > were posts last month about someone getting ready to > add IGMPv3 to the CVS tree. However, I recognize that > until it has been thoroughly beaten up by testers, it > is not going to be in any kind of final form and so > any answers will be slightly speculative. > > If I recall correctly, the last time I looked at the > IGMPv3 RFC I noted that it supported extensions to the > basic protocol, and that there was at least one draft > extension for authentication. > > Will the Xorp IGMPv3 implementation be just the raw > IGMPv3 protocol, the raw protocol with hooks to allow > for extensions, or will draft extensions be included? Since I won't be doing the implementation I can't say anything for sure. But IMHO I think that we shouldn't implement to much drafts but wait for them to be more generally accepted before implementing. On the other hand XORP is meant as a development and testing platform and thus it would make sense writing experimental stuff as well. > On a related note, I see that the IETF has a number of > multicast security protocols (RFCs 3547, 3740, 3830, > 4046 and 4082). They also seem to have a number of > drafts in circulation. Are there any plans to add any > of these in (assuming they're not there already)? I > didn't notice them on the roadmap, so wasn't sure what > the current status was. > > Out of the multicast arena and into the mobility. The > IETF seems to have three areas of development, at the > moment - mobile IP (manet), mobile networks (nemo) and > mobile IPSec (mobike). In addition, they have > IPv4-specific (mip4) and IPv6-specific (mip6 and > mipshop) mobility work. > > How much of this is going to end up being implemented > in Xorp? There seems to be an awful lot defined, but > using Freshmeat as an extremely crude form of > popularity poll, I'm not seeing as much interest as > I'd have expected in it. I think XORP should have support for different types of Mobile IP. What, how and when is something I really can't answer. Someone has to write it and mip is not the focus right now. It's better to do a few things well than a lot of things not so well. The focus is more on the basic routing as of now and should stay there for a bit longer ;) > Next up are the router redundancy protocols - VRRP and > CARP. CARP seems to be the "truly free" protocol, with > some questions as to the usability of VRRP in open > software. What (if any) plans on fail-over support are > in the air? CARP handles failover on interface level. XORP is a routing suite. It's in a routers nature to support failover. If one router breakes, OSPF (or some other protocol) will choose a different path - failover! Now if you would build a virtual router out of several machines it would require another level of failover. We would need to copy the routing table between the machines and so on. Of course, the configuration of CARP could be integrated into XORP and this is something I would love to see. It would be great to be able to configure a complete router without ever leaving the xorpshell. But I think interface configuration from within XORP should be done first :) > QoS seems to be a hot area at the moment, too - > nothing much on the IETF website, but citeseer > indicates that the number of methods tried and tested > number in the upper 20s, lower 30s. There WILL be > others I've missed, so this is a low-end figure. What > sort of QoS support is Xorp likely to have in future? This is kinda the same as the above. XORP should not handle QoS as it doesn't forward any traffic but it would be nice if XORP could configure dummynet/ALTQ. > And finally, a bugbear that seems to be widely used by > major ISPs but where the Linux implementation seems to > be dead - MPLS. As with some of the others, there > seems to be a vast amount defined for it - it's not a > simple thing. Most seems to be in the MPLS working > group's pages, but there's some in the BFD > (bi-directional forwarding detection) and CCAMP > (Common Control and Measurement Plane) groups. There's > even a L1VPN group - no RFCs or drafts yet - for > really low-level tunneling for it. There are probably > other relevent(ish) papers out in the wild blue yonder > not included in those three. How much - if any - is > going to make it into Xorp? I'm not into MPLS, but since it's a lot of layer 2 forwarding of packets it's not really XORPs domain. Though I suppose it requires some form of routing protocols and this should perhaps be developed for XORP. > At this point, having extended the roadmap by a couple > of centuries, it might be prudent for me to hide under > the computer desk. :) (Either that, or if anyone knows > of any research group that would fund the development > of any of these, I'd be very interested.) This is really a good idea. horde.org has this funding were companies/organisations can pay to have something added, it ranges from small $50 to thousand dollar payments. Perhaps XORP should have something similar? Just my $.02 :) /Kristian Larsson From mahimkar@sunfire2.ece.utexas.edu Thu Aug 11 06:31:31 2005 From: mahimkar@sunfire2.ece.utexas.edu (Ajay Anil Mahimkar) Date: Thu, 11 Aug 2005 00:31:31 -0500 (CDT) Subject: [Xorp-hackers] Query on Policy-Based Routing Message-ID: Hi, Does XORP support policy-based routing, (similar to route-maps on Cisco routers) ? Thanks, - Ajay ------------------------------------------- Ajay Mahimkar Graduate Student Dept. of Electrical & Computer Engineering The University of Texas at Austin Austin, TX 78713 USA Email: mahimkar@ece.utexas.edu ------------------------------------------- From a.bittau@cs.ucl.ac.uk Thu Aug 11 06:55:18 2005 From: a.bittau@cs.ucl.ac.uk (Andrea Bittau) Date: Thu, 11 Aug 2005 06:55:18 +0100 Subject: [Xorp-hackers] Query on Policy-Based Routing In-Reply-To: References: Message-ID: <20050811055518.GA1200@tribal.sorbonet.org> On Thu, Aug 11, 2005 at 12:31:31AM -0500, Ajay Anil Mahimkar wrote: > Does XORP support policy-based routing, (similar to route-maps on Cisco > routers) ? The tree in CVS has some support, similar to juniper with from, to, then syntax. Look at the bgp and policy template [.tp] file for what you can currently do. "Full" and documented support will be available in the next release. This should happen sometime this month hopefully, or in the near future. From mahimkar@sunfire2.ece.utexas.edu Fri Aug 12 03:18:10 2005 From: mahimkar@sunfire2.ece.utexas.edu (Ajay Anil Mahimkar) Date: Thu, 11 Aug 2005 21:18:10 -0500 (CDT) Subject: [Xorp-hackers] Query on Policy-Based Routing In-Reply-To: <20050811055518.GA1200@tribal.sorbonet.org> Message-ID: I looked at bgp.tp and policy.tp. Could someone please let me know whether (network4:ipv4net) in the "to" clause implies the destination network prefix. Also, in policy.tp, network4:ipv4net is present in both "from" and "to". Could someone elaborate on this? Basically, I want to know the functionality of "network4" in from and to. Also, is this the correct way to set LOCALPREF for say a destination network prefix, policy { policy-statement next-hop-selection { term 1 { to { network4: 128.43.0.0; (example destination prefix) } then { localpref: 300 } } } } One more question, if in the nexthop4 in the "then", if i specify an address that is not directly connected, would IGP be used to find the next hop interface for this nexthop4 address ? Also, currently do you support traffic classification based on interfaces. For example, if i want to select route based on the interface on which i received packet, like on interface eth1, i prefer a certain next-hop while on eth2, a different next-hop is preferred. Is this currently supported ? THanks, - Ajay ------------------------------------------- Ajay Mahimkar Graduate Student Dept. of Electrical & Computer Engineering The University of Texas at Austin Austin, TX 78713 USA Email: mahimkar@ece.utexas.edu ------------------------------------------- On Thu, 11 Aug 2005, Andrea Bittau wrote: > On Thu, Aug 11, 2005 at 12:31:31AM -0500, Ajay Anil Mahimkar wrote: > > Does XORP support policy-based routing, (similar to route-maps on Cisco > > routers) ? > > The tree in CVS has some support, similar to juniper with from, to, then syntax. > Look at the bgp and policy template [.tp] file for what you can currently do. > "Full" and documented support will be available in the next release. This > should happen sometime this month hopefully, or in the near future. > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From a.bittau@cs.ucl.ac.uk Fri Aug 12 06:16:06 2005 From: a.bittau@cs.ucl.ac.uk (Andrea Bittau) Date: Fri, 12 Aug 2005 06:16:06 +0100 Subject: [Xorp-hackers] Query on Policy-Based Routing In-Reply-To: References: <20050811055518.GA1200@tribal.sorbonet.org> Message-ID: <20050812051605.GA817@tribal.sorbonet.org> On Thu, Aug 11, 2005 at 09:18:10PM -0500, Ajay Anil Mahimkar wrote: > I looked at bgp.tp and policy.tp. Could someone please let me know whether > (network4:ipv4net) in the "to" clause implies the destination network > prefix. Also, in policy.tp, network4:ipv4net is present in both "from" and > "to". Could someone elaborate on this? "to" means: match these attributes just before the route is leaving the protocol / about to be advertised. For example: from { protocol: "static_routes" } to { neighbor: 10.0.1.1 } action { localpref: 100 } Using this as a BGP export policy, it means that all static routes will be redistributed only to the BGP peer 10.0.1.1, and will have a localpref set to 100. network4 will match the prefix of the route, both in from and to. i.e. from { network4: 10.0.0.0/24 } and to { network4: 10.0.0.0/24 } are equivalent. The only difference is that the matching occurs in a different stage [from in the input side, to in the output side]. I can't think of an example where using from vs to for network4 is useful. If you want to know more about what a "variable" [such as network4] really means, read the _varrw.cc files. For example bgp_varrw.cc and look how network4 is read / written to. > Also, is this the correct way to set LOCALPREF for say a destination > network prefix, > > policy { > policy-statement next-hop-selection { > term 1 { > to { > network4: 128.43.0.0; (example destination > prefix) > } > then { > localpref: 300 > } > } > } > } Yes this should work [you need a /XX in the prefix]. This will set the localpref to 300 on all routes passing through BGP. Depending on whether it is import or export filter, the actual change in localpref will occur pre/post decision. > One more question, if in the nexthop4 in the "then", if i specify an > address that is not directly connected, would IGP be used to find the > next hop interface for this nexthop4 address ? If used as an import filter, then the nexthop resolver should figure out what's going on. If used as an export filter, it will blindly be advertised with that nexthop. > Also, currently do you support traffic classification based on interfaces. > For example, if i want to select route based on the interface on which i > received packet, like on interface eth1, i prefer a certain next-hop while > on eth2, a different next-hop is preferred. Is this currently supported ? No but it's a good one to add... especially for RIP i guess. [I don't think BGP cares about interfaces... only about peers] I'll write a crude policy documentation today in the user-manual, so you might want to look in CVS tonight GMT time---hopefully it will be there. From mahimkar@sunfire2.ece.utexas.edu Fri Aug 12 07:35:20 2005 From: mahimkar@sunfire2.ece.utexas.edu (Ajay Anil Mahimkar) Date: Fri, 12 Aug 2005 01:35:20 -0500 (CDT) Subject: [Xorp-hackers] Query on Policy-Based Routing In-Reply-To: <20050812051605.GA817@tribal.sorbonet.org> Message-ID: > Also, currently do you support traffic classification based on interfaces. > For example, if i want to select route based on the interface on which i > received packet, like on interface eth1, i prefer a certain next-hop while > on eth2, a different next-hop is preferred. Is this currently supported ? No but it's a good one to add... especially for RIP i guess. [I don't think BGP cares about interfaces... only about peers] ------ With respect to this, could we know whether you plan to add this on your agenda. What functionality is interesting, is to have policy-based routing. For example, using ACL to match subset of traffic characteristics (for example, dest IP addresses, interface addresses) and then specifying different routing policies. Thanks, - Ajay ------------------------------------------- Ajay Mahimkar Graduate Student Dept. of Electrical & Computer Engineering The University of Texas at Austin Austin, TX 78713 USA Email: mahimkar@ece.utexas.edu ------------------------------------------- From kristian@juniks.net Fri Aug 12 08:17:12 2005 From: kristian@juniks.net (Kristian Larsson) Date: Fri, 12 Aug 2005 09:17:12 +0200 Subject: [Xorp-hackers] Query on Policy-Based Routing In-Reply-To: <20050812063421.GB6197@juniks.net> References: <20050811055518.GA1200@tribal.sorbonet.org> <20050812051605.GA817@tribal.sorbonet.org> <20050812063421.GB6197@juniks.net> Message-ID: <20050812071712.GC6197@juniks.net> ( sorry Andrea for dupes ) On Fri, Aug 12, 2005 at 06:16:06AM +0100, Andrea Bittau wrote: > On Thu, Aug 11, 2005 at 09:18:10PM -0500, Ajay Anil Mahimkar wrote: > > I looked at bgp.tp and policy.tp. Could someone please let me know whether > > (network4:ipv4net) in the "to" clause implies the destination network > > prefix. Also, in policy.tp, network4:ipv4net is present in both "from" and > > "to". Could someone elaborate on this? > > "to" means: match these attributes just before the route is leaving the protocol > / about to be advertised. For example: > > from { > protocol: "static_routes" > } > to { > neighbor: 10.0.1.1 > } > action { > localpref: 100 > } > > Using this as a BGP export policy, it means that all static routes will be > redistributed only to the BGP peer 10.0.1.1, and will have a localpref set to > 100. > > > network4 will match the prefix of the route, both in from and to. i.e. > > from { > network4: 10.0.0.0/24 > } > > and > > to { > network4: 10.0.0.0/24 > } > > are equivalent. The only difference is that the matching occurs in a different > stage [from in the input side, to in the output side]. > I can't think of an example where using from vs to for network4 is useful. > > If you want to know more about what a "variable" [such as network4] really > means, read the _varrw.cc files. For example bgp_varrw.cc and look how network4 > is read / written to. > > > Also, is this the correct way to set LOCALPREF for say a destination > > network prefix, > > > > policy { > > policy-statement next-hop-selection { > > term 1 { > > to { > > network4: 128.43.0.0; (example destination > > prefix) > > } > > then { > > localpref: 300 > > } > > } > > } > > } > > Yes this should work [you need a /XX in the prefix]. This will set the > localpref to 300 on all routes passing through BGP. Depending on whether it is > import or export filter, the actual change in localpref will occur pre/post > decision. > > > One more question, if in the nexthop4 in the "then", if i specify an > > address that is not directly connected, would IGP be used to find the > > next hop interface for this nexthop4 address ? > > If used as an import filter, then the nexthop resolver should figure out what's > going on. If used as an export filter, it will blindly be advertised with that > nexthop. > > > Also, currently do you support traffic classification based on interfaces. > > For example, if i want to select route based on the interface on which i > > received packet, like on interface eth1, i prefer a certain next-hop while > > on eth2, a different next-hop is preferred. Is this currently supported ? > > No but it's a good one to add... especially for RIP i guess. > [I don't think BGP cares about interfaces... only about peers] > > I'll write a crude policy documentation today in the user-manual, so you might > want to look in CVS tonight GMT time---hopefully it will be there. I'm not sure, but I think he means actual traffic coming from one interface should be forwarded down one path and traffic from another to some other path, ie not the actual route. Something along the lines (on a cisco): > > interface FastEthernet 0/1 > ip address 192.168.1.1 255.255.255.0 > ip policy route-map example1 > interface FastEthernet 0/2 > ip address 192.168.2.1 255.255.255.0 > ... > ip route 0.0.0.0 0.0.0.0 172.20.1.1 > route-map example1 permit 10 > set next-hop 10.0.0.1 > > > traffic from FE0/1 goes to 10.0.0.1 while > everything else goes to 172.20.1.1 > > Correct me if I'm wrong but XORP will never be > able to do this since it doesn't forward traffic. > It must be done by the kernel (unless the traffic > is lifted out into userspace first) and can be > done in for example Linux using iproute2. > > If this isn't what Ajay needed I kindly ask for > this mail to be ignored ;) > > //Kristian From m.handley@cs.ucl.ac.uk Fri Aug 12 08:48:03 2005 From: m.handley@cs.ucl.ac.uk (Mark Handley) Date: Fri, 12 Aug 2005 08:48:03 +0100 Subject: [Xorp-hackers] Query on Policy-Based Routing In-Reply-To: <20050812071712.GC6197@juniks.net> References: <20050811055518.GA1200@tribal.sorbonet.org> <20050812051605.GA817@tribal.sorbonet.org> <20050812063421.GB6197@juniks.net> <20050812071712.GC6197@juniks.net> Message-ID: <84a612dd05081200483b43056a@mail.gmail.com> > I'm not sure, but I think he means actual traffic > coming from one interface should be forwarded down > one path and traffic from another to some other > path, ie not the actual route. > > Something along the lines (on a cisco): > > > > interface FastEthernet 0/1 > > ip address 192.168.1.1 255.255.255.0 > > ip policy route-map example1 > > interface FastEthernet 0/2 > > ip address 192.168.2.1 255.255.255.0 > > ... > > ip route 0.0.0.0 0.0.0.0 172.20.1.1 > > route-map example1 permit 10 > > set next-hop 10.0.0.1 > > > > > > traffic from FE0/1 goes to 10.0.0.1 while > > everything else goes to 172.20.1.1 > > > > Correct me if I'm wrong but XORP will never be > > able to do this since it doesn't forward traffic. > > It must be done by the kernel (unless the traffic > > is lifted out into userspace first) and can be > > done in for example Linux using iproute2. I think you're right that you can't do this sort of thing in the normal kernel forwarding table on Linux or BSD. I haven't looked at iproute2, but I'll take your work for it that it can do this. You could also do this sort of thing with a Click-based forwarding path. In neither case does XORP have any way to configure this sort of kernel-forwarding rule at the moment. The policy routing framework Andrea has been working on is just that: policy *routing*. In other words it gives you a lot of control over how the routing protocols behave, but the general model of routing protocols still applies. In particular, the routing protocols contribute routes to a RIB (actually 4 RIBs, one for each combinaton of {IPv4,IPv6} {unicast,multicast}). For each RIB, there's only one final nexthop for a packet with a particular destination IP address. The sort of rule you describe, I would call policy *forwarding*, to distinguish it from policy *routing*. At this stage we only have the latter and not the former. The two are clearly complementary. >From XORP's point of view, policy routing is critical to do well. Policy forwarding seems mostly to deal with corner-cases - what I don't know is how common such corner cases are in the real world - I'd love some feedback on this. >From a practical point of view, cross-platform support for policy-routing is pretty simple. Cross-platform support for policy-forwarding seems really hard. Are there a common set of a abstractions for policy-forwarding? I haven't been tracking what the IETF ForCES WG has been doing in this space, so maybe there's something there. Cheers, Mark From kristian@juniks.net Fri Aug 12 09:38:53 2005 From: kristian@juniks.net (Kristian Larsson) Date: Fri, 12 Aug 2005 10:38:53 +0200 Subject: [Xorp-hackers] Query on Policy-Based Routing In-Reply-To: <84a612dd05081200483b43056a@mail.gmail.com> References: <20050811055518.GA1200@tribal.sorbonet.org> <20050812051605.GA817@tribal.sorbonet.org> <20050812063421.GB6197@juniks.net> <20050812071712.GC6197@juniks.net> <84a612dd05081200483b43056a@mail.gmail.com> Message-ID: <20050812083853.GD6197@juniks.net> On Fri, Aug 12, 2005 at 08:48:03AM +0100, Mark Handley wrote: > > I'm not sure, but I think he means actual traffic > > coming from one interface should be forwarded down > > one path and traffic from another to some other > > path, ie not the actual route. > > > > Something along the lines (on a cisco): > > > > > > interface FastEthernet 0/1 > > > ip address 192.168.1.1 255.255.255.0 > > > ip policy route-map example1 > > > interface FastEthernet 0/2 > > > ip address 192.168.2.1 255.255.255.0 > > > ... > > > ip route 0.0.0.0 0.0.0.0 172.20.1.1 > > > route-map example1 permit 10 > > > set next-hop 10.0.0.1 > > > > > > > > > traffic from FE0/1 goes to 10.0.0.1 while > > > everything else goes to 172.20.1.1 > > > > > > Correct me if I'm wrong but XORP will never be > > > able to do this since it doesn't forward traffic. > > > It must be done by the kernel (unless the traffic > > > is lifted out into userspace first) and can be > > > done in for example Linux using iproute2. > > I think you're right that you can't do this sort of thing in the > normal kernel forwarding table on Linux or BSD. I haven't looked at > iproute2, but I'll take your work for it that it can do this. You > could also do this sort of thing with a Click-based forwarding path. > In neither case does XORP have any way to configure this sort of > kernel-forwarding rule at the moment. On FreeBSD most of this can be done with IPFilter. OpenBSD has it mostly implemented through pf. pf can also do some really neat integration with OpenBGPD. OpenBGPD can send a list with all prefixes and their originating AS to pf which then can filter based on AS. If XORP could do this it would kick ass :) > > The policy routing framework Andrea has been working on is just that: > policy *routing*. In other words it gives you a lot of control over > how the routing protocols behave, but the general model of routing > protocols still applies. In particular, the routing protocols > contribute routes to a RIB (actually 4 RIBs, one for each combinaton > of {IPv4,IPv6} {unicast,multicast}). For each RIB, there's only one > final nexthop for a packet with a particular destination IP address. > > The sort of rule you describe, I would call policy *forwarding*, to > distinguish it from policy *routing*. At this stage we only have the > latter and not the former. The two are clearly complementary. > > From XORP's point of view, policy routing is critical to do well. > Policy forwarding seems mostly to deal with corner-cases - what I > don't know is how common such corner cases are in the real world - I'd > love some feedback on this. The policy "routing" ( I agree with you that forwarding is a better word for it, but AFAIK it , de facto, still goes under the term policy routing) implemented on cisco routers is very powerful, you could do quite a lot with 'em. Still I think the example I gave is one of the more common ones - to source route! I'm using it get route a /27 to my home. I have a tunnel between my "home" router (cisco 2811) and a router at work (7206). On the 7206 I just set a static route for my net down through the tunnel. Since I have a default route on my Cisco at home not pointing through the tunnel traffic that comes through the tunnel will be sent out on my usual connection when answered. With source routing I route all packets from the /27 I have forwarded to me, back through the tunnel. There are other examples, one could use a route-map to unset the DF bit before going through a link which has a smaller MTU than the normal 1500 (even though this is better corrected for by adjusting the MSS). Mostly I'd say policy forwarding is used for what we in Sweden would call a fulhack (c) which roughly translates to "ugly hack". A network which is properly built probably does not need to use policy forwarding. Perhaps there are exception but I can't think of an example where policy forwarding is the better solution, it's almost always used as a substitute for something more expensive or harder to setup. > From a practical point of view, cross-platform support for > policy-routing is pretty simple. Cross-platform support for > policy-forwarding seems really hard. Are there a common set of a > abstractions for policy-forwarding? I haven't been tracking what the > IETF ForCES WG has been doing in this space, so maybe there's > something there. AFAIK there are no standards for policy forwarding or how it's implemented. It's much like firewalls, everone knows what can be done (filtering on ACK/SYN, ports, dst, src and so on) but everyone has a different way to do it and configure it. //Kristian Larsson From a.bittau@cs.ucl.ac.uk Fri Aug 12 10:28:02 2005 From: a.bittau@cs.ucl.ac.uk (Andrea Bittau) Date: Fri, 12 Aug 2005 10:28:02 +0100 Subject: [Xorp-hackers] Query on Policy-Based Routing In-Reply-To: <20050812083853.GD6197@juniks.net> References: <20050811055518.GA1200@tribal.sorbonet.org> <20050812051605.GA817@tribal.sorbonet.org> <20050812063421.GB6197@juniks.net> <20050812071712.GC6197@juniks.net> <84a612dd05081200483b43056a@mail.gmail.com> <20050812083853.GD6197@juniks.net> Message-ID: <20050812092802.GA7533@tribal.sorbonet.org> On Fri, Aug 12, 2005 at 10:38:53AM +0200, Kristian Larsson wrote: > On FreeBSD most of this can be done with IPFilter. > OpenBSD has it mostly implemented through pf. pf fbsd 5 has pf. > prefixes and their originating AS to pf which then > can filter based on AS. If XORP could do this it > would kick ass :) What's the story with divert and forward? Can they help? On linux i used to use firewall marks, and then iproute2 to do weird routing based on firewall marks. E.g. mark packets on specific TCP port, then use a different routing table from them. On fbsd i can do it with ipfw by diverting packets to userland, then playing with natd for example to change IPs, or just write something to mangle packets, then you can route them to a different nexthop / interface with the forward command in ipfw. I'm not sure if this is what you are asking... From bms@spc.org Fri Aug 12 12:37:07 2005 From: bms@spc.org (Bruce M Simpson) Date: Fri, 12 Aug 2005 12:37:07 +0100 Subject: [Xorp-hackers] Query on Policy-Based Routing In-Reply-To: <20050812083853.GD6197@juniks.net> References: <20050811055518.GA1200@tribal.sorbonet.org> <20050812051605.GA817@tribal.sorbonet.org> <20050812063421.GB6197@juniks.net> <20050812071712.GC6197@juniks.net> <84a612dd05081200483b43056a@mail.gmail.com> <20050812083853.GD6197@juniks.net> Message-ID: <20050812113707.GA767@empiric.icir.org> On Fri, Aug 12, 2005 at 10:38:53AM +0200, Kristian Larsson wrote: > OpenBSD has it mostly implemented through pf. pf > can also do some really neat integration with > OpenBGPD. OpenBGPD can send a list with all > prefixes and their originating AS to pf which then > can filter based on AS. If XORP could do this it > would kick ass :) Well. Sort of. I guess if you created a policy which tagged routes from a given AS in the RIB and mapped them to a discard interface it may do what you want here. I added the discard interface support many months ago in XORP to deal with OSPF's aggregation mechanisms. It uses the RTF_BLACKHOLE flag on both FreeBSD and Linux. There is some IPFilter support in XORP too, but the filtering policy interface is still ongoing work. Regards, BMS From mahimkar@sunfire2.ece.utexas.edu Sat Aug 13 09:33:24 2005 From: mahimkar@sunfire2.ece.utexas.edu (Ajay Anil Mahimkar) Date: Sat, 13 Aug 2005 03:33:24 -0500 (CDT) Subject: [Xorp-hackers] Query on Policy-Based Routing In-Reply-To: <20050812113707.GA767@empiric.icir.org> Message-ID: Hi: I agree that policy "forwarding" lies on the data path, and need not be incorporated with XORP (since XORP is on the control path - routing decisions). How policy forwarding would work, is it would look for ACLs defined on interfaces, and any match for packets, the filter policy would be executed, otherwise, packets (that do not match any ACL) pick the next-hop interface from the forwarding table, which is established using XORP. Thanks for the discussions, - Ajay ------------------------------------------- Ajay Mahimkar Graduate Student Dept. of Electrical & Computer Engineering The University of Texas at Austin Austin, TX 78713 USA Email: mahimkar@ece.utexas.edu ------------------------------------------- From mahimkar@sunfire2.ece.utexas.edu Sun Aug 14 11:14:27 2005 From: mahimkar@sunfire2.ece.utexas.edu (Ajay Anil Mahimkar) Date: Sun, 14 Aug 2005 05:14:27 -0500 (CDT) Subject: [Xorp-hackers] RAW/TCP/UDP Socket Implementation Message-ID: Hi, I am currently going through the implementation of raw/tcp/udp sockets for control path communication. My understanding is that sockets use the actual interfaces (these interfaces are used for forwarding plane too) for sending control information (BGP, RIP, ..). On a router, when we run both XORP & forwarding (say Click), then there must be a way to differentiate regular data packets and control packets. Could some one tell where is this done (in Click or XORP) ? i believe it to be Click. If its done on forwarding plane, then it means that the forwarder should actually distinguish data & control packets. Now, suppose, if we decide to use another interface (not one, where data transfer occurs) for control packets, then it might incur some additional management. I think this is the model for having forwarding plane reside on different machine than XORP (as described in XORP FEA document). I think this was not supported as of April'05. Is this being incorporated now, or would it be in the near future ? Thanks, - Ajay ------------------------------------------- Ajay Mahimkar Graduate Student Dept. of Electrical & Computer Engineering The University of Texas at Austin Austin, TX 78713 USA Email: mahimkar@ece.utexas.edu ------------------------------------------- From mahimkar@sunfire2.ece.utexas.edu Sun Aug 14 11:17:35 2005 From: mahimkar@sunfire2.ece.utexas.edu (Ajay Anil Mahimkar) Date: Sun, 14 Aug 2005 05:17:35 -0500 (CDT) Subject: [Xorp-hackers] RAW/TCP/UDP Socket Implementation Message-ID: Hi, I am currently going through the implementation of raw/tcp/udp sockets for control path communication. My understanding is that sockets use the actual interfaces (these interfaces are used for forwarding plane too) for sending control information (BGP, RIP, ..). On a router, when we run both XORP & forwarding (say Click), then there must be a way to differentiate regular data packets and control packets. Could some one tell where is this done (in Click or XORP) ? i believe it to be Click. If its done on forwarding plane, then it means that the forwarder should actually distinguish data & control packets. Now, suppose, if we decide to use another interface (not one, where data transfer occurs) for control packets, then it might incur some additional management. I think this is the model for having forwarding plane reside on different machine than XORP (as described in XORP FEA document). I think this was not supported as of April'05. Is this being incorporated now, or would it be in the near future ? Thanks, - Ajay ------------------------------------------- Ajay Mahimkar Graduate Student Dept. of Electrical & Computer Engineering The University of Texas at Austin Austin, TX 78713 USA Email: mahimkar@ece.utexas.edu ------------------------------------------- From pavlin@icir.org Tue Aug 16 02:25:09 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 15 Aug 2005 18:25:09 -0700 Subject: [Xorp-hackers] RAW/TCP/UDP Socket Implementation In-Reply-To: Message from Ajay Anil Mahimkar of "Sun, 14 Aug 2005 05:17:35 CDT." Message-ID: <200508160125.j7G1P9HU044566@possum.icir.org> > I am currently going through the implementation of raw/tcp/udp sockets for > control path communication. My understanding is that sockets use the > actual interfaces (these interfaces are used for forwarding plane too) for > sending control information (BGP, RIP, ..). On a router, when we run both I am a bit confused by what you mean that "these interfaces are used for forwarding plane too". The forwarding plane is inside the kernel (or in user-level Click), and XORP itself is not on the forwarding path. Currently, the FEA RAW/TCP/UDP socket story is: * The FEA UDP socket interface is used by RIP/RIPng for sending and receiving control packets. * BGP itself uses its own TCP sockets, but in the future it will use the FEA TCP socket interface. * OSPF will use the RAW FEA socket interface for sending and receiving control packets. > XORP & forwarding (say Click), then there must be a way to differentiate > regular data packets and control packets. Could some one tell where is > this done (in Click or XORP) ? i believe it to be Click. If its done on > forwarding plane, then it means that the forwarder should actually > distinguish data & control packets. Are you trying to use Click+XORP, and inside your Click configuration you want to exclude from processing the control packets from/to the XORP control plane? I guess it is possible to create Click configuration that filters the control packets. The Click mailing list would be a better place to get an answer how to do that. > Now, suppose, if we decide to use another interface (not one, where data > transfer occurs) for control packets, then it might incur some additional > management. I think this is the model for having forwarding plane reside Here again I am confused about the mixture of data and control packets. > on different machine than XORP (as described in XORP FEA document). I > think this was not supported as of April'05. Is this being incorporated > now, or would it be in the near future ? The model for running remove FEA is as follows. Lets say that machine A is running the FEA, and machine B is running the rtrmgr and all other modules (RIB, RIP, etc). The XORP finder (running on B) knows that the FEA is running on A, so all XRLs destined to the FEA will be sent to A's IP address. E.g., if the RIB sends "add_route" XRL to the FEA, the XRL will be dispatch properly to A, and the forwarding plane on A will be modified appropriately. If, say, RIP sends a control packet (using the FEA UDP socket interface), the "send" XRL with the control payload will be sent to A. Similarly, RIP UDP (control) messages will be dispatched from A to B's RIP process. The forwarding of the data itself happens only in the forwarding plane on A, and B is not involved in that. Pavlin From pavlin@icir.org Tue Aug 16 03:01:51 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 15 Aug 2005 19:01:51 -0700 Subject: [Xorp-hackers] IGMPv3 and related In-Reply-To: Message from Kristian Larsson of "Wed, 10 Aug 2005 10:05:38 +0200." <20050810080538.GA6526@juniks.net> Message-ID: <200508160201.j7G21p05044905@possum.icir.org> > > I notice that IGMPv3 is on the roadmap and that there > > were posts last month about someone getting ready to > > add IGMPv3 to the CVS tree. However, I recognize that > > until it has been thoroughly beaten up by testers, it > > is not going to be in any kind of final form and so > > any answers will be slightly speculative. > > > > If I recall correctly, the last time I looked at the > > IGMPv3 RFC I noted that it supported extensions to the > > basic protocol, and that there was at least one draft > > extension for authentication. > > > > Will the Xorp IGMPv3 implementation be just the raw > > IGMPv3 protocol, the raw protocol with hooks to allow > > for extensions, or will draft extensions be included? > Since I won't be doing the implementation I can't say > anything for sure. But IMHO I think that we shouldn't > implement to much drafts but wait for them to be more > generally accepted before implementing. > On the other hand XORP is meant as a development and > testing platform and thus it would make sense writing > experimental stuff as well. In general, the approach we are taking is that first we implement the basic protocol, and after that we implement the extra stuff (as time allows us). There is also the trade-off between implementing new stuff (i.e.., new protocol) and enhancing an existing protocol implementation. But in general I agree with Kristian that we should implement drafts only if they are generally accepted. > > On a related note, I see that the IETF has a number of > > multicast security protocols (RFCs 3547, 3740, 3830, > > 4046 and 4082). They also seem to have a number of > > drafts in circulation. Are there any plans to add any > > of these in (assuming they're not there already)? I > > didn't notice them on the roadmap, so wasn't sure what > > the current status was. Eventually, we want to implement the multicast security protocols, but before doing that we want to have the multicast routing related protocols and modules (IGMPv3/MLDv2, Bidir-PIM, multicast interoperability module as in RFC-2715, etc). Furthermore, there are various non-multicast tasks that are probably higher priority than the multicast security protocols and that are not on the roadmap. Hence, at this time adding the multicast security protocols to the roadmap will be pointless because there is very high probability their implementation will be postponed a number of times by higher-priority tasks. > > Out of the multicast arena and into the mobility. The > > IETF seems to have three areas of development, at the > > moment - mobile IP (manet), mobile networks (nemo) and > > mobile IPSec (mobike). In addition, they have > > IPv4-specific (mip4) and IPv6-specific (mip6 and > > mipshop) mobility work. > > > > How much of this is going to end up being implemented > > in Xorp? There seems to be an awful lot defined, but > > using Freshmeat as an extremely crude form of > > popularity poll, I'm not seeing as much interest as > > I'd have expected in it. > I think XORP should have support for different types of > Mobile IP. What, how and when is something I really can't > answer. Someone has to write it and mip is not the focus > right now. > It's better to do a few things well than a lot of things > not so well. The focus is more on the basic routing as of > now and should stay there for a bit longer ;) Agree. Mobile IP is probably higher priority than multicast security protocols, but for similar reasons as those I described above it is not on our roadmap (yet). > > Next up are the router redundancy protocols - VRRP and > > CARP. CARP seems to be the "truly free" protocol, with > > some questions as to the usability of VRRP in open > > software. What (if any) plans on fail-over support are > > in the air? > CARP handles failover on interface level. > XORP is a routing suite. It's in a routers nature to support > failover. If one router breakes, OSPF (or some other protocol) > will choose a different path - failover! > > Now if you would build a virtual router out of several machines > it would require another level of failover. We would need to > copy the routing table between the machines and so on. > > Of course, the configuration of CARP could be integrated into > XORP and this is something I would love to see. It would be > great to be able to configure a complete router without ever > leaving the xorpshell. But I think interface configuration > from within XORP should be done first :) Agree. > > QoS seems to be a hot area at the moment, too - > > nothing much on the IETF website, but citeseer > > indicates that the number of methods tried and tested > > number in the upper 20s, lower 30s. There WILL be > > others I've missed, so this is a low-end figure. What > > sort of QoS support is Xorp likely to have in future? > This is kinda the same as the above. XORP should not handle > QoS as it doesn't forward any traffic but it would be nice if > XORP could configure dummynet/ALTQ. Agree. Again, it is question of time and task prioritization to have it done. > > And finally, a bugbear that seems to be widely used by > > major ISPs but where the Linux implementation seems to > > be dead - MPLS. As with some of the others, there > > seems to be a vast amount defined for it - it's not a > > simple thing. Most seems to be in the MPLS working > > group's pages, but there's some in the BFD > > (bi-directional forwarding detection) and CCAMP > > (Common Control and Measurement Plane) groups. There's > > even a L1VPN group - no RFCs or drafts yet - for > > really low-level tunneling for it. There are probably > > other relevent(ish) papers out in the wild blue yonder > > not included in those three. How much - if any - is > > going to make it into Xorp? > I'm not into MPLS, but since it's a lot of layer 2 > forwarding of packets it's not really XORPs domain. Though > I suppose it requires some form of routing protocols and > this should perhaps be developed for XORP. Agree. Pavlin From leclanch@enst.fr Tue Aug 16 13:40:54 2005 From: leclanch@enst.fr (Guillaume Leclanche) Date: Tue, 16 Aug 2005 14:40:54 +0200 Subject: [Xorp-hackers] IGMPv3 and related In-Reply-To: <20050810062408.2269.qmail@web31508.mail.mud.yahoo.com> References: <20050810062408.2269.qmail@web31508.mail.mud.yahoo.com> Message-ID: <4301DED6.3090803@enst.fr> Jonathan Day a écrit : > Hi, > > I notice that IGMPv3 is on the roadmap and that there > were posts last month about someone getting ready to > add IGMPv3 to the CVS tree. However, I recognize that > until it has been thoroughly beaten up by testers, it > is not going to be in any kind of final form and so > any answers will be slightly speculative. Hello, since I'm the one who said I was coding a patch in order for XORP to support igmpv3, I can precise I'm implementing strictly the RFC 3376, nothing more (and hopefully nothing less ;). Whether I have finished or not, I'll release the patch (likely untested) in about 10 days (which is my deadline since I start working abroad on the 29th). I'll do my best to describe clearly what will be done and to be done. I hope it will at least help you all going on with the implementation ! Anyway, I really "enjoy" working (well enjoy and working do not really fit together :) on XORP code since it's very well documented and clear. I'll remember it if I ever need a router with its characteristics in my soon-to-begin network engineer life. Guillaume From kristian@juniks.net Wed Aug 17 17:53:43 2005 From: kristian@juniks.net (Kristian Larsson) Date: Wed, 17 Aug 2005 18:53:43 +0200 Subject: [Xorp-hackers] 1.2 Message-ID: <20050817165343.GA22182@juniks.net> Reading the roadmap, version 1.2 is scheduled for August but it's been awfully quiet about it, no? >From what I understand all the functionality has been added, we just need a stable version to release. So why not checkout release candidate 1 out of the CVS and hear peoples input? If 1.2 would mean stable and reliable bgp policy routing I know one fort certain who would put XORP in production (me! :) ) and I bet there are other out there. Regards, Kristian From bms@spc.org Thu Aug 18 17:14:16 2005 From: bms@spc.org (Bruce M Simpson) Date: Thu, 18 Aug 2005 17:14:16 +0100 Subject: [Xorp-hackers] XORP/Win32 merged to mainline. Message-ID: <20050818161416.GF810@empiric.icir.org> The XORP CVS tree should now build on Windows systems, and is likely to be far more portable to non-UNIX/embedded environments. Please note that the configure checks are a bit more extensive than before. In situations where we use a UNIX specific idiom, this is protected with lots of defines found in config.h in the build root so as not to break the build on systems which don't support them (i.e. Windows). Some documentation will probably have to be updated to reflect the new state of affairs. There is a class XorpFd which encapsulates file descriptors. A number of its members are only used on Windows, where the I/O system is not as seamlessly unified as it is in the UNIX environment, and as such it's necessary to tell different objects apart (regular files, sockets, native pipes, consoles et cetera). Also note that the current state of Windows support is unstable. In order to achieve a stable configuration (as we demonstrated in Redmond), it will be necessary to hack the dispatch code to use the Windows version of SelectorList, with the main caveat that command line pipes won't work (operational mode commands are likely to fail, though configure mode should work). The reason for this is that a number of hacks are needed to deal with native Windows IPC and I/O mechanisms. For those who are interested the code has been localized as much as possible; the routines involved are found in libxorp/win_io.c and libxorp/win_dispatcher.cc. This is the culmination of many months of work, and we're extremely grateful to Microsoft for all their support, both technical and financial, over the duration of this project. Once again, thank you for flying XORP. Kind regards, BMS From oho@acm.org Fri Aug 19 03:54:42 2005 From: oho@acm.org (Orion Hodson) Date: Thu, 18 Aug 2005 19:54:42 -0700 Subject: [Xorp-hackers] Re: [Xorp-dev] XORP/Win32 merged to mainline. In-Reply-To: <20050818161416.GF810@empiric.icir.org> References: <20050818161416.GF810@empiric.icir.org> Message-ID: Absolutely, completely, and utterly awesome. Great job Bruce! - Orion On Aug 18, 2005, at 9:14 AM, Bruce M Simpson wrote: > The XORP CVS tree should now build on Windows systems, and is likely > to be far more portable to non-UNIX/embedded environments. > > ... > > Kind regards, > BMS From atanu@ICSI.Berkeley.EDU Tue Aug 23 00:42:36 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 22 Aug 2005 16:42:36 -0700 Subject: [Xorp-hackers] Power outage Message-ID: <43046.1124754156@tigger.icir.org> Hi, The Pacific Gas and Electric Company are going to depriving us of power for a four hour period. The main web server, cvs archive and email lists will be unavailable from 20:00PDT today (22th August) and hopefully they will be powered back up at 9.00PDT tomorrow (23th August). 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. From jtk@titania.net Wed Aug 24 20:32:13 2005 From: jtk@titania.net (Joseph T. Klein) Date: Wed, 24 Aug 2005 14:32:13 -0500 Subject: [Xorp-hackers] ipv6 only bgp Message-ID: <430CCB3D.8060908@titania.net> does xorp support ipv6 only bgp? if so, does anyone have a sample bgp config snippet? if not, what needs to be done? -- Joseph T. Klein Home: +1 414 431 4231 Mobile: +1 414 628 3380 From atanu@ICSI.Berkeley.EDU Wed Aug 24 22:11:00 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 24 Aug 2005 14:11:00 -0700 Subject: [Xorp-hackers] ipv6 only bgp In-Reply-To: Message from "Joseph T. Klein" of "Wed, 24 Aug 2005 14:32:13 CDT." <430CCB3D.8060908@titania.net> Message-ID: <76183.1124917860@tigger.icir.org> >>>>> "Joseph" == Joseph T Klein writes: Joseph> does xorp support ipv6 only bgp? if so, does anyone have a Joseph> sample bgp config snippet? if not, what needs to be done? Joseph> -- Joseph T. Klein Joseph> Home: +1 414 431 4231 Mobile: +1 414 628 3380 Joseph> _______________________________________________ Xorp-hackers Joseph> mailing list Xorp-hackers@icir.org Joseph> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers Below is the config that we are using to connect to the IPv6 world. I have obscured the actual addresses, ASes and networks, everything between <> needs to be replaced with your own values. The TCP connection is using IPv6 (IPv4 works as well) and only IPv6 reachability information is exchanged. There is currently a limitation in our template specification that forces an IPv4 nethop to be specified even though its not necessary and isn't used. Atanu. ---------------------------------------- interfaces { interface em1 { description: "Interface facing campus" vif em1 { address { prefix-length: 64 } } } } protocols { bgp { bgp-id: local-as: peer { /* Campus */ local-ip: as: holdtime: 90 /* Providing an IPv4 nexthop is mandatory at the moment */ next-hop: next-hop6: ipv4-unicast: false ipv4-multicast: false ipv6-unicast: true ipv6-multicast: false } network6 { next-hop: } } } ---------------------------------------- From John.Weaver@motorola.com Thu Aug 25 17:08:06 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Thu, 25 Aug 2005 11:08:06 -0500 Subject: [Xorp-hackers] Interfacing for runtime config Message-ID: <0DFC73466514D41186B700508B9510411BD99B27@tx14exm04.ftw.mot.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5A98F.2DA9DBF2 Content-Type: text/plain I am needing to find out how would be the best way to config XORP at init. Our system does not have predefined interfaces until some our applications come up and do the IPCP over the backhaul and read from a database. We then set up our interfaces and then bring up XORP for PIM and IGMP functionality. So for us to have a boot.config is not possible. Is there a way to write my our process that I can allow the other apps to talk to and tell it what the interface info is so I can config the VIFs? Thanks, John ------_=_NextPart_001_01C5A98F.2DA9DBF2 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KDQoNCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTUxNSIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElW PjxTUEFOIGNsYXNzPTkxNzU2MDExNi0yNTA4MjAwNT48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5J IGFtIG5lZWRpbmcgdG8gZmluZCANCm91dCBob3cgd291bGQgYmUgdGhlIGJlc3Qgd2F5IHRvIGNv bmZpZyBYT1JQIGF0IGluaXQuJm5ic3A7IE91ciBzeXN0ZW0gZG9lcyBub3QgDQpoYXZlIHByZWRl ZmluZWQgaW50ZXJmYWNlcyB1bnRpbCBzb21lIG91ciBhcHBsaWNhdGlvbnMgY29tZSB1cCBhbmQg ZG8gdGhlIElQQ1AgDQpvdmVyIHRoZSBiYWNraGF1bCBhbmQgcmVhZCBmcm9tIGEgZGF0YWJhc2Uu Jm5ic3A7IFdlIHRoZW4gc2V0IHVwIG91ciBpbnRlcmZhY2VzIA0KYW5kIHRoZW4gYnJpbmcgdXAg WE9SUCBmb3IgUElNIGFuZCBJR01QIGZ1bmN0aW9uYWxpdHkuJm5ic3A7IFNvIGZvciB1cyB0byBo YXZlIGEgDQpib290LmNvbmZpZyBpcyBub3QgcG9zc2libGUuJm5ic3A7IElzIHRoZXJlIGEgd2F5 IHRvIHdyaXRlIG15IG91ciBwcm9jZXNzIHRoYXQgSSANCmNhbiBhbGxvdyB0aGUgb3RoZXIgYXBw cyB0byB0YWxrIHRvIGFuZCB0ZWxsIGl0IHdoYXQgdGhlIGludGVyZmFjZSBpbmZvIGlzIHNvIEkg DQpjYW4gY29uZmlnIHRoZSBWSUZzPzwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNs YXNzPTkxNzU2MDExNi0yNTA4MjAwNT48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPjwvRk9OVD48 L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTkxNzU2MDExNi0yNTA4MjAwNT48 Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPlRoYW5rcyw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJ Vj48U1BBTiBjbGFzcz05MTc1NjAxMTYtMjUwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9 Mj5Kb2huPC9GT05UPjwvU1BBTj48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C5A98F.2DA9DBF2-- From pavlin@icir.org Thu Aug 25 17:40:38 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 25 Aug 2005 09:40:38 -0700 Subject: [Xorp-hackers] Interfacing for runtime config In-Reply-To: Message from Weaver John-JWEAVER1 of "Thu, 25 Aug 2005 11:08:06 CDT." <0DFC73466514D41186B700508B9510411BD99B27@tx14exm04.ftw.mot.com> Message-ID: <200508251640.j7PGec1x074055@possum.icir.org> > This message is in MIME format. Since your mail reader does not understand > this format, some or all of this message may not be legible. > > ------_=_NextPart_001_01C5A98F.2DA9DBF2 > Content-Type: text/plain > > I am needing to find out how would be the best way to config XORP at init. > Our system does not have predefined interfaces until some our applications > come up and do the IPCP over the backhaul and read from a database. We then > set up our interfaces and then bring up XORP for PIM and IGMP functionality. > So for us to have a boot.config is not possible. Is there a way to write my > our process that I can allow the other apps to talk to and tell it what the > interface info is so I can config the VIFs? Below is one possible solution: 1. Start XORP with an empty configuration file. 2. After your applications have started up and all interface information is available, then use an automated script to auto-generate the XORP configuration based on the available information. Write that configuration to a XORP config file (config.boot). 3. Execute a script like the following to reconfigure XORP: #!/bin/sh /path/to/xorpsh < of "Thu, 25 Aug 2005 11:08:06 CDT." <0DFC73466514D41186B700508B9510411BD99B27@tx14exm04.ftw.mot.com> Message-ID: <44744.1124988081@tigger.icir.org> Once the interface information is known you could generate a config.boot file and then start XORP. Another solution would be to invoke the xorpsh from a program to configure the interfaces. The xorpsh will accept commands on its standard input. A combination of both solutions generate a new config.boot whenever interfaces appear/disappear. Then instruct XORP to load the new configuration file. ---------------------------------------- #!/bin/sh xorpsh <>>>> "Weaver" == Weaver John writes: Weaver> I am needing to find out how would be the best way to config Weaver> XORP at init.  Our system does not have predefined Weaver> interfaces until some our applications come up and do the Weaver> IPCP over the backhaul and read from a database.  We then Weaver> set up our interfaces and then bring up XORP for PIM and Weaver> IGMP functionality.  So for us to have a boot.config is not Weaver> possible.  Is there a way to write my our process that I can Weaver> allow the other apps to talk to and tell it what the Weaver> interface info is so I can config the VIFs? Weaver>   Weaver> Thanks, Weaver> John From John.Weaver@motorola.com Thu Aug 25 17:58:19 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Thu, 25 Aug 2005 11:58:19 -0500 Subject: [Xorp-hackers] Interfacing for runtime config Message-ID: <0DFC73466514D41186B700508B9510411BD99CC5@tx14exm04.ftw.mot.com> So I guess there is no library that I can just make calls to pass just address and interface info? I was not looking forward to piecing something together and scripting it. -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin@icir.org] Sent: Thursday, August 25, 2005 11:41 AM To: Weaver John-JWEAVER1 Cc: xorp-hackers@icir.org Subject: Re: [Xorp-hackers] Interfacing for runtime config > This message is in MIME format. Since your mail reader does not > understand this format, some or all of this message may not be legible. > > ------_=_NextPart_001_01C5A98F.2DA9DBF2 > Content-Type: text/plain > > I am needing to find out how would be the best way to config XORP at init. > Our system does not have predefined interfaces until some our > applications come up and do the IPCP over the backhaul and read from a > database. We then set up our interfaces and then bring up XORP for PIM and IGMP functionality. > So for us to have a boot.config is not possible. Is there a way to > write my our process that I can allow the other apps to talk to and > tell it what the interface info is so I can config the VIFs? Below is one possible solution: 1. Start XORP with an empty configuration file. 2. After your applications have started up and all interface information is available, then use an automated script to auto-generate the XORP configuration based on the available information. Write that configuration to a XORP config file (config.boot). 3. Execute a script like the following to reconfigure XORP: #!/bin/sh /path/to/xorpsh < Is Python required for anything that is standard in XORP? -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin@icir.org] Sent: Thursday, August 25, 2005 11:41 AM To: Weaver John-JWEAVER1 Cc: xorp-hackers@icir.org Subject: Re: [Xorp-hackers] Interfacing for runtime config > This message is in MIME format. Since your mail reader does not > understand this format, some or all of this message may not be legible. > > ------_=_NextPart_001_01C5A98F.2DA9DBF2 > Content-Type: text/plain > > I am needing to find out how would be the best way to config XORP at init. > Our system does not have predefined interfaces until some our > applications come up and do the IPCP over the backhaul and read from a > database. We then set up our interfaces and then bring up XORP for PIM and IGMP functionality. > So for us to have a boot.config is not possible. Is there a way to > write my our process that I can allow the other apps to talk to and > tell it what the interface info is so I can config the VIFs? Below is one possible solution: 1. Start XORP with an empty configuration file. 2. After your applications have started up and all interface information is available, then use an automated script to auto-generate the XORP configuration based on the available information. Write that configuration to a XORP config file (config.boot). 3. Execute a script like the following to reconfigure XORP: #!/bin/sh /path/to/xorpsh < of "Thu, 25 Aug 2005 11:58:19 CDT." <0DFC73466514D41186B700508B9510411BD99CC5@tx14exm04.ftw.mot.com> Message-ID: <200508251756.j7PHuvbG074701@possum.icir.org> > So I guess there is no library that I can just make calls to pass just > address and interface info? I was not looking forward to piecing something > together and scripting it. You can use the XRL interface/library (e.g., see xrl/interfaces/fea_ifmgr.xif for configuring the network interfaces in the FEA). You can use other XRL interface to configure IGMP, PIM, etc. However, by talking directly to the processes and by bypassing xorpsh/rtrmgr, none of the changes will be visible in the XORP configuration (inside xorpsh). Furthermore, you should not use xorpsh anymore to reconfigure XORP, otherwise the result will be unpredictable. I would advice you against using the XRL library to reconfigure XORP, unless you really need it and you know what you are doing. Pavlin > > -----Original Message----- > From: Pavlin Radoslavov [mailto:pavlin@icir.org] > Sent: Thursday, August 25, 2005 11:41 AM > To: Weaver John-JWEAVER1 > Cc: xorp-hackers@icir.org > Subject: Re: [Xorp-hackers] Interfacing for runtime config > > > This message is in MIME format. Since your mail reader does not > > understand this format, some or all of this message may not be legible. > > > > ------_=_NextPart_001_01C5A98F.2DA9DBF2 > > Content-Type: text/plain > > > > I am needing to find out how would be the best way to config XORP at init. > > Our system does not have predefined interfaces until some our > > applications come up and do the IPCP over the backhaul and read from a > > database. We then set up our interfaces and then bring up XORP for PIM > and IGMP functionality. > > So for us to have a boot.config is not possible. Is there a way to > > write my our process that I can allow the other apps to talk to and > > tell it what the interface info is so I can config the VIFs? > > Below is one possible solution: > > 1. Start XORP with an empty configuration file. > > 2. After your applications have started up and all interface information is > available, then use an automated script to auto-generate the XORP > configuration based on the available information. Write that configuration > to a XORP config file (config.boot). > > 3. Execute a script like the following to reconfigure XORP: > > #!/bin/sh > > /path/to/xorpsh < configure > load /path/to/config.boot > EOF > > You could use a similar approach (running xorpsh in non-interactive > mode) to incrementally modify the XORP configuration: you just record the > particular xorpsh commands that need to be executed and then add those > commands to the above script. Though, in that case you may want to use, say, > Python so you can check for errors, etc. > > Of course, you could write a process that the applications talk to, and then > the process uses step 3 above to reconfigure XORP. > > Pavlin > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From John.Weaver@motorola.com Thu Aug 25 19:01:03 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Thu, 25 Aug 2005 13:01:03 -0500 Subject: [Xorp-hackers] Interfacing for runtime config Message-ID: <0DFC73466514D41186B700508B9510411BD99E3E@tx14exm04.ftw.mot.com> Would it be possible to put the configuration in a common place so that a user-define process and the xorpsh could access the same info? I would hate to lose the use of the xorpsh since it is an invaluable resource for debugging. -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin@icir.org] Sent: Thursday, August 25, 2005 12:57 PM To: Weaver John-JWEAVER1 Cc: Pavlin Radoslavov; xorp-hackers@icir.org Subject: Re: [Xorp-hackers] Interfacing for runtime config > So I guess there is no library that I can just make calls to pass just > address and interface info? I was not looking forward to piecing > something together and scripting it. You can use the XRL interface/library (e.g., see xrl/interfaces/fea_ifmgr.xif for configuring the network interfaces in the FEA). You can use other XRL interface to configure IGMP, PIM, etc. However, by talking directly to the processes and by bypassing xorpsh/rtrmgr, none of the changes will be visible in the XORP configuration (inside xorpsh). Furthermore, you should not use xorpsh anymore to reconfigure XORP, otherwise the result will be unpredictable. I would advice you against using the XRL library to reconfigure XORP, unless you really need it and you know what you are doing. Pavlin > > -----Original Message----- > From: Pavlin Radoslavov [mailto:pavlin@icir.org] > Sent: Thursday, August 25, 2005 11:41 AM > To: Weaver John-JWEAVER1 > Cc: xorp-hackers@icir.org > Subject: Re: [Xorp-hackers] Interfacing for runtime config > > > This message is in MIME format. Since your mail reader does not > > understand this format, some or all of this message may not be legible. > > > > ------_=_NextPart_001_01C5A98F.2DA9DBF2 > > Content-Type: text/plain > > > > I am needing to find out how would be the best way to config XORP at init. > > Our system does not have predefined interfaces until some our > > applications come up and do the IPCP over the backhaul and read from > > a database. We then set up our interfaces and then bring up XORP > > for PIM > and IGMP functionality. > > So for us to have a boot.config is not possible. Is there a way to > > write my our process that I can allow the other apps to talk to and > > tell it what the interface info is so I can config the VIFs? > > Below is one possible solution: > > 1. Start XORP with an empty configuration file. > > 2. After your applications have started up and all interface > information is available, then use an automated script to > auto-generate the XORP configuration based on the available > information. Write that configuration to a XORP config file (config.boot). > > 3. Execute a script like the following to reconfigure XORP: > > #!/bin/sh > > /path/to/xorpsh < configure > load /path/to/config.boot > EOF > > You could use a similar approach (running xorpsh in non-interactive > mode) to incrementally modify the XORP configuration: you just record > the particular xorpsh commands that need to be executed and then add > those commands to the above script. Though, in that case you may want > to use, say, Python so you can check for errors, etc. > > Of course, you could write a process that the applications talk to, > and then the process uses step 3 above to reconfigure XORP. > > Pavlin > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin@icir.org Thu Aug 25 19:03:45 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 25 Aug 2005 11:03:45 -0700 Subject: [Xorp-hackers] Interfacing for runtime config In-Reply-To: Message from Weaver John-JWEAVER1 of "Thu, 25 Aug 2005 12:24:50 CDT." <0DFC73466514D41186B700508B9510411BD99D66@tx14exm04.ftw.mot.com> Message-ID: <200508251803.j7PI3jnQ074769@possum.icir.org> > Is Python required for anything that is standard in XORP? Currently it is needed only for development purpose (though in the future we may use it for some of the automated test scripts). E.g., if you change any of the XRL interfaces (xrl/interfaces/*.xif and xrl/targets/*.tgt) or if you add your own XRL interface, then python is needed to auto-generate the C++ code. It is also used to auto-generate the callback C++ code (libxorp/callback_*.hh), but for all practical purposes you never want to touch that. Pavlin From pavlin@icir.org Thu Aug 25 19:07:50 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 25 Aug 2005 11:07:50 -0700 Subject: [Xorp-hackers] Interfacing for runtime config In-Reply-To: Message from Weaver John-JWEAVER1 of "Thu, 25 Aug 2005 13:01:03 CDT." <0DFC73466514D41186B700508B9510411BD99E3E@tx14exm04.ftw.mot.com> Message-ID: <200508251807.j7PI7odf074834@possum.icir.org> > Would it be possible to put the configuration in a common place so that a > user-define process and the xorpsh could access the same info? I would hate > to lose the use of the xorpsh since it is an invaluable resource for > debugging. The configuration's common place is the rtrmgr, and the xorpsh is the front-end for accessing and modifying it. Hence, if you really are against using a shell script that invokes xorpsh to modify that info, then you can write your own process that talks directly to the rtrmgr using the xorpsh/rtrmgr XRL interface. See rtrmgr.xif and rtrmgr_client.xif XRL interfaces about what the XRL exchange looks like. Pavlin From atanu@ICSI.Berkeley.EDU Thu Aug 25 19:10:53 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 25 Aug 2005 11:10:53 -0700 Subject: [Xorp-hackers] Interfacing for runtime config In-Reply-To: Message from Pavlin Radoslavov of "Thu, 25 Aug 2005 11:03:45 PDT." <200508251803.j7PI3jnQ074769@possum.icir.org> Message-ID: <65990.1124993453@tigger.icir.org> >> Is Python required for anything that is standard in XORP? Pavlin> Currently it is needed only for development purpose (though Pavlin> in the future we may use it for some of the automated test Pavlin> scripts). One of the BGP automated test scripts (gmake check) already uses python. There is no runtime dependency on python. Atanu. From m.handley@cs.ucl.ac.uk Thu Aug 25 19:26:17 2005 From: m.handley@cs.ucl.ac.uk (Mark Handley) Date: Thu, 25 Aug 2005 19:26:17 +0100 Subject: [Xorp-hackers] Interfacing for runtime config In-Reply-To: <0DFC73466514D41186B700508B9510411BD99CC5@tx14exm04.ftw.mot.com> References: <0DFC73466514D41186B700508B9510411BD99CC5@tx14exm04.ftw.mot.com> Message-ID: <84a612dd05082511262fdb6f69@mail.gmail.com> On 8/25/05, Weaver John-JWEAVER1 wrote: > So I guess there is no library that I can just make calls to pass just > address and interface info? I was not looking forward to piecing something > together and scripting it. We could build a library version of xorpsh that you would link against, and which would present a programatic interface for changing the config. So far we haven't done this because you can do this from a scripting language with the existing xorpsh, and because it's not clear what the user-based security model would be. Now, such an API would still know nothing about interfaces, vifs, etc. Bear in mind that in the XORP architecture, the rtrmgr and xorpsh have *no* inbuilt knowledge about the components they are managing and configuring. This knowledge comes from the template files that are read at runtime. An alternative would be for the FEA to provide a programatic library for configuring interfaces, but by itself this gives you nothing you can't already access using XRLs. The downside is that the rtrmgr would not learn about the interfaces, so you couldn't use xorpsh to monitor them, etc. Finally, and what I think you want, it would be possible to build a helper library than can configure interfaces (via XRLs to the FEA) and then tell the rtrmgr about them (using the same XRL interface that xorpsh uses). This might be worth doing. Normally we've avoided building such helpers because you can always code them yourself using XRLs. However in this case the requirement may be common enough, and actually coding it yourself may be hard enough that it may well be worth doing. - Mark From John.Weaver@motorola.com Thu Aug 25 21:57:17 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Thu, 25 Aug 2005 15:57:17 -0500 Subject: [Xorp-hackers] RE: Xorp-hackers digest, Vol 1 #183 - 1 msg Message-ID: <0DFC73466514D41186B700508B9510411BDE4BF1@tx14exm04.ftw.mot.com> The lib version of the xorpsh is prolly exactly what I need. I would think for the XORP project to be successful in an embedded market this would be necessary. Most of the switch/router projects I have done in the past have always required many boot time decisions on how to configure all the interfaces and protocols. None of our systems have ever had direct configuration by a user and almost always requires run-time changes via applications that trigger off of upstream database changes. I hope I can come to a way to use XORP in this way because I hate to think of the other vendor I will have to use if not. Plus it puts me way behind schedule. ;) I guess I can always resort to hacking out some scripts to try and configure things but it sounds real risky and not very easy, especially since I don't know shell scripting. -----Original Message----- From: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] On Behalf Of xorp-hackers-request@icir.org Sent: Thursday, August 25, 2005 2:03 PM To: xorp-hackers@icir.org Subject: Xorp-hackers digest, Vol 1 #183 - 1 msg Send Xorp-hackers mailing list submissions to xorp-hackers@icir.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers or, via email, send a message with subject or body 'help' to xorp-hackers-request@icir.org You can reach the person managing the list at xorp-hackers-admin@icir.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Xorp-hackers digest..." Today's Topics: 1. Re: Interfacing for runtime config (Mark Handley) --__--__-- Message: 1 Date: Thu, 25 Aug 2005 19:26:17 +0100 From: Mark Handley Reply-To: m.handley@cs.ucl.ac.uk To: Weaver John-JWEAVER1 Subject: Re: [Xorp-hackers] Interfacing for runtime config Cc: Pavlin Radoslavov , xorp-hackers@icir.org On 8/25/05, Weaver John-JWEAVER1 wrote: > So I guess there is no library that I can just make calls to pass just > address and interface info? I was not looking forward to piecing > something together and scripting it. We could build a library version of xorpsh that you would link against, and which would present a programatic interface for changing the config. So far we haven't done this because you can do this from a scripting language with the existing xorpsh, and because it's not clear what the user-based security model would be. Now, such an API would still know nothing about interfaces, vifs, etc. Bear in mind that in the XORP architecture, the rtrmgr and xorpsh have *no* inbuilt knowledge about the components they are managing and configuring. This knowledge comes from the template files that are read at runtime. An alternative would be for the FEA to provide a programatic library for configuring interfaces, but by itself this gives you nothing you can't already access using XRLs. The downside is that the rtrmgr would not learn about the interfaces, so you couldn't use xorpsh to monitor them, etc. Finally, and what I think you want, it would be possible to build a helper library than can configure interfaces (via XRLs to the FEA) and then tell the rtrmgr about them (using the same XRL interface that xorpsh uses). This might be worth doing. Normally we've avoided building such helpers because you can always code them yourself using XRLs. However in this case the requirement may be common enough, and actually coding it yourself may be hard enough that it may well be worth doing. - Mark --__--__-- _______________________________________________ Xorp-hackers mailing list Xorp-hackers@icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers End of Xorp-hackers Digest From John.Weaver@motorola.com Thu Aug 25 23:59:28 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Thu, 25 Aug 2005 17:59:28 -0500 Subject: [Xorp-hackers] Interfacing for runtime config Message-ID: <0DFC73466514D41186B700508B9510411BDE4EAA@tx14exm04.ftw.mot.com> What about SNMP? Can everything be configured through SNMP? Does this also get reflected in the xorpsh? -----Original Message----- From: Mark Handley [mailto:mark.j.handley@gmail.com] Sent: Thursday, August 25, 2005 1:26 PM To: Weaver John-JWEAVER1 Cc: Pavlin Radoslavov; xorp-hackers@icir.org Subject: Re: [Xorp-hackers] Interfacing for runtime config On 8/25/05, Weaver John-JWEAVER1 wrote: > So I guess there is no library that I can just make calls to pass just > address and interface info? I was not looking forward to piecing > something together and scripting it. We could build a library version of xorpsh that you would link against, and which would present a programatic interface for changing the config. So far we haven't done this because you can do this from a scripting language with the existing xorpsh, and because it's not clear what the user-based security model would be. Now, such an API would still know nothing about interfaces, vifs, etc. Bear in mind that in the XORP architecture, the rtrmgr and xorpsh have *no* inbuilt knowledge about the components they are managing and configuring. This knowledge comes from the template files that are read at runtime. An alternative would be for the FEA to provide a programatic library for configuring interfaces, but by itself this gives you nothing you can't already access using XRLs. The downside is that the rtrmgr would not learn about the interfaces, so you couldn't use xorpsh to monitor them, etc. Finally, and what I think you want, it would be possible to build a helper library than can configure interfaces (via XRLs to the FEA) and then tell the rtrmgr about them (using the same XRL interface that xorpsh uses). This might be worth doing. Normally we've avoided building such helpers because you can always code them yourself using XRLs. However in this case the requirement may be common enough, and actually coding it yourself may be hard enough that it may well be worth doing. - Mark From pavlin@icir.org Fri Aug 26 00:39:24 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 25 Aug 2005 16:39:24 -0700 Subject: [Xorp-hackers] Interfacing for runtime config In-Reply-To: Message from Weaver John-JWEAVER1 of "Thu, 25 Aug 2005 17:59:28 CDT." <0DFC73466514D41186B700508B9510411BDE4EAA@tx14exm04.ftw.mot.com> Message-ID: <200508252339.j7PNdOOX083445@possum.icir.org> > What about SNMP? Can everything be configured through SNMP? Does this also > get reflected in the xorpsh? No, you cannot use SNMP to configure XORP. Currently, the SNMP support is rather limited (I think that only the BGP MIB is implemented). Furthermore, even if you use SNMP to reconfigure something, it is still not reflected in the xorpsh. Pavlin From kristian@juniks.net Thu Aug 25 16:20:50 2005 From: kristian@juniks.net (Kristian Larsson) Date: Thu, 25 Aug 2005 17:20:50 +0200 Subject: [Xorp-hackers] release. Message-ID: <20050825152036.GA26594@juniks.net> I'm not sure my last mail ever reached the mailing list btw is it xorp-hackers@icir.org or @xorp.org? v1.2 is scheduled for release now in August, perhaps a release candidate would be appropriate? I have a few thoughts on the rtrmgr as well; I've noticed that it shuts down due to a lot of small errors. Sometimes the faults are larger but still I beleive it should be handled with an error message and not a exit. For example, OSPF is broken in CVS and so when trying to start an ospf process the rtrmgr dies with an error. Why not inform the xorpsh of this in a graceful manner without the exit. Another example is where the local hostname does not resolve which results in the rtrmgr not starting. What if someone misconfigured their router and then rebooted it from remote. It would never start. In my opinion these things are just as important as having a correct PIM implementation. People (at least the router nerds I know) will not use something that crashes. Resilience is the sh*t! :) Opinions? Regards, Kristian From pavlin@icir.org Fri Aug 26 01:26:39 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 25 Aug 2005 17:26:39 -0700 Subject: [Xorp-hackers] release. In-Reply-To: Message from Kristian Larsson of "Thu, 25 Aug 2005 17:20:50 +0200." <20050825152036.GA26594@juniks.net> Message-ID: <200508260026.j7Q0QdHV083945@possum.icir.org> > I'm not sure my last mail ever reached the mailing > list btw is it xorp-hackers@icir.org or @xorp.org? Yes, it reached the list, but we have been thinking for very long time what the reply should be :) No, seriously, we have been busy with fixing various things and the side effect of this is that occasionally an email is (unintentionally) overlooked. > v1.2 is scheduled for release now in August, > perhaps a release candidate would be appropriate? Yes, there will be a release candidate, but we are not ready yet so it may be delayed a bit. > I have a few thoughts on the rtrmgr as well; > I've noticed that it shuts down due to a lot of > small errors. Sometimes the faults are larger but > still I beleive it should be handled with an > error message and not a exit. > > For example, OSPF is broken in CVS and so when > trying to start an ospf process the rtrmgr dies > with an error. Why not inform the xorpsh of this > in a graceful manner without the exit. > Another example is where the local hostname does > not resolve which results in the rtrmgr not starting. > What if someone misconfigured their router and > then rebooted it from remote. It would never > start. Agree. Please add them as (separate) bugzilla entries. Thanks, Pavlin > In my opinion these things are just as important > as having a correct PIM implementation. People (at > least the router nerds I know) will not use > something that crashes. Resilience is the sh*t! :) > Opinions? > > Regards, > Kristian > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin@icir.org Fri Aug 26 01:35:52 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 25 Aug 2005 17:35:52 -0700 Subject: [Xorp-hackers] RE: Xorp-hackers digest, Vol 1 #183 - 1 msg In-Reply-To: Message from Weaver John-JWEAVER1 of "Thu, 25 Aug 2005 15:57:17 CDT." <0DFC73466514D41186B700508B9510411BDE4BF1@tx14exm04.ftw.mot.com> Message-ID: <200508260035.j7Q0Zqqv084018@possum.icir.org> > The lib version of the xorpsh is prolly exactly what I need. I would think > for the XORP project to be successful in an embedded market this would be > necessary. Most of the switch/router projects I have done in the past have > always required many boot time decisions on how to configure all the > interfaces and protocols. None of our systems have ever had direct > configuration by a user and almost always requires run-time changes via > applications that trigger off of upstream database changes. I hope I can > come to a way to use XORP in this way because I hate to think of the other > vendor I will have to use if not. Plus it puts me way behind schedule. ;) > I guess I can always resort to hacking out some scripts to try and configure > things but it sounds real risky and not very easy, especially since I don't > know shell scripting. Yes, I think this is a very good idea. Would you volunteer to extract the core xorpsh functionality in such library? :) Otherwise, I am afraid that currently we don't have the spare cycles to do this ourselves. We can add it to our TODO list, but it may take a while before it is ready. So your best bet would be to invest in the shell scripting solution, and eventually in the future you can switch to using the library instead. In any case, can you send us pointers to existing solutions (e.g., high-level description, API, etc). Thanks, Pavlin From kristian@juniks.net Fri Aug 26 19:16:10 2005 From: kristian@juniks.net (Kristian Larsson) Date: Fri, 26 Aug 2005 20:16:10 +0200 Subject: [Xorp-hackers] release. In-Reply-To: <200508260026.j7Q0QdHV083945@possum.icir.org> References: <20050825152036.GA26594@juniks.net> <200508260026.j7Q0QdHV083945@possum.icir.org> Message-ID: <20050826181554.GA6225@juniks.net> On Thu, Aug 25, 2005 at 05:26:39PM -0700, Pavlin Radoslavov wrote: > > I'm not sure my last mail ever reached the mailing > > list btw is it xorp-hackers@icir.org or @xorp.org? > > Yes, it reached the list, but we have been thinking for very long > time what the reply should be :) > > No, seriously, we have been busy with fixing various things and the > side effect of this is that occasionally an email is > (unintentionally) overlooked. I never received my own mail through the list and I've had a few problems with my mailserver so I kinda assumed the worst ;) > > > v1.2 is scheduled for release now in August, > > perhaps a release candidate would be appropriate? > > Yes, there will be a release candidate, but we are not ready yet so > it may be delayed a bit. Might one ask what you are planning for RC1? > > I have a few thoughts on the rtrmgr as well; > > I've noticed that it shuts down due to a lot of > > small errors. Sometimes the faults are larger but > > still I beleive it should be handled with an > > error message and not a exit. > > > > For example, OSPF is broken in CVS and so when > > trying to start an ospf process the rtrmgr dies > > with an error. Why not inform the xorpsh of this > > in a graceful manner without the exit. > > Another example is where the local hostname does > > not resolve which results in the rtrmgr not starting. > > What if someone misconfigured their router and > > then rebooted it from remote. It would never > > start. > > Agree. Please add them as (separate) bugzilla entries. Will do. Regards, Kristian > Thanks, > Pavlin > > > In my opinion these things are just as important > > as having a correct PIM implementation. People (at > > least the router nerds I know) will not use > > something that crashes. Resilience is the sh*t! :) > > Opinions? > > > > Regards, > > Kristian > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers@icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From pavlin@icir.org Fri Aug 26 19:29:14 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 26 Aug 2005 11:29:14 -0700 Subject: [Xorp-hackers] release. In-Reply-To: Message from Kristian Larsson of "Fri, 26 Aug 2005 20:16:10 +0200." <20050826181554.GA6225@juniks.net> Message-ID: <200508261829.j7QITEp9007543@possum.icir.org> > I never received my own mail through the list and > I've had a few problems with my mailserver so I > kinda assumed the worst ;) Just FYI, one-two days after your email/question to the list we saw several ML unsubscription requests from you so we thought you probably don't care about the answer :) Anyway, you may want to check your membership for xorp-hackers, xorp-users, xorp-announce, xorp-cvs MLs, because I think you are not a member of them anymore. > > > v1.2 is scheduled for release now in August, > > > perhaps a release candidate would be appropriate? > > > > Yes, there will be a release candidate, but we are not ready yet so > > it may be delayed a bit. > Might one ask what you are planning for RC1? RC1 should include everything that is suppose to go into release-1.2: the new policy stuff, the Windows stuff, etc. Pavlin From John.Weaver@motorola.com Fri Aug 26 20:30:10 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Fri, 26 Aug 2005 14:30:10 -0500 Subject: [Xorp-hackers] RE: Xorp-hackers digest, Vol 1 #183 - 1 msg Message-ID: <0DFC73466514D41186B700508B9510411BE39DDB@tx14exm04.ftw.mot.com> Sounds like a very interesting project although I am having a hard time wrapping my brain around the XRL stuff. I remember you telling once that XORP can be brought up and read particular interfaces on its own and configure itself. How would I do this and is this possible with just TAP interfaces? Thanks, John -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin@icir.org] Sent: Thursday, August 25, 2005 7:36 PM To: Weaver John-JWEAVER1 Cc: xorp-hackers@icir.org Subject: Re: [Xorp-hackers] RE: Xorp-hackers digest, Vol 1 #183 - 1 msg > The lib version of the xorpsh is prolly exactly what I need. I would > think for the XORP project to be successful in an embedded market this > would be necessary. Most of the switch/router projects I have done in > the past have always required many boot time decisions on how to > configure all the interfaces and protocols. None of our systems have > ever had direct configuration by a user and almost always requires > run-time changes via applications that trigger off of upstream > database changes. I hope I can come to a way to use XORP in this way > because I hate to think of the other vendor I will have to use if not. > Plus it puts me way behind schedule. ;) I guess I can always resort to > hacking out some scripts to try and configure things but it sounds > real risky and not very easy, especially since I don't know shell scripting. Yes, I think this is a very good idea. Would you volunteer to extract the core xorpsh functionality in such library? :) Otherwise, I am afraid that currently we don't have the spare cycles to do this ourselves. We can add it to our TODO list, but it may take a while before it is ready. So your best bet would be to invest in the shell scripting solution, and eventually in the future you can switch to using the library instead. In any case, can you send us pointers to existing solutions (e.g., high-level description, API, etc). Thanks, Pavlin From pavlin@icir.org Fri Aug 26 20:42:21 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 26 Aug 2005 12:42:21 -0700 Subject: [Xorp-hackers] RE: Xorp-hackers digest, Vol 1 #183 - 1 msg In-Reply-To: Message from Weaver John-JWEAVER1 of "Fri, 26 Aug 2005 14:30:10 CDT." <0DFC73466514D41186B700508B9510411BE39DDB@tx14exm04.ftw.mot.com> Message-ID: <200508261942.j7QJgLbF026209@possum.icir.org> > Sounds like a very interesting project although I am having a hard time > wrapping my brain around the XRL stuff. I remember you telling once that > XORP can be brought up and read particular interfaces on its own and > configure itself. How would I do this and is this possible with just TAP > interfaces? Was it in the context of implicitly configuring a network interface (inside XORP) to use whatever IP addresses have been assigned already to that interface: interfaces { interface rl0 { default-system-config } } In general, you should be able to use "default-system-config" for any network interfaces. If no, then please resend me the email so I can refresh my memory. Pavlin From John.Weaver@motorola.com Fri Aug 26 20:47:51 2005 From: John.Weaver@motorola.com (Weaver John-JWEAVER1) Date: Fri, 26 Aug 2005 14:47:51 -0500 Subject: [Xorp-hackers] RE: Xorp-hackers digest, Vol 1 #183 - 1 msg Message-ID: <0DFC73466514D41186B700508B9510411BE39E29@tx14exm04.ftw.mot.com> Maybe I read it, but I thought we discussed it at one time. Any way, when I bring up the system I will be configuring some TAP interfaces (i.e. TAP0, TAP1, etc.) before starting the XORP daemon. Is there a way to tell XORP to configure PIM and IGMP on its own to read the info and fill in its own config for these particular interfaces and no others? Thanks, John -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin@icir.org] Sent: Friday, August 26, 2005 2:42 PM To: Weaver John-JWEAVER1 Cc: Pavlin Radoslavov; xorp-hackers@icir.org Subject: Re: [Xorp-hackers] RE: Xorp-hackers digest, Vol 1 #183 - 1 msg > Sounds like a very interesting project although I am having a hard > time wrapping my brain around the XRL stuff. I remember you telling > once that XORP can be brought up and read particular interfaces on its > own and configure itself. How would I do this and is this possible > with just TAP interfaces? Was it in the context of implicitly configuring a network interface (inside XORP) to use whatever IP addresses have been assigned already to that interface: interfaces { interface rl0 { default-system-config } } In general, you should be able to use "default-system-config" for any network interfaces. If no, then please resend me the email so I can refresh my memory. Pavlin From pavlin@icir.org Fri Aug 26 22:37:31 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 26 Aug 2005 14:37:31 -0700 Subject: [Xorp-hackers] RE: Xorp-hackers digest, Vol 1 #183 - 1 msg In-Reply-To: Message from Weaver John-JWEAVER1 of "Fri, 26 Aug 2005 14:47:51 CDT." <0DFC73466514D41186B700508B9510411BE39E29@tx14exm04.ftw.mot.com> Message-ID: <200508262137.j7QLbVuj026847@possum.icir.org> > Maybe I read it, but I thought we discussed it at one time. Any way, when I > bring up the system I will be configuring some TAP interfaces (i.e. TAP0, > TAP1, etc.) before starting the XORP daemon. Is there a way to tell XORP to > configure PIM and IGMP on its own to read the info and fill in its own > config for these particular interfaces and no others? Yes. The MFEA, IGMP and PIM configuration doesn't contain any interface-specific information such as IP address, netmask, etc. Hence, all you need to do is just include the interface/vif in each blocks (mfea4, igmp, pimsm4), but only if the system already has that interface enabled and configured. Furthermore, each interface must be configured in the "interfaces" configuration block (either explicitly by specifying the IP address, etc, or implicitly by the default-system-config statement). If, however, the system doesn't have yet a particular interface, then this interface must not be included in the XORP configuration. Only after the interface is created in the kernel, then it should be added to the xorp configuration (interfaces, mfea4, igmp, pimsm4, etc). Pavlin > > Thanks, > John > > -----Original Message----- > From: Pavlin Radoslavov [mailto:pavlin@icir.org] > Sent: Friday, August 26, 2005 2:42 PM > To: Weaver John-JWEAVER1 > Cc: Pavlin Radoslavov; xorp-hackers@icir.org > Subject: Re: [Xorp-hackers] RE: Xorp-hackers digest, Vol 1 #183 - 1 msg > > > Sounds like a very interesting project although I am having a hard > > time wrapping my brain around the XRL stuff. I remember you telling > > once that XORP can be brought up and read particular interfaces on its > > own and configure itself. How would I do this and is this possible > > with just TAP interfaces? > > Was it in the context of implicitly configuring a network interface (inside > XORP) to use whatever IP addresses have been assigned already to that > interface: > > interfaces { > interface rl0 { > default-system-config > } > } > > In general, you should be able to use "default-system-config" for any > network interfaces. > > If no, then please resend me the email so I can refresh my memory. > > Pavlin > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From Per.Svensson.6835@student.uu.se Wed Aug 31 10:37:02 2005 From: Per.Svensson.6835@student.uu.se (Per Svensson) Date: Wed, 31 Aug 2005 11:37:02 +0200 Subject: [Xorp-hackers] bgp reflector client Message-ID: <1125481022.43157a3eae64b@webmail.uu.se> Hi! I would like to use a Xorp as a reflector client. What I actually need is the ORIGINATOR-ID attribute (type code 9). Does it exist a version of Xorp that has this implemented? If such a version doesn't exist, can someone give me some hints on where to look in the sourcecode if I want to implement support for the ORIGINATOR-ID attribute? Thanks Per Svensson Uppsala University