From yuvalif at gmail.com Wed Aug 1 01:44:12 2007 From: yuvalif at gmail.com (Yuval Lifshitz) Date: Wed, 1 Aug 2007 11:44:12 +0300 Subject: [Xorp-hackers] multiple instances on one machine Message-ID: Hi all, I'm trying to run multiple instances of xorp on the same machine. The machine has two different IPs - 172.16.1.141 and 172.16.1.142. I run into problems regarding the internal communication on the machine. When I tried to use the -i command line flag, I got: # ./xorp_rtrmgr -i 172.16.1.141 ../config.boot1 172.16.1.141 is not the address of an active interface. although it is defined on the interface: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0d:60:1c:40:06 brd ff:ff:ff:ff:ff:ff inet 172.16.0.109/20 brd 172.16.15.255 scope global eth0 inet 172.16.1.141/20 brd 172.16.15.255 scope global secondary eth0:1 inet 172.16.1.142/20 brd 172.16.15.255 scope global secondary eth0:2 and in the config.boot1 file: interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "data interface" disable: false /* default-system-config */ vif eth0 { disable: false address 172.16.1.141 { prefix-length: 20 broadcast: 172.16.15.255 disable: false } } } } Then, I tried to use the XORP_FINDER_SERVER_ADDRESS env variable: # export XORP_FINDER_SERVER_ADDRESS="172.16.1.141" # ./xorp_rtrmgr ../config.boot1 and got: Unexpected exception: thrown did not correspond to specification - fix code. InvalidAddress from line 292 of ../../libxipc/finder_tcp.cc -> Not a configured IPv4 address BTW, when using two ports, it is working fine. regards, Yuval. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070801/2a7d3d78/attachment.html From pavlin at icir.org Wed Aug 1 12:39:00 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 01 Aug 2007 12:39:00 -0700 Subject: [Xorp-hackers] multiple instances on one machine In-Reply-To: Message from "Yuval Lifshitz" of "Wed, 01 Aug 2007 11:44:12 +0300." Message-ID: <200708011939.l71Jd0kD012811@possum.icir.org> Yuval Lifshitz wrote: > Hi all, > I'm trying to run multiple instances of xorp on the same machine. > The machine has two different IPs - 172.16.1.141 and 172.16.1.142. > I run into problems regarding the internal communication on the machine. > When I tried to use the -i command line flag, I got: > # ./xorp_rtrmgr -i 172.16.1.141 ../config.boot1 > 172.16.1.141 is not the address of an active interface. There was a bug in the code that reads the list of IPv4 addresses from the system: that code didn't consider the secondary (alias) IP addresses. The problem is now fixed in CVS: Revision Changes Path 1.27 +152 -98; commitid: 2b9a46b0d8a07ea6; xorp/libxipc/sockutil.cc > although it is defined on the interface: > eth0: mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:0d:60:1c:40:06 brd ff:ff:ff:ff:ff:ff > inet 172.16.0.109/20 brd 172.16.15.255 scope global eth0 > inet 172.16.1.141/20 brd 172.16.15.255 scope global secondary eth0:1 > inet 172.16.1.142/20 brd 172.16.15.255 scope global secondary eth0:2 > > and in the config.boot1 file: > > interfaces { > restore-original-config-on-shutdown: false > interface eth0 { > description: "data interface" > disable: false > /* default-system-config */ > vif eth0 { > disable: false > address 172.16.1.141 { > prefix-length: 20 > broadcast: 172.16.15.255 > disable: false > } > } > } > } > > Then, I tried to use the XORP_FINDER_SERVER_ADDRESS env variable: > # export XORP_FINDER_SERVER_ADDRESS="172.16.1.141" > # ./xorp_rtrmgr ../config.boot1 > > and got: > > Unexpected exception: thrown did not correspond to specification - fix > code. > InvalidAddress from line 292 of ../../libxipc/finder_tcp.cc -> Not a > configured IPv4 address The second error was again because of the bug mentioned above (and just fixed). The first error "Unexpected exception" is now fixed as well. > BTW, when using two ports, it is working fine. Actually, if you want to run 2+ instances of XORP on the same machine, the simplest thing is indeed to set the XORP_FINDER_SERVER_PORT environmental variable to different value for each instance. I believe setting the XORP_FINDER_SERVER_ADDRESS should work as well. Off the top of my head I don't remember whether "-i " will do exactly the same thing as XORP_FINDER_SERVER_ADDRESS. If it does, then it also should work (after applying the above fix). In any case, please get the latest code from CVS and let us know if it still doesn't work for you. Thanks, Pavlin > regards, > > Yuval. > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From szabgab at gmail.com Tue Aug 14 14:19:06 2007 From: szabgab at gmail.com (Gabor Szabo) Date: Wed, 15 Aug 2007 00:19:06 +0300 Subject: [Xorp-hackers] testing xorp Message-ID: Hi, I am trying to collect information and write articles about Quality Assurance and Automated Testing in Open Source Projects http://www.szabgab.com/blog/2007/07/1183825266.html I have information on many stand-alone tools and applications (e.g. Perl, PostgreSQL) yet to be posted on my site, but I would like to include information on how testing is done for networking applications and especially xorp. I looked at http://www.xorp.org/ and http://www.vyatta.com/ but the only thing I found was http://www.vyatta.com/twiki/bin/view/Community/UnhTestResults This is not what I was looking for. Are there automatic (unit) tests in the project? If I want to run them, how can I do it? Are there smoke testers? Where are the reports? I'd appreciate pointers, where should I read about this? regards Gabor -- Gabor Szabo http://www.szabgab.com/ Perl Training in Israel http://www.pti.co.il/ From atanu at ICSI.Berkeley.EDU Tue Aug 14 19:38:17 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 14 Aug 2007 19:38:17 -0700 Subject: [Xorp-hackers] testing xorp In-Reply-To: Message from "Gabor Szabo" of "Wed, 15 Aug 2007 00:19:06 +0300." Message-ID: <26401.1187145497@tigger.icir.org> Hi, You are right we don't have anything on the web site about our testing procedures. We say a little when we announce a new release: . The unit/regression tests can invoked by running "gmake check". To run through all the tests takes about three hours. We have a tinderbox setup that continuously builds XORP on a number of different operating systems with different compilers, the output is sent to an internal mailing list. Whenever we write code or fix bugs we try and add test cases: The tests vary in complexity from simple unit tests to verify that the class that holds IPv4 addresses works correctly, to starting BGP and injecting 17000 routes. The test programs have the prefix test_* we have about 154 (1) of these programs and most of them will run multiple tests (One of the BGP test scripts has 58 tests). Some of the complex routing protocols such as BGP have their own test harness (http://www.xorp.org/releases/1.4/docs/test_harness/test_harness.pdf), which allow the whole process to be started and tested. XRL's can easily represented in text form so a number of our tests are run from scripts. We have a number of machines permanently running with full BGP feeds (IPv4 and IPv6). We have one host that receives both feeds and has all the protocols enabled, we track the resource usage of the XORP processes on this host, memory usage per process, routes in kernel, swap space and open files. We don't currently make the results of our testing available. Atanu. (1) find . -name 'test_*' -print | egrep '*.cc$|*.py$|*.sh$' | wc -l >>>>> "Gabor" == Gabor Szabo writes: Gabor> Hi, Gabor> I am trying to collect information and write articles about Gabor> Quality Assurance and Automated Testing in Open Source Projects Gabor> http://www.szabgab.com/blog/2007/07/1183825266.html Gabor> I have information on many stand-alone tools and applications Gabor> (e.g. Perl, PostgreSQL) yet to be posted on my site, Gabor> but I would like to include information on how testing is done for Gabor> networking applications and especially xorp. Gabor> I looked at http://www.xorp.org/ and http://www.vyatta.com/ Gabor> but the only thing I found was Gabor> http://www.vyatta.com/twiki/bin/view/Community/UnhTestResults Gabor> This is not what I was looking for. Gabor> Are there automatic (unit) tests in the project? Gabor> If I want to run them, how can I do it? Gabor> Are there smoke testers? Gabor> Where are the reports? Gabor> I'd appreciate pointers, where should I read about this? Gabor> regards Gabor> Gabor Gabor> -- Gabor> Gabor Szabo Gabor> http://www.szabgab.com/ Gabor> Perl Training in Israel http://www.pti.co.il/ Gabor> _______________________________________________ Gabor> Xorp-hackers mailing list Gabor> Xorp-hackers at icir.org Gabor> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From gilligan at vyatta.com Fri Aug 17 18:29:49 2007 From: gilligan at vyatta.com (Bob Gilligan) Date: Fri, 17 Aug 2007 18:29:49 -0700 (PDT) Subject: [Xorp-hackers] testing xorp In-Reply-To: Message-ID: <14606834.387841187400589158.JavaMail.root@tahiti.vyatta.com> Hi Gabor -- I don't know if this is what you are looking for, but at Vyatta, we do alot of routing protocol testing with the Spirent SmartBits Tera Routing Tester (TRT). The advantage of TRT is that it allows one to generate a wide range of workloads for multiple routing protocols. You can have the tester simulate multiple routers, offering different route updates, and schedule events like link flaps, and simulate IP traffic all at the same time. The downside is that it only runs on a SmartBits tester, and those are not exactly cheap! TRT tests can be automated. Spirent provides a TCL client library for scripting. But we haven't done any automation yet. Spirent has lots of info on the SmartBits tester and info about TRT and other applications for it on their web site at: http://www.spirent.com/analysis/technology.cfm?media=7&ws=325&ss=110&stype=15&a=1 Bob. ----- "Gabor Szabo" wrote: > Hi, > > I am trying to collect information and write articles about > Quality Assurance and Automated Testing in Open Source Projects > http://www.szabgab.com/blog/2007/07/1183825266.html > > I have information on many stand-alone tools and applications > (e.g. Perl, PostgreSQL) yet to be posted on my site, > but I would like to include information on how testing is done for > networking applications and especially xorp. > > I looked at http://www.xorp.org/ and http://www.vyatta.com/ > but the only thing I found was > http://www.vyatta.com/twiki/bin/view/Community/UnhTestResults > This is not what I was looking for. > > Are there automatic (unit) tests in the project? > If I want to run them, how can I do it? > Are there smoke testers? > Where are the reports? > > I'd appreciate pointers, where should I read about this? > > regards > Gabor > > -- > Gabor Szabo > http://www.szabgab.com/ > Perl Training in Israel http://www.pti.co.il/ > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From b_kalahasti at yahoo.com Tue Aug 21 18:11:56 2007 From: b_kalahasti at yahoo.com (Bharadwaj Kalahasti) Date: Tue, 21 Aug 2007 18:11:56 -0700 (PDT) Subject: [Xorp-hackers] Status of ISIS protocol code Message-ID: <534627.38897.qm@web54603.mail.re2.yahoo.com> Atanu, What is the status of ISIS protocol support in XORP suite? If no other developer has started working on it, I would be able to put in ISIS code following existing XORP design guidelines into the suite with basic support for RFC 1195. I have some industrial experience with testing and fixing bugs for ISIS. Thanks, Kalahasti ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC From kristian at spritelink.net Wed Aug 22 02:59:31 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Wed, 22 Aug 2007 11:59:31 +0200 Subject: [Xorp-hackers] Status of ISIS protocol code In-Reply-To: <534627.38897.qm@web54603.mail.re2.yahoo.com> References: <534627.38897.qm@web54603.mail.re2.yahoo.com> Message-ID: <46CC0903.8070809@spritelink.net> Bharadwaj Kalahasti wrote: > Atanu, > What is the status of ISIS protocol support in XORP suite? Pardon for replying to a directed mail.. there is no code checked in for ISIS and if I recall correctly (can't find the page on the xorp site) ISIS support was to be included in XORP 1.5 which is scheduled for release in October. I'd say it's gonna run a bit late ;) Looking at recent CVS commits it seems most work is done on internal socket handling and the alike right now. > If no other developer has started working on it, I would be able to put in ISIS > code following existing XORP design guidelines into the suite with basic support for > RFC 1195. > I have some industrial experience with testing and fixing bugs for ISIS. I would love to see someone with the expertise to work on this and the XORP project is in strong need of more supporters/developers :) I would be very willing to help out testing your code and contributing in anyway I can (though I'm a lousy coder).. :) Kristian. From steffen at schumacher.dk Thu Aug 23 00:17:44 2007 From: steffen at schumacher.dk (Steffen Schumacher) Date: Thu, 23 Aug 2007 09:17:44 +0200 Subject: [Xorp-hackers] Recursive next-hop lookup.. Message-ID: <20070823071744.GC66643@schumacher.dk> Hi! I read the status page, so that the feature in subject still isnt implemented. (http://www.xorp.org/status.html) Or is it simply not working? Does anyone know if it will be working by 1.5? Currently I've used quagga, but it seems that it also doesn't support it. I'd really like it, because my ISP will only announce a default candidate via bgp, vs. a default. The idea is that I configure a static default directed at this Default candidate, and my default will then move around when my eBGP peers go up/down. If there is simply a bug in the code I'd like to have a look at it. But implementing the feature might be a bit much, since this is not a small task. Anyways - any status updates on the feature would be nice! /Steffen From atanu at ICSI.Berkeley.EDU Thu Aug 23 18:24:36 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 23 Aug 2007 18:24:36 -0700 Subject: [Xorp-hackers] Status of ISIS protocol code In-Reply-To: Message from Bharadwaj Kalahasti of "Tue, 21 Aug 2007 18:11:56 PDT." <534627.38897.qm@web54603.mail.re2.yahoo.com> Message-ID: <28680.1187918676@tigger.icir.org> Hi, We have wanted an ISIS implementation for some time but have not had the resources to work on one. An attempt was made a few years ago by a third party to write an ISIS for XORP if you are interested I can try and get this code to you as a starting point? Atanu. >>>>> "Bharadwaj" == Bharadwaj Kalahasti writes: Bharadwaj> Atanu, Bharadwaj> What is the status of ISIS protocol support in XORP suite? Bharadwaj> If no other developer has started working on it, I would be able to put in ISIS Bharadwaj> code following existing XORP design guidelines into the suite with basic support for Bharadwaj> RFC 1195. Bharadwaj> I have some industrial experience with testing and fixing bugs for ISIS. Bharadwaj> Thanks, Bharadwaj> Kalahasti Bharadwaj> ____________________________________________________________________________________ Bharadwaj> Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. Bharadwaj> http://mobile.yahoo.com/go?refer=1GNXIC Bharadwaj> _______________________________________________ Bharadwaj> Xorp-hackers mailing list Bharadwaj> Xorp-hackers at icir.org Bharadwaj> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From Erlend.Knutsen at applica.no Mon Aug 27 10:34:46 2007 From: Erlend.Knutsen at applica.no (Erlend Knutsen) Date: Mon, 27 Aug 2007 19:34:46 +0200 Subject: [Xorp-hackers] OSPFv2 p2p links Message-ID: Hi all, It seems like XORP OSPFv2 does not fully manage to update the routing table when a neighbor connected through a p2p link goes down, e.g. when an xorp OSPFv2 neighbour is stopped. The neighbour state is set correctly to down, but the routes advertised by/through the neighbour are not removed from the rest of the network. The LS DB is identical before and after the neighbour has been stopped (only the age field differs, but is not set to MaxAge). I have tested this in a very simple scenario with 3 routers R1-R2-R3 up and running with p2p links configured over Ethernet. I have for example stopped ospf on R2 and then observed that R1 and R3 still have routes to each other. However, when the same routers run with Broadcast links the routes are correctly removed when one of the other routers goes down. I can see from the source code and debug output that the difference in handling of the InactivityTimer Event (i.e. Hello timeout) between Broadcast and p2p links seems to start in the method: Neighbour::tear_down_state; This method does not do any work for p2p (_peer.adjacency_change only works for DR or BDR). I therefore simply tried to add the call: _peer.get_area_router()->refresh_router_lsa() to the end Neighbour::tear_down_state. This causes a total recompute of the routing but the routes from/via the router that has been shut down are not removed. It may be that p2p links should have some kind of special static state, but to me, it does not seem sane that the links to/via a router that has gone down are not removed. The RFC 2178 is somewhat diffuse when it comes to p2p and Hello timeout. (It may seem somewhat strange to run p2p over Ethernet but this is a requirement.) Anyway I hope someone can give me some hints on how to work further in this. I can send debug logs and config setup if necessary. Thanks in advance! Regards, Erlend -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070827/395f84c4/attachment.html From b_kalahasti at yahoo.com Mon Aug 27 14:59:38 2007 From: b_kalahasti at yahoo.com (Bharadwaj Kalahasti) Date: Mon, 27 Aug 2007 14:59:38 -0700 (PDT) Subject: [Xorp-hackers] OSPFv2 P2P Links Message-ID: <290776.93019.qm@web54601.mail.re2.yahoo.com> Erlend, Generally speaking, one set of implementations for non-broadcast neighbors such as those of P2MP, P2P and NBMA seems to be to configure the neighbors as 'STATIC' neighbors. For P2P Neighbors, the Hellos are multicast. The Intf state for the OSPF interface should be P2P after the IP interface comes up. And the Nbr state should finally be Full on the local end assuming that the Router ID of the neighbor is seen by the local router. These are the steps that should happen: -- So assuming that your neighbor has gone Down at the remote end for the reasons - Admin down, Link transmission failure but Link is still Up etc, then this should cause Inactivity Timer to be fired on the local end. -- Expiry of this timer should cause a new Router LSA to be generated and area-flooded but without the Neighbor's Router ID in its Neighbor list (since it failed to have bi-directional communication). -- Since the new Router-LSA would be different in its LS Header from the previous one for the same local router's Router ID, that should cause its installation on all of the area's routers and kick off a new SPF run once the installation of the Router-LSA in the LSDB is done. -- The SPF run should take care of deleting the P2P host route in the Routing Table. I think the implementation of a P2P Nbr is upto interpretation. The catch here is that a static configuration of the Nbr would mean that the Hello packet can always have the Neighbor router listed in it indicating bi-directional communication and full adjacency though the link may actually be down (if knowing the existence of a Neighbor implies including it in the sent Hello). The other way to interpret the RFC is that configuration is good enough to know its existence but its inclusion in the Hello is subject to event occurence on the link. I do not know the OSPFv2 code in XORP but if Static neighbors are not supported yet, then may be it is a good idea to support it. Regards, Kalahasti >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all, It seems like XORP OSPFv2 does not fully manage to update the routing table when a neighbor connected through a p2p link goes down, e.g. when an xorp OSPFv2 neighbour is stopped. The neighbour state is set correctly to down, but the routes advertised by/through the neighbour are not removed from the rest of the network. The LS DB is identical before and after the neighbour has been stopped (only the age field differs, but is not set to MaxAge). I have tested this in a very simple scenario with 3 routers R1-R2-R3 up and running with p2p links configured over Ethernet. I have for example stopped ospf on R2 and then observed that R1 and R3 still have routes to each other. However, when the same routers run with Broadcast links the routes are correctly removed when one of the other routers goes down. I can see from the source code and debug output that the difference in handling of the InactivityTimer Event (i.e. Hello timeout) between Broadcast and p2p links seems to start in the method: Neighbour::tear_down_state; This method does not do any work for p2p (_peer.adjacency_change only works for DR or BDR). I therefore simply tried to add the call: _peer.get_area_router()->refresh_router_lsa() to the end Neighbour::tear_down_state. This causes a total recompute of the routing but the routes from/via the router that has been shut down are not removed. It may be that p2p links should have some kind of special static state, but to me, it does not seem sane that the links to/via a router that has gone down are not removed. The RFC 2178 is somewhat diffuse when it comes to p2p and Hello timeout. (It may seem somewhat strange to run p2p over Ethernet but this is a requirement.) Anyway I hope someone can give me some hints on how to work further in this. I can send debug logs and config setup if necessary. Thanks in advance! Regards, Erlend ____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz From luca.giraudo at gmail.com Tue Aug 28 03:21:08 2007 From: luca.giraudo at gmail.com (Luca Giraudo) Date: Tue, 28 Aug 2007 12:21:08 +0200 Subject: [Xorp-hackers] Generating the XRL interface In-Reply-To: <46A0B89F.6070907@uclouvain.be> References: <200707200346.l6K3khfZ023091@possum.icir.org> <46A0B89F.6070907@uclouvain.be> Message-ID: <33404c390708280321s106e3bfcqcd830e2be56bb469@mail.gmail.com> I am trying to writing a XORP process like Damien Leroy, but something doesn't work. I am using the CVS version of XORP, and I have installed: * autoconf 2.59 (from Fedora Core 6: which autoconf -> /usr/bin/autoconf) * autoconf 2.61 (which autoconf261 -> /usr/local/bin/autoconf261) * automake 1.9.6 (from FC6: which automake -> /usr/bin/automake) * automake 1.10 (which automake110 -> /usr/local/bin/automake110) * libtoolize 1.5.22 I don't modify the "bootstrap" because the variables (ACLOCAL, AUTOCONF, ..., LIBTOOLIZE) are correct. So, I run ./bootstrap, but the output is: ... aclocal110 -I config configure.in:39: error: Autoconf version 2.61 or higher is required configure.in:39: the top level autom4te: /usr/bin/m4 failed with exit status: 63 aclocal110: autom4te failed with exit status: 63 Error running 'aclocal110 -I config' I think that aclocal110 finds only the old version of autoconf, but I don't know how to resolve this trouble. Thanks Luca Giraudo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070828/be3ff6bc/attachment.html From Erlend.Knutsen at applica.no Tue Aug 28 06:12:08 2007 From: Erlend.Knutsen at applica.no (Erlend Knutsen) Date: Tue, 28 Aug 2007 15:12:08 +0200 Subject: [Xorp-hackers] OSPFv2 P2P Links References: <290776.93019.qm@web54601.mail.re2.yahoo.com> Message-ID: Thank you! This pretty much helped clearing up how OSPF p2p is supposed to work. To answer your question: XORP only seem to support p2p when configurig the neighbours statically, so YES! XORP supports static Neighbours. When running OSPF p2p over Ethernet the Router LSA (catched from tcpdump) reports a p2p link and a stub link to the Ethernet subnet between the routers. I can managed to multicast an LSA update as a result of the Hello inactivity timer for the p2p link. However the p2p link that went down is still reported. I am looking further into the code now to try to ensure that the "downed" p2p link is removed before a new LSA is sent. Regards, Erlend -----Original Message----- From: Bharadwaj Kalahasti [mailto:b_kalahasti at yahoo.com] Sent: ma 27-aug-07 23:59 To: xorp-hackers at icir.org; Erlend Knutsen Subject: OSPFv2 P2P Links Erlend, Generally speaking, one set of implementations for non-broadcast neighbors such as those of P2MP, P2P and NBMA seems to be to configure the neighbors as 'STATIC' neighbors. For P2P Neighbors, the Hellos are multicast. The Intf state for the OSPF interface should be P2P after the IP interface comes up. And the Nbr state should finally be Full on the local end assuming that the Router ID of the neighbor is seen by the local router. These are the steps that should happen: -- So assuming that your neighbor has gone Down at the remote end for the reasons - Admin down, Link transmission failure but Link is still Up etc, then this should cause Inactivity Timer to be fired on the local end. -- Expiry of this timer should cause a new Router LSA to be generated and area-flooded but without the Neighbor's Router ID in its Neighbor list (since it failed to have bi-directional communication). -- Since the new Router-LSA would be different in its LS Header from the previous one for the same local router's Router ID, that should cause its installation on all of the area's routers and kick off a new SPF run once the installation of the Router-LSA in the LSDB is done. -- The SPF run should take care of deleting the P2P host route in the Routing Table. I think the implementation of a P2P Nbr is upto interpretation. The catch here is that a static configuration of the Nbr would mean that the Hello packet can always have the Neighbor router listed in it indicating bi-directional communication and full adjacency though the link may actually be down (if knowing the existence of a Neighbor implies including it in the sent Hello). The other way to interpret the RFC is that configuration is good enough to know its existence but its inclusion in the Hello is subject to event occurence on the link. I do not know the OSPFv2 code in XORP but if Static neighbors are not supported yet, then may be it is a good idea to support it. Regards, Kalahasti >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all, It seems like XORP OSPFv2 does not fully manage to update the routing table when a neighbor connected through a p2p link goes down, e.g. when an xorp OSPFv2 neighbour is stopped. The neighbour state is set correctly to down, but the routes advertised by/through the neighbour are not removed from the rest of the network. The LS DB is identical before and after the neighbour has been stopped (only the age field differs, but is not set to MaxAge). I have tested this in a very simple scenario with 3 routers R1-R2-R3 up and running with p2p links configured over Ethernet. I have for example stopped ospf on R2 and then observed that R1 and R3 still have routes to each other. However, when the same routers run with Broadcast links the routes are correctly removed when one of the other routers goes down. I can see from the source code and debug output that the difference in handling of the InactivityTimer Event (i.e. Hello timeout) between Broadcast and p2p links seems to start in the method: Neighbour::tear_down_state; This method does not do any work for p2p (_peer.adjacency_change only works for DR or BDR). I therefore simply tried to add the call: _peer.get_area_router()->refresh_router_lsa() to the end Neighbour::tear_down_state. This causes a total recompute of the routing but the routes from/via the router that has been shut down are not removed. It may be that p2p links should have some kind of special static state, but to me, it does not seem sane that the links to/via a router that has gone down are not removed. The RFC 2178 is somewhat diffuse when it comes to p2p and Hello timeout. (It may seem somewhat strange to run p2p over Ethernet but this is a requirement.) Anyway I hope someone can give me some hints on how to work further in this. I can send debug logs and config setup if necessary. Thanks in advance! Regards, Erlend ____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070828/f8deeb43/attachment.html From b_kalahasti at yahoo.com Tue Aug 28 10:50:37 2007 From: b_kalahasti at yahoo.com (Bharadwaj Kalahasti) Date: Tue, 28 Aug 2007 10:50:37 -0700 (PDT) Subject: [Xorp-hackers] OSPFv2 P2P Links Message-ID: <524820.71499.qm@web54601.mail.re2.yahoo.com> Erlend, You are right. The stub link should remain in the Router-LSA while the Type 1 link should be removed due to non-adjacency with the neighbor. I know of how the changes need to be done. May be you can review them. If I make the same changes for NBMA and P2MP, would you be able to test them for me? I have a single Ubuntu linux loaded DELL PC that does not help much but for a single router instance. Thanks, Kalahasti >>>>>>>>>>>> Thank you! This pretty much helped clearing up how OSPF p2p is supposed to work. To answer your question: XORP only seem to support p2p when configurig the neighbours statically, so YES! XORP supports static Neighbours. When running OSPF p2p over Ethernet the Router LSA (catched from tcpdump) reports a p2p link and a stub link to the Ethernet subnet between the routers. I can managed to multicast an LSA update as a result of the Hello inactivity timer for the p2p link. However the p2p link that went down is still reported. I am looking further into the code now to try to ensure that the "downed" p2p link is removed before a new LSA is sent. Regards, Erlend --- Bharadwaj Kalahasti wrote: > Erlend, > Generally speaking, one set of implementations for non-broadcast neighbors such > as > those of P2MP, P2P and NBMA seems to be to configure the neighbors as 'STATIC' > neighbors. > For P2P Neighbors, the Hellos are multicast. The Intf state for the OSPF > interface > should be P2P after the IP interface comes up. And the Nbr state should finally > be > Full on the local end assuming that the Router ID of the neighbor is seen by the > local router. > > These are the steps that should happen: > -- So assuming that your neighbor has gone Down at the remote end for the reasons > - > Admin down, Link transmission failure but Link is still Up etc, then this should > cause Inactivity Timer to be fired on the local end. > -- Expiry of this timer should cause a new Router LSA to be generated and > area-flooded but without the Neighbor's Router ID in its Neighbor list (since it > failed to have bi-directional communication). > -- Since the new Router-LSA would be different in its LS Header from the previous > one for the same local router's Router ID, that should cause its installation on > all > of the area's routers and kick off a new SPF run once the installation of the > Router-LSA in the LSDB is done. > -- The SPF run should take care of deleting the P2P host route in the Routing > Table. > > > I think the implementation of a P2P Nbr is upto interpretation. The catch here > is > that a static configuration of the Nbr would mean that the Hello packet can always > have the Neighbor router listed in it indicating bi-directional communication and > full adjacency though the link may actually be down (if knowing the existence of a > Neighbor implies including it in the sent Hello). The other way to interpret the > RFC > is that configuration is good enough to know its existence but its inclusion in > the > Hello is subject to event occurence on the link. > > I do not know the OSPFv2 code in XORP but if Static neighbors are not supported > yet, then may be it is a good idea to support it. > > Regards, > Kalahasti > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > Hi all, > > > > It seems like XORP OSPFv2 does not fully manage to update the routing > table > > when a neighbor connected through a p2p link goes down, e.g. when an > xorp > > OSPFv2 neighbour is stopped. The neighbour state is set correctly to > down, > > but the routes advertised by/through the neighbour are not removed from > the > > rest of the network. The LS DB is identical before and after the > neighbour > > has been stopped (only the age field differs, but is not set to MaxAge). > > > > I have tested this in a very simple scenario with 3 routers R1-R2-R3 up > and > > running with p2p links configured over Ethernet. I have for example > stopped > > ospf on R2 and then observed that R1 and R3 still have routes to each > other. > > However, when the same routers run with Broadcast links the routes are > > correctly removed when one of the other routers goes down. > > > > I can see from the source code and debug output that the difference in > > handling of the InactivityTimer Event (i.e. Hello timeout) between > Broadcast > > and p2p links seems to start in the method: > Neighbour::tear_down_state; > > This method does not do any work for p2p (_peer.adjacency_change > > only works for DR or BDR). I therefore simply tried to add the call: > > _peer.get_area_router()->refresh_router_lsa() > > to the end Neighbour::tear_down_state. This causes a total recompute > > of the routing but the routes from/via the router that has been shut > down are > > not removed. > > > > It may be that p2p links should have some kind of special static state, > > but to me, it does not seem sane that the links to/via a router that has > > gone down are not removed. The RFC 2178 is somewhat diffuse when > > it comes to p2p and Hello timeout. (It may seem somewhat strange > > to run p2p over Ethernet but this is a requirement.) > > > > Anyway I hope someone can give me some hints on how to work further in > this. > > > > I can send debug logs and config setup if necessary. > > Thanks in advance! > > > > Regards, > > Erlend > > > > ____________________________________________________________________________________ > Luggage? GPS? Comic books? > Check out fitting gifts for grads at Yahoo! Search > http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz > ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC From a.greenhalgh at cs.ucl.ac.uk Tue Aug 28 11:02:08 2007 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Tue, 28 Aug 2007 19:02:08 +0100 Subject: [Xorp-hackers] OSPFv2 P2P Links In-Reply-To: <524820.71499.qm@web54601.mail.re2.yahoo.com> References: <524820.71499.qm@web54601.mail.re2.yahoo.com> Message-ID: <4769af410708281102y738eac1dy62c5c7c434f50a78@mail.gmail.com> Kalahasti , Erlend, Feel free to submit patches. Adam On 8/28/07, Bharadwaj Kalahasti wrote: > Erlend, > You are right. The stub link should remain in the Router-LSA while the Type 1 link > should be removed due to non-adjacency with the neighbor. > I know of how the changes need to be done. May be you can review them. > If I make the same changes for NBMA and P2MP, would you be able to test them for > me? I have a single Ubuntu linux loaded DELL PC that does not help much but for a > single router instance. > Thanks, > Kalahasti > > > > >>>>>>>>>>>> > Thank you! This pretty much helped clearing up how OSPF p2p is supposed to work. > To answer your question: XORP only seem to support p2p when configurig the > neighbours statically, so YES! XORP supports static Neighbours. > > When running OSPF p2p over Ethernet the Router LSA (catched from tcpdump) reports a > p2p link and a stub link to the Ethernet subnet between the routers. I can managed > to multicast an LSA update as a result of the Hello inactivity timer for the p2p > link. However the p2p link that went down is still reported. I am looking further > into the code now to try to ensure that the "downed" p2p link is removed before a > new LSA is sent. > > Regards, > Erlend > --- Bharadwaj Kalahasti wrote: > > > Erlend, > > Generally speaking, one set of implementations for non-broadcast neighbors such > > as > > those of P2MP, P2P and NBMA seems to be to configure the neighbors as 'STATIC' > > neighbors. > > For P2P Neighbors, the Hellos are multicast. The Intf state for the OSPF > > interface > > should be P2P after the IP interface comes up. And the Nbr state should finally > > be > > Full on the local end assuming that the Router ID of the neighbor is seen by the > > local router. > > > > These are the steps that should happen: > > -- So assuming that your neighbor has gone Down at the remote end for the reasons > > - > > Admin down, Link transmission failure but Link is still Up etc, then this should > > cause Inactivity Timer to be fired on the local end. > > -- Expiry of this timer should cause a new Router LSA to be generated and > > area-flooded but without the Neighbor's Router ID in its Neighbor list (since it > > failed to have bi-directional communication). > > -- Since the new Router-LSA would be different in its LS Header from the previous > > one for the same local router's Router ID, that should cause its installation on > > all > > of the area's routers and kick off a new SPF run once the installation of the > > Router-LSA in the LSDB is done. > > -- The SPF run should take care of deleting the P2P host route in the Routing > > Table. > > > > > > I think the implementation of a P2P Nbr is upto interpretation. The catch here > > is > > that a static configuration of the Nbr would mean that the Hello packet can always > > have the Neighbor router listed in it indicating bi-directional communication and > > full adjacency though the link may actually be down (if knowing the existence of a > > Neighbor implies including it in the sent Hello). The other way to interpret the > > RFC > > is that configuration is good enough to know its existence but its inclusion in > > the > > Hello is subject to event occurence on the link. > > > > I do not know the OSPFv2 code in XORP but if Static neighbors are not supported > > yet, then may be it is a good idea to support it. > > > > Regards, > > Kalahasti > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > > > > Hi all, > > > > > > > > It seems like XORP OSPFv2 does not fully manage to update the routing > > table > > > > when a neighbor connected through a p2p link goes down, e.g. when an > > xorp > > > > OSPFv2 neighbour is stopped. The neighbour state is set correctly to > > down, > > > > but the routes advertised by/through the neighbour are not removed from > > the > > > > rest of the network. The LS DB is identical before and after the > > neighbour > > > > has been stopped (only the age field differs, but is not set to MaxAge). > > > > > > > > I have tested this in a very simple scenario with 3 routers R1-R2-R3 up > > and > > > > running with p2p links configured over Ethernet. I have for example > > stopped > > > > ospf on R2 and then observed that R1 and R3 still have routes to each > > other. > > > > However, when the same routers run with Broadcast links the routes are > > > > correctly removed when one of the other routers goes down. > > > > > > > > I can see from the source code and debug output that the difference in > > > > handling of the InactivityTimer Event (i.e. Hello timeout) between > > Broadcast > > > > and p2p links seems to start in the method: > > Neighbour::tear_down_state; > > > > This method does not do any work for p2p (_peer.adjacency_change > > > > only works for DR or BDR). I therefore simply tried to add the call: > > > > _peer.get_area_router()->refresh_router_lsa() > > > > to the end Neighbour::tear_down_state. This causes a total recompute > > > > of the routing but the routes from/via the router that has been shut > > down are > > > > not removed. > > > > > > > > It may be that p2p links should have some kind of special static state, > > > > but to me, it does not seem sane that the links to/via a router that has > > > > gone down are not removed. The RFC 2178 is somewhat diffuse when > > > > it comes to p2p and Hello timeout. (It may seem somewhat strange > > > > to run p2p over Ethernet but this is a requirement.) > > > > > > > > Anyway I hope someone can give me some hints on how to work further in > > this. > > > > > > > > I can send debug logs and config setup if necessary. > > > > Thanks in advance! > > > > > > > > Regards, > > > > Erlend > > > > > > > > > ____________________________________________________________________________________ > > Luggage? GPS? Comic books? > > Check out fitting gifts for grads at Yahoo! Search > > http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz > > > > > > > ____________________________________________________________________________________ > Yahoo! oneSearch: Finally, mobile search > that gives answers, not web links. > http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From Erlend.Knutsen at applica.no Tue Aug 28 13:38:25 2007 From: Erlend.Knutsen at applica.no (Erlend Knutsen) Date: Tue, 28 Aug 2007 22:38:25 +0200 Subject: [Xorp-hackers] OSPFv2 P2P Links References: <524820.71499.qm@web54601.mail.re2.yahoo.com> Message-ID: Kalahasti, I probably will be able to test the code. I run 3 instances of OSPF over 3 vmware machines (debian Etch over windows VMWare player). I may also be able to extend the configuration with more machines and different topologies. However, I have never testet NBMA and P2MP before, but I guess I only need to make some small adjustments in the config.boot file. Regards, Erlend ________________________________ Fra: Bharadwaj Kalahasti [mailto:b_kalahasti at yahoo.com] Sendt: ti 28-aug-07 19:50 Til: Bharadwaj Kalahasti; xorp-hackers at icir.org; Erlend Knutsen Emne: Re: OSPFv2 P2P Links Erlend, You are right. The stub link should remain in the Router-LSA while the Type 1 link should be removed due to non-adjacency with the neighbor. I know of how the changes need to be done. May be you can review them. If I make the same changes for NBMA and P2MP, would you be able to test them for me? I have a single Ubuntu linux loaded DELL PC that does not help much but for a single router instance. Thanks, Kalahasti >>>>>>>>>>>> Thank you! This pretty much helped clearing up how OSPF p2p is supposed to work. To answer your question: XORP only seem to support p2p when configurig the neighbours statically, so YES! XORP supports static Neighbours. When running OSPF p2p over Ethernet the Router LSA (catched from tcpdump) reports a p2p link and a stub link to the Ethernet subnet between the routers. I can managed to multicast an LSA update as a result of the Hello inactivity timer for the p2p link. However the p2p link that went down is still reported. I am looking further into the code now to try to ensure that the "downed" p2p link is removed before a new LSA is sent. Regards, Erlend --- Bharadwaj Kalahasti wrote: > Erlend, > Generally speaking, one set of implementations for non-broadcast neighbors such > as > those of P2MP, P2P and NBMA seems to be to configure the neighbors as 'STATIC' > neighbors. > For P2P Neighbors, the Hellos are multicast. The Intf state for the OSPF > interface > should be P2P after the IP interface comes up. And the Nbr state should finally > be > Full on the local end assuming that the Router ID of the neighbor is seen by the > local router. > > These are the steps that should happen: > -- So assuming that your neighbor has gone Down at the remote end for the reasons > - > Admin down, Link transmission failure but Link is still Up etc, then this should > cause Inactivity Timer to be fired on the local end. > -- Expiry of this timer should cause a new Router LSA to be generated and > area-flooded but without the Neighbor's Router ID in its Neighbor list (since it > failed to have bi-directional communication). > -- Since the new Router-LSA would be different in its LS Header from the previous > one for the same local router's Router ID, that should cause its installation on > all > of the area's routers and kick off a new SPF run once the installation of the > Router-LSA in the LSDB is done. > -- The SPF run should take care of deleting the P2P host route in the Routing > Table. > > > I think the implementation of a P2P Nbr is upto interpretation. The catch here > is > that a static configuration of the Nbr would mean that the Hello packet can always > have the Neighbor router listed in it indicating bi-directional communication and > full adjacency though the link may actually be down (if knowing the existence of a > Neighbor implies including it in the sent Hello). The other way to interpret the > RFC > is that configuration is good enough to know its existence but its inclusion in > the > Hello is subject to event occurence on the link. > > I do not know the OSPFv2 code in XORP but if Static neighbors are not supported > yet, then may be it is a good idea to support it. > > Regards, > Kalahasti > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > Hi all, > > > > It seems like XORP OSPFv2 does not fully manage to update the routing > table > > when a neighbor connected through a p2p link goes down, e.g. when an > xorp > > OSPFv2 neighbour is stopped. The neighbour state is set correctly to > down, > > but the routes advertised by/through the neighbour are not removed from > the > > rest of the network. The LS DB is identical before and after the > neighbour > > has been stopped (only the age field differs, but is not set to MaxAge). > > > > I have tested this in a very simple scenario with 3 routers R1-R2-R3 up > and > > running with p2p links configured over Ethernet. I have for example > stopped > > ospf on R2 and then observed that R1 and R3 still have routes to each > other. > > However, when the same routers run with Broadcast links the routes are > > correctly removed when one of the other routers goes down. > > > > I can see from the source code and debug output that the difference in > > handling of the InactivityTimer Event (i.e. Hello timeout) between > Broadcast > > and p2p links seems to start in the method: > Neighbour::tear_down_state; > > This method does not do any work for p2p (_peer.adjacency_change > > only works for DR or BDR). I therefore simply tried to add the call: > > _peer.get_area_router()->refresh_router_lsa() > > to the end Neighbour::tear_down_state. This causes a total recompute > > of the routing but the routes from/via the router that has been shut > down are > > not removed. > > > > It may be that p2p links should have some kind of special static state, > > but to me, it does not seem sane that the links to/via a router that has > > gone down are not removed. The RFC 2178 is somewhat diffuse when > > it comes to p2p and Hello timeout. (It may seem somewhat strange > > to run p2p over Ethernet but this is a requirement.) > > > > Anyway I hope someone can give me some hints on how to work further in > this. > > > > I can send debug logs and config setup if necessary. > > Thanks in advance! > > > > Regards, > > Erlend > > > > ____________________________________________________________________________________ > Luggage? GPS? Comic books? > Check out fitting gifts for grads at Yahoo! Search > http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz > ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070828/c5d98b6a/attachment.html From pavlin at icir.org Tue Aug 28 17:14:55 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 28 Aug 2007 17:14:55 -0700 Subject: [Xorp-hackers] Generating the XRL interface In-Reply-To: Message from "Luca Giraudo" of "Tue, 28 Aug 2007 12:21:08 +0200." <33404c390708280321s106e3bfcqcd830e2be56bb469@mail.gmail.com> Message-ID: <200708290014.l7T0Et7A012852@possum.icir.org> Luca Giraudo wrote: > I am trying to writing a XORP process like Damien Leroy, but something > doesn't work. > > I am using the CVS version of XORP, and I have installed: > * autoconf 2.59 (from Fedora Core 6: which autoconf -> /usr/bin/autoconf) > * autoconf 2.61 (which autoconf261 -> /usr/local/bin/autoconf261) > * automake 1.9.6 (from FC6: which automake -> /usr/bin/automake) > * automake 1.10 (which automake110 -> /usr/local/bin/automake110) > * libtoolize 1.5.22 > > I don't modify the "bootstrap" because the variables (ACLOCAL, AUTOCONF, > ..., LIBTOOLIZE) are correct. > So, I run ./bootstrap, but the output is: > > ... > aclocal110 -I config > configure.in:39: error: Autoconf version 2.61 or higher is required > configure.in:39: the top level > autom4te: /usr/bin/m4 failed with exit status: 63 > aclocal110: autom4te failed with exit status: 63 > Error running 'aclocal110 -I config' > > I think that aclocal110 finds only the old version of autoconf, but I don't > know how to resolve this trouble. We have Fedora 7 installation and the default installation for autoconf (i.e., the installation for executable /usr/bin/autoconf) is 2.61 so we can't use that to reproduce your problem. If you just run "aclocal110 -I config" from the top XORP directory do you still get the same error? If you haven't solved the problem yet, can you try pointing /usr/bin/autoconf to autoconf261. This might not be the cleanest solution, but it appears that /usr/bin/autoconf is invoked in some indirect way (e.g., either via aclocal110 or some other program autotool-related program called by aclocal110). Regards, Pavlin From pavlin at icir.org Tue Aug 28 18:06:48 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 28 Aug 2007 18:06:48 -0700 Subject: [Xorp-hackers] Recursive next-hop lookup.. In-Reply-To: Message from Steffen Schumacher of "Thu, 23 Aug 2007 09:17:44 +0200." <20070823071744.GC66643@schumacher.dk> Message-ID: <200708290106.l7T16mTA013346@possum.icir.org> Steffen Schumacher wrote: > Hi! > > I read the status page, so that the feature in subject still isnt > implemented. (http://www.xorp.org/status.html) > > Or is it simply not working? Does anyone know if it will be working > by 1.5? > > Currently I've used quagga, but it seems that it also doesn't support > it. I'd really like it, because my ISP will only announce a default > candidate via bgp, vs. a default. The idea is that I configure a static > default directed at this Default candidate, and my default will then > move around when my eBGP peers go up/down. Could you please send an ASCII diagram with your topology and a little extra explanation, because we are finding it difficult to understand the issue you are facing. Atanu & Pavlin > If there is simply a bug in the code I'd like to have a look at it. > But implementing the feature might be a bit much, since this is not > a small task. > > Anyways - any status updates on the feature would be nice! From atanu at ICSI.Berkeley.EDU Tue Aug 28 19:29:47 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 28 Aug 2007 19:29:47 -0700 Subject: [Xorp-hackers] OSPFv2 P2P Links In-Reply-To: Message from "Erlend Knutsen" of "Tue, 28 Aug 2007 22:38:25 +0200." Message-ID: <31446.1188354587@tigger.icir.org> Hi, Adding a call to "update_router_links()" at the end of the method "Neighbour::tear_down_state()", should solve your problem, let me know. Atanu. >>>>> "Erlend" == Erlend Knutsen writes: Erlend> Kalahasti, Erlend> I probably will be able to test the code. Erlend> I run 3 instances of OSPF over 3 vmware machines (debian Etch Erlend> over windows VMWare player). Erlend> I may also be able to extend the configuration with more machines and Erlend> different topologies. Erlend> However, I have never testet NBMA and P2MP before, Erlend> but I guess I only need to make some small adjustments in the Erlend> config.boot file. Erlend> Regards, Erlend> Erlend Erlend> _________________________________________________________________ Erlend> Fra: Bharadwaj Kalahasti [mailto:b_kalahasti at yahoo.com] Erlend> Sendt: ti 28-aug-07 19:50 Erlend> Til: Bharadwaj Kalahasti; xorp-hackers at icir.org; Erlend Knutsen Erlend> Emne: Re: OSPFv2 P2P Links Erlend> Erlend, Erlend> You are right. The stub link should remain in the Router-LSA while Erlend> the Type 1 link Erlend> should be removed due to non-adjacency with the neighbor. Erlend> I know of how the changes need to be done. May be you can review Erlend> them. Erlend> If I make the same changes for NBMA and P2MP, would you be able to Erlend> test them for Erlend> me? I have a single Ubuntu linux loaded DELL PC that does not help Erlend> much but for a Erlend> single router instance. Erlend> Thanks, Erlend> Kalahasti >>>>>>>>>>>>> Erlend> Thank you! This pretty much helped clearing up how OSPF p2p is Erlend> supposed to work. Erlend> To answer your question: XORP only seem to support p2p when configurig Erlend> the Erlend> neighbours statically, so YES! XORP supports static Neighbours. Erlend> When running OSPF p2p over Ethernet the Router LSA (catched from Erlend> tcpdump) reports a Erlend> p2p link and a stub link to the Ethernet subnet between the routers. I Erlend> can managed Erlend> to multicast an LSA update as a result of the Hello inactivity timer Erlend> for the p2p Erlend> link. However the p2p link that went down is still reported. I am Erlend> looking further Erlend> into the code now to try to ensure that the "downed" p2p link is Erlend> removed before a Erlend> new LSA is sent. Erlend> Regards, Erlend> Erlend Erlend> --- Bharadwaj Kalahasti wrote: >> Erlend, >> Generally speaking, one set of implementations for non-broadcast Erlend> neighbors such >> as >> those of P2MP, P2P and NBMA seems to be to configure the neighbors Erlend> as 'STATIC' >> neighbors. >> For P2P Neighbors, the Hellos are multicast. The Intf state for Erlend> the OSPF >> interface >> should be P2P after the IP interface comes up. And the Nbr state Erlend> should finally >> be >> Full on the local end assuming that the Router ID of the neighbor is Erlend> seen by the >> local router. >> >> These are the steps that should happen: >> -- So assuming that your neighbor has gone Down at the remote end Erlend> for the reasons >> - >> Admin down, Link transmission failure but Link is still Up etc, then Erlend> this should >> cause Inactivity Timer to be fired on the local end. >> -- Expiry of this timer should cause a new Router LSA to be Erlend> generated and >> area-flooded but without the Neighbor's Router ID in its Neighbor Erlend> list (since it >> failed to have bi-directional communication). >> -- Since the new Router-LSA would be different in its LS Header from Erlend> the previous >> one for the same local router's Router ID, that should cause its Erlend> installation on >> all >> of the area's routers and kick off a new SPF run once the Erlend> installation of the >> Router-LSA in the LSDB is done. >> -- The SPF run should take care of deleting the P2P host route in Erlend> the Routing >> Table. >> >> >> I think the implementation of a P2P Nbr is upto interpretation. Erlend> The catch here >> is >> that a static configuration of the Nbr would mean that the Hello Erlend> packet can always >> have the Neighbor router listed in it indicating bi-directional Erlend> communication and >> full adjacency though the link may actually be down (if knowing the Erlend> existence of a >> Neighbor implies including it in the sent Hello). The other way to Erlend> interpret the >> RFC >> is that configuration is good enough to know its existence but its Erlend> inclusion in >> the >> Hello is subject to event occurence on the link. >> >> I do not know the OSPFv2 code in XORP but if Static neighbors are Erlend> not supported >> yet, then may be it is a good idea to support it. >> >> Regards, >> Kalahasti >> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >> >> Hi all, >> >> >> >> It seems like XORP OSPFv2 does not fully manage to update the Erlend> routing >> table >> >> when a neighbor connected through a p2p link goes down, e.g. when an >> xorp >> >> OSPFv2 neighbour is stopped. The neighbour state is set correctly to >> down, >> >> but the routes advertised by/through the neighbour are not removed Erlend> from >> the >> >> rest of the network. The LS DB is identical before and after the >> neighbour >> >> has been stopped (only the age field differs, but is not set to Erlend> MaxAge). >> >> >> >> I have tested this in a very simple scenario with 3 routers R1-R2-R3 Erlend> up >> and >> >> running with p2p links configured over Ethernet. I have for example >> stopped >> >> ospf on R2 and then observed that R1 and R3 still have routes to Erlend> each >> other. >> >> However, when the same routers run with Broadcast links the routes Erlend> are >> >> correctly removed when one of the other routers goes down. >> >> >> >> I can see from the source code and debug output that the difference Erlend> in >> >> handling of the InactivityTimer Event (i.e. Hello timeout) between >> Broadcast >> >> and p2p links seems to start in the method: >> Neighbour::tear_down_state; >> >> This method does not do any work for p2p (_peer.adjacency_change >> >> only works for DR or BDR). I therefore simply tried to add the call: >> >> _peer.get_area_router()->refresh_router_lsa() >> >> to the end Neighbour::tear_down_state. This causes a total Erlend> recompute >> >> of the routing but the routes from/via the router that has been shut >> down are >> >> not removed. >> >> >> >> It may be that p2p links should have some kind of special static Erlend> state, >> >> but to me, it does not seem sane that the links to/via a router that Erlend> has >> >> gone down are not removed. The RFC 2178 is somewhat diffuse when >> >> it comes to p2p and Hello timeout. (It may seem somewhat strange >> >> to run p2p over Ethernet but this is a requirement.) >> >> >> >> Anyway I hope someone can give me some hints on how to work further Erlend> in >> this. >> >> >> >> I can send debug logs and config setup if necessary. >> >> Thanks in advance! >> >> >> >> Regards, >> >> Erlend >> >> >> >> Erlend> ______________________________________________________________________ Erlend> ______________ >> Luggage? GPS? Comic books? >> Check out fitting gifts for grads at Yahoo! Search >> Erlend> http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz >> Erlend> ______________________________________________________________________ Erlend> ______________ Erlend> Yahoo! oneSearch: Finally, mobile search Erlend> that gives answers, not web links. Erlend> http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC Erlend> _______________________________________________ Erlend> Xorp-hackers mailing list Erlend> Xorp-hackers at icir.org Erlend> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian at spritelink.net Wed Aug 29 00:13:34 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Wed, 29 Aug 2007 09:13:34 +0200 Subject: [Xorp-hackers] Recursive next-hop lookup.. In-Reply-To: <200708290106.l7T16mTA013346@possum.icir.org> References: <200708290106.l7T16mTA013346@possum.icir.org> Message-ID: <46D51C9E.3090508@spritelink.net> Pavlin Radoslavov wrote: > Steffen Schumacher wrote: > >> Hi! >> >> I read the status page, so that the feature in subject still isnt >> implemented. (http://www.xorp.org/status.html) >> >> Or is it simply not working? Does anyone know if it will be working >> by 1.5? >> >> Currently I've used quagga, but it seems that it also doesn't support >> it. I'd really like it, because my ISP will only announce a default >> candidate via bgp, vs. a default. The idea is that I configure a static >> default directed at this Default candidate, and my default will then >> move around when my eBGP peers go up/down. > > Could you please send an ASCII diagram with your topology and a > little extra explanation, because we are finding it difficult to > understand the issue you are facing. The way I understand it.. One router on Steffans end with two connections, one to each ISP. (Hope my ASCII doesn't get mangled by this bloody email client). +-------+ +-------+ | ISP-A | | ISP-B | +-------+ +-------+ \ / +---------+ | Steffan | +---------+ The "normal" way of doing this, provided that Steffan can't take a full table, would be for ISP-A and ISP-B to announce a default route each. Another way, and this is the scenario at hand I believe, would be for ISP-[AB] to announce 1.3.3.7/32 (with the next-hop of ISP-[AB]'s router) and then you would point whatever route you want towards 1.3.3.7 which would be looked up recursively and resolve to ISP-[AB]'s next-hop. Or if ISP-[AB] would announce different "default candidates" then you could perform some crude load balancing towards the different "default candidates" of ISP-[AB]. Regards, Kristian. From steffen at schumacher.dk Wed Aug 29 01:01:44 2007 From: steffen at schumacher.dk (Steffen Schumacher) Date: Wed, 29 Aug 2007 10:01:44 +0200 Subject: [Xorp-hackers] Recursive next-hop lookup.. In-Reply-To: <46D51C9E.3090508@spritelink.net> References: <200708290106.l7T16mTA013346@possum.icir.org> <46D51C9E.3090508@spritelink.net> Message-ID: <20070829080144.GA74926@schumacher.dk> On 29.08.2007 09:13:34 +0200, Kristian Larsson wrote: > Pavlin Radoslavov wrote: > > Steffen Schumacher wrote: > > > >> Hi! > >> > >> I read the status page, so that the feature in subject still isnt > >> implemented. (http://www.xorp.org/status.html) > >> > >> Or is it simply not working? Does anyone know if it will be working > >> by 1.5? > >> > >> Currently I've used quagga, but it seems that it also doesn't support > >> it. I'd really like it, because my ISP will only announce a default > >> candidate via bgp, vs. a default. The idea is that I configure a static > >> default directed at this Default candidate, and my default will then > >> move around when my eBGP peers go up/down. > > > > Could you please send an ASCII diagram with your topology and a > > little extra explanation, because we are finding it difficult to > > understand the issue you are facing. > Actually its the same ISP.. so they anounce the same PE. I'll post a description.. > The way I understand it.. > One router on Steffans end with two connections, one to each ISP. (Hope > my ASCII doesn't get mangled by this bloody email client). > > +-------+ +-------+ > | ISP-A | | ISP-B | > +-------+ +-------+ > \ / > +---------+ > | Steffan | > +---------+ > > The "normal" way of doing this, provided that Steffan can't take a full > table, would be for ISP-A and ISP-B to announce a default route each. > Another way, and this is the scenario at hand I believe, would be for > ISP-[AB] to announce 1.3.3.7/32 (with the next-hop of ISP-[AB]'s router) > and then you would point whatever route you want towards 1.3.3.7 which > would be looked up recursively and resolve to ISP-[AB]'s next-hop. > Or if ISP-[AB] would announce different "default candidates" then you > could perform some crude load balancing towards the different "default > candidates" of ISP-[AB]. > > > Regards, > Kristian. > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From steffen at schumacher.dk Wed Aug 29 01:03:32 2007 From: steffen at schumacher.dk (Steffen Schumacher) Date: Wed, 29 Aug 2007 10:03:32 +0200 Subject: [Xorp-hackers] Recursive next-hop lookup.. In-Reply-To: <200708290106.l7T16mTA013346@possum.icir.org> References: <20070823071744.GC66643@schumacher.dk> <200708290106.l7T16mTA013346@possum.icir.org> Message-ID: <20070829080332.GB74926@schumacher.dk> On 28.08.2007 18:06:48 -0700, Pavlin Radoslavov wrote: > Steffen Schumacher wrote: > > > Hi! > > > > I read the status page, so that the feature in subject still isnt > > implemented. (http://www.xorp.org/status.html) > > > > Or is it simply not working? Does anyone know if it will be working > > by 1.5? > > > > Currently I've used quagga, but it seems that it also doesn't support > > it. I'd really like it, because my ISP will only announce a default > > candidate via bgp, vs. a default. The idea is that I configure a static > > default directed at this Default candidate, and my default will then > > move around when my eBGP peers go up/down. > > Could you please send an ASCII diagram with your topology and a > little extra explanation, because we are finding it difficult to > understand the issue you are facing. > > Atanu & Pavlin > I'm connected to the same ISP via two xDSL lines, and want automatic failover when one goes down. PE1 (Cisco) ----xDSL (Bridged Ethernet) ---- CPE1(quagga/xorp) |GigE PE2 (Juniper) --xDSL (Bridged Ethernet) ---- CPE2(quagga/xorp) The provider insists on providing what they call a default candidate: a single prefix. which is used as next-hop for the default. The lines are small, so full table is not a viable option, and its not supported on one of the PEs. Juniper must have a default route in their table in order to inject it, and it doesn't which is I guess is why they use this default candidate scheme. The idea is to create a default route with a next-hop within the provider announced prefix. The CPE should then update the next-hop info (interface, L2 address) according to that of the provider anounced prefix. This (I guess) requires a recursive lookup. When the PE1 line goes down, the two CPEs will reach the default candidate via PE2 and vice versa. The static default should then have the next-hop info updated, if PE1 was prefered before. I don't know if that is descriptive enough, if not please let me know. /Steffen > > If there is simply a bug in the code I'd like to have a look at it. > > But implementing the feature might be a bit much, since this is not > > a small task. > > > > Anyways - any status updates on the feature would be nice! From Erlend.Knutsen at applica.no Wed Aug 29 01:43:50 2007 From: Erlend.Knutsen at applica.no (Erlend Knutsen) Date: Wed, 29 Aug 2007 10:43:50 +0200 Subject: [Xorp-hackers] OSPFv2 P2P Links References: <31446.1188354587@tigger.icir.org> Message-ID: Hi all, Added: "_peer.update_router_links()" to the end of the method "Neighbour::tear_down_state()" This seem to do the work for p2p!! The p2p link is now correclty deleted from the LSA update, while the stub is kept. When the neighbour comes up again the p2p links appear again in the LSA update. However we have only tested this once, with 3 routers and 1 router at the edge going down/up. Thanks Atanu! Erlend -----Original Message----- From: atanu at icir.org on behalf of Atanu Ghosh Sent: on 29-aug-07 04:29 To: Erlend Knutsen Cc: Bharadwaj Kalahasti; xorp-hackers at icir.org Subject: Re: [Xorp-hackers] OSPFv2 P2P Links Hi, Adding a call to "update_router_links()" at the end of the method "Neighbour::tear_down_state()", should solve your problem, let me know. Atanu. >>>>> "Erlend" == Erlend Knutsen writes: Erlend> Kalahasti, Erlend> I probably will be able to test the code. Erlend> I run 3 instances of OSPF over 3 vmware machines (debian Etch Erlend> over windows VMWare player). Erlend> I may also be able to extend the configuration with more machines and Erlend> different topologies. Erlend> However, I have never testet NBMA and P2MP before, Erlend> but I guess I only need to make some small adjustments in the Erlend> config.boot file. Erlend> Regards, Erlend> Erlend Erlend> _________________________________________________________________ Erlend> Fra: Bharadwaj Kalahasti [mailto:b_kalahasti at yahoo.com] Erlend> Sendt: ti 28-aug-07 19:50 Erlend> Til: Bharadwaj Kalahasti; xorp-hackers at icir.org; Erlend Knutsen Erlend> Emne: Re: OSPFv2 P2P Links Erlend> Erlend, Erlend> You are right. The stub link should remain in the Router-LSA while Erlend> the Type 1 link Erlend> should be removed due to non-adjacency with the neighbor. Erlend> I know of how the changes need to be done. May be you can review Erlend> them. Erlend> If I make the same changes for NBMA and P2MP, would you be able to Erlend> test them for Erlend> me? I have a single Ubuntu linux loaded DELL PC that does not help Erlend> much but for a Erlend> single router instance. Erlend> Thanks, Erlend> Kalahasti >>>>>>>>>>>>> Erlend> Thank you! This pretty much helped clearing up how OSPF p2p is Erlend> supposed to work. Erlend> To answer your question: XORP only seem to support p2p when configurig Erlend> the Erlend> neighbours statically, so YES! XORP supports static Neighbours. Erlend> When running OSPF p2p over Ethernet the Router LSA (catched from Erlend> tcpdump) reports a Erlend> p2p link and a stub link to the Ethernet subnet between the routers. I Erlend> can managed Erlend> to multicast an LSA update as a result of the Hello inactivity timer Erlend> for the p2p Erlend> link. However the p2p link that went down is still reported. I am Erlend> looking further Erlend> into the code now to try to ensure that the "downed" p2p link is Erlend> removed before a Erlend> new LSA is sent. Erlend> Regards, Erlend> Erlend Erlend> --- Bharadwaj Kalahasti wrote: >> Erlend, >> Generally speaking, one set of implementations for non-broadcast Erlend> neighbors such >> as >> those of P2MP, P2P and NBMA seems to be to configure the neighbors Erlend> as 'STATIC' >> neighbors. >> For P2P Neighbors, the Hellos are multicast. The Intf state for Erlend> the OSPF >> interface >> should be P2P after the IP interface comes up. And the Nbr state Erlend> should finally >> be >> Full on the local end assuming that the Router ID of the neighbor is Erlend> seen by the >> local router. >> >> These are the steps that should happen: >> -- So assuming that your neighbor has gone Down at the remote end Erlend> for the reasons >> - >> Admin down, Link transmission failure but Link is still Up etc, then Erlend> this should >> cause Inactivity Timer to be fired on the local end. >> -- Expiry of this timer should cause a new Router LSA to be Erlend> generated and >> area-flooded but without the Neighbor's Router ID in its Neighbor Erlend> list (since it >> failed to have bi-directional communication). >> -- Since the new Router-LSA would be different in its LS Header from Erlend> the previous >> one for the same local router's Router ID, that should cause its Erlend> installation on >> all >> of the area's routers and kick off a new SPF run once the Erlend> installation of the >> Router-LSA in the LSDB is done. >> -- The SPF run should take care of deleting the P2P host route in Erlend> the Routing >> Table. >> >> >> I think the implementation of a P2P Nbr is upto interpretation. Erlend> The catch here >> is >> that a static configuration of the Nbr would mean that the Hello Erlend> packet can always >> have the Neighbor router listed in it indicating bi-directional Erlend> communication and >> full adjacency though the link may actually be down (if knowing the Erlend> existence of a >> Neighbor implies including it in the sent Hello). The other way to Erlend> interpret the >> RFC >> is that configuration is good enough to know its existence but its Erlend> inclusion in >> the >> Hello is subject to event occurence on the link. >> >> I do not know the OSPFv2 code in XORP but if Static neighbors are Erlend> not supported >> yet, then may be it is a good idea to support it. >> >> Regards, >> Kalahasti >> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >> >> Hi all, >> >> >> >> It seems like XORP OSPFv2 does not fully manage to update the Erlend> routing >> table >> >> when a neighbor connected through a p2p link goes down, e.g. when an >> xorp >> >> OSPFv2 neighbour is stopped. The neighbour state is set correctly to >> down, >> >> but the routes advertised by/through the neighbour are not removed Erlend> from >> the >> >> rest of the network. The LS DB is identical before and after the >> neighbour >> >> has been stopped (only the age field differs, but is not set to Erlend> MaxAge). >> >> >> >> I have tested this in a very simple scenario with 3 routers R1-R2-R3 Erlend> up >> and >> >> running with p2p links configured over Ethernet. I have for example >> stopped >> >> ospf on R2 and then observed that R1 and R3 still have routes to Erlend> each >> other. >> >> However, when the same routers run with Broadcast links the routes Erlend> are >> >> correctly removed when one of the other routers goes down. >> >> >> >> I can see from the source code and debug output that the difference Erlend> in >> >> handling of the InactivityTimer Event (i.e. Hello timeout) between >> Broadcast >> >> and p2p links seems to start in the method: >> Neighbour::tear_down_state; >> >> This method does not do any work for p2p (_peer.adjacency_change >> >> only works for DR or BDR). I therefore simply tried to add the call: >> >> _peer.get_area_router()->refresh_router_lsa() >> >> to the end Neighbour::tear_down_state. This causes a total Erlend> recompute >> >> of the routing but the routes from/via the router that has been shut >> down are >> >> not removed. >> >> >> >> It may be that p2p links should have some kind of special static Erlend> state, >> >> but to me, it does not seem sane that the links to/via a router that Erlend> has >> >> gone down are not removed. The RFC 2178 is somewhat diffuse when >> >> it comes to p2p and Hello timeout. (It may seem somewhat strange >> >> to run p2p over Ethernet but this is a requirement.) >> >> >> >> Anyway I hope someone can give me some hints on how to work further Erlend> in >> this. >> >> >> >> I can send debug logs and config setup if necessary. >> >> Thanks in advance! >> >> >> >> Regards, >> >> Erlend >> >> >> >> Erlend> ______________________________________________________________________ Erlend> ______________ >> Luggage? GPS? Comic books? >> Check out fitting gifts for grads at Yahoo! Search >> Erlend> http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz >> Erlend> ______________________________________________________________________ Erlend> ______________ Erlend> Yahoo! oneSearch: Finally, mobile search Erlend> that gives answers, not web links. Erlend> http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC Erlend> _______________________________________________ Erlend> Xorp-hackers mailing list Erlend> Xorp-hackers at icir.org Erlend> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070829/2131d03d/attachment-0001.html From luca.giraudo at gmail.com Thu Aug 30 05:53:57 2007 From: luca.giraudo at gmail.com (Luca Giraudo) Date: Thu, 30 Aug 2007 14:53:57 +0200 Subject: [Xorp-hackers] Generating the XRL interface In-Reply-To: <200708290014.l7T0Et7A012852@possum.icir.org> References: <33404c390708280321s106e3bfcqcd830e2be56bb469@mail.gmail.com> <200708290014.l7T0Et7A012852@possum.icir.org> Message-ID: <33404c390708300553n6138f62eta3cbb029d9b72821@mail.gmail.com> I have installed Ubuntu 7.04 and now all works fine. Now the script (bootstrap) ends without errors and "make" generates the library for my xif interface. Thanks, Luca -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070830/b2c9c9dc/attachment.html