From bbb999 at zerodistance.fi Fri Feb 1 10:52:58 2008 From: bbb999 at zerodistance.fi (Arsi Antila) Date: Fri, 1 Feb 2008 20:52:58 +0200 Subject: [Xorp-users] Advertising same route from two BGP peers Message-ID: <20080201185258.GA28037@zerodistance.fi> XORP has two BGP peers, which both advertise route 14.14.14.0/24. If there is a simple policy rule in the XORP configuration, then both routes are marked 'Winner'. If there is no policy rule, only one of the routes is marked 'Winner'. Is this expected behaviour? When XORP is started with 'bgp1.boot' as parameter, 'show bgp routes detail' shows the following: > show bgp routes detail 14.14.14.0/24 From peer: 10.1.0.2 Route: Winner Origin: IGP AS Path: 1114 Nexthop: 10.1.0.2 Multiple Exit Discriminator: 0 14.14.14.0/24 From peer: 11.1.0.2 Route: Not Used Origin: IGP AS Path: 1112 Nexthop: 11.1.0.2 Multiple Exit Discriminator: 0 If XORP is started with 'bgp2.boot' as parameter, both routes are marked 'Winner'. In addition, if BGP peer 10.1.0.2 is restarted, XORP BGP process dies (this situation is similar, but simpler, to the situation described in my previous mail "BGP crash". > show bgp routes detail 14.14.14.0/24 From peer: 11.1.0.2 Route: Winner Origin: IGP AS Path: 1112 Nexthop: 11.1.0.2 Multiple Exit Discriminator: 0 14.14.14.0/24 From peer: 10.1.0.2 Route: Winner Origin: IGP AS Path: 1114 Nexthop: 10.1.0.2 Multiple Exit Discriminator: 0 -------- bgp1.boot ------------- interfaces { restore-original-config-on-shutdown: false interface eth1 { default-system-config } interface eth1.10 { default-system-config } interface eth1.11 { default-system-config } } protocols { bgp { bgp-id: 10.1.0.1 local-as: 1113 peer 10.1.0.2 { local-ip: 10.1.0.1 as: 1114 next-hop: 10.1.0.1 } peer 11.1.0.2 { local-ip: 11.1.0.1 as: 1112 next-hop: 11.1.0.1 } } } ------ bgp2.boot ---- interfaces { restore-original-config-on-shutdown: false interface eth1 { default-system-config } interface eth1.10 { default-system-config } interface eth1.11 { default-system-config } } policy { policy-statement bgp_export_policy { term a1 { from { protocol: "bgp" } then { accept } } } } protocols { bgp { export: "bgp_export_policy" bgp-id: 10.1.0.1 local-as: 1113 peer 10.1.0.2 { local-ip: 10.1.0.1 as: 1114 next-hop: 10.1.0.1 } peer 11.1.0.2 { local-ip: 11.1.0.1 as: 1112 next-hop: 11.1.0.1 } } } From expo01 at free.fr Tue Feb 5 05:51:11 2008 From: expo01 at free.fr (expo01 at free.fr) Date: Tue, 05 Feb 2008 14:51:11 +0100 Subject: [Xorp-users] IGMP and Multicast question Message-ID: <1202219471.47a869cf3b80b@imp.free.fr> Hi, We are trying to make the following work, as a test platform for now, but then it will be needed in a real case operation : mcast source-------Linux smcroute---------LinuxXORP-------mcast receiver ^ ^ ^ ^ | | | | 192.168.1.1 eth0 eth1 192.168.3.4 192.168.2.3 192.168.3.3 smcroute is present only in the case of the test platform, it will later be substituted with a Juniper router on which we will have no interaction possible. The MC source is sending MC data to 230.1.1.1 (for the test) This MC flow is seen on the Linux XORP router, interface eth0 (wireshark) The fact to start the MC receiving application triggers an IGMP report, seen on eth1 of the Linux XORP router. There is no routing of the MC flow from the input interface eth0 to the output interface eth1, on the Xorp router. Our understanding of what should occur is probably wrong, but we thought that the IGMP report received from the MC receiver should be enough for the XORP router to have the necessary information to be able to forward the stream received on eth0 to eth1. What is not correct in this assumption ? Thanks in advance for helping. Vincent xorp traces extract: [ 2008/02/05 11:01:53 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 192.168.1.1 dst = 230.1.1.1 [ 2008/02/05 11:02:03 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 192.168.1.1 dst = 230.1.1.1 [ 2008/02/05 11:02:04 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 192.168.3.3 to 224.0.0.1 [ 2008/02/05 11:02:04 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 192.168.3.3 to 224.0.0.1 on vif eth1 [ 2008/02/05 11:02:08 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.3.4 to 230.1.1.1 on vif eth1 [ 2008/02/05 11:02:08 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.3.4 to 224.0.0.251 on vif eth1 [ 2008/02/05 11:02:10 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.3.3 to 224.0.0.2 on vif eth1 [ 2008/02/05 11:02:11 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.3.3 to 224.0.0.22 on vif eth1 [ 2008/02/05 11:02:13 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 192.168.1.1 dst = 230.1.1.1 Xorp configuration file : /**** Interface list ****/ interfaces { interface eth0 { description: "" disable: false default-system-config } interface eth1 { description: "" disable: false default-system-config } } /**** Forwarding engine ****/ fea { unicast-forwarding4 { disable: false } unicast-forwarding6 { disable: false } } plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { disable: false } } traceoptions { flag all { disable: false } } } } /**** IGMP ****/ protocols { igmp { disable: false interface eth1 { vif eth1 { disable:false } } traceoptions { flag all { disable: false } } } } protocols { fib2mrib { disable: false } } From jfs at computer.org Tue Feb 5 06:52:58 2008 From: jfs at computer.org (Javier Fernandez-Sanguino) Date: Tue, 5 Feb 2008 15:52:58 +0100 Subject: [Xorp-users] IGMP and Multicast question In-Reply-To: <1202219471.47a869cf3b80b@imp.free.fr> References: <1202219471.47a869cf3b80b@imp.free.fr> Message-ID: 2008/2/5, expo01 at free.fr : > Hi, > > We are trying to make the following work, as a test platform for now, but then > it will be needed in a real case operation : > > mcast source-------Linux smcroute---------LinuxXORP-------mcast receiver > ^ ^ ^ ^ > | | | | > 192.168.1.1 eth0 eth1 192.168.3.4 > 192.168.2.3 192.168.3.3 Linux smcroute and LinuxXorp are different systems, right? Question: why don't you enable IGMP on the eth0 interface? I don't see how you can make this work, AFAIK Xorp cannot act as an IGMP proxy (RFC4605?) and if you are working with two routers you need to have PIM in both sides (i.e. in the Linux smcroute and LinuxXorp). Actually, you are not simulating properly the Juniper case by just adding a Linux system with smcroute. You need to have a PIM-enabled daemon in that side, to simulate multicast routing amongst routers. > Our understanding of what should occur is probably wrong, but we thought that > the IGMP report received from the MC receiver should be enough for the XORP > router to have the necessary information to be able to forward the stream > received on eth0 to eth1. What is not correct in this assumption ? No, from my limited understanding (I'm not a multicast guru, but hey) the Xorp router has to "find" which multicast routers are available (through PIM) and then, when it sees, the IGMP repo from a MC receiver on its side it will "subscribe" to the multicast group with its main multicast router. In your environment there is only one multicast router (i.e. Xorp) so it does not know who to contact to get the group 230.1.1.1 requested by the client. That being said, I'm not sure if it will work if you add eth0 to the IGMP definition, as smcroute will just forward (if properly configured) the multicast traffic from the server "as is". Did you try that? Regards Javier From expo01 at free.fr Tue Feb 5 08:31:54 2008 From: expo01 at free.fr (expo01 at free.fr) Date: Tue, 05 Feb 2008 17:31:54 +0100 Subject: [Xorp-users] IGMP and Multicast question In-Reply-To: References: <1202219471.47a869cf3b80b@imp.free.fr> Message-ID: <1202229114.47a88f7ad6432@imp.free.fr> Thanks for answering, see my comments below : Selon Javier Fernandez-Sanguino : > 2008/2/5, expo01 at free.fr : > > Hi, > > > > We are trying to make the following work, as a test platform for now, but > then > > it will be needed in a real case operation : > > > > mcast source-------Linux smcroute---------LinuxXORP-------mcast receiver > > ^ ^ ^ ^ > > | | | | > > 192.168.1.1 eth0 eth1 192.168.3.4 > > 192.168.2.3 192.168.3.3 > > Linux smcroute and LinuxXorp are different systems, right? Yes, indeed. We used smcroute only for the test, because it is quick to configure. > > Question: why don't you enable IGMP on the eth0 interface? In my understanding, activating an interface for igmp in Xorp means "listen for potential receivers on this interface". And I know we have receivers only on eth1. Am I wrong ? By the way, in a first configuration I in fact had configured eth0 for igmp also, with no difference in behaviour. > > I don't see how you can make this work, AFAIK Xorp cannot act as an > IGMP proxy (RFC4605?) and if you are working with two routers you need > to have PIM in both sides (i.e. in the Linux smcroute and LinuxXorp). > > Actually, you are not simulating properly the Juniper case by just > adding a Linux system with smcroute. You need to have a PIM-enabled > daemon in that side, to simulate multicast routing amongst routers. See below my comments about a "two PIM routers" configuration. > > Our understanding of what should occur is probably wrong, but we thought > that > > the IGMP report received from the MC receiver should be enough for the XORP > > router to have the necessary information to be able to forward the stream > > received on eth0 to eth1. What is not correct in this assumption ? > > No, from my limited understanding (I'm not a multicast guru, but hey) > the Xorp router has to "find" which multicast routers are available > (through PIM) and then, when it sees, the IGMP repo from a MC receiver > on its side it will "subscribe" to the multicast group with its main > multicast router. In your environment there is only one multicast > router (i.e. Xorp) so it does not know who to contact to get the group > 230.1.1.1 requested by the client. > > That being said, I'm not sure if it will work if you add eth0 to the > IGMP definition, as smcroute will just forward (if properly > configured) the multicast traffic from the server "as is". Did you try > that? Yes, we tried and saw no difference. We also tried to have a Xorp Pim daemon running instead of smcroute, and it did work, the receiver had the MC flow directed to him (it ?), but in the real world case, there will not be a PIM router on the Juniper (AFAIK as of today). Regards Vincent From pavlin at ICSI.Berkeley.EDU Tue Feb 5 10:07:39 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 05 Feb 2008 10:07:39 -0800 Subject: [Xorp-users] IGMP and Multicast question In-Reply-To: <1202229114.47a88f7ad6432@imp.free.fr> References: <1202219471.47a869cf3b80b@imp.free.fr> <1202229114.47a88f7ad6432@imp.free.fr> Message-ID: <200802051807.m15I7dMB017997@fruitcake.ICSI.Berkeley.EDU> > > > We are trying to make the following work, as a test platform for now, but > > then > > > it will be needed in a real case operation : > > > > > > mcast source-------Linux smcroute---------LinuxXORP-------mcast receiver > > > ^ ^ ^ ^ > > > | | | | > > > 192.168.1.1 eth0 eth1 192.168.3.4 > > > 192.168.2.3 192.168.3.3 > > > > Linux smcroute and LinuxXorp are different systems, right? > Yes, indeed. We used smcroute only for the test, because it is quick to > configure. > > > > Question: why don't you enable IGMP on the eth0 interface? > In my understanding, activating an interface for igmp in Xorp means "listen for > potential receivers on this interface". And I know we have receivers only on > eth1. Am I wrong ? By the way, in a first configuration I in fact had configured > eth0 for igmp also, with no difference in behaviour. > > > > I don't see how you can make this work, AFAIK Xorp cannot act as an > > IGMP proxy (RFC4605?) and if you are working with two routers you need > > to have PIM in both sides (i.e. in the Linux smcroute and LinuxXorp). > > > > Actually, you are not simulating properly the Juniper case by just > > adding a Linux system with smcroute. You need to have a PIM-enabled > > daemon in that side, to simulate multicast routing amongst routers. > See below my comments about a "two PIM routers" configuration. > > > > Our understanding of what should occur is probably wrong, but we thought > > that > > > the IGMP report received from the MC receiver should be enough for the XORP > > > router to have the necessary information to be able to forward the stream > > > received on eth0 to eth1. What is not correct in this assumption ? > > > > No, from my limited understanding (I'm not a multicast guru, but hey) > > the Xorp router has to "find" which multicast routers are available > > (through PIM) and then, when it sees, the IGMP repo from a MC receiver > > on its side it will "subscribe" to the multicast group with its main > > multicast router. In your environment there is only one multicast > > router (i.e. Xorp) so it does not know who to contact to get the group > > 230.1.1.1 requested by the client. > > > > That being said, I'm not sure if it will work if you add eth0 to the > > IGMP definition, as smcroute will just forward (if properly > > configured) the multicast traffic from the server "as is". Did you try > > that? > Yes, we tried and saw no difference. We also tried to have a Xorp Pim daemon > running instead of smcroute, and it did work, the receiver had the MC flow > directed to him (it ?), but in the real world case, there will not be a PIM > router on the Juniper (AFAIK as of today). Juniper has PIM-SM so is there any reason not to configure/use it? If Juniper won't be running PIM how are you going to get that box forward the multicast traffic? Are you planning to have it running IGMP proxy? If this is the case then XORP needs to run PIM-SM with little special configuration. I can provide that info to you once I know what are you going to do on the Juniper side. Regards, Pavlin From expo01 at free.fr Tue Feb 5 12:44:16 2008 From: expo01 at free.fr (admin galerie) Date: Tue, 5 Feb 2008 21:44:16 +0100 Subject: [Xorp-users] IGMP and Multicast question In-Reply-To: <200802051807.m15I7dMB017997@fruitcake.ICSI.Berkeley.EDU> References: <1202219471.47a869cf3b80b@imp.free.fr> <1202229114.47a88f7ad6432@imp.free.fr> <200802051807.m15I7dMB017997@fruitcake.ICSI.Berkeley.EDU> Message-ID: Le 5 f?vr. 08, ? 19:07, Pavlin Radoslavov a ?crit : >>>> We are trying to make the following work, as a test platform for >>>> now, but >>> then >>>> it will be needed in a real case operation : >>>> >>>> mcast source-------Linux smcroute---------LinuxXORP-------mcast >>>> receiver >>>> ^ ^ ^ ^ >>>> | | | | >>>> 192.168.1.1 eth0 eth1 192.168.3.4 >>>> 192.168.2.3 192.168.3.3 >>> >>> Linux smcroute and LinuxXorp are different systems, right? >> Yes, indeed. We used smcroute only for the test, because it is quick >> to >> configure. >>> >>> Question: why don't you enable IGMP on the eth0 interface? >> In my understanding, activating an interface for igmp in Xorp means >> "listen for >> potential receivers on this interface". And I know we have receivers >> only on >> eth1. Am I wrong ? By the way, in a first configuration I in fact had >> configured >> eth0 for igmp also, with no difference in behaviour. >>> >>> I don't see how you can make this work, AFAIK Xorp cannot act as an >>> IGMP proxy (RFC4605?) and if you are working with two routers you >>> need >>> to have PIM in both sides (i.e. in the Linux smcroute and LinuxXorp). >>> >>> Actually, you are not simulating properly the Juniper case by just >>> adding a Linux system with smcroute. You need to have a PIM-enabled >>> daemon in that side, to simulate multicast routing amongst routers. >> See below my comments about a "two PIM routers" configuration. >> >>>> Our understanding of what should occur is probably wrong, but we >>>> thought >>> that >>>> the IGMP report received from the MC receiver should be enough for >>>> the XORP >>>> router to have the necessary information to be able to forward the >>>> stream >>>> received on eth0 to eth1. What is not correct in this assumption ? >>> >>> No, from my limited understanding (I'm not a multicast guru, but hey) >>> the Xorp router has to "find" which multicast routers are available >>> (through PIM) and then, when it sees, the IGMP repo from a MC >>> receiver >>> on its side it will "subscribe" to the multicast group with its main >>> multicast router. In your environment there is only one multicast >>> router (i.e. Xorp) so it does not know who to contact to get the >>> group >>> 230.1.1.1 requested by the client. >>> >>> That being said, I'm not sure if it will work if you add eth0 to the >>> IGMP definition, as smcroute will just forward (if properly >>> configured) the multicast traffic from the server "as is". Did you >>> try >>> that? >> Yes, we tried and saw no difference. We also tried to have a Xorp Pim >> daemon >> running instead of smcroute, and it did work, the receiver had the >> MC flow >> directed to him (it ?), but in the real world case, there will not be >> a PIM >> router on the Juniper (AFAIK as of today). > > Juniper has PIM-SM so is there any reason not to configure/use it? > If Juniper won't be running PIM how are you going to get that box > forward the multicast traffic? Are you planning to have it running > IGMP proxy? > If this is the case then XORP needs to run PIM-SM with little > special configuration. I can provide that info to you once I > know what are you going to do on the Juniper side. > The Juniper side is not our responsibility, so we can't make choices for the people who are going to configure it. Between the Juniper and our Xorp router, there is a satellite network, and cypher/decypher devices, where it is necessary to configure security associations for each flow you intend to transmit (unicast and multicast). That is the main reason why we try not to have PIM signalling between the Juniper and us. I asked the person in charge of the Juniper how it was going to forward the multicast traffic, and he answered there was a simple static configuration, the kind "all MC traffic from interface A shall be directed to interface B". Does it make sense ? To resolve my problem, which seems to be a RFC4605 (thanks Javier) test case, couldn't I start two instances of Xorp on my Xorp router ? Thanks again for helping me (I confess I'm kind of a newbie in routing magic...) best regards, Vincent From pavlin at ICSI.Berkeley.EDU Tue Feb 5 20:29:34 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 05 Feb 2008 20:29:34 -0800 Subject: [Xorp-users] IGMP and Multicast question In-Reply-To: References: <1202219471.47a869cf3b80b@imp.free.fr> <1202229114.47a88f7ad6432@imp.free.fr> <200802051807.m15I7dMB017997@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200802060429.m164TYSu029307@fruitcake.ICSI.Berkeley.EDU> > > Juniper has PIM-SM so is there any reason not to configure/use it? > > If Juniper won't be running PIM how are you going to get that box > > forward the multicast traffic? Are you planning to have it running > > IGMP proxy? > > If this is the case then XORP needs to run PIM-SM with little > > special configuration. I can provide that info to you once I > > know what are you going to do on the Juniper side. > > > The Juniper side is not our responsibility, so we can't make choices > for the people who are going to configure it. Between the Juniper and > our Xorp router, there is a satellite network, and cypher/decypher > devices, where it is necessary to configure security associations for > each flow you intend to transmit (unicast and multicast). That is the > main reason why we try not to have PIM signalling between the Juniper > and us. I asked the person in charge of the Juniper how it was going to > forward the multicast traffic, and he answered there was a simple > static configuration, the kind "all MC traffic from interface A shall > be directed to interface B". Does it make sense ? > > To resolve my problem, which seems to be a RFC4605 (thanks Javier) test > case, couldn't I start two instances of Xorp on my Xorp router ? The simple answer is no. However, if Juniper forwards all multicast traffic to you, there is a way to get it working: 1. Configure PIM-SM on XORP and configure one of its interfaces as a static RP for the whole 224.0.0.0/4 multicast address range. 2. Use the "alternative-subnet" configuration statement(s) for the interface/vif on the XORP box toward the Juniper. For example, "alternative subnet 10.0.0.0/8" will tell XORP to consider all multicast traffic from source address in the 10.0.0.0/8 range appear like coming from a directly connected subnet, and typically traffic from directly connected subnets will be forwarded if there are downstream receivers. You might need to use more than one such statement to cover all possible sender addresses. Regards, Pavlin From expo01 at free.fr Wed Feb 6 14:31:25 2008 From: expo01 at free.fr (admin galerie) Date: Wed, 6 Feb 2008 23:31:25 +0100 Subject: [Xorp-users] IGMP and Multicast question In-Reply-To: <200802060429.m164TYSu029307@fruitcake.ICSI.Berkeley.EDU> References: <1202219471.47a869cf3b80b@imp.free.fr> <1202229114.47a88f7ad6432@imp.free.fr> <200802051807.m15I7dMB017997@fruitcake.ICSI.Berkeley.EDU> <200802060429.m164TYSu029307@fruitcake.ICSI.Berkeley.EDU> Message-ID: Le 6 f?vr. 08, ? 05:29, Pavlin Radoslavov a ?crit : >>> Juniper has PIM-SM so is there any reason not to configure/use it? >>> If Juniper won't be running PIM how are you going to get that box >>> forward the multicast traffic? Are you planning to have it running >>> IGMP proxy? >>> If this is the case then XORP needs to run PIM-SM with little >>> special configuration. I can provide that info to you once I >>> know what are you going to do on the Juniper side. >>> >> The Juniper side is not our responsibility, so we can't make choices >> for the people who are going to configure it. Between the Juniper and >> our Xorp router, there is a satellite network, and cypher/decypher >> devices, where it is necessary to configure security associations for >> each flow you intend to transmit (unicast and multicast). That is the >> main reason why we try not to have PIM signalling between the Juniper >> and us. I asked the person in charge of the Juniper how it was going >> to >> forward the multicast traffic, and he answered there was a simple >> static configuration, the kind "all MC traffic from interface A shall >> be directed to interface B". Does it make sense ? >> >> To resolve my problem, which seems to be a RFC4605 (thanks Javier) >> test >> case, couldn't I start two instances of Xorp on my Xorp router ? > > The simple answer is no. > > However, if Juniper forwards all multicast traffic to you, there is > a way to get it working: > > 1. Configure PIM-SM on XORP and configure one of its interfaces as a > static RP for the whole 224.0.0.0/4 multicast address range. > > 2. Use the "alternative-subnet" configuration statement(s) for the > interface/vif on the XORP box toward the Juniper. > For example, "alternative subnet 10.0.0.0/8" will tell XORP to > consider all multicast traffic from source address in the > 10.0.0.0/8 range appear like coming from a directly connected > subnet, and typically traffic from directly connected subnets > will be forwarded if there are downstream receivers. > You might need to use more than one such statement to cover all > possible sender addresses. Thanks for your help Pavlin, I did not have time to test today your configuration proposition, but I will try it tomorrow and will let you know if it does what I need. Best regards Vincent From Florian.Thiessenhusen at admeritia.de Sat Feb 9 11:12:09 2008 From: Florian.Thiessenhusen at admeritia.de (Florian Thiessenhusen) Date: Sat, 9 Feb 2008 20:12:09 +0100 Subject: [Xorp-users] Question concerning Unicast Routing Message-ID: Hi, i am a newbie at xorp. I have a really simple question i think. I want to implement xorp in a simple network only with static routes. My config.boot looks like that: ------------- interfaces { restore-original-config-on-shutdown: false interface lo { description: "Ethernet Interface #1" disable: false default-system-config } interface eth1 { description: "Ethernet Interface #2" disable: false default-system-config } } fea { unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } ------------- In this configuration all works fine in my testscenario. But when i disable "Unicast-forwarding", no more route is populatet (logical). When i try to add static routes in cli, these also are note populatet to the clients... Where is the failure, the user manual doesnt help :( Thanks, Florian From ahmadyudo at yahoo.com Sat Feb 9 18:47:50 2008 From: ahmadyudo at yahoo.com (oduy ahmad) Date: Sat, 9 Feb 2008 18:47:50 -0800 (PST) Subject: [Xorp-users] compiling xorp on FreeBSD 6.3 error Message-ID: <362298.62014.qm@web62001.mail.re1.yahoo.com> i am trying to compile xorp from cvs repository on my FreeBSD 6.3 while compiling i found an error message g++ -DHAVE_CONFIG_H -I. -I.. -I.. -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -MT task.lo -MD -MP -MF .deps/task.Tpo -c task.cc -o task.o In file included from callback.hh:27, from task.hh:24, from task.cc:22: callback_nodebug.hh:3225: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gmake[3]: *** [task.lo] Error 1 gmake[3]: Leaving directory `/usr/home/bogank/xorp/libxorp' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/home/bogank/xorp/libxorp' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/home/bogank/xorp' gmake: *** [all] Error 2 can anybody help me what its mean ?? thanx ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From andreas.voellmy at gmail.com Sun Feb 10 16:03:37 2008 From: andreas.voellmy at gmail.com (Andreas Voellmy) Date: Sun, 10 Feb 2008 19:03:37 -0500 Subject: [Xorp-users] Fwd: from and to blocks of policy terms In-Reply-To: <6d3800770802061125h32c4f259s94107f31cbc623d9@mail.gmail.com> References: <6d3800770802061125h32c4f259s94107f31cbc623d9@mail.gmail.com> Message-ID: <6d3800770802101603j4834facal43c3fd948ad3a321@mail.gmail.com> Hi all, I originally posted my message (see below) to the xorp-hackers list, but I think it might be more appropriate on this list, so I am sending it here also. -Andreas ---------- Forwarded message ---------- From: Andreas Voellmy Date: Feb 6, 2008 2:25 PM Subject: from and to blocks of policy terms To: Xorp-hackers at icir.org Hi, I've read the XORP user manual and Bittau & Handley's paper on "Decoupling Policy from Protocols" and I am still a bit confused as to how the policy terms work. I understand that policies that do route redistribution, like "from {protocol:rip} to {neighbor: 192.168.1.2} then {accept}" make sense as an export policy, but it's not clear to me why a policy term has both from and to blocks when it is not doing route redistribution. For example, take the following policy term: from {} to {neighbor: 192.168.1.2} then {accept} As an export policy I understand that it would advertise all routes to neighbor 192.168.1.2. However, if it were an IMPORT policy, what would it mean? More generally, what do any conditions in the to block mean in an import policy? Similarly, what does "from {neighbor: 192.168.1.2} to {} then {accept}" mean as an export policy? What does any condition in the from block of an export policy mean? Thanks! -Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080210/96ef8358/attachment.html From Florian.Thiessenhusen at admeritia.de Mon Feb 11 08:14:19 2008 From: Florian.Thiessenhusen at admeritia.de (Florian Thiessenhusen) Date: Mon, 11 Feb 2008 17:14:19 +0100 Subject: [Xorp-users] Question concerning Unicast Routing In-Reply-To: References: Message-ID: Problem solved. The problem was that the gateway on the router pointet to antoher Gateway. I think the best method is, let the router point to himself :) -----Urspr?ngliche Nachricht----- Von: Florian Thiessenhusen Gesendet: Samstag, 9. Februar 2008 20:12 An: xorp-users at xorp.org Betreff: Question concerning Unicast Routing Hi, i am a newbie at xorp. I have a really simple question i think. I want to implement xorp in a simple network only with static routes. My config.boot looks like that: ------------- interfaces { restore-original-config-on-shutdown: false interface lo { description: "Ethernet Interface #1" disable: false default-system-config } interface eth1 { description: "Ethernet Interface #2" disable: false default-system-config } } fea { unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } ------------- In this configuration all works fine in my testscenario. But when i disable "Unicast-forwarding", no more route is populatet (logical). When i try to add static routes in cli, these also are note populatet to the clients... Where is the failure, the user manual doesnt help :( Thanks, Florian From Florian.Thiessenhusen at admeritia.de Mon Feb 11 08:21:30 2008 From: Florian.Thiessenhusen at admeritia.de (Florian Thiessenhusen) Date: Mon, 11 Feb 2008 17:21:30 +0100 Subject: [Xorp-users] Qualified-Next-Hop Problem Message-ID: Hi, also at this point the user-manual is not detailed enough. I would like to know how the "Qualified-Next-Hop" mechanism works. I have a static route and in my testlab i have two Internet routers. When i disconnect the first router that is responsible for the 0.0.0.0/0 static route the "Qualified-Next-Hop" does not automatically switch to the alternative route (Next-Hop Gateway 192.168.15.12). Thanks for the help, Florian From pavlin at ICSI.Berkeley.EDU Mon Feb 11 10:56:44 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Mon, 11 Feb 2008 10:56:44 -0800 Subject: [Xorp-users] Qualified-Next-Hop Problem In-Reply-To: References: Message-ID: <200802111856.m1BIuitL003007@fruitcake.ICSI.Berkeley.EDU> > I would like to know how the "Qualified-Next-Hop" mechanism > works. I have a static route and in my testlab i have two Internet > routers. When i disconnect the first router that is responsible > for the 0.0.0.0/0 static route the "Qualified-Next-Hop" does not > automatically switch to the alternative route (Next-Hop Gateway > 192.168.15.12). The next-hop information for the primary and the qualified-next-hop should utilize different network interfaces. If the cable for the primary next-hop is disconnected, then the qualified-next-hop should take over. If it doesn't work, use the "show interfaces" xorpsh command: it should show "NO-CARRIER" for the disconnected interface. Note that the NO-CARRIER detection might take up to 1 minute or so for certain network interface cards. Use the "ip monitor" for Linux or "route -n monitor" for BSD to see when the cable disconnection event upcall is generated. Regards, Pavlin From pavlin at ICSI.Berkeley.EDU Mon Feb 11 11:19:30 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Mon, 11 Feb 2008 11:19:30 -0800 Subject: [Xorp-users] Fwd: from and to blocks of policy terms In-Reply-To: <6d3800770802101603j4834facal43c3fd948ad3a321@mail.gmail.com> References: <6d3800770802061125h32c4f259s94107f31cbc623d9@mail.gmail.com> <6d3800770802101603j4834facal43c3fd948ad3a321@mail.gmail.com> Message-ID: <200802111919.m1BJJUZY007068@fruitcake.ICSI.Berkeley.EDU> > I've read the XORP user manual and Bittau & Handley's paper on "Decoupling > Policy from Protocols" and I am still a bit confused as to how the policy > terms work. > > I understand that policies that do route redistribution, like "from > {protocol:rip} to {neighbor: 192.168.1.2} then {accept}" make sense as an > export policy, but it's not clear to me why a policy term has both from and > to blocks when it is not doing route redistribution. For example, take the > following policy term: > > from {} to {neighbor: 192.168.1.2} then {accept} > > As an export policy I understand that it would advertise all routes to > neighbor 192.168.1.2. However, if it were an IMPORT policy, what would it > mean? More generally, what do any conditions in the to block mean in an > import policy? > > Similarly, what does "from {neighbor: 192.168.1.2} to {} then {accept}" mean > as an export policy? What does any condition in the from block of an export > policy mean? A small piece of information that might be helpful for you: for export policy the "from" block must have the "protocol" set. I.e., you can't export routes if the protocol is not specified. Also, all the conditions in the "from" and "to" blocks must be matched for a term's "them" block to be evaluated. For example, "from {} to {neighbor: 192.168.1.2} then {accept}" can't be used as an export policy, but can be used as an import policy. As an import policy, when the routes reach the outbound evaluation, only the routes to neighbor 192.168.1.2 will be accepted (i.e., transmitted). Similarly, "from {neighbor: 192.168.1.2} to {} then {accept}" also cannot be used as an export policy. As an import policy it will accept only the routes coming from neighbor 192.168.1.2. Hope that helps, Pavlin From andreas.voellmy at gmail.com Mon Feb 11 13:09:12 2008 From: andreas.voellmy at gmail.com (Andreas Voellmy) Date: Mon, 11 Feb 2008 16:09:12 -0500 Subject: [Xorp-users] Fwd: from and to blocks of policy terms In-Reply-To: <200802111919.m1BJJUZY007068@fruitcake.ICSI.Berkeley.EDU> References: <6d3800770802061125h32c4f259s94107f31cbc623d9@mail.gmail.com> <6d3800770802101603j4834facal43c3fd948ad3a321@mail.gmail.com> <200802111919.m1BJJUZY007068@fruitcake.ICSI.Berkeley.EDU> Message-ID: <6d3800770802111309j79b003e9m7c1921a20ee5bafc@mail.gmail.com> Thanks Pavlin! A couple more questions below ... On Feb 11, 2008 2:19 PM, Pavlin Radoslavov wrote: > A small piece of information that might be helpful for you: for > export policy the "from" block must have the "protocol" set. I.e., > you can't export routes if the protocol is not specified. Is the "protocol" attribute required in the "from" clause in every export policy, or only in those which are redistributing routes from another protocol? > > For example, "from {} to {neighbor: 192.168.1.2} then {accept}" > can't be used as an export policy, but can be used as an import > policy. As an import policy, when the routes reach the outbound > evaluation, only the routes to neighbor 192.168.1.2 will be > accepted (i.e., transmitted). I am still a bit confused. Would it be a valid export policy if it had a protocol attribute in the from clause, i.e. if it was like this: "from {protocol: bgp} to {neighbor: 192.168.1.2} then {accept}"? If I understand you correctly, you are saying that if "from {} to {neighbor: 192.168.1.2} then {accept}" were an IMPORT policy, then it would be equivalent to the following EXPORT policy "from {protocol: bgp} to {neighbor: 192.168.1.2} then {accept}"? > > Similarly, "from {neighbor: 192.168.1.2} to {} then {accept}" also > cannot be used as an export policy. As an import policy it will > accept only the routes coming from neighbor 192.168.1.2. > Again, would it be a valid export policy if it were modified to "from {protocol: bgp; neighbor: 192.168.1.2} to {} then {accept}"? -Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080211/17003893/attachment.html From pavlin at ICSI.Berkeley.EDU Mon Feb 11 21:35:22 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Mon, 11 Feb 2008 21:35:22 -0800 Subject: [Xorp-users] Fwd: from and to blocks of policy terms In-Reply-To: <6d3800770802111309j79b003e9m7c1921a20ee5bafc@mail.gmail.com> References: <6d3800770802061125h32c4f259s94107f31cbc623d9@mail.gmail.com> <6d3800770802101603j4834facal43c3fd948ad3a321@mail.gmail.com> <200802111919.m1BJJUZY007068@fruitcake.ICSI.Berkeley.EDU> <6d3800770802111309j79b003e9m7c1921a20ee5bafc@mail.gmail.com> Message-ID: <200802120535.m1C5ZMFI014730@fruitcake.ICSI.Berkeley.EDU> > > A small piece of information that might be helpful for you: for > > export policy the "from" block must have the "protocol" set. I.e., > > you can't export routes if the protocol is not specified. > > > Is the "protocol" attribute required in the "from" clause in every export > policy, or only in those which are redistributing routes from another > protocol? It should be in all export policy. In the special case where you are using an export policy inside BGP itself, and it should be applied to the BGP routes that come from a BGP neighbor, then the "protocol" attribute in the "from" clause should be set to "bgp". Note that this was a relatively recent change to the XORP code itself so it might not be in the original policy framework documentation (or the policy paper itself). > > For example, "from {} to {neighbor: 192.168.1.2} then {accept}" > > can't be used as an export policy, but can be used as an import > > policy. As an import policy, when the routes reach the outbound > > evaluation, only the routes to neighbor 192.168.1.2 will be > > accepted (i.e., transmitted). > > > I am still a bit confused. Would it be a valid export policy if it had a > protocol attribute in the from clause, i.e. if it was like this: "from > {protocol: bgp} to {neighbor: 192.168.1.2} then {accept}"? Yes. See above. > If I understand you correctly, you are saying that if "from {} to {neighbor: > 192.168.1.2} then {accept}" were an IMPORT policy, then it would be > equivalent to the following EXPORT policy "from {protocol: bgp} to > {neighbor: 192.168.1.2} then {accept}"? I believe the answer is yes. However, I should also say that it has been a while since I looked into the policy framework details so I could be wrong. > > Similarly, "from {neighbor: 192.168.1.2} to {} then {accept}" also > > cannot be used as an export policy. As an import policy it will > > accept only the routes coming from neighbor 192.168.1.2. > > > > Again, would it be a valid export policy if it were modified to "from > {protocol: bgp; neighbor: 192.168.1.2} to {} then {accept}"? Yes (with the same disclamer as above). Regards, Pavlin From Florian.Thiessenhusen at admeritia.de Tue Feb 12 00:31:09 2008 From: Florian.Thiessenhusen at admeritia.de (Florian Thiessenhusen) Date: Tue, 12 Feb 2008 09:31:09 +0100 Subject: [Xorp-users] Qualified-Next-Hop Problem In-Reply-To: <200802111856.m1BIuitL003007@fruitcake.ICSI.Berkeley.EDU> References: , <200802111856.m1BIuitL003007@fruitcake.ICSI.Berkeley.EDU> Message-ID: Hi Pvlin, thank for your fast help! In my case, i have only one physical NIC where the two Gateways are connected (via switch). And the same NIC is used for requests vom clients. Should i combine are Ping-Probe Cron to detect, if a Gateway is down and let the cron job reconfigure the static-route config? Thanks, Florian ________________________________________ Von: Pavlin Radoslavov [pavlin at ICSI.Berkeley.EDU] Gesendet: Montag, 11. Februar 2008 19:56 An: Florian Thiessenhusen Cc: xorp-users at xorp.org Betreff: Re: [Xorp-users] Qualified-Next-Hop Problem > I would like to know how the "Qualified-Next-Hop" mechanism > works. I have a static route and in my testlab i have two Internet > routers. When i disconnect the first router that is responsible > for the 0.0.0.0/0 static route the "Qualified-Next-Hop" does not > automatically switch to the alternative route (Next-Hop Gateway > 192.168.15.12). The next-hop information for the primary and the qualified-next-hop should utilize different network interfaces. If the cable for the primary next-hop is disconnected, then the qualified-next-hop should take over. If it doesn't work, use the "show interfaces" xorpsh command: it should show "NO-CARRIER" for the disconnected interface. Note that the NO-CARRIER detection might take up to 1 minute or so for certain network interface cards. Use the "ip monitor" for Linux or "route -n monitor" for BSD to see when the cable disconnection event upcall is generated. Regards, Pavlin From pavlin at ICSI.Berkeley.EDU Tue Feb 12 00:57:45 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 12 Feb 2008 00:57:45 -0800 Subject: [Xorp-users] Qualified-Next-Hop Problem In-Reply-To: References: , <200802111856.m1BIuitL003007@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200802120857.m1C8vjso015282@fruitcake.ICSI.Berkeley.EDU> Florian Thiessenhusen wrote: > Hi Pvlin, > > thank for your fast help! > > In my case, i have only one physical NIC where the two Gateways are connected (via switch). And the same NIC is used for requests vom clients. Should i combine are Ping-Probe Cron to detect, if a Gateway is down and let the cron job reconfigure the static-route config? With a single NIC you can't use qualified-next-hop for its intended purpose. In that case you might want to use something like what you suggest above: have a periodic ping probe, and if the ping fails use xorpsh in script mode to reconfigure the static route. Regards, Pavlin > > Thanks, > Florian > > ________________________________________ > Von: Pavlin Radoslavov [pavlin at ICSI.Berkeley.EDU] > Gesendet: Montag, 11. Februar 2008 19:56 > An: Florian Thiessenhusen > Cc: xorp-users at xorp.org > Betreff: Re: [Xorp-users] Qualified-Next-Hop Problem > > > I would like to know how the "Qualified-Next-Hop" mechanism > > works. I have a static route and in my testlab i have two Internet > > routers. When i disconnect the first router that is responsible > > for the 0.0.0.0/0 static route the "Qualified-Next-Hop" does not > > automatically switch to the alternative route (Next-Hop Gateway > > 192.168.15.12). > > The next-hop information for the primary and the qualified-next-hop > should utilize different network interfaces. > If the cable for the primary next-hop is disconnected, then the > qualified-next-hop should take over. > If it doesn't work, use the "show interfaces" xorpsh command: it > should show "NO-CARRIER" for the disconnected interface. > > Note that the NO-CARRIER detection might take up to 1 minute or so > for certain network interface cards. > Use the "ip monitor" for Linux or "route -n monitor" for BSD to see > when the cable disconnection event upcall is generated. > > Regards, > Pavlin > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From atanu at ICSI.Berkeley.EDU Tue Feb 12 12:08:16 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 12 Feb 2008 12:08:16 -0800 Subject: [Xorp-users] compiling xorp on FreeBSD 6.3 error In-Reply-To: Message from oduy ahmad of "Sat, 09 Feb 2008 18:47:50 PST." <362298.62014.qm@web62001.mail.re1.yahoo.com> Message-ID: <76814.1202846896@tigger.icir.org> Hi, Looks like you have triggered a compiler problem. We have no problems compiling XORP on FreeBSD 6.3 with "gcc version 3.4.6 [FreeBSD] 20060305" (the output of gcc -v). What happens if you try the compilation again? Atanu. >>>>> "oduy" == oduy ahmad writes: oduy> i am trying to compile xorp from cvs repository on my oduy> FreeBSD 6.3 oduy> while compiling i found an error message oduy> g++ -DHAVE_CONFIG_H -I. -I.. -I.. -g -Werror -W -Wall oduy> -Wwrite-strings -Wcast-qual -Wpointer-arith oduy> -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 oduy> -pipe -MT task.lo -MD -MP -MF .deps/task.Tpo -c oduy> task.cc -o task.o oduy> In file included from callback.hh:27, oduy> from task.hh:24, oduy> from task.cc:22: oduy> callback_nodebug.hh:3225: internal compiler error: oduy> Segmentation fault: 11 oduy> Please submit a full bug report, oduy> with preprocessed source if appropriate. oduy> See for oduy> instructions. oduy> gmake[3]: *** [task.lo] Error 1 oduy> gmake[3]: Leaving directory oduy> `/usr/home/bogank/xorp/libxorp' oduy> gmake[2]: *** [all] Error 2 oduy> gmake[2]: Leaving directory oduy> `/usr/home/bogank/xorp/libxorp' oduy> gmake[1]: *** [all-recursive] Error 1 oduy> gmake[1]: Leaving directory `/usr/home/bogank/xorp' oduy> gmake: *** [all] Error 2 oduy> can anybody help me what its mean ?? oduy> thanx oduy> ____________________________________________________________________________________ oduy> Be a better friend, newshound, and oduy> know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ oduy> _______________________________________________ oduy> Xorp-users mailing list oduy> Xorp-users at xorp.org oduy> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From arvind at macil.in Sat Feb 16 01:17:41 2008 From: arvind at macil.in (arvind) Date: Sat, 16 Feb 2008 14:47:41 +0530 Subject: [Xorp-users] want to link chip with xorp.. Message-ID: <47B6AA35.5080001@macil.in> An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080216/b6654674/attachment.html From yueli.m at gmail.com Mon Feb 18 12:05:17 2008 From: yueli.m at gmail.com (Yue Li) Date: Mon, 18 Feb 2008 15:05:17 -0500 Subject: [Xorp-users] [xorp-users] Run xorp on virtual machine, network down? Message-ID: <49567c360802181205r2aa36e74w9bdcb0ee198c9b35@mail.gmail.com> Hi, All I am running XORP on OpenVZ (an OS-level virtual machine). OpenVZ has a virtualized network stack. Something strange is everything is fine after xorp starts (I can see routes update), but 7-8 minutes later I can not ping 127.0.0.1, it seems network is down (but xorp is still running). The following are some messages printed out. Could someone give me some clues, thank you very much! When xorp starts, there are some warning messages: [ 2008/02/18 19:40:35 INFO xorp_rtrmgr:11752 RTRMGR +239 master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, policy, ospf4 [ 2008/02/18 19:40:35 INFO xorp_rtrmgr:11752 RTRMGR +96 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2008/02/18 19:40:37 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:38 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:39 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:40 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:41 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:42 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:43 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:44 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:45 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:46 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:47 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:48 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:49 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:50 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:51 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:52 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:53 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:54 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. [ 2008/02/18 19:40:55 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Xrl target is not enabled. [ 2008/02/18 19:40:55 INFO xorp_fea MFEA ] MFEA enabled [ 2008/02/18 19:40:55 INFO xorp_fea MFEA ] CLI enabled [ 2008/02/18 19:40:55 INFO xorp_fea MFEA ] CLI started [ 2008/02/18 19:40:55 INFO xorp_fea MFEA ] MFEA enabled [ 2008/02/18 19:40:55 INFO xorp_fea MFEA ] CLI enabled [ 2008/02/18 19:40:55 INFO xorp_fea MFEA ] CLI started [ 2008/02/18 19:40:56 INFO xorp_rtrmgr:11752 RTRMGR +96 module_manager.cc execute ] Executing module: fea (fea/xorp_fea) [ 2008/02/18 19:41:00 INFO xorp_rtrmgr:11752 RTRMGR +96 module_manager.cc execute ] Executing module: rib (rib/xorp_rib) [ 2008/02/18 19:41:02 INFO xorp_rtrmgr:11752 RTRMGR +96 module_manager.cc execute ] Executing module: policy (policy/xorp_policy) [ 2008/02/18 19:41:04 INFO xorp_rtrmgr:11752 RTRMGR +96 module_manager.cc execute ] Executing module: ospf4 (ospf/xorp_ospfv2) [ 2008/02/18 19:41:06 INFO xorp_rtrmgr:11752 RTRMGR +2228 task.cc run_task ] No more tasks to run When I shut down xorp (Ctl-c), there are some errors: [ 2008/02/18 19:42:49 INFO xorp_rtrmgr:11752 RTRMGR +1019 task.cc shutdown ] Shutting down module: ospf4 [ 2008/02/18 19:42:49 INFO xorp_rtrmgr:11752 RTRMGR +275 module_manager.cc module_exited ] Module normal exit: ospf4 [ 2008/02/18 19:42:50 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "ospfv2" does not exist or is not enabled. [ 2008/02/18 19:42:51 INFO xorp_rtrmgr:11752 RTRMGR +1019 task.cc shutdown ] Shutting down module: policy [ 2008/02/18 19:42:52 INFO xorp_rtrmgr:11752 XRL +391 xrl_router.cc send_resolved ] Sender died (protocol = "stcp", address = "127.0.0.1:34400") [ 2008/02/18 19:42:52 ERROR xorp_rtrmgr:11752 LIBXORP +213 buffered_asyncio.cc io_event ] read error 111 [ 2008/02/18 19:42:52 ERROR xorp_rtrmgr:11752 XRL +782 xrl_pf_stcp.cc read_event ] Read failed (error = 111) [ 2008/02/18 19:42:52 ERROR xorp_rtrmgr:11752 XRL +635 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: read error [ 2008/02/18 19:42:52 INFO xorp_rtrmgr:11752 RTRMGR +275 module_manager.cc module_exited ] Module normal exit: policy [ 2008/02/18 19:42:53 INFO xorp_rtrmgr:11752 RTRMGR +1019 task.cc shutdown ] Shutting down module: rib [ 2008/02/18 19:42:53 INFO xorp_rtrmgr:11752 RTRMGR +275 module_manager.cc module_exited ] Module normal exit: rib [ 2008/02/18 19:42:54 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "rib" does not exist or is not enabled. [ 2008/02/18 19:42:58 INFO xorp_rtrmgr:11752 RTRMGR +171 module_manager.cc terminate ] Terminating module: fea [ 2008/02/18 19:42:58 INFO xorp_fea MFEA ] CLI stopped [ 2008/02/18 19:42:58 INFO xorp_fea MFEA ] CLI stopped [ 2008/02/18 19:42:58 ERROR xorp_fea:11753 LIBXORP +249 selector.cc remove_ioevent_cb ] Attempting to remove fd = -1 that is outside range of file descriptors 0..41 [ 2008/02/18 19:42:58 INFO xorp_rtrmgr:11752 RTRMGR +1019 task.cc shutdown ] Shutting down module: interfaces [ 2008/02/18 19:42:58 ERROR xorp_rtrmgr:11752 LIBXORP +533 asyncio.cc complete_transfer ] Write error 104 [ 2008/02/18 19:42:58 ERROR xorp_rtrmgr:11752 LIBXORP +213 buffered_asyncio.cc io_event ] read error 104 [ 2008/02/18 19:42:58 ERROR xorp_rtrmgr:11752 XRL +782 xrl_pf_stcp.cc read_event ] Read failed (error = 104) [ 2008/02/18 19:42:58 ERROR xorp_rtrmgr:11752 XRL +635 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: read error [ 2008/02/18 19:42:58 INFO xorp_rtrmgr:11752 RTRMGR +275 module_manager.cc module_exited ] Module normal exit: interfaces [ 2008/02/18 19:42:59 INFO xorp_rtrmgr:11752 RTRMGR +2228 task.cc run_task ] No more tasks to run From pavlin at ICSI.Berkeley.EDU Wed Feb 20 11:50:18 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 20 Feb 2008 11:50:18 -0800 Subject: [Xorp-users] want to link chip with xorp.. In-Reply-To: <47B6AA35.5080001@macil.in> References: <47B6AA35.5080001@macil.in> Message-ID: <200802201950.m1KJoIIA026940@fruitcake.ICSI.Berkeley.EDU> I am working with xorp cvs version. xorp is working fine for me. > so i want to link one chip with xorp, i.e while running the > xorp_rtrmgr, first I want to startup the chip before xorp_rtrmgr, > xorp_fea, xorp_staticroures, .... starts, So I need to know where i > need to modify so that i will take effect. > My doubt was whether i need to modify in template files, or any part of > coding? Please clarify what you mean by "chip". >From the context I would have to guess you mean UNIX process that you want to start within XORP? Please clarify whether that process is aware of XORP (i.e., whether it understands XRLs). Also, if you briefly describe the purpose of that process it could help us with evaluating the set of possible solutions. Regards, Pavlin From pavlin at ICSI.Berkeley.EDU Wed Feb 20 11:58:18 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 20 Feb 2008 11:58:18 -0800 Subject: [Xorp-users] [xorp-users] Run xorp on virtual machine, network down? In-Reply-To: <49567c360802181205r2aa36e74w9bdcb0ee198c9b35@mail.gmail.com> References: <49567c360802181205r2aa36e74w9bdcb0ee198c9b35@mail.gmail.com> Message-ID: <200802201958.m1KJwI8K028584@fruitcake.ICSI.Berkeley.EDU> Yue Li wrote: > Hi, All > > I am running XORP on OpenVZ (an OS-level virtual machine). OpenVZ has > a virtualized network stack. > Something strange is everything is fine after xorp starts (I can see > routes update), but 7-8 minutes > later I can not ping 127.0.0.1, it seems network is down (but xorp is > still running). > The following are some messages printed out. > Could someone give me some clues, thank you very much! > > When xorp starts, there are some warning messages: The startup/shutdown warning messages are transient so you can ignore them. I haven't used OpenVZ so I can't really help you with the ping problem. However, the following thread in the OpenVZ forum describes exactly same problem: http://forum.openvz.org/index.php?t=rview&goto=27520&th=5499 For the record, the answer seems to be that the dgramrcvbuf quota needs to be increased. Hope that helps, Pavlin > [ 2008/02/18 19:40:35 INFO xorp_rtrmgr:11752 RTRMGR +239 > master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, > policy, ospf4 > [ 2008/02/18 19:40:35 INFO xorp_rtrmgr:11752 RTRMGR +96 > module_manager.cc execute ] Executing module: interfaces > (fea/xorp_fea) > [ 2008/02/18 19:40:37 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:38 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:39 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:40 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:41 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:42 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:43 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:44 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:45 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:46 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:47 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:48 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:49 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:50 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:51 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:52 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:53 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:54 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "fea" does not exist or is not enabled. > [ 2008/02/18 19:40:55 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Xrl target is not enabled. > [ 2008/02/18 19:40:55 INFO xorp_fea MFEA ] MFEA enabled > [ 2008/02/18 19:40:55 INFO xorp_fea MFEA ] CLI enabled > [ 2008/02/18 19:40:55 INFO xorp_fea MFEA ] CLI started > [ 2008/02/18 19:40:55 INFO xorp_fea MFEA ] MFEA enabled > [ 2008/02/18 19:40:55 INFO xorp_fea MFEA ] CLI enabled > [ 2008/02/18 19:40:55 INFO xorp_fea MFEA ] CLI started > [ 2008/02/18 19:40:56 INFO xorp_rtrmgr:11752 RTRMGR +96 > module_manager.cc execute ] Executing module: fea (fea/xorp_fea) > [ 2008/02/18 19:41:00 INFO xorp_rtrmgr:11752 RTRMGR +96 > module_manager.cc execute ] Executing module: rib (rib/xorp_rib) > [ 2008/02/18 19:41:02 INFO xorp_rtrmgr:11752 RTRMGR +96 > module_manager.cc execute ] Executing module: policy > (policy/xorp_policy) > [ 2008/02/18 19:41:04 INFO xorp_rtrmgr:11752 RTRMGR +96 > module_manager.cc execute ] Executing module: ospf4 (ospf/xorp_ospfv2) > [ 2008/02/18 19:41:06 INFO xorp_rtrmgr:11752 RTRMGR +2228 task.cc > run_task ] No more tasks to run > > > When I shut down xorp (Ctl-c), there are some errors: > > [ 2008/02/18 19:42:49 INFO xorp_rtrmgr:11752 RTRMGR +1019 task.cc > shutdown ] Shutting down module: ospf4 > [ 2008/02/18 19:42:49 INFO xorp_rtrmgr:11752 RTRMGR +275 > module_manager.cc module_exited ] Module normal exit: ospf4 > [ 2008/02/18 19:42:50 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "ospfv2" does not exist or is not enabled. > [ 2008/02/18 19:42:51 INFO xorp_rtrmgr:11752 RTRMGR +1019 task.cc > shutdown ] Shutting down module: policy > [ 2008/02/18 19:42:52 INFO xorp_rtrmgr:11752 XRL +391 xrl_router.cc > send_resolved ] Sender died (protocol = "stcp", address = > "127.0.0.1:34400") > [ 2008/02/18 19:42:52 ERROR xorp_rtrmgr:11752 LIBXORP +213 > buffered_asyncio.cc io_event ] read error 111 > [ 2008/02/18 19:42:52 ERROR xorp_rtrmgr:11752 XRL +782 xrl_pf_stcp.cc > read_event ] Read failed (error = 111) > [ 2008/02/18 19:42:52 ERROR xorp_rtrmgr:11752 XRL +635 xrl_pf_stcp.cc > die ] XrlPFSTCPSender died: read error > [ 2008/02/18 19:42:52 INFO xorp_rtrmgr:11752 RTRMGR +275 > module_manager.cc module_exited ] Module normal exit: policy > [ 2008/02/18 19:42:53 INFO xorp_rtrmgr:11752 RTRMGR +1019 task.cc > shutdown ] Shutting down module: rib > [ 2008/02/18 19:42:53 INFO xorp_rtrmgr:11752 RTRMGR +275 > module_manager.cc module_exited ] Module normal exit: rib > [ 2008/02/18 19:42:54 WARNING xorp_rtrmgr:11752 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command > failed Target "rib" does not exist or is not enabled. > [ 2008/02/18 19:42:58 INFO xorp_rtrmgr:11752 RTRMGR +171 > module_manager.cc terminate ] Terminating module: fea > [ 2008/02/18 19:42:58 INFO xorp_fea MFEA ] CLI stopped > [ 2008/02/18 19:42:58 INFO xorp_fea MFEA ] CLI stopped > [ 2008/02/18 19:42:58 ERROR xorp_fea:11753 LIBXORP +249 selector.cc > remove_ioevent_cb ] Attempting to remove fd = -1 that is outside range > of file descriptors 0..41 > [ 2008/02/18 19:42:58 INFO xorp_rtrmgr:11752 RTRMGR +1019 task.cc > shutdown ] Shutting down module: interfaces > [ 2008/02/18 19:42:58 ERROR xorp_rtrmgr:11752 LIBXORP +533 asyncio.cc > complete_transfer ] Write error 104 > [ 2008/02/18 19:42:58 ERROR xorp_rtrmgr:11752 LIBXORP +213 > buffered_asyncio.cc io_event ] read error 104 > [ 2008/02/18 19:42:58 ERROR xorp_rtrmgr:11752 XRL +782 xrl_pf_stcp.cc > read_event ] Read failed (error = 104) > [ 2008/02/18 19:42:58 ERROR xorp_rtrmgr:11752 XRL +635 xrl_pf_stcp.cc > die ] XrlPFSTCPSender died: read error > [ 2008/02/18 19:42:58 INFO xorp_rtrmgr:11752 RTRMGR +275 > module_manager.cc module_exited ] Module normal exit: interfaces > [ 2008/02/18 19:42:59 INFO xorp_rtrmgr:11752 RTRMGR +2228 task.cc > run_task ] No more tasks to run > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From dirk.schulz at kinzesberg.de Thu Feb 28 11:09:11 2008 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Thu, 28 Feb 2008 20:09:11 +0100 Subject: [Xorp-users] BadPeer ...: Area ... not handled by eth0/eth0 Message-ID: Hi Folks, I am new to running routers on my own and new to Xorp and OSPF. I have setup two routers using ospf. They are two communication with two upstream routers using ospf as well. Now my own routers find each other as neighbors (the do not find the upstream routers, but that is a problem I have to solve with the upstream provider, I think). They seem to work, my routers, but both put out the following message every few seconds: BadPeer from line 379 of peer.cc: Area 217.64.164.128 not handled by eth0/eth0 I have not found anything relating in the docs, in Google nor elsewhere. 217.64.164.128 is the subnet used for area 0.0.0.1 on interface bond0 on both routers. I do not understand why it should be handled by eth0 which has a setting of 217.64.170.238/29 resp. 217.64.170.230/29. This is the configuration of one router, the other is nearly identical (just other IP addresses): > interfaces { > restore-original-config-on-shutdown: true > > interface eth0 { > description: "external (area0) interface" > disable: false > default-system-config > } > > interface eth1 { > description: "inter router interface" > disable: false > default-system-config > } > > interface bond0 { > description: "area1 bonding interface" > disable: false > default-system-config > } > /* > interface bond1 { > description: "area2 bonding interface" > disable: false > default-system-config > } > */ > } > > fea { > unicast-forwarding4 { > disable: false > forwarding-entries { > retain-on-startup: false > retain-on-shutdown: false > } > } > unicast-forwarding6 { > disable: true > forwarding-entries { > retain-on-startup: false > retain-on-shutdown: false > } > } > } > > protocols { > ospf4 { > router-id: 217.64.170.238 > > area 0.0.0.0 { > area-type: "normal" > interface eth0 { > vif eth0 { > address 217.64.170.238 { > priority: 128 > hello-interval: 5 > router-dead-interval: 15 > interface-cost: 1 > retransmit-interval: 2 > transit-delay: 1 > disable: false > } > } > } > interface eth1 { > vif eth1 { > address 192.168.11.1 { > priority: 128 > hello-interval: 5 > router-dead-interval: 15 > interface-cost: 2 > retransmit-interval: 2 > transit-delay: 1 > disable: false > } > } > } > } > > area 0.0.0.1 { > area-type: "normal" > interface bond0 { > vif bond0 { > address 217.64.164.129 { > priority: 128 > hello-interval: 5 > router-dead-interval: 15 > interface-cost: 2 > retransmit-interval: 2 > transit-delay: 1 > disable: false > } > } > } > } > /* > area 0.0.0.2 { > area-type: "normal" > interface bond1 { > vif bond1 { > address 217.64.170.60 > } > } > } > */ > } > } Any ideas? Every hint or help is appreciated. Thanks in advance, Dirk From atanu at ICSI.Berkeley.EDU Thu Feb 28 11:40:13 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 28 Feb 2008 11:40:13 -0800 Subject: [Xorp-users] BadPeer ...: Area ... not handled by eth0/eth0 In-Reply-To: Message from "Dirk H. Schulz" of "Thu, 28 Feb 2008 20:09:11 +0100." Message-ID: <13707.1204227613@tigger.icir.org> Hi, The message is telling you that OSPF packets are being received on eth0/eth0 from a router which is in area 217.64.164.128, which in your configuration is area 0.0.0.0. If you change your configuration to area 217.64.164.128 you will probably be able to peer with your upstream routers. Atanu. >>>>> "Dirk" == Dirk H Schulz writes: Dirk> Hi Folks, I am new to running routers on my own and new to Dirk> Xorp and OSPF. Dirk> I have setup two routers using ospf. They are two Dirk> communication with two upstream routers using ospf as Dirk> well. Now my own routers find each other as neighbors (the do Dirk> not find the upstream routers, but that is a problem I have to Dirk> solve with the upstream provider, I think). Dirk> They seem to work, my routers, but both put out the following Dirk> message every few seconds: Dirk> BadPeer from line 379 of peer.cc: Area 217.64.164.128 Dirk> not handled by eth0/eth0 Dirk> I have not found anything relating in the docs, in Google nor Dirk> elsewhere. Dirk> 217.64.164.128 is the subnet used for area 0.0.0.1 on Dirk> interface bond0 on both routers. I do not understand why it Dirk> should be handled by eth0 which has a setting of Dirk> 217.64.170.238/29 resp. 217.64.170.230/29. Dirk> This is the configuration of one router, the other is nearly Dirk> identical (just other IP addresses): >> interfaces { restore-original-config-on-shutdown: true >> >> interface eth0 { description: "external (area0) interface" >> disable: false default-system-config } >> >> interface eth1 { description: "inter router interface" disable: >> false default-system-config } >> >> interface bond0 { description: "area1 bonding interface" disable: >> false default-system-config } /* interface bond1 { description: >> "area2 bonding interface" disable: false default-system-config } >> */ } >> >> fea { unicast-forwarding4 { disable: false forwarding-entries { >> retain-on-startup: false retain-on-shutdown: false } } >> unicast-forwarding6 { disable: true forwarding-entries { >> retain-on-startup: false retain-on-shutdown: false } } } >> >> protocols { ospf4 { router-id: 217.64.170.238 >> >> area 0.0.0.0 { area-type: "normal" interface eth0 { vif eth0 { >> address 217.64.170.238 { priority: 128 hello-interval: 5 >> router-dead-interval: 15 interface-cost: 1 retransmit-interval: 2 >> transit-delay: 1 disable: false } } } interface eth1 { vif eth1 { >> address 192.168.11.1 { priority: 128 hello-interval: 5 >> router-dead-interval: 15 interface-cost: 2 retransmit-interval: 2 >> transit-delay: 1 disable: false } } } } >> >> area 0.0.0.1 { area-type: "normal" interface bond0 { vif bond0 { >> address 217.64.164.129 { priority: 128 hello-interval: 5 >> router-dead-interval: 15 interface-cost: 2 retransmit-interval: 2 >> transit-delay: 1 disable: false } } } } /* area 0.0.0.2 { >> area-type: "normal" interface bond1 { vif bond1 { address >> 217.64.170.60 } } } */ } } Dirk> Any ideas? Every hint or help is appreciated. Dirk> Thanks in advance, Dirk> Dirk Dirk> _______________________________________________ Xorp-users Dirk> mailing list Xorp-users at xorp.org Dirk> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From dirk.schulz at kinzesberg.de Thu Feb 28 22:59:55 2008 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Fri, 29 Feb 2008 07:59:55 +0100 Subject: [Xorp-users] BadPeer ...: Area ... not handled by eth0/eth0 In-Reply-To: <13707.1204227613@tigger.icir.org> References: <13707.1204227613@tigger.icir.org> Message-ID: <77C5F656290370244A1616A8@Dirks-MacBook-Pro.local> Hi Atanu, thanks for helping. I am not sure I understand you right. You say that on eth0 ospf packets from a router arrive that is in subnet 217.64.164.128? I am logging all traffic at the moment, and ospf packets on eth0 arrive only from 217.64.170.233 which is the address of the upstream router (I checked on my first router). And I do not understand > area 217.64.164.128, which in your > configuration is area 0.0.0.0 In my configuration this is area 0.0.0.1 - do you think it SHOULD be area 0.0.0.0? I thought that area 0.0.0.0 always is the area with the upstream connection. Thanks again for your help. Dirk --On 28. Februar 2008 11:40:13 -0800 Atanu Ghosh wrote: > Hi, > > The message is telling you that OSPF packets are being received on > eth0/eth0 from a router which is in area 217.64.164.128, which in your > configuration is area 0.0.0.0. If you change your configuration to area > 217.64.164.128 you will probably be able to peer with your upstream > routers. > > Atanu. > >>>>>> "Dirk" == Dirk H Schulz writes: > > Dirk> Hi Folks, I am new to running routers on my own and new to > Dirk> Xorp and OSPF. > > Dirk> I have setup two routers using ospf. They are two > Dirk> communication with two upstream routers using ospf as > Dirk> well. Now my own routers find each other as neighbors (the do > Dirk> not find the upstream routers, but that is a problem I have to > Dirk> solve with the upstream provider, I think). > > Dirk> They seem to work, my routers, but both put out the following > Dirk> message every few seconds: > > Dirk> BadPeer from line 379 of peer.cc: Area 217.64.164.128 > Dirk> not handled by eth0/eth0 > > Dirk> I have not found anything relating in the docs, in Google nor > Dirk> elsewhere. > > Dirk> 217.64.164.128 is the subnet used for area 0.0.0.1 on > Dirk> interface bond0 on both routers. I do not understand why it > Dirk> should be handled by eth0 which has a setting of > Dirk> 217.64.170.238/29 resp. 217.64.170.230/29. > > Dirk> This is the configuration of one router, the other is nearly > Dirk> identical (just other IP addresses): > > >> interfaces { restore-original-config-on-shutdown: true > >> > >> interface eth0 { description: "external (area0) interface" > >> disable: false default-system-config } > >> > >> interface eth1 { description: "inter router interface" disable: > >> false default-system-config } > >> > >> interface bond0 { description: "area1 bonding interface" disable: > >> false default-system-config } /* interface bond1 { description: > >> "area2 bonding interface" disable: false default-system-config } > >> */ } > >> > >> fea { unicast-forwarding4 { disable: false forwarding-entries { > >> retain-on-startup: false retain-on-shutdown: false } } > >> unicast-forwarding6 { disable: true forwarding-entries { > >> retain-on-startup: false retain-on-shutdown: false } } } > >> > >> protocols { ospf4 { router-id: 217.64.170.238 > >> > >> area 0.0.0.0 { area-type: "normal" interface eth0 { vif eth0 { > >> address 217.64.170.238 { priority: 128 hello-interval: 5 > >> router-dead-interval: 15 interface-cost: 1 retransmit-interval: 2 > >> transit-delay: 1 disable: false } } } interface eth1 { vif eth1 { > >> address 192.168.11.1 { priority: 128 hello-interval: 5 > >> router-dead-interval: 15 interface-cost: 2 retransmit-interval: 2 > >> transit-delay: 1 disable: false } } } } > >> > >> area 0.0.0.1 { area-type: "normal" interface bond0 { vif bond0 { > >> address 217.64.164.129 { priority: 128 hello-interval: 5 > >> router-dead-interval: 15 interface-cost: 2 retransmit-interval: 2 > >> transit-delay: 1 disable: false } } } } /* area 0.0.0.2 { > >> area-type: "normal" interface bond1 { vif bond1 { address > >> 217.64.170.60 } } } */ } } > > Dirk> Any ideas? Every hint or help is appreciated. > > Dirk> Thanks in advance, > > Dirk> Dirk > > > Dirk> _______________________________________________ Xorp-users > Dirk> mailing list Xorp-users at xorp.org > Dirk> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users -------------------------------------------------------------- Dirk H. Schulz IT Systems Service Wiesenweg 12, 85567 Grafing Tel. 0 80 92/86 25 68 Fax. 0 80 92/86 25 72 -------------------------------------------------------------- Technik vom Feinsten - und das n?tige Tuning From atanu at ICSI.Berkeley.EDU Fri Feb 29 09:19:57 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 29 Feb 2008 09:19:57 -0800 Subject: [Xorp-users] BadPeer ...: Area ... not handled by eth0/eth0 In-Reply-To: Message from "Dirk H. Schulz" of "Fri, 29 Feb 2008 07:59:55 +0100." <77C5F656290370244A1616A8@Dirks-MacBook-Pro.local> Message-ID: <3358.1204305597@tigger.icir.org> Hi, OSPF divides the network into areas, each area has a 32 bit area ID, the areas are *independent* of subnets. Areas are structured in a heirarchy, area 0.0.0.0 also called the backbone, is the top of the heirarchy and all other areas are connected to the backbone (there is an exception but we don't need to worry about that here). Figure 6 in RFC 2328 has an example topology. In order for neighbouring OSPF routers to communcate they must be configured to be in the same area. Every OSPF packet contains a header and one of the fields in the header is the area ID. The warning messages that you are seeing is OSPF reporting that it was seeing packets on eth0 from area 217.64.164.12, but your configuration has eth0 in area 0.0.0.0. It looks like your "upstream" has not connected you directly to the backbone but has put you in a separate area 217.64.164.12. If you change your configuration replacing area 0.0.0.0 with 217.64.164.12 then you should form adjacencies with your "upstream". Atanu. >>>>> "Dirk" == Dirk H Schulz writes: Dirk> Hi Atanu, thanks for helping. Dirk> I am not sure I understand you right. You say that on eth0 Dirk> ospf packets from a router arrive that is in subnet Dirk> 217.64.164.128? I am logging all traffic at the moment, and Dirk> ospf packets on eth0 arrive only from 217.64.170.233 which is Dirk> the address of the upstream router (I checked on my first Dirk> router). Dirk> And I do not understand >> area 217.64.164.128, which in your configuration is area 0.0.0.0 Dirk> In my configuration this is area 0.0.0.1 - do you think it Dirk> SHOULD be area 0.0.0.0? I thought that area 0.0.0.0 always is Dirk> the area with the upstream connection. Dirk> Thanks again for your help. Dirk> Dirk Dirk> --On 28. Februar 2008 11:40:13 -0800 Atanu Ghosh Dirk> wrote: >> Hi, >> >> The message is telling you that OSPF packets are being received >> on eth0/eth0 from a router which is in area 217.64.164.128, which >> in your configuration is area 0.0.0.0. If you change your >> configuration to area 217.64.164.128 you will probably be able to >> peer with your upstream routers. >> >> Atanu. >> >>>>>>> "Dirk" == Dirk H Schulz writes: >> Dirk> Hi Folks, I am new to running routers on my own and new to Dirk> Xorp and OSPF. >> Dirk> I have setup two routers using ospf. They are two Dirk> communication with two upstream routers using ospf as Dirk> well. Now my own routers find each other as neighbors (the do Dirk> not find the upstream routers, but that is a problem I have to Dirk> solve with the upstream provider, I think). >> Dirk> They seem to work, my routers, but both put out the following Dirk> message every few seconds: >> Dirk> BadPeer from line 379 of peer.cc: Area 217.64.164.128 not Dirk> handled by eth0/eth0 >> Dirk> I have not found anything relating in the docs, in Google nor Dirk> elsewhere. >> Dirk> 217.64.164.128 is the subnet used for area 0.0.0.1 on Dirk> interface bond0 on both routers. I do not understand why it Dirk> should be handled by eth0 which has a setting of Dirk> 217.64.170.238/29 resp. 217.64.170.230/29. >> Dirk> This is the configuration of one router, the other is nearly Dirk> identical (just other IP addresses): >> >> interfaces { restore-original-config-on-shutdown: true >> >> >> >> interface eth0 { description: "external (area0) interface" >> >> disable: false default-system-config } >> >> >> >> interface eth1 { description: "inter router interface" >> disable: >> false default-system-config } >> >> >> >> interface bond0 { description: "area1 bonding interface" >> disable: >> false default-system-config } /* interface bond1 { >> description: >> "area2 bonding interface" disable: false >> default-system-config } >> */ } >> >> >> >> fea { unicast-forwarding4 { disable: false forwarding-entries >> { >> retain-on-startup: false retain-on-shutdown: false } } >> >> unicast-forwarding6 { disable: true forwarding-entries { >> >> retain-on-startup: false retain-on-shutdown: false } } } >> >> >> >> protocols { ospf4 { router-id: 217.64.170.238 >> >> >> >> area 0.0.0.0 { area-type: "normal" interface eth0 { vif eth0 { >> >> address 217.64.170.238 { priority: 128 hello-interval: 5 >> >> router-dead-interval: 15 interface-cost: 1 retransmit-interval: 2 >> >> transit-delay: 1 disable: false } } } interface eth1 { vif >> eth1 { >> address 192.168.11.1 { priority: 128 hello-interval: 5 >> >> router-dead-interval: 15 interface-cost: 2 >> retransmit-interval: 2 >> transit-delay: 1 disable: false } } } } >> >> >> >> area 0.0.0.1 { area-type: "normal" interface bond0 { vif bond0 >> { >> address 217.64.164.129 { priority: 128 hello-interval: 5 >> >> router-dead-interval: 15 interface-cost: 2 retransmit-interval: 2 >> >> transit-delay: 1 disable: false } } } } /* area 0.0.0.2 { >> >> area-type: "normal" interface bond1 { vif bond1 { address >> >> 217.64.170.60 } } } */ } } >> Dirk> Any ideas? Every hint or help is appreciated. >> Dirk> Thanks in advance, >> Dirk> Dirk >> Dirk> _______________________________________________ Xorp-users Dirk> mailing list Xorp-users at xorp.org Dirk> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users Dirk> -------------------------------------------------------------- Dirk> Dirk H. Schulz IT Systems Service Wiesenweg 12, 85567 Grafing Dirk> Tel. 0 80 92/86 25 68 Fax. 0 80 92/86 25 72 Dirk> -------------------------------------------------------------- Dirk> Technik vom Feinsten - und das n??tige Tuning From Florian.Thiessenhusen at admeritia.de Fri Feb 29 09:46:38 2008 From: Florian.Thiessenhusen at admeritia.de (Florian Thiessenhusen) Date: Fri, 29 Feb 2008 18:46:38 +0100 Subject: [Xorp-users] static Route 0.0.0.0/0 In-Reply-To: <13707.1204227613@tigger.icir.org> References: Message from "Dirk H. Schulz" of "Thu, 28 Feb 2008 20:09:11 +0100." <13707.1204227613@tigger.icir.org> Message-ID: Hello together, i am testing some very simple Xorp-functions in a testlab. My testlab: 1 Firewall (192.168.15.11) (serves internet and some other local nets) 1 Xorp Router (192.168.15.15) (in the same subnet like LAN interface of Firewall) 2 Clients (in the same interface like Firewall and Xorp) I only use static routes for the clients, that they can connect to internet via Firewall and the other local Networks. The Xorp Router is standardgateway in the clients. All routing is working properly for the Networks, directly attached to the Firewall. My config.boot lokes like this: <------------------------------------------------------> /*XORP Configuration File, v1.0*/ protocols { static { disable: false route 0.0.0.0/0 { next-hop: 192.168.15.11 metric: 1 } route 192.168.14.0/24 { next-hop: 192.168.15.11 metric: 1 } } } fea { unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } interfaces { restore-original-config-on-shutdown: false interface lo { disable: false discard: false description: "Ethernet Interface #1" default-system-config } interface eth1 { disable: false discard: false description: "Ethernet Interface #2" default-system-config } } <------------------------------------------------------> Now i have a problem: I cannot route into 0.0.0.0/0 (Internet?). It will not work. Where is the failure? Thanks for help, Florian From dan at obluda.cz Fri Feb 29 10:55:35 2008 From: dan at obluda.cz (Dan Lukes) Date: Fri, 29 Feb 2008 19:55:35 +0100 Subject: [Xorp-users] static Route 0.0.0.0/0 In-Reply-To: References: Message from "Dirk H. Schulz" of "Thu, 28 Feb 2008 20:09:11 +0100." <13707.1204227613@tigger.icir.org> Message-ID: <47C85527.20801@obluda.cz> Florian Thiessenhusen napsal/wrote, On 02/29/08 18:46: > i am testing some very simple Xorp-functions in a testlab. ... > protocols { > static { > disable: false > route 0.0.0.0/0 { > next-hop: 192.168.15.11 > metric: 1 > } > I cannot route into 0.0.0.0/0 (Internet?). It will not work. Where is the failure? 1. who is I ? The client station ? The router ? 2. what mean "it will not work" exactly, in the terms like "X sends packet to Y, it shall be routed via Z but never arrive on it" ? 3. what's the route table entry for the outgoing packet in question ? Dan From sd88 at drexel.edu Fri Feb 29 18:23:51 2008 From: sd88 at drexel.edu (Sukrit Dasgupta) Date: Fri, 29 Feb 2008 21:23:51 -0500 Subject: [Xorp-users] OSPF Areas and Linux Route table Message-ID: Hi list, I have a pretty simple setup of 3 areas using OSPF: 12.0.0.0 (Area1: XORP on Linux)<---------->14.0.0.0 (Area 0: Cisco 7200 Testbed) <-----------------> 16.0.0.0 (Area 2: XORP on linux) The XORP border routers in Area 1 and Area 2 can ping the Cisco ABR routers, but thats about it. The linux route table shows that only an entry for the corresponding area. So for example, $route -e on the XORP with router with IP 12.0.11.2 connected to the Cisco 7200 with IP 12.0.11.3 only shows Destination Gateway Genmask Flags MSS Window irtt Iface 12.0.11.0 * 255.255.255.0 U 0 0 0 eth1 No OSPF area information is being shared amongst the routers. Any ideas? Thanks in advance Sukrit From atanu at ICSI.Berkeley.EDU Fri Feb 29 23:52:25 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 29 Feb 2008 23:52:25 -0800 Subject: [Xorp-users] OSPF Areas and Linux Route table In-Reply-To: Message from Sukrit Dasgupta of "Fri, 29 Feb 2008 21:23:51 EST." Message-ID: <33859.1204357945@tigger.icir.org> Hi, The output of "show ospf4 neighbor" would be a useful starting point to verify that the adjacencies have been correctly formed. Atanu. >>>>> "Sukrit" == Sukrit Dasgupta writes: Sukrit> Hi list, I have a pretty simple setup of 3 areas using OSPF: Sukrit> 12.0.0.0 (Area1: XORP on Linux)<---------->14.0.0.0 (Area 0: Sukrit> Cisco 7200 Testbed) <-----------------> 16.0.0.0 (Area 2: Sukrit> XORP on linux) Sukrit> The XORP border routers in Area 1 and Area 2 can ping the Sukrit> Cisco ABR routers, but thats about it. The linux route table Sukrit> shows that only an entry for the corresponding area. So for Sukrit> example, $route -e on the XORP with router with IP 12.0.11.2 Sukrit> connected to the Cisco 7200 with IP 12.0.11.3 only shows Sukrit> Destination Gateway Genmask Flags MSS Window irtt Iface Sukrit> 12.0.11.0 * 255.255.255.0 U 0 0 0 eth1 Sukrit> No OSPF area information is being shared amongst the Sukrit> routers. Sukrit> Any ideas? Sukrit> Thanks in advance Sukrit Sukrit> _______________________________________________ Xorp-users Sukrit> mailing list Xorp-users at xorp.org Sukrit> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users