From james.dutton at gmail.com Tue Jul 1 10:13:28 2008 From: james.dutton at gmail.com (James Courtier-Dutton) Date: Tue, 1 Jul 2008 18:13:28 +0100 Subject: [Xorp-users] Static joins Message-ID: Hi, Is there a XRL is could send to XORP to force a particular interface to think that it has always joined a particular multicast group. I know I could send IGMPs to that interfaces, but a simple XRL would be easier for me. Kind Regards James From pavlin at ICSI.Berkeley.EDU Tue Jul 1 17:00:34 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 01 Jul 2008 17:00:34 -0700 Subject: [Xorp-users] Static joins In-Reply-To: References: Message-ID: <200807020000.m6200YRj001359@fruitcake.ICSI.Berkeley.EDU> James Courtier-Dutton wrote: > Hi, > > Is there a XRL is could send to XORP to force a particular interface > to think that it has always joined a particular multicast group. > I know I could send IGMPs to that interfaces, but a simple XRL would > be easier for me. Could you specify what exactly you are trying to achieve? If you have a XORP application that has opened an UDP socket for example, that application can use socket4/0.1/udp_join_group XRL (see xrl/interfaces/socket4.xif) to join a multicast group. There are similar XRLs for the raw IP and raw link interface: join_multicast_group in fea_rawpkt4.xif and join_multicast_group in fea_rawlink.xif . In all cases there must be an application (XORP client) that is listening for the packets received for the joined multicast group, but I have the feeling this is not what you are looking for. Pavlin > Kind Regards > > James > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From bms at ICSI.Berkeley.EDU Wed Jul 2 10:49:22 2008 From: bms at ICSI.Berkeley.EDU (Bruce M. Simpson) Date: Wed, 02 Jul 2008 18:49:22 +0100 Subject: [Xorp-users] Static joins In-Reply-To: References: <200807020000.m6200YRj001359@fruitcake.ICSI.Berkeley.EDU> Message-ID: <486BBFA2.5080002@icsi.berkeley.edu> James Courtier-Dutton wrote: > I have an application than generates a tunN interface. > XORP has this tunN interface as one of its PIM-SM/IGMP interfaces. > Now, I need to find the easiest way to get XORP to output multicast > traffic over this interface. > One option is for my application to create and send IGMP messages > towards the tunN interface. > I was hoping that there might be a XRL interface directly into XORP > that would simulate the IGMPs being received on the tunN interface by > XORP so that I would not have to reimplement IGMP in my application. > Actually, doing IGMP yourself isn't too bad -- see pcs.sourgeforge.net for a Python toolkit with IGMP support which I co-authored with George Neville-Neill. I haven't published the baseline regression tests which I did using this stuff yet, ping me if you want to see those. Of course, another way is to add IGMP-like hooks which you describe. In the case of tunX, it sounds like you're using some kind of VPN or other encapsulation. Are you? And if so, is the problem the fact that these interfaces are dynamically allocated and added to the system? cheers BMS From pavlin at ICSI.Berkeley.EDU Thu Jul 3 09:30:36 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 03 Jul 2008 09:30:36 -0700 Subject: [Xorp-users] Static joins In-Reply-To: <486BBFA2.5080002@icsi.berkeley.edu> References: <200807020000.m6200YRj001359@fruitcake.ICSI.Berkeley.EDU> <486BBFA2.5080002@icsi.berkeley.edu> Message-ID: <200807031630.m63GUaoa008253@fruitcake.ICSI.Berkeley.EDU> > James Courtier-Dutton wrote: > > I have an application than generates a tunN interface. > > XORP has this tunN interface as one of its PIM-SM/IGMP interfaces. > > Now, I need to find the easiest way to get XORP to output multicast > > traffic over this interface. > > One option is for my application to create and send IGMP messages > > towards the tunN interface. > > I was hoping that there might be a XRL interface directly into XORP > > that would simulate the IGMPs being received on the tunN interface by > > XORP so that I would not have to reimplement IGMP in my application. > > Do you know in advance the multicast group whose traffic needs to be replicated on tunN? If yes, in your application you can just join that group on interface tunN (I assume the application is running on the XORP host). E.g., you need to use setsockopt(..., IP_ADD_MEMBERSHIP, ...) if your application is in C/C++. Then the kernel will generate the IGMP Join message and XORP should forward the multicast data for that group on the tunN interface. If you don't know in advance the multicast groups and you want to forward all multicast traffic on tunN, then the solution would be different. Please clarify whether you need to forward all multicast groups or a small pre-defined set of known groups. Pavlin From minlanyu at cs.princeton.edu Sat Jul 5 15:15:11 2008 From: minlanyu at cs.princeton.edu (Minlan Yu) Date: Sat, 5 Jul 2008 18:15:11 -0400 Subject: [Xorp-users] AsyncFileWriter warning Message-ID: Hi, I tried to run xorp in openvz, and get the following warning: [ 2008/07/05 14:28:54 WARNING xorp_bgp:11322 LIBXORP +512 asyncio.cc write ] Write error 11 [ 2008/07/05 14:28:54 WARNING xorp_bgp:11322 LIBXORP +73 asyncio.cc is_pseudo_error ] AsyncFileWriter (fd = 17) got EWOULDBLOCK, continuing. Can anyone tell me what's wrong? or how can I figure it out? Thanks, -- Minlan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080705/6c118ffd/attachment.html From bms at incunabulum.net Sat Jul 5 17:47:52 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sun, 06 Jul 2008 01:47:52 +0100 Subject: [Xorp-users] AsyncFileWriter warning In-Reply-To: References: Message-ID: <48701638.8040806@incunabulum.net> Minlan Yu wrote: > Hi, > > I tried to run xorp in openvz, and get the following warning: > > [ 2008/07/05 14:28:54 WARNING xorp_bgp:11322 LIBXORP +512 asyncio.cc > write ] Write error 11 > [ 2008/07/05 14:28:54 WARNING xorp_bgp:11322 LIBXORP +73 asyncio.cc > is_pseudo_error ] AsyncFileWriter (fd = 17) got EWOULDBLOCK, continuing. > > Can anyone tell me what's wrong? or how can I figure it out? This error sounds fairly harmless, it just means that XORP tried to write to a file descriptor, and failed to do so as the intermediate file buffers were full. cheers BMS From damien.girard at odyssee-systemes.fr Mon Jul 7 02:58:42 2008 From: damien.girard at odyssee-systemes.fr (Damien Girard) Date: Mon, 07 Jul 2008 11:58:42 +0200 Subject: [Xorp-users] Multicast router: Everything is not working Message-ID: <1215424722.2891.14.camel@wsdev3.odyssee-systemes.fr> Hi all, I am a new user to xorp, and I have few problems with it. I am running Debian 4.0 (Etch), and I have installed the xorp package that comes from "testing" (Ver: 1.5~cvs.20080128-1) What I want to do is fairly simple: - Two network. 192.168.1.0/24 and 192.168.2.0/24 - Those two networks must be able to talk together using multicast protocol. - eth0 is connected on network 192.168.2.0/24 - eth1 is connected on network 192.168.1.0/24 Multicast is enabled in the kernel as the Xorp manual say. What I want to do is the following to test everything: VLC is playing a multicast stream from one network, the another network must show the video. The IP Address of the streaming multicast is : 239.255.0.1 ------------------------------------------------ My xorp configuration file: protocols { fib2mrib { } igmp { interface eth0 { vif eth0 { } } interface eth1 { vif eth1 { } } traceoptions { flag { all { } } } } pimsm4 { interface eth0 { vif eth0 { } } interface eth1 { vif eth1 { } } bootstrap { cand-bsr { scope-zone 224.0.0.0/4 { cand-bsr-by-vif-name: "eth0" } } cand-rp { group-prefix 224.0.0.0/4 { cand-rp-by-vif-name: "eth0" } } } switch-to-spt-threshold { bytes: 102400 } traceoptions { flag { all { } } } } } fea { unicast-forwarding4 { forwarding-entries { } } } interfaces { interface eth0 { description: "Ethernet Interface #1" default-system-config } interface eth1 { description: "Ethernet Interface #2" default-system-config } } plumbing { mfea4 { interface eth0 { vif eth0 { } } interface eth1 { vif eth1 { } } interface "register_vif" { vif "register_vif" { } } traceoptions { flag { all { } } } } } ------------------------------------------------ root at R1> show interfaces eth0/eth0: Flags: mtu 1500 inet 192.168.2.1 subnet 192.168.2.0/24 broadcast 192.168.2.255 physical index 2 ether 0:80:82:49:52:c2 eth1/eth1: Flags: mtu 1500 inet 192.168.1.109 subnet 192.168.1.0/24 broadcast 192.168.1.255 physical index 1 ether 0:80:82:49:52:c3 Multicast seem to be enabled on all interfaces. ------------------------------------------------ root at R1> show mfea interface Interface State Vif/PifIndex Addr Flags eth0 UP 0/2 192.168.2.1 MULTICAST BROADCAST KERN_UP eth1 UP 1/1 192.168.1.109 MULTICAST BROADCAST KERN_UP register_vif UP 2/2 192.168.2.1 PIM_REGISTER KERN_UP ------------------------------------------------ root at R1> show mfea dataflow Group Source 224.0.1.24 192.168.1.3 Measured(Start|Packets|Bytes) Type Thresh(Interval|Packets|Bytes) Remain 3540.952097|0|? <= 210.0|0|? 93.77190 239.255.0.1 192.168.1.101 Measured(Start|Packets|Bytes) Type Thresh(Interval|Packets|Bytes) Remain 3610.112892|68960|? <= 210.0|0|? 162.237985 239.255.0.1 is VLC Media player that is sending multicast packet on the network. So it detects it. ------------------------------------------------ root at R1> show pim join 239.255.0.1 192.168.1.101 192.168.2.1 SG DirectlyConnectedS Upstream interface (S): eth1 Upstream interface (RP): UNKNOWN Upstream MRIB next hop (RP): UNKNOWN Upstream MRIB next hop (S): UNKNOWN Upstream RPF'(S,G): UNKNOWN Upstream state: NotJoined Register state: RegisterNoinfo RegisterNotCouldRegister Join timer: -1 KAT(S,G) running: true Local receiver include WC: ... Local receiver include SG: ... Local receiver exclude SG: ... Joins RP: ... Joins WC: ... Joins SG: ... Join state: ... Prune state: ... Prune pending state: ... I am assert winner state: ... I am assert loser state: ... Assert winner WC: ... Assert winner SG: ... Assert lost WC: ... Assert lost SG: ... Assert lost SG_RPT: ... Assert tracking SG: ... Could assert WC: ... Could assert SG: ... I am DR: OOO Immediate olist RP: ... Immediate olist WC: ... Immediate olist SG: ... Inherited olist SG: ... Inherited olist SG_RPT: ... PIM include WC: ... PIM include SG: ... PIM exclude SG: ... As you seen, it really see the multicast. I do not know how interpret this result as I am not a network engineer. ------------------------------------------------ So, what I am asking is how make this configuration working. I navigated through the entire documentation multiple time and I did not found anything that helped me. Regards, -- Damien Girard Software Engineer Odyssee Systemes. From morten at workzone.no Mon Jul 7 06:17:26 2008 From: morten at workzone.no (Morten Pedersen) Date: Mon, 7 Jul 2008 15:17:26 +0200 (CEST) Subject: [Xorp-users] Supported hardware In-Reply-To: <709965170.269411215436404917.JavaMail.root@zmail> Message-ID: <1980359055.269591215436646154.JavaMail.root@zmail> Hello all. I am new to XORP and have a few questions. 1. Will XORP support 10 gigabit ethernet interfaces and 10 gigabit LX connections, or is this restricted to the underlying OS? 2. I am thinking about a redundant setup, with 2 x XORP BGP routers at one place, and another 2 x XORP BGP routers another place, talking OSPF between them for failover. Would this be feasible? Thanks, Morten Pedersen From bms at incunabulum.net Mon Jul 7 07:37:21 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon, 07 Jul 2008 15:37:21 +0100 Subject: [Xorp-users] Supported hardware In-Reply-To: <1980359055.269591215436646154.JavaMail.root@zmail> References: <1980359055.269591215436646154.JavaMail.root@zmail> Message-ID: <48722A21.9040506@incunabulum.net> Morten Pedersen wrote: > Hello all. > > I am new to XORP and have a few questions. > > 1. Will XORP support 10 gigabit ethernet interfaces and 10 gigabit LX connections, or is this restricted to the underlying OS? > The ixgb driver is going to be in the upcoming LiveCD, which will be based on FreeBSD 7.0-RELEASE. Requests for specific drivers to be included would be useful to have on the table now. There will be no special treatment of 10GBE interfaces in the FEA, at least for the time being -- folk are welcome to contribute. Of course actual driver support for such interfaces is entirely down to the OS which is used to host XORP (XORP is not an operating system). > 2. I am thinking about a redundant setup, with 2 x XORP BGP routers at one place, and another 2 x XORP BGP routers another place, talking OSPF between them for failover. Would this be feasible? > I'm not sure how you would plan to achieve failover beyond 1 hop with only OSPF. There's a case for HSRP or VRRP here if any end-stations (or non OSPF peers) are going to be on link. cheers BMS From greearb at candelatech.com Tue Jul 8 16:39:25 2008 From: greearb at candelatech.com (Ben Greear) Date: Tue, 08 Jul 2008 16:39:25 -0700 Subject: [Xorp-users] OSPFv3 problem? Message-ID: <4873FAAD.2020109@candelatech.com> I'm trying to add OSPFv3 (and v2 and multicast) support to one of my virtual routers. From the xorp-user guide, I think I have it configured correctly, but perhaps not. The error in the logs: [ 2008/07/08 16:31:39 ERROR xorp_rtrmgr:12359 RTRMGR main_rtrmgr.cc:330 run ] rtrmgr shutting down due to an init error: PARSE ERROR [Config File vr_conf/xorp-vr10001.conf, line 89]: No template found in template map; Last symbol parsed was "router-id" The ospfv6 section looks like: ospf6 { router-id: 127.1.0.1 area 0.0.0.0 { interface rddVR2 vif rddVR2 { } } interface rddVR1 vif rddVR1 { } } interface rddVR4 vif rddVR4 { } } } /* area */ } /* ospfv6 protocol */ The line 89 is the 'area 0.0.0.0 {' one. My config is attached. Any idea what I'm doing wrong? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorp-vr10001.conf Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080708/e32b32c0/attachment.ksh From greearb at candelatech.com Wed Jul 9 10:11:38 2008 From: greearb at candelatech.com (Ben Greear) Date: Wed, 09 Jul 2008 10:11:38 -0700 Subject: [Xorp-users] OSPFv3 problem? In-Reply-To: <4873FAAD.2020109@candelatech.com> References: <4873FAAD.2020109@candelatech.com> Message-ID: <4874F14A.4040805@candelatech.com> Ben Greear wrote: > I'm trying to add OSPFv3 (and v2 and multicast) support to one > of my virtual routers. > > From the xorp-user guide, I think I have it configured correctly, > but perhaps not. > > The error in the logs: > [ 2008/07/08 16:31:39 ERROR xorp_rtrmgr:12359 RTRMGR main_rtrmgr.cc:330 > run ] rtrmgr shutting down due to an init error: PARSE ERROR [Config > File vr_conf/xorp-vr10001.conf, line 89]: No template found in template > map; Last symbol parsed was "router-id" > > The ospfv6 section looks like: > > ospf6 { > router-id: 127.1.0.1 > area 0.0.0.0 { > interface rddVR2 > vif rddVR2 { > } > } Ok, so I had a bad syntax. An integer is needed after ospf6, as in: ospf6 0 { No idea what it means, but it's required. I was also missing an open parens after the interface foo { lines. Now xorp starts, but it doesn't seem to be populating IPv6 routes. This could be other issues with my setup, however..so I'll go off and try to debug that. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Wed Jul 9 11:17:50 2008 From: greearb at candelatech.com (Ben Greear) Date: Wed, 09 Jul 2008 11:17:50 -0700 Subject: [Xorp-users] OSPFv3 problem? In-Reply-To: <4874F14A.4040805@candelatech.com> References: <4873FAAD.2020109@candelatech.com> <4874F14A.4040805@candelatech.com> Message-ID: <487500CE.30900@candelatech.com> > Now xorp starts, but it doesn't seem to be populating IPv6 routes. > This could be other issues with my setup, however..so I'll go off > and try to debug that. For the record, it was my config problem (I wasn't adding ipv6 link-local addrs to the xorp config and forgot the fea table-id for unicast-forwarding6). But that is now fixed, and I have two virtual routers using unique routing-table IDs doing OSPFv3 and OSPFv2 (and IPv4 multicast routing just for kicks). Off to try more crazy things now! Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From atanu at ICSI.Berkeley.EDU Wed Jul 9 15:51:57 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 09 Jul 2008 15:51:57 -0700 Subject: [Xorp-users] Announcing XORP Release Candidate 1.5 Message-ID: <60045.1215643917@tigger.icir.org> On behalf of the entire XORP team, I'm delighted to announce the XORP 1.5 Release Candidate, which is now available from . New features in this release include preliminary firewall support, VLANs and BGP support for four-octet AS numbers. In addition, this release contains numerous bug fixes. Once the release candidate has proven to be stable, the actual 1.5 release will be prepared. This is planned to occur before the end of the month. In the intervening period we will be fixing minor problems and updating the documentation. In general, to test XORP, we run automated regression tests on a daily basis with various operating systems and compilers. We also run a number of PCs as XORP routers. We have enabled as many protocols as feasible on those routers to test protocol interactions (for example a BGP IPv6 multicast feed being used by PIM-SM). In addition, automated scripts are run to externally toggle BGP peerings. Finally, we have automated scripts that interact directly with the xorpsh to change the configuration settings. We have put significant effort into testing but obviously we have not found all the problems. This is where you can help us to make XORP more stable, by downloading and using it! As always we'd welcome your comments - xorp-users at xorp.org is the right place for general discussion, and private feedback to the XORP core team can be sent to feedback at xorp.org. - The XORP Team P.S. Release notes included below. ------------------------------------------------------------------ XORP RELEASE NOTES Release 1.5-RC (2008/07/08) =========================== ALL: - XORP now builds on DragonFlyBSD-1.10.1, Linux Fedora 7, Linux Fedora 8, Linux Debian-4.0 (etch), Linux Ubuntu-7.04, Linux Ubuntu-7.10, NetBSD-4.0, OpenBSD-4.1, and OpenBSD-4.2. CONFIGURATION: - Addition of new FEA configuration statements to set the IPv4/IPv6 unicast forwarding table IDs: fea { unicast-forwarding4 { table-id: 254 } unicast-forwarding6 { table-id: 254 } } If the table ID is not configured, the FEA will use the default table ID for the system. Note that not all systems support multiple forwarding tables. Currently, they exist only on Linux (among all systems supported by XORP). - The "DISCARD" network interface flag is printed as appropriate when displaying the list of interfaces in the CLI. - Addition of new FEA configuration statement to support "unreachable" interfaces. Such interfaces are similar to "discard" interfaces, except that instead of silently throwing away packets, the system will respond with "ICMP destination unreachable". interfaces { interface my_unreachable { unreachable: true vif my_unreachable { } } } The default value for the "unreachable" statement is false. - Addition of new FEA configuration statement to flag an interface for "management" purpose. An interface that is flagged as "management" might be used in the future by some of the protocols for protocol-specific purpose. interfaces { interface fxp0 { management: true vif fxp0 { address 10.10.10.10 { prefix-length: 24 } } } } The default value for the "management" statement is false. - Addition of support to configure VLANs on an interface. A VLAN is configured by using a "vlan" block that includes the VLAN ID: interfaces { interface fxp0 { vif fxp0 { address 10.10.10.10 { prefix-length: 24 } } vif vlan1 { vlan { vlan-id: 1 } address 10.10.20.20 { prefix-length: 24 } } } } - Addition of preliminary support to configure firewall rules. Firewall rules are configured by using numbered entries: firewall { rule4 100 { action: "drop" protocol: 6 /* TCP */ source { interface: "fxp0" vif: "fxp0" network: 0.0.0.0/0 port-begin: 0 port-end: 65535 } destination { network: 10.10.0.0/24 port-begin: 0 port-end: 1024 } } } Note that compiling firewall support on Linux systems require patching some of the system header files. See ERRATA for details. - The following PIM-SM configuration statements have been deprecated, because PIM-SM doesn't use Router Alert IP option anymore: protocols { pimsm4 { interface foo { vif foo { enable-ip-router-alert-option-check: true } } } } protocols { pimsm6 { interface foo { vif foo { enable-ip-router-alert-option-check: true } } } } LIBXORP: - The local system-independent xorp_random() implemenation is used instead of the random(3) provided by the system. - Improved MAC address support (classes Mac and EtherMac). - More consistent usage of XORP_OK and XORP_ERROR to return error codes. LIBXIPC: - Bug fix in the internal mechanism for obtaining the IPv4 addresses from the system. After the bug fix, a secondary (alias) IP address can be specified with the "-i " command-line option to the xorp_rtrmgr or xorp_finder binaries. LIBFEACLIENT: - No significant changes. XRL: - Critical bug fix that can be triggered by malformatted XRLs. - Addition of support for 64-bit integers: i64 and u64 for signed and unsigned respectively. RTRMGR: - Addition of preliminary mechanism to log events to a file or to a syslog facility. - Addition of support to run XORP in background (in daemon mode). XORPSH: - Bug fix related to assigning the node ID position in case the previous (sibling) node was deleted at the same time a new node was added. This fixes "Found out-of-order term(s) inside policy ..." error inside the policy manager. - The "-c " command line option can be used more than once to run multiple commands. - Fix a long configuration delay when using xorpsh in non-interactive mode (e.g., "cat commands.txt | xorpsh"). - Addition of a new "-e" command line option. It can be used to tell xorpsh to exit immediately if the connection to the Finder fails. POLICY: - No significant changes. FEA/MFEA: - Major refactoring of the FEA/MFEA internals. - Critical bug fix that affects recent NetBSD and OpenBSD releases. - Critical IPv6-related bug fix when adding unicast forwarding entries to the kernel. This bug was exposed only on *BSD systems with 64-bit CPU. - If MFEA is started, it will explicitly enable the multicast forwarding flags that have been added to recent OpenBSD releases: net.inet.ip.mforwarding (for OpenBSD-3.9 and later) and net.inet6.ip6.mforwarding (for OpenBSD-4.0 and later). RIB: - No significant changes. RIP/RIPng: - Addition of support for "show ripng" xorpsh operational commands. - Critical RIPng-related bug fix. Previously the RIPng installed routes had incorrect outgoing interface toward the destination. - Bug fix related to the TTL for RIPng multicast packets: now it is set to 255 as specified in the protocol specification (RFC 2080) instead of 1. OSPF: - Bug fix related to OSPFv3 link-local scope LSAs. Previously the link-local scope LSAs were incorrectly flooded to links other than the one they belonged to. - Bug fix related to OSPFv3 Inter-Area-Prefix-LSAs. The check for the minimum size of an Inter-Area-Prefix-LSA was incorrect so short prefixes such as the default route would be rejected. - Added a clear database command. - In the OSPFv2 configuration "passive" is no longer a bool but a directive. Previously setting an interface to passive would set the interface to loopback and announce a host route for the interface. Using the passive keyword will still set the interface to loopback but now the network will be announced. If the previous behaviour of of announcing the host route is required the host variable can be set to true. BGP: - Added support for 4-byte AS numbers, as detailed in RFC 4893. From 1st Jan 2009 4-byte AS numbers will be allocated by default by RIPE, so it is desirable that all BGP implementations support four-byte AS numbers by that time. Currently 4-byte support is not enabled in XORP by default, but can be enabled using the "enable-4byte-as-numbers" configuration option. STATIC_ROUTES: - Bug fix that prevented the deletion of interface-specific routes using xorpsh. MLD/IGMP: - No significant changes. PIM-SM: - No significant changes. FIB2MRIB: - No significant changes. CLI: - No significant changes. SNMP: - No significant changes. From pavlin at ICSI.Berkeley.EDU Wed Jul 9 18:22:07 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 09 Jul 2008 18:22:07 -0700 Subject: [Xorp-users] Multicast router: Everything is not working In-Reply-To: <1215424722.2891.14.camel@wsdev3.odyssee-systemes.fr> References: <1215424722.2891.14.camel@wsdev3.odyssee-systemes.fr> Message-ID: <200807100122.m6A1M7xF026078@fruitcake.ICSI.Berkeley.EDU> What is the output of "show igmp group"? It looks like that the PIM-SM module hasn't received IGMP membership information for group 239.255.0.1 on the interface toward the receiver. BTW, in your setup you might want to consider a static RP instead of using the Bootstrap mechanism: it is simpler to understand/debug and on startup you don't have to wait until things are converged. E.g., remove the whole "bootstrap" section and replace it with: static-rps { rp 192.168.2.1 { group-prefix 224.0.0.0/4 { } } } Pavlin Damien Girard wrote: > Hi all, > > I am a new user to xorp, and I have few problems with it. > > I am running Debian 4.0 (Etch), and I have installed the xorp package > that comes from "testing" (Ver: 1.5~cvs.20080128-1) > > What I want to do is fairly simple: > - Two network. 192.168.1.0/24 and 192.168.2.0/24 > - Those two networks must be able to talk together using multicast > protocol. > > - eth0 is connected on network 192.168.2.0/24 > - eth1 is connected on network 192.168.1.0/24 > > Multicast is enabled in the kernel as the Xorp manual say. > > What I want to do is the following to test everything: > > VLC is playing a multicast stream from one network, the another network > must show the video. The IP Address of the streaming multicast is : > 239.255.0.1 > > ------------------------------------------------ > My xorp configuration file: > > protocols { > fib2mrib { > } > igmp { > interface eth0 { > vif eth0 { > } > } > interface eth1 { > vif eth1 { > } > } > traceoptions { > flag { > all { > } > } > } > } > pimsm4 { > interface eth0 { > vif eth0 { > } > } > interface eth1 { > vif eth1 { > } > } > bootstrap { > cand-bsr { > scope-zone 224.0.0.0/4 { > cand-bsr-by-vif-name: "eth0" > } > } > cand-rp { > group-prefix 224.0.0.0/4 { > cand-rp-by-vif-name: "eth0" > } > } > } > switch-to-spt-threshold { > bytes: 102400 > } > traceoptions { > flag { > all { > } > } > } > } > } > fea { > unicast-forwarding4 { > forwarding-entries { > } > } > } > interfaces { > interface eth0 { > description: "Ethernet Interface #1" > default-system-config > } > interface eth1 { > description: "Ethernet Interface #2" > default-system-config > } > } > plumbing { > mfea4 { > interface eth0 { > vif eth0 { > } > } > interface eth1 { > vif eth1 { > } > } > interface "register_vif" { > vif "register_vif" { > } > } > traceoptions { > flag { > all { > } > } > } > } > } > > ------------------------------------------------ > root at R1> show interfaces > > eth0/eth0: Flags: mtu 1500 > inet 192.168.2.1 subnet 192.168.2.0/24 broadcast 192.168.2.255 > physical index 2 > ether 0:80:82:49:52:c2 > eth1/eth1: Flags: mtu 1500 > inet 192.168.1.109 subnet 192.168.1.0/24 broadcast 192.168.1.255 > physical index 1 > ether 0:80:82:49:52:c3 > > Multicast seem to be enabled on all interfaces. > > ------------------------------------------------ > root at R1> show mfea interface > > Interface State Vif/PifIndex Addr Flags > eth0 UP 0/2 192.168.2.1 MULTICAST BROADCAST > KERN_UP > eth1 UP 1/1 192.168.1.109 MULTICAST BROADCAST > KERN_UP > register_vif UP 2/2 192.168.2.1 PIM_REGISTER KERN_UP > > ------------------------------------------------ > root at R1> show mfea dataflow > > Group > Source > 224.0.1.24 > 192.168.1.3 > Measured(Start|Packets|Bytes) Type Thresh(Interval|Packets|Bytes) > Remain > 3540.952097|0|? <= 210.0|0|? > 93.77190 > 239.255.0.1 > 192.168.1.101 > Measured(Start|Packets|Bytes) Type Thresh(Interval|Packets|Bytes) > Remain > 3610.112892|68960|? <= 210.0|0|? > 162.237985 > > > 239.255.0.1 is VLC Media player that is sending multicast packet on the > network. So it detects it. > > ------------------------------------------------ > root at R1> show pim join > 239.255.0.1 192.168.1.101 192.168.2.1 SG DirectlyConnectedS > Upstream interface (S): eth1 > Upstream interface (RP): UNKNOWN > Upstream MRIB next hop (RP): UNKNOWN > Upstream MRIB next hop (S): UNKNOWN > Upstream RPF'(S,G): UNKNOWN > Upstream state: NotJoined > Register state: RegisterNoinfo RegisterNotCouldRegister > Join timer: -1 > KAT(S,G) running: true > Local receiver include WC: ... > Local receiver include SG: ... > Local receiver exclude SG: ... > Joins RP: ... > Joins WC: ... > Joins SG: ... > Join state: ... > Prune state: ... > Prune pending state: ... > I am assert winner state: ... > I am assert loser state: ... > Assert winner WC: ... > Assert winner SG: ... > Assert lost WC: ... > Assert lost SG: ... > Assert lost SG_RPT: ... > Assert tracking SG: ... > Could assert WC: ... > Could assert SG: ... > I am DR: OOO > Immediate olist RP: ... > Immediate olist WC: ... > Immediate olist SG: ... > Inherited olist SG: ... > Inherited olist SG_RPT: ... > PIM include WC: ... > PIM include SG: ... > PIM exclude SG: ... > > > As you seen, it really see the multicast. I do not know how interpret > this result as I am not a network engineer. > > ------------------------------------------------ > > So, what I am asking is how make this configuration working. I navigated > through the entire documentation multiple time and I did not found > anything that helped me. > > Regards, > > -- > Damien Girard > Software Engineer > Odyssee Systemes. > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From atanu at ICSI.Berkeley.EDU Wed Jul 9 18:36:36 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 09 Jul 2008 18:36:36 -0700 Subject: [Xorp-users] OSPFv3 problem? In-Reply-To: Message from Ben Greear of "Wed, 09 Jul 2008 10:11:38 PDT." <4874F14A.4040805@candelatech.com> Message-ID: <74888.1215653796@tigger.icir.org> Hi, The integer is an instance ID, in the future it will be possible to run multiple instances of OSPFv3. At the moment only a a single instance can be run but you can select that instance value. Atanu. Ben Greear wrote: > Ben Greear wrote: > > I'm trying to add OSPFv3 (and v2 and multicast) support to one > > of my virtual routers. > > > > From the xorp-user guide, I think I have it configured correctly, > > but perhaps not. > > > > The error in the logs: > > [ 2008/07/08 16:31:39 ERROR xorp_rtrmgr:12359 RTRMGR main_rtrmgr.cc:330 > > run ] rtrmgr shutting down due to an init error: PARSE ERROR [Config > > File vr_conf/xorp-vr10001.conf, line 89]: No template found in template > > map; Last symbol parsed was "router-id" > > > > The ospfv6 section looks like: > > > > ospf6 { > > router-id: 127.1.0.1 > > area 0.0.0.0 { > > interface rddVR2 > > vif rddVR2 { > > } > > } > > Ok, so I had a bad syntax. > > An integer is needed after ospf6, as in: > > ospf6 0 { > > No idea what it means, but it's required. > > I was also missing an open parens after the interface foo { > lines. > > Now xorp starts, but it doesn't seem to be populating IPv6 routes. > This could be other issues with my setup, however..so I'll go off > and try to debug that. > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From yuchi18 at gmail.com Wed Jul 9 20:11:41 2008 From: yuchi18 at gmail.com (chi yu) Date: Thu, 10 Jul 2008 11:11:41 +0800 Subject: [Xorp-users] is any plan for implement IS-IS protocol ? Message-ID: <51e46f600807092011r269a5367v4a7e10ccbeb0c7d1@mail.gmail.com> As 1.5 RC released , how about IS-IS protocol ? looking forward to it for quite long time , it dosen't have any plan yet ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080710/813d6613/attachment.html From pavlin at ICSI.Berkeley.EDU Wed Jul 9 20:59:29 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 09 Jul 2008 20:59:29 -0700 Subject: [Xorp-users] is any plan for implement IS-IS protocol ? In-Reply-To: <51e46f600807092011r269a5367v4a7e10ccbeb0c7d1@mail.gmail.com> References: <51e46f600807092011r269a5367v4a7e10ccbeb0c7d1@mail.gmail.com> Message-ID: <200807100359.m6A3xTQl017643@fruitcake.ICSI.Berkeley.EDU> chi yu wrote: > As 1.5 RC released , how about IS-IS protocol ? > looking forward to it for quite long time , it dosen't have any plan yet ? Yes, IS-IS is on our TODO list, but we haven't scheduled it yet. Pavlin From greearb at candelatech.com Thu Jul 10 17:49:28 2008 From: greearb at candelatech.com (Ben Greear) Date: Thu, 10 Jul 2008 17:49:28 -0700 Subject: [Xorp-users] [Xorp-hackers] Announcing XORP Release Candidate 1.5 In-Reply-To: <60045.1215643917@tigger.icir.org> References: <60045.1215643917@tigger.icir.org> Message-ID: <4876AE18.7060509@candelatech.com> Atanu Ghosh wrote: > On behalf of the entire XORP team, I'm delighted to announce the XORP > 1.5 Release Candidate, which is now available from . > > New features in this release include preliminary firewall > support, VLANs and BGP support for four-octet AS numbers. I want to say thanks for all the hard work. The stability and feature sets for weirder configurations (such as my own) has improved greatly in the last year. I'm currently digging into BGP and ipv6 multicast routing. Do you happen to have an updated user-guide for 1.5? I'll be happy to help proof read and debug it for you... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at ICSI.Berkeley.EDU Thu Jul 10 18:32:38 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 10 Jul 2008 18:32:38 -0700 Subject: [Xorp-users] [Xorp-hackers] Announcing XORP Release Candidate 1.5 In-Reply-To: <4876AE18.7060509@candelatech.com> References: <60045.1215643917@tigger.icir.org> <4876AE18.7060509@candelatech.com> Message-ID: <200807110133.m6B1WcrJ022663@fruitcake.ICSI.Berkeley.EDU> > I'm currently digging into BGP and ipv6 multicast routing. Do you happen > to have an updated user-guide for 1.5? I'll be happy to help proof read > and debug it for you... The user-guide changes will happen between now and the release itself. Content-wise there will be relatively few changes. It will be great if you can proof read and debug it. Which implies that we should make the changes sooner to give extra time for proof reading. Thanks, Pavlin From morten at workzone.no Mon Jul 14 06:10:19 2008 From: morten at workzone.no (Morten Pedersen) Date: Mon, 14 Jul 2008 15:10:19 +0200 (CEST) Subject: [Xorp-users] Anyone using XORP in live production environment with big traffic load? In-Reply-To: <1658137375.311831216040768833.JavaMail.root@zmail> Message-ID: <1028954482.311851216041019709.JavaMail.root@zmail> I guess the header says it all. We are currently using a couple of Cisco 7206 for our BGP routing, but need to upgrade to something with more bandwith. Therefore, I was thinking about XORP as a cheaper alternative. I am planning to go for a configuration with two identical servers for failover: One 2U server with: 2 x PCI Express x16 1 x PCI Express x8 2 x 2 port 10Gbit fibre network cards 1 x quad 1Gbit ethernet network card My question is, will this be viable? Also, should I go for AMD or Intel? I need to keep in mind that my servers must be able to handle around 50Gbit of network traffic, so the choice of databus is important I guess. Another issue is the network cards. I am planning on using Intel network cards. Anyone with some ideas on this? Thanks, Morten From M.Handley at cs.ucl.ac.uk Mon Jul 14 06:40:37 2008 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Mon, 14 Jul 2008 14:40:37 +0100 Subject: [Xorp-users] Anyone using XORP in live production environment with big traffic load? In-Reply-To: <1028954482.311851216041019709.JavaMail.root@zmail> References: <1658137375.311831216040768833.JavaMail.root@zmail> <1028954482.311851216041019709.JavaMail.root@zmail> Message-ID: <84a612dd0807140640h29172391o453c46c720998eb7@mail.gmail.com> My guess is that you might have trouble forwarding 50Gb/s, primarily because you will hit memory bottlenecks. We've not used any 10Gig cards (we didn't have access to a polling driver for Click for these cards), but with 12 x 1Gig ports in a box, we can saturate all 12 bi-directionally with 1024byte packets, but with minimum sized packets we top out around 7Mpps. This is primarily due to memory latency issues. I can send you a draft research paper, if it's helpful to you. So, the real question if you want to consider software forwarding at these speeds on commodity hardware is what sort of traffic mix to you need to handle? - Mark On Mon, Jul 14, 2008 at 2:10 PM, Morten Pedersen wrote: > I guess the header says it all. > > We are currently using a couple of Cisco 7206 for our BGP routing, but need to upgrade to something with more bandwith. Therefore, I was thinking about XORP as a cheaper alternative. I am planning to go for a configuration with two identical servers for failover: > > One 2U server with: > 2 x PCI Express x16 > 1 x PCI Express x8 > 2 x 2 port 10Gbit fibre network cards > 1 x quad 1Gbit ethernet network card > > My question is, will this be viable? Also, should I go for AMD or Intel? I need to keep in mind that my servers must be able to handle around 50Gbit of network traffic, so the choice of databus is important I guess. Another issue is the network cards. I am planning on using Intel network cards. > > Anyone with some ideas on this? > > Thanks, > > Morten > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From morten at workzone.no Mon Jul 14 06:53:41 2008 From: morten at workzone.no (Morten Pedersen) Date: Mon, 14 Jul 2008 15:53:41 +0200 (CEST) Subject: [Xorp-users] Anyone using XORP in live production environment with big traffic load? In-Reply-To: <84a612dd0807140640h29172391o453c46c720998eb7@mail.gmail.com> Message-ID: <2048367151.312701216043621318.JavaMail.root@zmail> Ouch. I didn't consider memory latency, that will of course be a issue. I would be interested in reading your draft research paper. We might get into trouble here, since we have a mix of both regular web-traffic together with unicast video and audio streams in different formats :( Thanks, Morten ----- Original Message ----- From: "Mark Handley" To: "Morten Pedersen" Cc: xorp-users at xorp.org Sent: Monday, July 14, 2008 3:40:37 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [Xorp-users] Anyone using XORP in live production environment with big traffic load? My guess is that you might have trouble forwarding 50Gb/s, primarily because you will hit memory bottlenecks. We've not used any 10Gig cards (we didn't have access to a polling driver for Click for these cards), but with 12 x 1Gig ports in a box, we can saturate all 12 bi-directionally with 1024byte packets, but with minimum sized packets we top out around 7Mpps. This is primarily due to memory latency issues. I can send you a draft research paper, if it's helpful to you. So, the real question if you want to consider software forwarding at these speeds on commodity hardware is what sort of traffic mix to you need to handle? - Mark On Mon, Jul 14, 2008 at 2:10 PM, Morten Pedersen wrote: > I guess the header says it all. > > We are currently using a couple of Cisco 7206 for our BGP routing, but need to upgrade to something with more bandwith. Therefore, I was thinking about XORP as a cheaper alternative. I am planning to go for a configuration with two identical servers for failover: > > One 2U server with: > 2 x PCI Express x16 > 1 x PCI Express x8 > 2 x 2 port 10Gbit fibre network cards > 1 x quad 1Gbit ethernet network card > > My question is, will this be viable? Also, should I go for AMD or Intel? I need to keep in mind that my servers must be able to handle around 50Gbit of network traffic, so the choice of databus is important I guess. Another issue is the network cards. I am planning on using Intel network cards. > > Anyone with some ideas on this? > > Thanks, > > Morten > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From charles at thewybles.com Mon Jul 14 07:42:05 2008 From: charles at thewybles.com (Charles Wyble) Date: Mon, 14 Jul 2008 07:42:05 -0700 Subject: [Xorp-users] Anyone using XORP in live production environment with big traffic load? In-Reply-To: <1028954482.311851216041019709.JavaMail.root@zmail> References: <1028954482.311851216041019709.JavaMail.root@zmail> Message-ID: <487B65BD.2010300@thewybles.com> Morten Pedersen wrote: > I guess the header says it all. > Hello Morten, Indeed the header does sayit all. :) > We are currently using a couple of Cisco 7206 for our BGP routing, but need to upgrade to something with more bandwith. How much bandwidth are you currently supporting? How much are you planning to support? > Therefore, I was thinking about XORP as a cheaper alternative. Xorp does seem like an interesting platform that provides a viable low cost alternative to Cisco/Juniper kit. > I am planning to go for a configuration with two identical servers for failover: > > One 2U server with: > 2 x PCI Express x16 > 1 x PCI Express x8 > Not sure what the x16 and x8 mean in the above? > 2 x 2 port 10Gbit fibre network cards > 1 x quad 1Gbit ethernet network card > So which would be your ingress? The 1Gbit cards? Network core would be the 2 x 2 port 10Gbit cards = 40Gbps? A bit more info about your current and desired setup would be most appreciated. :) Are you going to run the server pair active/active or active/passive? > My question is, will this be viable? Hmmmm. Good question. More and more Cisco kit is X86 processor based, running a Linux hypervisor. (like my ASA kit which is a 1GBPS network). So I would say that a commodity hardware based router is viable. You might also want to check out adding some FPGA interface cards to the mix. Check out http://www.invea-tech.com/fpga/boards for some hardware which you may be interested in. I am currently in talks with this vendor for a service provider network I am building. I am evaluating Quagga and Xorp for the management plane. > Also, should I go for AMD or Intel? Hmmmm. Well that's a very interesting question. Cisco went with Intel Xeon in the ASA. I prefer AMD kit myself. Naturally you will want 64bit CPU. Most likely dual proc/dual core. Also at least 2 gigs of high speed RAM. I would also recommend a solid state disk with a SCSI or SATA back plane. The popular server vendors may or may not offer this. You can buy the enterprise grade SSD from 3rd party manufacturers. Let me know if you want a contact. You could also go the ramdisk route. Throw in say 4 or 6 gigs of RAM. That would be incredibly fast and power efficient. > I need to keep in mind that my servers must be able to handle around 50Gbit of network traffic, Hence the 2x2 10Gbps fiber ports I presume. > so the choice of databus is important I guess. Another issue is the network cards. I am planning on using Intel network cards. > I hear good things about them. Might be best to search around on the mailing lists and poke through the driver source code of the 10gbps cards before making the choice. > Anyone with some ideas on this? > I think I qualify. Haha! :) > Thanks, > > Morten > Thank you for starting a very interesting thread. Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project From M.Handley at cs.ucl.ac.uk Mon Jul 14 08:14:42 2008 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Mon, 14 Jul 2008 16:14:42 +0100 Subject: [Xorp-users] Anyone using XORP in live production environment with big traffic load? In-Reply-To: <2048367151.312701216043621318.JavaMail.root@zmail> References: <84a612dd0807140640h29172391o453c46c720998eb7@mail.gmail.com> <2048367151.312701216043621318.JavaMail.root@zmail> Message-ID: <84a612dd0807140814qe3dfa98m9ef43bb380c824@mail.gmail.com> Ok, as a rough rule of thumb: You need a minimum of about ten memory access to forward a packet (three for the NIC to receive (DMA of data + buffer descriptor r/w), three to transmit, and four for the CPU to look at the packet and set up DMA). Likely you need a few more than this if you've a non-trivial forwarding table, decrement TTL, etc - ten is for simple L2 forwarding. The best case for non-burst transfer of data to/from memory is you pay the CAS latency. On the DDR2 memory we have, CL=5, and the memory bus speed is 333MHz (ie 3ns per clock). That's 15ns latency per memory access (assuming accesses are independent, but you don't have to change RAS). If you get no memory parallelism, ten memory accesses ties up the memory bus for 150ns per packet, which gives 6.7Mpps. Of course this argument glosses over lots of details about how modern memory subsystems work, so it's not completely accurate, but it gives you some idea of the ballpark numbers, and it matches pretty well the actual numbers we get for Click forwarding (about 7.1Mpps). Large packets cost a little more than small ones, but you usually get to burst transfer the bytes, so they don't cost all that much more (at least not in memory latency). These numbers also assume you've got a bunch of cores doing SMP (if not, you'll be CPU limited instead), and you set things up so as not to copy packets from core to core unless they share an L2 cache. You ought to be able to do better on a AMD NUMA box than on an Intel uniform memory architecture box if you're smart about paralllelizing memory access, but our preliminary numbers are actually worse, so presumably we're doing something wrong. - Mark On Mon, Jul 14, 2008 at 2:53 PM, Morten Pedersen wrote: > Ouch. > > I didn't consider memory latency, that will of course be a issue. I would be interested in reading your draft research paper. We might get into trouble here, since we have a mix of both regular web-traffic together with unicast video and audio streams in different formats :( > > Thanks, > > Morten > > ----- Original Message ----- > From: "Mark Handley" > To: "Morten Pedersen" > Cc: xorp-users at xorp.org > Sent: Monday, July 14, 2008 3:40:37 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: Re: [Xorp-users] Anyone using XORP in live production environment with big traffic load? > > My guess is that you might have trouble forwarding 50Gb/s, primarily > because you will hit memory bottlenecks. > > We've not used any 10Gig cards (we didn't have access to a polling > driver for Click for these cards), but with 12 x 1Gig ports in a box, > we can saturate all 12 bi-directionally with 1024byte packets, but > with minimum sized packets we top out around 7Mpps. This is primarily > due to memory latency issues. I can send you a draft research paper, > if it's helpful to you. > > So, the real question if you want to consider software forwarding at > these speeds on commodity hardware is what sort of traffic mix to you > need to handle? > > - Mark > > On Mon, Jul 14, 2008 at 2:10 PM, Morten Pedersen wrote: >> I guess the header says it all. >> >> We are currently using a couple of Cisco 7206 for our BGP routing, but need to upgrade to something with more bandwith. Therefore, I was thinking about XORP as a cheaper alternative. I am planning to go for a configuration with two identical servers for failover: >> >> One 2U server with: >> 2 x PCI Express x16 >> 1 x PCI Express x8 >> 2 x 2 port 10Gbit fibre network cards >> 1 x quad 1Gbit ethernet network card >> >> My question is, will this be viable? Also, should I go for AMD or Intel? I need to keep in mind that my servers must be able to handle around 50Gbit of network traffic, so the choice of databus is important I guess. Another issue is the network cards. I am planning on using Intel network cards. >> >> Anyone with some ideas on this? >> >> Thanks, >> >> Morten >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> > From dirk.schulz at kinzesberg.de Mon Jul 14 12:44:54 2008 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Mon, 14 Jul 2008 21:44:54 +0200 Subject: [Xorp-users] Virtual IP on Router Cluster Message-ID: Hi folks, I have setup two routers running xorp with ospf4 (connected to two upstream routers), and everything works fine so far. Now I want the internal interfaces to run a virtual IP address as active/passive cluster (so that my servers behind my routers have a clustered gateway address that automatically switches in case of a router breakdown). I have configured this with heartbeat, and it works, too. I am stuck at adding the virtual IP address to the xorp's ospf4 config. If I do not add it, the servers using the virtual IP as gateway lose connections to the outside. But how do I add a virtual IP to the config? I have tried simply adding it to the vif configuration. This is what I did: area 0.0.0.0 { area-type: "normal" interface bond0 { vif bond0 { address MAIN.IP.ADDR.ESS { priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 2 retransmit-interval: 2 transit-delay: 1 disable: false } address SECOND.IP.ADDR.ESS { priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 2 retransmit-interval: 2 transit-delay: 1 disable: false } } } } This seems not to work, at least routing through the virtual gateway does not work. There must be something I overlook. Any hint or help is appreciated. Dirk From M.Handley at cs.ucl.ac.uk Mon Jul 14 14:44:49 2008 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Mon, 14 Jul 2008 22:44:49 +0100 Subject: [Xorp-users] Anyone using XORP in live production environment with big traffic load? In-Reply-To: <2048367151.312701216043621318.JavaMail.root@zmail> References: <84a612dd0807140640h29172391o453c46c720998eb7@mail.gmail.com> <2048367151.312701216043621318.JavaMail.root@zmail> Message-ID: <84a612dd0807141444u4a371e29ob193af92fdfa2c0c@mail.gmail.com> On Mon, Jul 14, 2008 at 2:53 PM, Morten Pedersen wrote: > Ouch. > > I didn't consider memory latency, that will of course be a issue. I would be interested in reading your draft research paper. We might get into trouble here, since we have a mix of both regular web-traffic together with unicast video and audio streams in different formats :( I've put a draft of our virtual routers paper here: http://nrg.cs.ucl.ac.uk/mjh/tmp/vrouter-perf.pdf The main focus of the paper is on virtualization, but the first half of the paper is mostly about the performance of generic software routers. - Mark From charles at thewybles.com Mon Jul 14 15:02:13 2008 From: charles at thewybles.com (Charles Wyble) Date: Mon, 14 Jul 2008 15:02:13 -0700 Subject: [Xorp-users] Anyone using XORP in live production environment with big traffic load? In-Reply-To: <84a612dd0807141444u4a371e29ob193af92fdfa2c0c@mail.gmail.com> References: <84a612dd0807140640h29172391o453c46c720998eb7@mail.gmail.com> <2048367151.312701216043621318.JavaMail.root@zmail> <84a612dd0807141444u4a371e29ob193af92fdfa2c0c@mail.gmail.com> Message-ID: <487BCCE5.1080803@thewybles.com> Mark Handley wrote: > > The main focus of the paper is on virtualization, but the first half > of the paper is mostly about the performance of generic software > routers. > Mark, Thank you so much for this!!! Its exactly what I was looking for just this morning (benchmarks on software router performance). Much appreciated! -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project From morten at workzone.no Tue Jul 15 00:44:28 2008 From: morten at workzone.no (Morten Pedersen) Date: Tue, 15 Jul 2008 09:44:28 +0200 (CEST) Subject: [Xorp-users] Anyone using XORP in live production environment with big traffic load? In-Reply-To: <318146397.315781216107846223.JavaMail.root@zmail> Message-ID: <1806205851.315801216107868751.JavaMail.root@zmail> Thanks Mark. This is exactly what I was looking for. I also were planning on going for a Dell 2950, but obviously need to use some more time finding the correct system. I had a brief look at todays number of packets, and can foresee approx. 2-4Mpps for the next 3-5 years. We have a general mix of all packet-sizes, giving us approx. 1Mpps for 10Gbit of traffic. Thus, I shouldn't go over the 7Mpps limit as described in your paper. Since I am planning on two dual 10Gbit network cards, I need at least two PCI Express 1.1 x16 (number of lanes) to be able to take the bandwith. PCIe 1.1 x16 can handle 32Gbit of total bandwith. What needs more research from my point of view now, is the following: * AMD vs Intel. It seems obvious that L2 cache is critical. I need to see which quad core processor gives me the most. * Intel 10Gbit network cards. Will I run into issues here? As described earlier, I am planning on setting this up in a production environment, building two similar XORP software routers. They will serve a mix of all packet sizes, and do BGP routing. I am thinking about using iBGP between the two routers to have them syncronized at all times. If one goes down, the other can take over immediately. Each router is connected to Norways Internet eXhange switch, but resides at two physical locations. We already have this up and running using Cisco equipment, should be possible to do it with XORP as well. I'll get back to this when I start writing the config for it. If anyone have more input to me about this, I would appreciate it. Also, if XORP is mature enough to be used in a live production environment. Still haven't heard of anyone using it ;-) Thanks, Morten ----- Original Message ----- From: "Mark Handley" To: "Morten Pedersen" Cc: "xorp-users" Sent: Monday, July 14, 2008 11:44:49 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [Xorp-users] Anyone using XORP in live production environment with big traffic load? On Mon, Jul 14, 2008 at 2:53 PM, Morten Pedersen wrote: > Ouch. > > I didn't consider memory latency, that will of course be a issue. I would be interested in reading your draft research paper. We might get into trouble here, since we have a mix of both regular web-traffic together with unicast video and audio streams in different formats :( I've put a draft of our virtual routers paper here: http://nrg.cs.ucl.ac.uk/mjh/tmp/vrouter-perf.pdf The main focus of the paper is on virtualization, but the first half of the paper is mostly about the performance of generic software routers. - Mark From bms at incunabulum.net Tue Jul 15 04:13:13 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue, 15 Jul 2008 12:13:13 +0100 Subject: [Xorp-users] Virtual IP on Router Cluster In-Reply-To: References: Message-ID: <487C8649.6010603@incunabulum.net> Dirk H. Schulz wrote: > I am stuck at adding the virtual IP address to the xorp's ospf4 config. If > I do not add it, the servers using the virtual IP as gateway lose > connections to the outside. > But how do I add a virtual IP to the config? > Which protocol are you using for failover (I assume FreeVRRP) ? Currently XORP has no builtin support for these interfaces, they have to be configured up outside of XORP, and then the IP address of the virtual interface must be added to your FEA interfaces {} configuration block. cheers BMS From greearb at candelatech.com Tue Jul 15 08:50:59 2008 From: greearb at candelatech.com (Ben Greear) Date: Tue, 15 Jul 2008 08:50:59 -0700 Subject: [Xorp-users] Anyone using XORP in live production environment with big traffic load? In-Reply-To: <1806205851.315801216107868751.JavaMail.root@zmail> References: <1806205851.315801216107868751.JavaMail.root@zmail> Message-ID: <487CC763.9090907@candelatech.com> Morten Pedersen wrote: > Thanks Mark. This is exactly what I was looking for. > > I also were planning on going for a Dell 2950, but obviously need to use some more time finding the correct system. > > I had a brief look at todays number of packets, and can foresee approx. 2-4Mpps for the next 3-5 years. We have a general mix of all packet-sizes, giving us approx. 1Mpps for 10Gbit of traffic. > > Thus, I shouldn't go over the 7Mpps limit as described in your paper. > > Since I am planning on two dual 10Gbit network cards, I need at least two PCI Express 1.1 x16 (number of lanes) to be able to take the bandwith. > > PCIe 1.1 x16 can handle 32Gbit of total bandwith. > > What needs more research from my point of view now, is the following: > > * AMD vs Intel. It seems obvious that L2 cache is critical. I need to see which quad core processor gives me the most. > * Intel 10Gbit network cards. Will I run into issues here? > I haven't done exhaustive testing, but so far Intel pci-e 10G NICs are the most stable and the best performers in my testing (on Linux). I get dual-port NICs with these chipsets from silicom-usa.com, btw. I'm not sure if there are any improvements by getting Intel branded NICs, but it's possible. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From dirk.schulz at kinzesberg.de Tue Jul 15 10:12:52 2008 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Tue, 15 Jul 2008 19:12:52 +0200 Subject: [Xorp-users] Virtual IP on Router Cluster In-Reply-To: <487C8649.6010603@incunabulum.net> References: <487C8649.6010603@incunabulum.net> Message-ID: <2911BEFAC4FB356D248FE373@ip-77-24-60-64.web.vodafone.de> Hi Bruce, --On 15. Juli 2008 12:13:13 +0100 Bruce M Simpson wrote: > Dirk H. Schulz wrote: >> I am stuck at adding the virtual IP address to the xorp's ospf4 config. >> If I do not add it, the servers using the virtual IP as gateway lose >> connections to the outside. >> But how do I add a virtual IP to the config? >> > > Which protocol are you using for failover (I assume FreeVRRP) ? This is done with Heartbeat (Linux-HA). What would be the advantage of FreeVRRP? > > Currently XORP has no builtin support for these interfaces, they have to > be configured up outside of XORP, They are. > and then the IP address of the virtual > interface must be added to your FEA interfaces {} configuration block. Well, the interfaces are configured as "default-system-config" in the interfaces {} block, the fea {} block contains only the forwarding config, and the ip addresses are configured in the ospf4 {} block of the protocols {} block. I have taken that from the "Getting Started" document on xorp.org. Do you suppose to use a different structure? And the question remains: How do I make an additional IP address on a certain interface known to xorp? Thanks for helping! Dirk > > cheers > BMS -------------------------------------------------------------- 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 Wed Jul 16 11:23:24 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 16 Jul 2008 11:23:24 -0700 Subject: [Xorp-users] Power Outage Message-ID: <19473.1216232604@tigger.icir.org> Hi, For unexplained PG&E's will be removing power from ICSI where the XORP servers reside. We will therefore be shutting down the servers today Wednesday 16th July at 17:00PDT (UTC -8), the power is supposed to be restored tomorrow Thursday 17th July 6:00PDT. We will bring the servers back up as soon as power is restored. The mirror sites will still be available. Atanu. From bms at incunabulum.net Wed Jul 16 14:24:45 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed, 16 Jul 2008 22:24:45 +0100 Subject: [Xorp-users] Virtual IP on Router Cluster In-Reply-To: <2911BEFAC4FB356D248FE373@ip-77-24-60-64.web.vodafone.de> References: <487C8649.6010603@incunabulum.net> <2911BEFAC4FB356D248FE373@ip-77-24-60-64.web.vodafone.de> Message-ID: <487E671D.7070500@incunabulum.net> Dirk H. Schulz wrote: >> >> Which protocol are you using for failover (I assume FreeVRRP) ? > > This is done with Heartbeat (Linux-HA). What would be the advantage of > FreeVRRP? OK. Not familiar with Linux-HA. I imagine they perform much the same function i.e. failover functionality is dealt with by its own protocol. > > Well, the interfaces are configured as "default-system-config" in the > interfaces {} block, the fea {} block contains only the forwarding > config, and the ip addresses are configured in the ospf4 {} block of > the protocols {} block. I have taken that from the "Getting Started" > document on xorp.org. > Do you suppose to use a different structure? Please try manual configuration -- it's entirely possible that XORP may be somehow confused by the type of interface the Linux kernel exposes to the FEA for the Linux-HA interface. I'd be interested to know if other folk have had similar experiences with FreeVRRP or CARP. > > And the question remains: How do I make an additional IP address on a > certain interface known to xorp? A single vif can have multiple IP addresses; please refer to the user manual for configuration of multiple IP addresses. thanks! BMS From baaaaad.boy at gmail.com Wed Jul 16 16:03:28 2008 From: baaaaad.boy at gmail.com (abdelali) Date: Wed, 16 Jul 2008 23:03:28 +0000 Subject: [Xorp-users] I do not have the bin directory after compiling and making xorp ! Message-ID: <756635d40807161603p747bb70qc3bcb007b2892d4f@mail.gmail.com> hello I have a serious problem so please help me ! I downloaded xorp with different ways ( stable 1.4 version, the latest from cvs, the package from ubuntu... ) I tried to install it in different linux distributions as Fedora core 5, 7, 8 and ubuntu 7.10 and JeOS ubuntu. The problem is that I can't start the xorp_rtrmgr and the message is what the class xorp_main() gives and it is XrlRouter no finder? and now I know the origin of the problem; it's because I don't have programs in xorp or more precisely I don't have the bin directory in /usr/local/xorp directory !!!! to install the last xorp from cvs, I downloaded it and put it in the /usr/local directory, I passed to root account to have all permissions and ./configure and make (before that, I installed all the missed packages and headers (gcc, ssl...) following the xorp build_note. I didn't do the make check this last time because for the others times I didn't look for the bin directory and now I still have this problem and don't know its origin. today I installed the FreeBSD to try xorp on but I think I must know where the problem is !!! for informations I use VMware workstation 5.5 on a Toshiba Satellite L40-12k with a dual core pentium processor. I have a friend who works with the same VMware in other machine and he says that all works fine ! thanks a lot for any suggestion. I am really in an impasse. Abdelali Master MRGI Student. -- Apprendre et faire apprendre... c'est notre destin? en fin de compte !! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080716/18d23bac/attachment.html From pavlin at ICSI.Berkeley.EDU Wed Jul 16 18:40:36 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 16 Jul 2008 18:40:36 -0700 Subject: [Xorp-users] Virtual IP on Router Cluster In-Reply-To: <487E671D.7070500@incunabulum.net> References: <487C8649.6010603@incunabulum.net> <2911BEFAC4FB356D248FE373@ip-77-24-60-64.web.vodafone.de> <487E671D.7070500@incunabulum.net> Message-ID: <200807170140.m6H1ea8C015818@fruitcake.ICSI.Berkeley.EDU> Bruce M Simpson wrote: > Dirk H. Schulz wrote: > > Well, the interfaces are configured as "default-system-config" in the > > interfaces {} block, the fea {} block contains only the forwarding > > config, and the ip addresses are configured in the ospf4 {} block of > > the protocols {} block. I have taken that from the "Getting Started" > > document on xorp.org. > > Do you suppose to use a different structure? According to the XORP User Manual (Section 8.3 Configuring OSPF, page 84): --------------------- The OSPFv2 and OSPFv3 configurations are practically equivalent with the following exceptions: ... * OSPFv2 supports a single address per interface/vif, therefore all parameters are set below the address node. --------------------- In other words, you can't have more than one IP address in the ospf4 block. You might want to rethink your setup and see whether you can achieve it with a single OSPF address. Pavlin > Please try manual configuration -- it's entirely possible that XORP may > be somehow confused by the type of interface the Linux kernel exposes to > the FEA for the Linux-HA interface. > > I'd be interested to know if other folk have had similar experiences > with FreeVRRP or CARP. > > > > > And the question remains: How do I make an additional IP address on a > > certain interface known to xorp? > > A single vif can have multiple IP addresses; please refer to the user > manual for configuration of multiple IP addresses. > > thanks! > BMS > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From dirk.schulz at kinzesberg.de Wed Jul 16 21:44:27 2008 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Thu, 17 Jul 2008 06:44:27 +0200 Subject: [Xorp-users] Virtual IP on Router Cluster In-Reply-To: <200807170140.m6H1ea8C015818@fruitcake.ICSI.Berkeley.EDU> References: <487C8649.6010603@incunabulum.net> <2911BEFAC4FB356D248FE373@ip-77-24-60-64.web.vodafone.de> <487E671D.7070500@incunabulum.net> <200807170140.m6H1ea8C015818@fruitcake.ICSI.Berkeley.EDU> Message-ID: <2B07A12399940B0AB9F965AA@file.wkd-druck.org> Pavlin, --On 16. Juli 2008 18:40:36 -0700 Pavlin Radoslavov wrote: - snip - > Bruce M Simpson wrote: > > * OSPFv2 supports a single address per interface/vif, therefore all > parameters are set below the address node. > --------------------- > > In other words, you can't have more than one IP address in the > ospf4 block. Thanks very much for that! I have really overread it. > > You might want to rethink your setup and see whether you can achieve > it with a single OSPF address. Okay then, would it work with alias interfaces like eth0:0? They are run as separate interfaces. I did not find any hint on how ospfv2 in XORP deals with alias interfaces. Guess I have to just test it. Thanks a lot for helping. Dirk > > Pavlin > >> Please try manual configuration -- it's entirely possible that XORP may >> be somehow confused by the type of interface the Linux kernel exposes to >> the FEA for the Linux-HA interface. >> >> I'd be interested to know if other folk have had similar experiences >> with FreeVRRP or CARP. >> >> > >> > And the question remains: How do I make an additional IP address on a >> > certain interface known to xorp? >> >> A single vif can have multiple IP addresses; please refer to the user >> manual for configuration of multiple IP addresses. >> >> thanks! >> BMS >> >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From dirk.schulz at kinzesberg.de Wed Jul 16 21:52:03 2008 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Thu, 17 Jul 2008 06:52:03 +0200 Subject: [Xorp-users] Virtual IP on Router Cluster In-Reply-To: <487E671D.7070500@incunabulum.net> References: <487C8649.6010603@incunabulum.net> <2911BEFAC4FB356D248FE373@ip-77-24-60-64.web.vodafone.de> <487E671D.7070500@incunabulum.net> Message-ID: <3B7566E8356CA24870E1A1D6@file.wkd-druck.org> --On 16. Juli 2008 22:24:45 +0100 Bruce M Simpson wrote: Like Pavlin said, ospfv2 can only make use one address per interface. > I'd be interested to know if other folk have had similar experiences with > FreeVRRP or CARP. Then I would like to know how people using VRRP are doing it? Do you use interface aliases, or some scripts to switch the single ip address ospfv2 can handle? Is there anybody out there using VRRP together with OSPF? Dirk From greearb at candelatech.com Wed Jul 16 23:09:18 2008 From: greearb at candelatech.com (Ben Greear) Date: Wed, 16 Jul 2008 23:09:18 -0700 Subject: [Xorp-users] Virtual IP on Router Cluster In-Reply-To: <3B7566E8356CA24870E1A1D6@file.wkd-druck.org> References: <487C8649.6010603@incunabulum.net> <2911BEFAC4FB356D248FE373@ip-77-24-60-64.web.vodafone.de> <487E671D.7070500@incunabulum.net> <3B7566E8356CA24870E1A1D6@file.wkd-druck.org> Message-ID: <487EE20E.4070207@candelatech.com> Dirk H. Schulz wrote: > --On 16. Juli 2008 22:24:45 +0100 Bruce M Simpson > wrote: > > Like Pavlin said, ospfv2 can only make use one address per interface. > > >> I'd be interested to know if other folk have had similar experiences with >> FreeVRRP or CARP. >> > > Then I would like to know how people using VRRP are doing it? Do you use > interface aliases, or some scripts to switch the single ip address ospfv2 > can handle? > Is there anybody out there using VRRP together with OSPF? > If you're using Linux, you might could use MAC-VLANs as they are a real interface as far as the OS (and xorp) is concerned, but to the outside world they appear somewhat as a virtual IP address. Thanks, Ben > Dirk > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at ICSI.Berkeley.EDU Thu Jul 17 11:08:08 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 17 Jul 2008 11:08:08 -0700 Subject: [Xorp-users] Virtual IP on Router Cluster In-Reply-To: <2B07A12399940B0AB9F965AA@file.wkd-druck.org> References: <487C8649.6010603@incunabulum.net> <2911BEFAC4FB356D248FE373@ip-77-24-60-64.web.vodafone.de> <487E671D.7070500@incunabulum.net> <200807170140.m6H1ea8C015818@fruitcake.ICSI.Berkeley.EDU> <2B07A12399940B0AB9F965AA@file.wkd-druck.org> Message-ID: <200807171808.m6HI89jj019068@fruitcake.ICSI.Berkeley.EDU> > > You might want to rethink your setup and see whether you can achieve > > it with a single OSPF address. > > Okay then, would it work with alias interfaces like eth0:0? They are run as > separate interfaces. I did not find any hint on how ospfv2 in XORP deals > with alias interfaces. > Guess I have to just test it. The Linux alias interfaces like eth0:0 are not real interfaces. It is just how ifconfig prints the IP aliases. E.g., if you use "ip addr" you won't see them. You might want to try using VLANs as Ben suggested. FYI, VLANs are supported in XORP-1.5-RC, and the RELEASE_NOTES contains an example how to configure a VLAN using XORP (the User Manual is not updated yet). Of course, you could also configure the VLANs before starting XORP, and in that case you won't need the "vlan" block under the "vif" node. If having interfaces/vifs named eth0/vlan1 and eth0/vlan2 doesn't help you at the OSPF level, you could try to use XORP interfaces/vifs named vlan1/vlan1 and vlan2/vlan2, but in that case you must configure the VLANs before starting XORP. Pavlin From bms at incunabulum.net Fri Jul 18 03:38:15 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Fri, 18 Jul 2008 11:38:15 +0100 Subject: [Xorp-users] Announcement: OLSR support in XORP 1.5 Message-ID: <48807297.6060309@incunabulum.net> Hi, This is just a brief announcement to let everyone know about the OLSR implementation which will be in the XORP 1.5 release. CenGen, Inc. generously funded the development of an RFC 3626 Optimized Link State Routing (OLSR) implementation over late 2007 and early 2008. This code has been made available under the XORP license. Currently it is in the contrib/olsr directory, is a configure-time option, and is a fully fledged XORP routing process. Route redistribution is supported and I understand CenGen had success with exporting into OSPF in their testbed. The code has some limitations, in particular, it does not currently support the ETX link metric feature ('link quality' in olsrd), however it could do so with some changes. Other than that, it interworks successfully with the olsrd.org implementation. I'd also be interested to hear from folk interested in porting features from Joe Macker's NRL implementation of OLSR. The regression testing is pretty thorough, though as is always the case with building a routing protocol, it can be difficult, if not impossible, to exercise all possible combinations of protocol state which can result. In particular the MPR behaviour could do with 3rd party review. I would very much like to hear from anyone who is interested in using XORP to build mesh network solutions with the XORP/OLSR code base (currently we have folk from UCL doing so), so we can gauge interest in the code going forward, and establish what lies in the future as regards support. many thanks BMS From dirk.schulz at kinzesberg.de Fri Jul 18 05:27:42 2008 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Fri, 18 Jul 2008 14:27:42 +0200 Subject: [Xorp-users] Virtual IP on Router Cluster In-Reply-To: <200807171808.m6HI89jj019068@fruitcake.ICSI.Berkeley.EDU> References: <487C8649.6010603@incunabulum.net> <2911BEFAC4FB356D248FE373@ip-77-24-60-64.web.vodafone.de> <487E671D.7070500@incunabulum.net> <200807170140.m6H1ea8C015818@fruitcake.ICSI.Berkeley.EDU> <2B07A12399940B0AB9F965AA@file.wkd-druck.org> <200807171808.m6HI89jj019068@fruitcake.ICSI.Berkeley.EDU> Message-ID: <6EE74339D5E03C121E26281B@Dirks-MacBook-Pro.local> Hello Pavlin, I have setup the cluster software to use interface aliases (like eth0:0) and configured these in xorp.conf, and now everything works as I wanted it to do. I get the virtual IP listet in xorpsh (show interfaces), and routing via the virtual IP works. Thanks to all who helped! Dirk --On 17. Juli 2008 11:08:08 -0700 Pavlin Radoslavov wrote: >> > You might want to rethink your setup and see whether you can achieve >> > it with a single OSPF address. >> >> Okay then, would it work with alias interfaces like eth0:0? They are run >> as separate interfaces. I did not find any hint on how ospfv2 in XORP >> deals with alias interfaces. >> Guess I have to just test it. > > The Linux alias interfaces like eth0:0 are not real interfaces. > It is just how ifconfig prints the IP aliases. > E.g., if you use "ip addr" you won't see them. > > You might want to try using VLANs as Ben suggested. > > FYI, VLANs are supported in XORP-1.5-RC, and the RELEASE_NOTES > contains an example how to configure a VLAN using XORP (the User > Manual is not updated yet). > Of course, you could also configure the VLANs before starting XORP, > and in that case you won't need the "vlan" block under the "vif" > node. > > If having interfaces/vifs named eth0/vlan1 and eth0/vlan2 doesn't > help you at the OSPF level, you could try to use XORP > interfaces/vifs named vlan1/vlan1 and vlan2/vlan2, but in that case > you must configure the VLANs before starting XORP. > > Pavlin -------------------------------------------------------------- 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 pavlin at ICSI.Berkeley.EDU Fri Jul 18 16:20:40 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 18 Jul 2008 16:20:40 -0700 Subject: [Xorp-users] [Xorp-hackers] Announcing XORP Release Candidate 1.5 In-Reply-To: <200807110133.m6B1WcrJ022663@fruitcake.ICSI.Berkeley.EDU> References: <60045.1215643917@tigger.icir.org> <4876AE18.7060509@candelatech.com> <200807110133.m6B1WcrJ022663@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200807182321.m6INKeVM015068@fruitcake.ICSI.Berkeley.EDU> Pavlin Radoslavov wrote: > > I'm currently digging into BGP and ipv6 multicast routing. Do you happen > > to have an updated user-guide for 1.5? I'll be happy to help proof read > > and debug it for you... Ben, You can get a preliminary version of the new XORP User Manual from http://www.icir.org/pavlin/.private/xorp/user_manual.pdf There might be few more things that will change in the manual before the release, but those probably will be minor. It will be great if you (and anybody else) can provide provide feedback. Thanks, Pavlin From bms at incunabulum.net Sat Jul 19 16:33:50 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sun, 20 Jul 2008 00:33:50 +0100 Subject: [Xorp-users] I do not have the bin directory after compiling and making xorp ! In-Reply-To: <756635d40807161603p747bb70qc3bcb007b2892d4f@mail.gmail.com> References: <756635d40807161603p747bb70qc3bcb007b2892d4f@mail.gmail.com> Message-ID: <488279DE.7030003@incunabulum.net> Hi, abdelali wrote: > hello > I have a serious problem so please help me ! > I downloaded xorp with different ways ( stable 1.4 version, the latest > from cvs, the package from ubuntu... ) I tried to install it in > different linux distributions as Fedora core 5, 7, 8 and ubuntu 7.10 > and JeOS ubuntu. > The problem is that I can't start the xorp_rtrmgr and the message is > what the class xorp_main() gives and it is XrlRouter no finder? and > now I know the origin of the problem; it's because I don't have > programs in xorp or more precisely I don't have the bin directory in > /usr/local/xorp directory !!!! I can't speak for the Ubuntu distros or others as I'm not familiar with their packaging systems -- cvs source for xorp is another matter... > > to install the last xorp from cvs, I downloaded it and put it in the > /usr/local directory, I passed to root account to have all permissions > and ./configure and make (before that, I installed all the missed > packages and headers (gcc, ssl...) following the xorp build_note. You could try doing a "find /usr/local -type f -name xorp_bgp" command to try to establish if the packaging system(s) installed XORP in an unexpected location. Unless you have something unusual in your shell environment, the "make install" target of the XORP top level GNU makefile should "just work". Please send us the output of the "env" command from the shell you're attempting to install XORP from. > > I didn't do the make check this last time because for the others times > I didn't look for the bin directory and now I still have this problem > and don't know its origin. today I installed the FreeBSD to try xorp > on but I think I must know where the problem is !!! Not doing the "make check" for a production install of a released version is fine. Thanks BMS From dirk.schulz at kinzesberg.de Sun Jul 20 09:26:49 2008 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Sun, 20 Jul 2008 18:26:49 +0200 Subject: [Xorp-users] Configure in xorpsh Message-ID: Hi folks, according to documentation it should suffice to put a user into the "xorp" group to enable him/her to use configure in xorpsh. I have tried that with root and an underprivileged user, but in both cases xorpsh rebukes: "ERROR: You do not have permission for this operation." What else do I have to do to enable a user to use configure? Thanks for any hint or help, Dirk From bms at incunabulum.net Sun Jul 20 09:48:32 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sun, 20 Jul 2008 17:48:32 +0100 Subject: [Xorp-users] Configure in xorpsh In-Reply-To: References: Message-ID: <48836C60.80401@incunabulum.net> Dirk H. Schulz wrote: > Hi folks, > > according to documentation it should suffice to put a user into the "xorp" > group to enable him/her to use configure in xorpsh. > > I have tried that with root and an underprivileged user, but in both cases > xorpsh rebukes: "ERROR: You do not have permission for this operation." > > What else do I have to do to enable a user to use configure? > Quick questions: Which OS? Did you restart the router manager after adding the user(s) to group xorp? Did you logout and run xorpsh from new shell sessions after adding the user(s) to group xorp? thanks BMS From dirk.schulz at kinzesberg.de Sun Jul 20 10:13:56 2008 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Sun, 20 Jul 2008 19:13:56 +0200 Subject: [Xorp-users] Configure in xorpsh In-Reply-To: <48836C60.80401@incunabulum.net> References: <48836C60.80401@incunabulum.net> Message-ID: Hi Bruce, --On 20. Juli 2008 17:48:32 +0100 Bruce M Simpson wrote: > Dirk H. Schulz wrote: >> Hi folks, >> >> according to documentation it should suffice to put a user into the >> "xorp" group to enable him/her to use configure in xorpsh. >> >> I have tried that with root and an underprivileged user, but in both >> cases xorpsh rebukes: "ERROR: You do not have permission for this >> operation." >> >> What else do I have to do to enable a user to use configure? >> > > Quick questions: > Which OS? Centos 5.2, xorp is from dag wieers rpm > Did you restart the router manager after adding the user(s) to group xorp? No. I will test that. > Did you logout and run xorpsh from new shell sessions after adding the > user(s) to group xorp? I logged into xorpsh after adding the users. I am the only one to use xorpsh. Now I have restarted the xorp router manager, and I cannot login into xorpsh any more. This is what I get: Waiting for xorp_rtrmgr... [ 2008/07/20 19:12:04 ERROR xorpsh:8906 RTRMGR +90 xorpsh_main.cc wait_for_xrl_router_ready ] XrlRouter failed. No Finder? [ 2008/07/20 19:12:04 ERROR xorpsh:8906 RTRMGR +897 xorpsh_main.cc main ] xorpsh exiting due to an init error: Failed to connect to the router manager There is a remark in the manual about xorp router manager having to be able to write to /tmp. This should not be a problem. Thanks for your help. Dirk From pavlin at ICSI.Berkeley.EDU Mon Jul 21 11:21:11 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Mon, 21 Jul 2008 11:21:11 -0700 Subject: [Xorp-users] Configure in xorpsh In-Reply-To: References: <48836C60.80401@incunabulum.net> Message-ID: <200807211821.m6LILBb6014867@fruitcake.ICSI.Berkeley.EDU> Dirk H. Schulz wrote: > Hi Bruce, > > --On 20. Juli 2008 17:48:32 +0100 Bruce M Simpson > wrote: > > > Dirk H. Schulz wrote: > >> Hi folks, > >> > >> according to documentation it should suffice to put a user into the > >> "xorp" group to enable him/her to use configure in xorpsh. > >> > >> I have tried that with root and an underprivileged user, but in both > >> cases xorpsh rebukes: "ERROR: You do not have permission for this > >> operation." > >> > >> What else do I have to do to enable a user to use configure? > >> > > > > Quick questions: > > Which OS? > > Centos 5.2, xorp is from dag wieers rpm > > > Did you restart the router manager after adding the user(s) to group xorp? > > No. I will test that. > > > Did you logout and run xorpsh from new shell sessions after adding the > > user(s) to group xorp? > > I logged into xorpsh after adding the users. I am the only one to use > xorpsh. > > Now I have restarted the xorp router manager, and I cannot login into > xorpsh any more. This is what I get: > > Waiting for xorp_rtrmgr... > [ 2008/07/20 19:12:04 ERROR xorpsh:8906 RTRMGR +90 xorpsh_main.cc > wait_for_xrl_router_ready ] XrlRouter failed. No Finder? > [ 2008/07/20 19:12:04 ERROR xorpsh:8906 RTRMGR +897 xorpsh_main.cc main ] > xorpsh exiting due to an init error: Failed to connect to the router manager Are you restarting the rtrmgr using the startup rc scripts that come with the RPM? You might want to double-check that the restart worked and the rtrmgr process is actually running after the restart. For simplicity of debugging, you might want to consider starting the rtrmgr by hand: /path/to/rtrmgr -b /path/to/config.boot Pavlin > There is a remark in the manual about xorp router manager having to be able > to write to /tmp. This should not be a problem. > > Thanks for your help. > > Dirk > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From dirk.schulz at kinzesberg.de Mon Jul 21 12:20:30 2008 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Mon, 21 Jul 2008 21:20:30 +0200 Subject: [Xorp-users] Configure in xorpsh In-Reply-To: <200807211821.m6LILBb6014867@fruitcake.ICSI.Berkeley.EDU> References: <48836C60.80401@incunabulum.net> <200807211821.m6LILBb6014867@fruitcake.ICSI.Berkeley.EDU> Message-ID: <5E7E87B3B910DC2C0B4DEEBF@file.wkd-druck.org> Thanks, Pavlin, for pointing me to something obvious - I should have checked THAT by myself. --On 21. Juli 2008 11:21:11 -0700 Pavlin Radoslavov wrote: - snip - > Are you restarting the rtrmgr using the startup rc scripts that come > with the RPM? > You might want to double-check that the restart worked and the > rtrmgr process is actually running after the restart. > For simplicity of debugging, you might want to consider starting the > rtrmgr by hand: /path/to/rtrmgr -b /path/to/config.boot The router manager had not started up again because of some misconfig I had made. Now that it runs again I can enter configuration mode. Sorry for asking first instead of thinking more on it. :-) Dirk From tushar.mehta at einfochips.com Mon Jul 21 22:03:21 2008 From: tushar.mehta at einfochips.com (Tushar Mehta) Date: Tue, 22 Jul 2008 10:33:21 +0530 Subject: [Xorp-users] getting problem in IGMPv3 XORP behavior Message-ID: <48856A19.3070700@einfochips.com> I am currently facing problem in the XORP regarding IGMPv3 protocol. I want to check whether XORP router is sending the IGMPv3 report when you send IGMP General Query without router alert option. It should not send IGMPv3 report when it get the General Query with router alert option in the IP header as per the rfc-3376 In my it is sending the IGMPv3 report. this is the problem i am getting now. also when i am sending IGMPv3 report without router alert option XORP is accepting it and making appropriate entry in multicast routing table. It should not do that as per rfc-3376 so where is the problem lies. here i am sending the configuration file that i am using for my setup. -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. _____________________________________________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config.boot.sample_igmp Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080722/91612287/attachment.ksh From tushar.mehta at einfochips.com Mon Jul 21 22:15:50 2008 From: tushar.mehta at einfochips.com (Tushar Mehta) Date: Tue, 22 Jul 2008 10:45:50 +0530 Subject: [Xorp-users] How to decide Unsolicited Report Interval in IGMPv3 XORP Message-ID: <48856D06.1090802@einfochips.com> Can anyone tell me how i can find the Unsolicited Report Interval that is used when any IGMP host use while transmitting state change record? according to the rfc-3376: - To cover the possibility of the State-Change Report being missed by one or more multicast routers, it is retransmitted [Robustness Variable] - 1 more times, at intervals chosen at random from the range (0, [Unsolicited Report Interval]). - Unsolicited Report Interval The Unsolicited Report Interval is the time between repetitions of a host's initial report of membership in a group. Default: 1 second. by default Unsolicited Report Interval should be 1 but XORP is not following it. it is picking up this interval randamly. i m attaching the configuration file that i am using for my set up. -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. _____________________________________________________________________ From bms at incunabulum.net Tue Jul 22 02:32:46 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue, 22 Jul 2008 10:32:46 +0100 Subject: [Xorp-users] getting problem in IGMPv3 XORP behavior In-Reply-To: <48856A19.3070700@einfochips.com> References: <48856A19.3070700@einfochips.com> Message-ID: <4885A93E.8070902@incunabulum.net> Tushar Mehta wrote: > I am currently facing problem in the XORP regarding IGMPv3 protocol. > I want to check whether XORP router is sending the IGMPv3 report when > you send IGMP General Query without router alert option. > It should not send IGMPv3 report when it get the General Query with > router alert option in the IP header as per the rfc-3376 > In my it is sending the IGMPv3 report. this is the problem i am > getting now. I'm confused by the above. Are you running XORP as a multicast router? Sending a General Query to a IGMPv3 querier or router shouldn't matter. Or are you having problems with XORP as a multicast end-station? > > also when i am sending IGMPv3 report without router alert option XORP > is accepting it and making appropriate entry in multicast routing table. > It should not do that as per rfc-3376 Which OS are you using? That would be a big help -- the processing of IGMPv3 reports is dependent upon raw sockets and that's an OS specific thing. thanks BMS From bms at incunabulum.net Tue Jul 22 02:34:39 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue, 22 Jul 2008 10:34:39 +0100 Subject: [Xorp-users] How to decide Unsolicited Report Interval in IGMPv3 XORP In-Reply-To: <48856D06.1090802@einfochips.com> References: <48856D06.1090802@einfochips.com> Message-ID: <4885A9AF.9050203@incunabulum.net> Tushar Mehta wrote: > Can anyone tell me how i can find the Unsolicited Report Interval that > is used when any IGMP host use while transmitting state change record? > > ... > by default Unsolicited Report Interval should be 1 but XORP is not > following it. it is picking up this interval randamly. > The URI is subject to jitter, as are most IGMPv3 protocol timers. It isn't in any of the packets, it sits only in the end station's IP stack. URI is entirely specific to the IGMPv3 host mode implementation. You don't specify which OS is showing this behaviour so it's difficult to give useful feedback here. cheers BMS From tushar.mehta at einfochips.com Tue Jul 22 04:12:49 2008 From: tushar.mehta at einfochips.com (Tushar Mehta) Date: Tue, 22 Jul 2008 16:42:49 +0530 Subject: [Xorp-users] How to decide Unsolicited Report Interval in IGMPv3 XORP In-Reply-To: <4885A9AF.9050203@incunabulum.net> References: <48856D06.1090802@einfochips.com> <4885A9AF.9050203@incunabulum.net> Message-ID: <4885C0B1.7040704@einfochips.com> sorry i forgot to mention the OS on which my XORP IGMPv3 is running thank you for your reply it is 2.6.18-1.2798 fc6xen(Fedora 6) OS which XORP IGMPv3 is running Bruce M Simpson wrote: > Tushar Mehta wrote: >> Can anyone tell me how i can find the Unsolicited Report Interval >> that is used when any IGMP host use while transmitting state change >> record? >> >> ... >> by default Unsolicited Report Interval should be 1 but XORP is not >> following it. it is picking up this interval randamly. >> > > The URI is subject to jitter, as are most IGMPv3 protocol timers. It > isn't in any of the packets, it sits only in the end station's IP stack. > > URI is entirely specific to the IGMPv3 host mode implementation. You > don't specify which OS is showing this behaviour so it's difficult to > give useful feedback here. > > cheers > BMS > > > Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com > > -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. _____________________________________________________________________ From tushar.mehta at einfochips.com Tue Jul 22 04:29:08 2008 From: tushar.mehta at einfochips.com (Tushar Mehta) Date: Tue, 22 Jul 2008 16:59:08 +0530 Subject: [Xorp-users] getting problem in IGMPv3 XORP behavior In-Reply-To: <4885A93E.8070902@incunabulum.net> References: <48856A19.3070700@einfochips.com> <4885A93E.8070902@incunabulum.net> Message-ID: <4885C484.3070605@einfochips.com> here my setup design is attached. My IGMPv3 router is running and is attached with host via switch. IGMPv3 is running on XORP. just for checking i am sending a IGMP General Query(without router alert option) from Host machine to XORP router. in this case it should not reply by sending IGMPv3 report but it is replying in my case. now re you getting my setup or problem? Bruce M Simpson wrote: > Tushar Mehta wrote: >> I am currently facing problem in the XORP regarding IGMPv3 protocol. >> I want to check whether XORP router is sending the IGMPv3 report when >> you send IGMP General Query without router alert option. >> It should not send IGMPv3 report when it get the General Query with >> router alert option in the IP header as per the rfc-3376 >> In my it is sending the IGMPv3 report. this is the problem i am >> getting now. > > I'm confused by the above. Are you running XORP as a multicast router? > Sending a General Query to a IGMPv3 querier or router shouldn't matter. > > Or are you having problems with XORP as a multicast end-station? > >> >> also when i am sending IGMPv3 report without router alert option XORP >> is accepting it and making appropriate entry in multicast routing table. >> It should not do that as per rfc-3376 > > Which OS are you using? That would be a big help -- the processing of > IGMPv3 reports is dependent upon raw sockets and that's an OS specific > thing. > > thanks > BMS > > > Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com > > -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. _____________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.jpg Type: image/jpeg Size: 27756 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080722/395f8f0c/attachment-0001.jpg From tushar.mehta at einfochips.com Tue Jul 22 04:52:37 2008 From: tushar.mehta at einfochips.com (Tushar Mehta) Date: Tue, 22 Jul 2008 17:22:37 +0530 Subject: [Xorp-users] getting problem in IGMPv3 XORP behavior In-Reply-To: <4885C484.3070605@einfochips.com> References: <48856A19.3070700@einfochips.com> <4885A93E.8070902@incunabulum.net> <4885C484.3070605@einfochips.com> Message-ID: <4885CA05.2000203@einfochips.com> on host machine i am using RHEL 4 and the XORP side i am using Fedora Core 6 Tushar Mehta wrote: > here my setup design is attached. > > My IGMPv3 router is running and is attached with host via switch. > IGMPv3 is running on XORP. > just for checking i am sending a IGMP General Query(without router > alert option) from Host machine to XORP router. > in this case it should not reply by sending IGMPv3 report but it is > replying in my case. > > now re you getting my setup or problem? > > > Bruce M Simpson wrote: >> Tushar Mehta wrote: >>> I am currently facing problem in the XORP regarding IGMPv3 protocol. >>> I want to check whether XORP router is sending the IGMPv3 report >>> when you send IGMP General Query without router alert option. >>> It should not send IGMPv3 report when it get the General Query with >>> router alert option in the IP header as per the rfc-3376 >>> In my it is sending the IGMPv3 report. this is the problem i am >>> getting now. >> >> I'm confused by the above. Are you running XORP as a multicast >> router? Sending a General Query to a IGMPv3 querier or router >> shouldn't matter. >> >> Or are you having problems with XORP as a multicast end-station? >> >>> >>> also when i am sending IGMPv3 report without router alert option >>> XORP is accepting it and making appropriate entry in multicast >>> routing table. >>> It should not do that as per rfc-3376 >> >> Which OS are you using? That would be a big help -- the processing of >> IGMPv3 reports is dependent upon raw sockets and that's an OS >> specific thing. >> >> thanks >> BMS >> >> >> Email Scanned for Virus & Dangerous Content by : >> www.CleanMailGateway.com >> >> > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. _____________________________________________________________________ From viney.khera at ipvidnet.com Mon Jul 21 18:14:21 2008 From: viney.khera at ipvidnet.com (Viney Khera) Date: Mon, 21 Jul 2008 18:14:21 -0700 Subject: [Xorp-users] Multicast not working Message-ID: <29b76190807211814r4017a425y73f8b9dbaa80c728@mail.gmail.com> Hi, I'm new to Xorp router, i want to configure xorp routers for multicasting. I want to route multicast packets through the routers. I began with a simple network and unicasting worked on it, but i don't know why multicast is not working. Please any one can look at the configuration of my routers and tell me what's wrong? Here is what my network looks like : 2 xorp routers PC's running on XORP version: Release-1.4 live cd's, one connected to transmitting video source and other to the recieving VLC streaming PC. Routers WAN side connected to the cisco switch. Transmitter Receiver | | XORP Router 1 XORP Router 2 | | |-------------Cisco Switch---------------| *Here is the configuration of 1st Router : * /*XORP Configuration File, v1.0*/ protocols { igmp { disable: false interface bge0 { vif bge0 { disable: false version: 2 enable-ip-router-alert-option-check: false query-interval: 125 query-last-member-interval: 1 query-response-interval: 10 robust-count: 2 } } interface bge1 { vif bge1 { disable: false version: 2 enable-ip-router-alert-option-check: false query-interval: 125 query-last-member-interval: 1 query-response-interval: 10 robust-count: 2 } } traceoptions { flag { all { disable: false } } } } pimsm4 { disable: false interface bge1 { vif bge1 { disable: false enable-ip-router-alert-option-check: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } interface "register_vif" { vif "register_vif" { disable: false enable-ip-router-alert-option-check: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } bootstrap { disable: false cand-bsr { scope-zone 224.0.0.0/32 { is-scope-zone: false cand-bsr-by-vif-name: "bge1" cand-bsr-by-vif-addr: 0.0.0.0 bsr-priority: 1 hash-mask-len: 30 } } cand-rp { group-prefix 224.0.0.0/32 { is-scope-zone: false cand-rp-by-vif-name: "bge1" cand-rp-by-vif-addr: 0.0.0.0 rp-priority: 192 rp-holdtime: 150 } } } switch-to-spt-threshold { disable: false interval: 100 bytes: 0 } traceoptions { flag { all { disable: false } } } } rip { interface bge0 { vif bge0 { address 192.168.1.1 { metric: 1 horizon: "split-horizon-poison-reverse" disable: false passive: false accept-non-rip-requests: true accept-default-route: true advertise-default-route: true route-timeout: 180 deletion-delay: 120 triggered-delay: 3 triggered-jitter: 66 update-interval: 30 update-jitter: 16 request-interval: 30 interpacket-delay: 50 } } } interface bge1 { vif bge1 { address 10.10.0.1 { metric: 1 horizon: "split-horizon-poison-reverse" disable: false passive: false accept-non-rip-requests: true accept-default-route: true advertise-default-route: true route-timeout: 180 deletion-delay: 120 triggered-delay: 3 triggered-jitter: 66 update-interval: 30 update-jitter: 16 request-interval: 30 interpacket-delay: 50 } } } export: "connected" } } policy { policy-statement connected { term export { from { protocol: "connected" } } } } fea { unicast-forwarding4 { disable: false } } interfaces { restore-original-config-on-shutdown: false interface bge0 { disable: false discard: false description: "LAN" vif bge0 { disable: false address 192.168.1.1 { prefix-length: 24 broadcast: 192.168.1.255 disable: false } } } interface bge1 { disable: false discard: false description: "WAN" vif bge1 { disable: false address 10.10.0.1 { prefix-length: 24 broadcast: 10.10.0.255 disable: false } } } interface lo0 { disable: false discard: false description: "Loopback interface" vif lo0 { disable: false } } } plumbing { mfea4 { disable: false interface bge0 { vif bge0 { disable: false } } interface bge1 { vif bge1 { disable: false } } interface "register_vif" { vif "register_vif" { disable: false } } traceoptions { flag { all { disable: false } } } } } *Here is the configuration of 2nd Router : * /*XORP Configuration File, v1.0*/ protocols { igmp { disable: false interface em0 { vif em0 { disable: false version: 2 enable-ip-router-alert-option-check: false query-interval: 125 query-last-member-interval: 1 query-response-interval: 10 robust-count: 2 } } interface fxp0 { vif fxp0 { disable: false version: 2 enable-ip-router-alert-option-check: false query-interval: 125 query-last-member-interval: 1 query-response-interval: 10 robust-count: 2 } } traceoptions { flag { all { disable: false } } } } pimsm4 { disable: false interface fxp0 { vif fxp0 { disable: false enable-ip-router-alert-option-check: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } interface "register_vif" { vif "register_vif" { disable: false enable-ip-router-alert-option-check: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } bootstrap { disable: false cand-bsr { scope-zone 224.0.0.0/32 { cand-bsr-by-vif-name: "fxp0" } } cand-rp { group-prefix 224.0.0.0/32 { cand-rp-by-vif-name: "fxp0" } } } switch-to-spt-threshold { disable: false interval: 100 bytes: 0 } } rip { interface em0 { vif em0 { address 192.168.2.1 { metric: 1 horizon: "split-horizon-poison-reverse" disable: false passive: false accept-non-rip-requests: true accept-default-route: true advertise-default-route: true route-timeout: 180 deletion-delay: 120 triggered-delay: 3 triggered-jitter: 66 update-interval: 30 update-jitter: 16 request-interval: 30 interpacket-delay: 50 } } } interface fxp0 { vif fxp0 { address 10.10.0.2 { metric: 1 horizon: "split-horizon-poison-reverse" disable: false passive: false accept-non-rip-requests: true accept-default-route: true advertise-default-route: true route-timeout: 180 deletion-delay: 120 triggered-delay: 3 triggered-jitter: 66 update-interval: 30 update-jitter: 16 request-interval: 30 interpacket-delay: 50 } } } export: "connected" } } policy { policy-statement connected { term export { from { protocol: "connected" } } } } fea { unicast-forwarding4 { disable: false } } interfaces { restore-original-config-on-shutdown: false interface em0 { disable: false discard: false description: "LAN" vif em0 { disable: false address 192.168.2.1 { prefix-length: 24 broadcast: 192.168.2.255 disable: false } } } interface fxp0 { disable: false discard: false description: "WAN" vif fxp0 { disable: false address 10.10.0.2 { prefix-length: 24 broadcast: 10.10.0.255 disable: false } } } interface lo0 { disable: false discard: false description: "Loopback interface" vif lo0 { disable: false } } } plumbing { mfea4 { disable: false interface em0 { vif em0 { disable: false } } interface fxp0 { vif fxp0 { disable: false } } interface "register_vif" { vif "register_vif" { disable: false } } traceoptions { flag { all { disable: false } } } } } I also sniffed the network packets from switch and looked them in wireshark, igmp join/ unjoin and rip request/response seems to be working properly. I can also see PIM hello and bootstrap messages exchanged. I used show pim bootstrap to check, it also seems to be correct as it is electing one of the wan addresses of the 2 routers as bsr. Thanks Regards Viney Khera IPVN -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080721/9d389fd3/attachment-0001.html From tushar.mehta at einfochips.com Mon Jul 21 22:25:53 2008 From: tushar.mehta at einfochips.com (Tushar Mehta) Date: Tue, 22 Jul 2008 10:55:53 +0530 Subject: [Xorp-users] XORP IGMPv3 is not accepting the report with source IP 0.0.0.0 Message-ID: <48856F61.8070304@einfochips.com> according to rfc-3376: An IGMP report is sent with a valid IP source address for the destination subnet. The 0.0.0.0 source address may be used by a system that has not yet acquired an IP address. Note that the 0.0.0.0 source address may simultaneously be used by multiple systems on a LAN. Routers MUST accept a report with a source address of 0.0.0.0. but in my case it is showing me this error message on the terminal "source must be unicast".... XORP is accepting my IGMPv3 report with source IP address "0.0.0.0". what is the problem with XORP or in my setup? i m attaching the configuration file that i am using for running IGMPv3 -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. _____________________________________________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config.boot.sample_igmp Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080722/f59c3544/attachment-0001.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rfc3376.txt Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080722/f59c3544/attachment-0001.txt From bms at incunabulum.net Tue Jul 22 07:18:38 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue, 22 Jul 2008 15:18:38 +0100 Subject: [Xorp-users] XORP IGMPv3 is not accepting the report with source IP 0.0.0.0 In-Reply-To: <48856F61.8070304@einfochips.com> References: <48856F61.8070304@einfochips.com> Message-ID: <4885EC3E.9060602@incunabulum.net> Hi, Tushar Mehta wrote: > according to rfc-3376: > An IGMP report is sent with a valid IP source address for the > destination subnet. The 0.0.0.0 source address may be used by a > system that has not yet acquired an IP address. Note that the > 0.0.0.0 source address may simultaneously be used by multiple systems > on a LAN. Routers MUST accept a report with a source address of > 0.0.0.0. That's correct, it's a workaround for multicast end-stations which have not yet obtained IP addresses. It went away in MLDv2/v3 because link-local IPv6 addresses MUST be used for MLD traffic. > > but in my case it is showing me this error message on the terminal > "source must be unicast".... > XORP is accepting my IGMPv3 report with source IP address "0.0.0.0". > what is the problem with XORP or in my setup? Once again: can you please tell us which operating system, version of XORP, etc you are using? I don't see anything obviously wrong with your configuration file, although your robustness variable is set to 5, which is quite high: is this intentional, i.e. is it a very lossy network medium? Please don't send RFCs as attachments to the list. thanks BMS From bms at incunabulum.net Tue Jul 22 07:19:55 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue, 22 Jul 2008 15:19:55 +0100 Subject: [Xorp-users] Multicast not working In-Reply-To: <29b76190807211814r4017a425y73f8b9dbaa80c728@mail.gmail.com> References: <29b76190807211814r4017a425y73f8b9dbaa80c728@mail.gmail.com> Message-ID: <4885EC8B.5050905@incunabulum.net> Viney Khera wrote: > Hi, > > I'm new to Xorp router, i want to configure xorp routers for > multicasting. I want to route multicast packets through the routers. I > began with a simple network and unicasting worked on it, but i don't > know why multicast is not working. Please any one can look at the > configuration of my routers and tell me what's wrong? Many forwarding plane implementations will not forward 224.0.0.0/24 as it is link scope only. Please try a different test prefix. thanks BMS From bms at incunabulum.net Tue Jul 22 07:21:17 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue, 22 Jul 2008 15:21:17 +0100 Subject: [Xorp-users] XORP IGMPv3 is not accepting the report with source IP 0.0.0.0 In-Reply-To: <48856F61.8070304@einfochips.com> References: <48856F61.8070304@einfochips.com> Message-ID: <4885ECDD.8040706@incunabulum.net> P.S. Can you please send tcpdump or Wireshark captures of the packet(s) which you believe xorp_igmp should be accepting. Thanks. From bms at incunabulum.net Tue Jul 22 07:22:36 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue, 22 Jul 2008 15:22:36 +0100 Subject: [Xorp-users] How to decide Unsolicited Report Interval in IGMPv3 XORP In-Reply-To: <4885C0B1.7040704@einfochips.com> References: <48856D06.1090802@einfochips.com> <4885A9AF.9050203@incunabulum.net> <4885C0B1.7040704@einfochips.com> Message-ID: <4885ED2C.9090307@incunabulum.net> Tushar Mehta wrote: > sorry i forgot to mention the OS on which my XORP IGMPv3 is running > thank you for your reply > it is 2.6.18-1.2798 fc6xen(Fedora 6) OS which XORP IGMPv3 is running Please consult the documentation in Linux for setting the URI variable in the implementation of IGMPv3 you're using -- there are several IGMPv3 implementations for Linux; I believe the one in 2.6.24 uses /proc or sysctl for setting URI. thanks BMS From bms at incunabulum.net Tue Jul 22 07:28:04 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue, 22 Jul 2008 15:28:04 +0100 Subject: [Xorp-users] getting problem in IGMPv3 XORP behavior In-Reply-To: <4885C484.3070605@einfochips.com> References: <48856A19.3070700@einfochips.com> <4885A93E.8070902@incunabulum.net> <4885C484.3070605@einfochips.com> Message-ID: <4885EE74.1090902@incunabulum.net> Tushar Mehta wrote: > here my setup design is attached. > > My IGMPv3 router is running and is attached with host via switch. > IGMPv3 is running on XORP. > just for checking i am sending a IGMP General Query(without router > alert option) from Host machine to XORP router. > in this case it should not reply by sending IGMPv3 report but it is > replying in my case. Can you paste a Wireshark or tcpdump capture of how the IGMPv3 router is responding to the query? It is entirely possible (and likely) the router is responding to the query in line with the protocol if it's a member of any IGMP groups. For example, state change for end stations in groups within the 224.0.0.0/8 block need not be announced, however if they aren't, this breaks IGMP snooping at the link layer. You don't specify if your switch performs IGMP snooping. Rememeber, there may be more than one IGMPv3 querier in an IP subnet -- there is an election process when there is more than one querier. thanks BMS From greearb at candelatech.com Tue Jul 22 08:48:41 2008 From: greearb at candelatech.com (Ben Greear) Date: Tue, 22 Jul 2008 08:48:41 -0700 Subject: [Xorp-users] getting problem in IGMPv3 XORP behavior In-Reply-To: <4885CA05.2000203@einfochips.com> References: <48856A19.3070700@einfochips.com> <4885A93E.8070902@incunabulum.net> <4885C484.3070605@einfochips.com> <4885CA05.2000203@einfochips.com> Message-ID: <48860159.9090006@candelatech.com> Tushar Mehta wrote: > on host machine i am using RHEL 4 and the XORP side i am using Fedora Core 6 > From what I can tell, IGMP routing for IPv6 doesn't work in the default linux kernel, at least through 2.6.25. Supposedly, 2.6.26 includes support. Unless you are specifically patching your kernel, I don't think this can work. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From viney.khera at ipvidnet.com Tue Jul 22 10:11:10 2008 From: viney.khera at ipvidnet.com (Viney Khera) Date: Tue, 22 Jul 2008 10:11:10 -0700 Subject: [Xorp-users] Multicast not working In-Reply-To: <29b76190807220944t4eca1fa3m2fbbe17869eaf2ad@mail.gmail.com> References: <29b76190807211814r4017a425y73f8b9dbaa80c728@mail.gmail.com> <4885EC8B.5050905@incunabulum.net> <29b76190807220944t4eca1fa3m2fbbe17869eaf2ad@mail.gmail.com> Message-ID: <29b76190807221011p72bbf716r9b1c8944004ab5e8@mail.gmail.com> > Hi, > > I corrected that, i tried 224.112.0.0/16, 228.0.0.0/24 and other different > things, but still not working. > > Thanks > Viney > > > On Tue, Jul 22, 2008 at 7:19 AM, Bruce M Simpson > wrote: > >> Viney Khera wrote: >> >>> Hi, >>> >>> I'm new to Xorp router, i want to configure xorp routers for >>> multicasting. I want to route multicast packets through the routers. I began >>> with a simple network and unicasting worked on it, but i don't know why >>> multicast is not working. Please any one can look at the configuration of my >>> routers and tell me what's wrong? >>> >> >> Many forwarding plane implementations will not forward 224.0.0.0/24 as it >> is link scope only. Please try a different test prefix. >> >> thanks >> BMS >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080722/8b7b7e03/attachment.html From kristian at spritelink.net Tue Jul 22 10:52:49 2008 From: kristian at spritelink.net (Kristian Larsson) Date: Tue, 22 Jul 2008 19:52:49 +0200 Subject: [Xorp-users] [Xorp-hackers] Announcing XORP Release Candidate 1.5 In-Reply-To: <200807182321.m6INKeVM015068@fruitcake.ICSI.Berkeley.EDU> References: <60045.1215643917@tigger.icir.org> <4876AE18.7060509@candelatech.com> <200807110133.m6B1WcrJ022663@fruitcake.ICSI.Berkeley.EDU> <200807182321.m6INKeVM015068@fruitcake.ICSI.Berkeley.EDU> Message-ID: <20080722175249.GB58197@spritelink.se> On Fri, Jul 18, 2008 at 04:20:40PM -0700, Pavlin Radoslavov wrote: > Pavlin Radoslavov wrote: > > > > I'm currently digging into BGP and ipv6 multicast routing. Do you happen > > > to have an updated user-guide for 1.5? I'll be happy to help proof read > > > and debug it for you... > > Ben, > > You can get a preliminary version of the new XORP User Manual from > http://www.icir.org/pavlin/.private/xorp/user_manual.pdf > > There might be few more things that will change in the manual before > the release, but those probably will be minor. > > It will be great if you (and anybody else) can provide provide > feedback. Having only read through half of the manual, these are my current nitpickings... ;) In the definitions section.. EGP is not only a term covering, basically only, BGP but it is also a protocol of it's own. Would be nice if that was reflected in the manual. You write 'an user' throughout the paper while I believe that 'a user' would be the correct article. I bring forth evidence A ;) http://www.googlefight.com/index.php?lang=en_GB&word1=%22a+user%22&word2=%22an+user%22 For those seeking an explanation I found the following two pages excellent: http://en.allexperts.com/q/English-Second-Language-1815/vs.htm http://owl.english.purdue.edu/handouts/esl/esliart.html Now given that English is not my native tongue I might be wrong.. In the OSPF section I would like to change the router-id part, as it's not an IPv4 address, it's rather just an 4 byte ID usually displayed in dotted quad notation. "The smallest IP address of an interface belonging to the router is a good choice." An address belonging to a loopback is probably a better choice if available and I think 'lowest' instead of 'smallest' is more correct, no? page 57, source->vif section: "The value mist be" should probably be "The value must be", same thing in vif section. page 61 "packets and then forwards then from one" ==> "packets and then forwards _them_ from one" I'll continue reading when I get home :) Kind regards, Kristian. -- Kristian Larsson KLL-RIPE Network Engineer / Internet Core Tele2 / SWIPnet [AS1257] +46 704 910401 kll at spritelink.net From pavlin at ICSI.Berkeley.EDU Tue Jul 22 11:56:52 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 22 Jul 2008 11:56:52 -0700 Subject: [Xorp-users] getting problem in IGMPv3 XORP behavior In-Reply-To: <48856A19.3070700@einfochips.com> References: <48856A19.3070700@einfochips.com> Message-ID: <200807221857.m6MIuqct015648@fruitcake.ICSI.Berkeley.EDU> Tushar Mehta wrote: > I am currently facing problem in the XORP regarding IGMPv3 protocol. > I want to check whether XORP router is sending the IGMPv3 report when you send > IGMP General Query without router alert option. > It should not send IGMPv3 report when it get the General Query with router > alert option in the IP header as per the rfc-3376 > In my it is sending the IGMPv3 report. this is the problem i am getting now. XORP implements only the router-side of IGMP/MLD. The IGMPv3 reports generated by the router running XORP are actually generated by the kernel. Hence, this issue is related to the particular OS/kernel you are running. > also when i am sending IGMPv3 report without router alert option XORP is > accepting it and making appropriate entry in multicast routing table. > It should not do that as per rfc-3376 In XORP there is an IGMP/MLD configuration flag regarding this: protocols { igmp { interface eth0 { vif eth0 { enable-ip-router-alert-option-check: true ... } } ... } } The default value for the flag is false. If you set it to true, the XORP router-side implementation will drop all IGMP/MLD messages that don't have the Router Alert option set. FYI, the reasoning for the default value being "false" is to be able to work out-of-the-box with earlier IGMP implementations that don't use Router Alert. It looks like you have set the value to true in your config so it should work and you should just see warning messages like: "RX ...: missing IP Router Alert option" What XORP version are you using? Please try the latest code from CVS (or the XORP-1.5-RC) and see whether you still have the problem. Pavlin > so where is the problem lies. > here i am sending the configuration file that i am using for my setup. > > -- > _____________________________________________________________________ > Disclaimer: This e-mail message and all attachments transmitted with it > are intended solely for the use of the addressee and may contain legally > privileged and confidential information. If the reader of this message > is not the intended recipient, or an employee or agent responsible for > delivering this message to the intended recipient, you are hereby > notified that any dissemination, distribution, copying, or other use of > this message or its attachments is strictly prohibited. If you have > received this message in error, please notify the sender immediately by > replying to this message and please delete it from your computer. Any > views expressed in this message are those of the individual sender > unless otherwise stated.Company has taken enough precautions to prevent > the spread of viruses. However the company accepts no liability for any > damage caused by any virus transmitted by this email. > _____________________________________________________________________ > > /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu Exp $ */ > > > interfaces { > restore-original-config-on-shutdown: false > interface eth0 { > description: "ethernet interface" > disable: false > default-system-config > } > /* interface eth1 { > description: "ethernet interface" > disable: false > default-system-config > }*/ > } > > > fea { > unicast-forwarding4 { > disable: false > forwarding-entries { > retain-on-startup: false > retain-on-shutdown: false > } > } > } > > > policy { > /* Describe connected routes for redistribution */ > policy-statement connected { > term export { > from { > protocol: "connected" > } > } > } > } > > policy { > /* Describe static routes for redistribution */ > policy-statement static { > term export { > from { > protocol: "static" > } > } > } > } > > plumbing { > mfea4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > /* interface eth1 { > vif eth1 { > disable: false > } > }*/ > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > igmp { > disable: false > interface eth0 { > vif eth0 { > disable: false > version: 3 > enable-ip-router-alert-option-check: true > query-interval: 5 > query-last-member-interval: 5 > query-response-interval: 2 > robust-count: 5 > } > } > /* interface eth1 { > vif eth1 { > disable: false > version: 3 > enable-ip-router-alert-option-check: true > query-interval: 10 > query-last-member-interval: 5 > query-response-interval: 10 > robust-count: 3 > } > }*/ > traceoptions { > flag all { > disable: false > } > } > } > } > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at ICSI.Berkeley.EDU Tue Jul 22 12:08:28 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 22 Jul 2008 12:08:28 -0700 Subject: [Xorp-users] How to decide Unsolicited Report Interval in IGMPv3 XORP In-Reply-To: <48856D06.1090802@einfochips.com> References: <48856D06.1090802@einfochips.com> Message-ID: <200807221909.m6MJ8S45017553@fruitcake.ICSI.Berkeley.EDU> Tushar Mehta wrote: > Can anyone tell me how i can find the Unsolicited Report Interval that > is used when any IGMP host use while transmitting state change record? > > according to the rfc-3376: > - To cover the possibility of the State-Change Report being missed by > one or more multicast routers, it is retransmitted [Robustness > Variable] - 1 more times, at intervals chosen at random from the range > (0, [Unsolicited Report Interval]). > > - Unsolicited Report Interval > The Unsolicited Report Interval is the time between repetitions of a > host's initial report of membership in a group. Default: 1 second. > > by default Unsolicited Report Interval should be 1 but XORP is not > following it. it is picking up this interval randamly. As Bruce mentioned in another email on the subject, this is kernel-related config. To clarify: IGMP/MLD has two parts: router-side and host-side. The host-side is typically implemented by the OS (in the kernel). The router-side is typically an userland process. XORP implements only the router-side, and for the host-side relies on the kernel implementation. The configuration changes in XORP apply only to the router side; the host-side configuration changes are OS specific and you should refer to the particular OS/kernel documentation for that. In the future we might expose the host-side configuration in the xorpsh, but right now this is a very low priority for us. Hope that helps, Pavlin > i m attaching the configuration file that i am using for my set up. > > > -- > _____________________________________________________________________ > Disclaimer: This e-mail message and all attachments transmitted with it > are intended solely for the use of the addressee and may contain legally > privileged and confidential information. If the reader of this message > is not the intended recipient, or an employee or agent responsible for > delivering this message to the intended recipient, you are hereby > notified that any dissemination, distribution, copying, or other use of > this message or its attachments is strictly prohibited. If you have > received this message in error, please notify the sender immediately by > replying to this message and please delete it from your computer. Any > views expressed in this message are those of the individual sender > unless otherwise stated.Company has taken enough precautions to prevent > the spread of viruses. However the company accepts no liability for any > damage caused by any virus transmitted by this email. > _____________________________________________________________________ > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at ICSI.Berkeley.EDU Tue Jul 22 12:37:46 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 22 Jul 2008 12:37:46 -0700 Subject: [Xorp-users] XORP IGMPv3 is not accepting the report with source IP 0.0.0.0 In-Reply-To: <48856F61.8070304@einfochips.com> References: <48856F61.8070304@einfochips.com> Message-ID: <200807221938.m6MJbkbl022277@fruitcake.ICSI.Berkeley.EDU> A non-text attachment was scrubbed... Name: igmp.patch Type: text/x-c++ Size: 1124 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080722/750f8322/attachment.bin From pavlin at ICSI.Berkeley.EDU Tue Jul 22 12:46:17 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 22 Jul 2008 12:46:17 -0700 Subject: [Xorp-users] Multicast not working In-Reply-To: <29b76190807211814r4017a425y73f8b9dbaa80c728@mail.gmail.com> References: <29b76190807211814r4017a425y73f8b9dbaa80c728@mail.gmail.com> Message-ID: <200807221947.m6MJkI7i023509@fruitcake.ICSI.Berkeley.EDU> Viney Khera wrote: > Hi, > > I'm new to Xorp router, i want to configure xorp routers for multicasting. I > want to route multicast packets through the routers. I began with a simple > network and unicasting worked on it, but i don't know why multicast is not > working. Please any one can look at the configuration of my routers and tell > me what's wrong? > > Here is what my network looks like : 2 xorp routers PC's running on XORP > version: Release-1.4 live cd's, one connected to transmitting video source > and other to the recieving VLC streaming PC. Routers WAN side connected to > the cisco switch. > > > > Transmitter Receiver > > | | > XORP Router 1 > XORP Router 2 > > | | > > |-------------Cisco Switch---------------| Sorry, your diagram is mis-aligned, so it wasn't clear. Anyway, here are two issues with your config: * The following config statement seems bogus and should be deleted: cand-bsr-by-vif-addr: 0.0.0.0 If you want to be explicitly abou the Cand BSR IP address, it should be that address instead of 0.0.0.0 * fib2mrib is missing from both configuration files: protocols { fib2mrib { disable: false } } If the above two changes don't fix the problem, then please send the following info (from xorpsh operational mode): show igmp group show pim rp show pim join Pavlin > > *Here is the configuration of 1st Router : > * > /*XORP Configuration File, v1.0*/ > protocols { > igmp { > disable: false > interface bge0 { > vif bge0 { > disable: false > version: 2 > enable-ip-router-alert-option-check: false > query-interval: 125 > query-last-member-interval: 1 > query-response-interval: 10 > robust-count: 2 > } > } > interface bge1 { > vif bge1 { > disable: false > version: 2 > enable-ip-router-alert-option-check: false > query-interval: 125 > query-last-member-interval: 1 > query-response-interval: 10 > robust-count: 2 > } > } > traceoptions { > flag { > all { > disable: false > } > } > } > } > pimsm4 { > disable: false > interface bge1 { > vif bge1 { > disable: false > enable-ip-router-alert-option-check: false > dr-priority: 1 > hello-period: 30 > hello-triggered-delay: 5 > } > } > interface "register_vif" { > vif "register_vif" { > disable: false > enable-ip-router-alert-option-check: false > dr-priority: 1 > hello-period: 30 > hello-triggered-delay: 5 > } > } > bootstrap { > disable: false > cand-bsr { > scope-zone 224.0.0.0/32 { > is-scope-zone: false > cand-bsr-by-vif-name: "bge1" > cand-bsr-by-vif-addr: 0.0.0.0 > bsr-priority: 1 > hash-mask-len: 30 > } > } > cand-rp { > group-prefix 224.0.0.0/32 { > is-scope-zone: false > cand-rp-by-vif-name: "bge1" > cand-rp-by-vif-addr: 0.0.0.0 > rp-priority: 192 > rp-holdtime: 150 > } > } > } > switch-to-spt-threshold { > disable: false > interval: 100 > bytes: 0 > } > traceoptions { > flag { > all { > disable: false > } > } > } > } > rip { > interface bge0 { > vif bge0 { > address 192.168.1.1 { > metric: 1 > horizon: "split-horizon-poison-reverse" > disable: false > passive: false > accept-non-rip-requests: true > accept-default-route: true > advertise-default-route: true > route-timeout: 180 > deletion-delay: 120 > triggered-delay: 3 > triggered-jitter: 66 > update-interval: 30 > update-jitter: 16 > request-interval: 30 > interpacket-delay: 50 > } > } > } > interface bge1 { > vif bge1 { > address 10.10.0.1 { > metric: 1 > horizon: "split-horizon-poison-reverse" > disable: false > passive: false > accept-non-rip-requests: true > accept-default-route: true > advertise-default-route: true > route-timeout: 180 > deletion-delay: 120 > triggered-delay: 3 > triggered-jitter: 66 > update-interval: 30 > update-jitter: 16 > request-interval: 30 > interpacket-delay: 50 > } > } > } > export: "connected" > } > } > policy { > policy-statement connected { > term export { > from { > protocol: "connected" > } > } > } > } > fea { > unicast-forwarding4 { > disable: false > } > } > interfaces { > restore-original-config-on-shutdown: false > interface bge0 { > disable: false > discard: false > description: "LAN" > vif bge0 { > disable: false > address 192.168.1.1 { > prefix-length: 24 > broadcast: 192.168.1.255 > disable: false > } > } > } > interface bge1 { > disable: false > discard: false > description: "WAN" > vif bge1 { > disable: false > address 10.10.0.1 { > prefix-length: 24 > broadcast: 10.10.0.255 > disable: false > } > } > } > interface lo0 { > disable: false > discard: false > description: "Loopback interface" > vif lo0 { > disable: false > } > } > } > plumbing { > mfea4 { > disable: false > interface bge0 { > vif bge0 { > disable: false > } > } > interface bge1 { > vif bge1 { > disable: false > } > } > interface "register_vif" { > vif "register_vif" { > disable: false > } > } > traceoptions { > flag { > all { > disable: false > } > } > } > } > } > > > *Here is the configuration of 2nd Router : > * > /*XORP Configuration File, v1.0*/ > protocols { > igmp { > disable: false > interface em0 { > vif em0 { > disable: false > version: 2 > enable-ip-router-alert-option-check: false > query-interval: 125 > query-last-member-interval: 1 > query-response-interval: 10 > robust-count: 2 > } > } > interface fxp0 { > vif fxp0 { > disable: false > version: 2 > enable-ip-router-alert-option-check: false > query-interval: 125 > query-last-member-interval: 1 > query-response-interval: 10 > robust-count: 2 > } > } > traceoptions { > flag { > all { > disable: false > } > } > } > } > pimsm4 { > disable: false > interface fxp0 { > vif fxp0 { > disable: false > enable-ip-router-alert-option-check: false > dr-priority: 1 > hello-period: 30 > hello-triggered-delay: 5 > } > } > interface "register_vif" { > vif "register_vif" { > disable: false > enable-ip-router-alert-option-check: false > dr-priority: 1 > hello-period: 30 > hello-triggered-delay: 5 > } > } > bootstrap { > disable: false > cand-bsr { > scope-zone 224.0.0.0/32 { > cand-bsr-by-vif-name: "fxp0" > } > } > cand-rp { > group-prefix 224.0.0.0/32 { > cand-rp-by-vif-name: "fxp0" > } > } > } > switch-to-spt-threshold { > disable: false > interval: 100 > bytes: 0 > } > } > rip { > interface em0 { > vif em0 { > address 192.168.2.1 { > metric: 1 > horizon: "split-horizon-poison-reverse" > disable: false > passive: false > accept-non-rip-requests: true > accept-default-route: true > advertise-default-route: true > route-timeout: 180 > deletion-delay: 120 > triggered-delay: 3 > triggered-jitter: 66 > update-interval: 30 > update-jitter: 16 > request-interval: 30 > interpacket-delay: 50 > } > } > } > interface fxp0 { > vif fxp0 { > address 10.10.0.2 { > metric: 1 > horizon: "split-horizon-poison-reverse" > disable: false > passive: false > accept-non-rip-requests: true > accept-default-route: true > advertise-default-route: true > route-timeout: 180 > deletion-delay: 120 > triggered-delay: 3 > triggered-jitter: 66 > update-interval: 30 > update-jitter: 16 > request-interval: 30 > interpacket-delay: 50 > } > } > } > export: "connected" > } > } > policy { > policy-statement connected { > term export { > from { > protocol: "connected" > } > } > } > } > fea { > unicast-forwarding4 { > disable: false > } > } > interfaces { > restore-original-config-on-shutdown: false > interface em0 { > disable: false > discard: false > description: "LAN" > vif em0 { > disable: false > address 192.168.2.1 { > prefix-length: 24 > broadcast: 192.168.2.255 > disable: false > } > } > } > interface fxp0 { > disable: false > discard: false > description: "WAN" > vif fxp0 { > disable: false > address 10.10.0.2 { > prefix-length: 24 > broadcast: 10.10.0.255 > disable: false > } > } > } > interface lo0 { > disable: false > discard: false > description: "Loopback interface" > vif lo0 { > disable: false > } > } > } > plumbing { > mfea4 { > disable: false > interface em0 { > vif em0 { > disable: false > } > } > interface fxp0 { > vif fxp0 { > disable: false > } > } > interface "register_vif" { > vif "register_vif" { > disable: false > } > } > traceoptions { > flag { > all { > disable: false > } > } > } > } > } > > > I also sniffed the network packets from switch and looked them in wireshark, > igmp join/ unjoin and rip request/response seems to be working properly. I > can also see PIM hello and bootstrap messages exchanged. I used show pim > bootstrap to check, it also seems to be correct as it is electing one of the > wan addresses of the 2 routers as bsr. > > Thanks > Regards > Viney Khera > IPVN > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From kristian at spritelink.net Tue Jul 22 15:02:31 2008 From: kristian at spritelink.net (Kristian Larsson) Date: Wed, 23 Jul 2008 00:02:31 +0200 Subject: [Xorp-users] SPF Calculations In-Reply-To: <17396.1209652996@tigger.icir.org> References: <9863411DEA890E458E57C11C5A1A18EAB8247C@IMCSRV7.MITRE.ORG> <17396.1209652996@tigger.icir.org> Message-ID: <20080722220231.GD58197@spritelink.se> On Thu, May 01, 2008 at 07:43:16AM -0700, Atanu Ghosh wrote: > Hi, > > We don't keep track of the number of SPF calculations performed. It'd be nice if XORP would. show ospf spf-log in IOS is often quite helpful when seeking to make your network more stable or for tuning spf-parameters. I've created a BugZilla entry for this. -K > >>>>> "Andrew" == Andrew J Gorski writes: > > Andrew> When using OSPF in XORP, is there anyway to see how many > Andrew> SPF calculations have been performed since the process began > Andrew> or since the counter was reset? > Andrew> _______________________________________________ Xorp-users > Andrew> mailing list Xorp-users at xorp.org > Andrew> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users -- Kristian Larsson KLL-RIPE Network Engineer / Internet Core Tele2 / SWIPnet [AS1257] +46 704 910401 kll at spritelink.net From pavlin at ICSI.Berkeley.EDU Tue Jul 22 15:12:22 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 22 Jul 2008 15:12:22 -0700 Subject: [Xorp-users] Multicast not working In-Reply-To: <29b76190807221346n6dd40f5fq338a9de46a2f8278@mail.gmail.com> References: <29b76190807211814r4017a425y73f8b9dbaa80c728@mail.gmail.com> <200807221947.m6MJkI7i023509@fruitcake.ICSI.Berkeley.EDU> <29b76190807221346n6dd40f5fq338a9de46a2f8278@mail.gmail.com> Message-ID: <200807222212.m6MMCMUA017608@fruitcake.ICSI.Berkeley.EDU> Viney Khera wrote: > I got it working now. > > Thanks > Viney Great! Thanks for the update. Pavlin > On Tue, Jul 22, 2008 at 12:46 PM, Pavlin Radoslavov < > pavlin at icsi.berkeley.edu> wrote: > > > Viney Khera wrote: > > > > > Hi, > > > > > > I'm new to Xorp router, i want to configure xorp routers for > > multicasting. I > > > want to route multicast packets through the routers. I began with a > > simple > > > network and unicasting worked on it, but i don't know why multicast is > > not > > > working. Please any one can look at the configuration of my routers and > > tell > > > me what's wrong? > > > > > > Here is what my network looks like : 2 xorp routers PC's running on XORP > > > version: Release-1.4 live cd's, one connected to transmitting video > > source > > > and other to the recieving VLC streaming PC. Routers WAN side connected > > to > > > the cisco switch. > > > > > > > > > > > > Transmitter Receiver > > > > > > | | > > > XORP Router 1 > > > XORP Router 2 > > > > > > | | > > > > > > |-------------Cisco Switch---------------| > > > > Sorry, your diagram is mis-aligned, so it wasn't clear. > > Anyway, here are two issues with your config: > > > > * The following config statement seems bogus and should be deleted: > > cand-bsr-by-vif-addr: 0.0.0.0 > > If you want to be explicitly abou the Cand BSR IP address, it > > should be that address instead of 0.0.0.0 > > > > * fib2mrib is missing from both configuration files: > > > > protocols { > > fib2mrib { > > disable: false > > } > > } > > > > If the above two changes don't fix the problem, then please send the > > following info (from xorpsh operational mode): > > > > show igmp group > > show pim rp > > show pim join > > > > > > Pavlin > > > > > > > > *Here is the configuration of 1st Router : > > > * > > > /*XORP Configuration File, v1.0*/ > > > protocols { > > > igmp { > > > disable: false > > > interface bge0 { > > > vif bge0 { > > > disable: false > > > version: 2 > > > enable-ip-router-alert-option-check: false > > > query-interval: 125 > > > query-last-member-interval: 1 > > > query-response-interval: 10 > > > robust-count: 2 > > > } > > > } > > > interface bge1 { > > > vif bge1 { > > > disable: false > > > version: 2 > > > enable-ip-router-alert-option-check: false > > > query-interval: 125 > > > query-last-member-interval: 1 > > > query-response-interval: 10 > > > robust-count: 2 > > > } > > > } > > > traceoptions { > > > flag { > > > all { > > > disable: false > > > } > > > } > > > } > > > } > > > pimsm4 { > > > disable: false > > > interface bge1 { > > > vif bge1 { > > > disable: false > > > enable-ip-router-alert-option-check: false > > > dr-priority: 1 > > > hello-period: 30 > > > hello-triggered-delay: 5 > > > } > > > } > > > interface "register_vif" { > > > vif "register_vif" { > > > disable: false > > > enable-ip-router-alert-option-check: false > > > dr-priority: 1 > > > hello-period: 30 > > > hello-triggered-delay: 5 > > > } > > > } > > > bootstrap { > > > disable: false > > > cand-bsr { > > > scope-zone 224.0.0.0/32 { > > > is-scope-zone: false > > > cand-bsr-by-vif-name: "bge1" > > > cand-bsr-by-vif-addr: 0.0.0.0 > > > bsr-priority: 1 > > > hash-mask-len: 30 > > > } > > > } > > > cand-rp { > > > group-prefix 224.0.0.0/32 { > > > is-scope-zone: false > > > cand-rp-by-vif-name: "bge1" > > > cand-rp-by-vif-addr: 0.0.0.0 > > > rp-priority: 192 > > > rp-holdtime: 150 > > > } > > > } > > > } > > > switch-to-spt-threshold { > > > disable: false > > > interval: 100 > > > bytes: 0 > > > } > > > traceoptions { > > > flag { > > > all { > > > disable: false > > > } > > > } > > > } > > > } > > > rip { > > > interface bge0 { > > > vif bge0 { > > > address 192.168.1.1 { > > > metric: 1 > > > horizon: "split-horizon-poison-reverse" > > > disable: false > > > passive: false > > > accept-non-rip-requests: true > > > accept-default-route: true > > > advertise-default-route: true > > > route-timeout: 180 > > > deletion-delay: 120 > > > triggered-delay: 3 > > > triggered-jitter: 66 > > > update-interval: 30 > > > update-jitter: 16 > > > request-interval: 30 > > > interpacket-delay: 50 > > > } > > > } > > > } > > > interface bge1 { > > > vif bge1 { > > > address 10.10.0.1 { > > > metric: 1 > > > horizon: "split-horizon-poison-reverse" > > > disable: false > > > passive: false > > > accept-non-rip-requests: true > > > accept-default-route: true > > > advertise-default-route: true > > > route-timeout: 180 > > > deletion-delay: 120 > > > triggered-delay: 3 > > > triggered-jitter: 66 > > > update-interval: 30 > > > update-jitter: 16 > > > request-interval: 30 > > > interpacket-delay: 50 > > > } > > > } > > > } > > > export: "connected" > > > } > > > } > > > policy { > > > policy-statement connected { > > > term export { > > > from { > > > protocol: "connected" > > > } > > > } > > > } > > > } > > > fea { > > > unicast-forwarding4 { > > > disable: false > > > } > > > } > > > interfaces { > > > restore-original-config-on-shutdown: false > > > interface bge0 { > > > disable: false > > > discard: false > > > description: "LAN" > > > vif bge0 { > > > disable: false > > > address 192.168.1.1 { > > > prefix-length: 24 > > > broadcast: 192.168.1.255 > > > disable: false > > > } > > > } > > > } > > > interface bge1 { > > > disable: false > > > discard: false > > > description: "WAN" > > > vif bge1 { > > > disable: false > > > address 10.10.0.1 { > > > prefix-length: 24 > > > broadcast: 10.10.0.255 > > > disable: false > > > } > > > } > > > } > > > interface lo0 { > > > disable: false > > > discard: false > > > description: "Loopback interface" > > > vif lo0 { > > > disable: false > > > } > > > } > > > } > > > plumbing { > > > mfea4 { > > > disable: false > > > interface bge0 { > > > vif bge0 { > > > disable: false > > > } > > > } > > > interface bge1 { > > > vif bge1 { > > > disable: false > > > } > > > } > > > interface "register_vif" { > > > vif "register_vif" { > > > disable: false > > > } > > > } > > > traceoptions { > > > flag { > > > all { > > > disable: false > > > } > > > } > > > } > > > } > > > } > > > > > > > > > *Here is the configuration of 2nd Router : > > > * > > > /*XORP Configuration File, v1.0*/ > > > protocols { > > > igmp { > > > disable: false > > > interface em0 { > > > vif em0 { > > > disable: false > > > version: 2 > > > enable-ip-router-alert-option-check: false > > > query-interval: 125 > > > query-last-member-interval: 1 > > > query-response-interval: 10 > > > robust-count: 2 > > > } > > > } > > > interface fxp0 { > > > vif fxp0 { > > > disable: false > > > version: 2 > > > enable-ip-router-alert-option-check: false > > > query-interval: 125 > > > query-last-member-interval: 1 > > > query-response-interval: 10 > > > robust-count: 2 > > > } > > > } > > > traceoptions { > > > flag { > > > all { > > > disable: false > > > } > > > } > > > } > > > } > > > pimsm4 { > > > disable: false > > > interface fxp0 { > > > vif fxp0 { > > > disable: false > > > enable-ip-router-alert-option-check: false > > > dr-priority: 1 > > > hello-period: 30 > > > hello-triggered-delay: 5 > > > } > > > } > > > interface "register_vif" { > > > vif "register_vif" { > > > disable: false > > > enable-ip-router-alert-option-check: false > > > dr-priority: 1 > > > hello-period: 30 > > > hello-triggered-delay: 5 > > > } > > > } > > > bootstrap { > > > disable: false > > > cand-bsr { > > > scope-zone 224.0.0.0/32 { > > > cand-bsr-by-vif-name: "fxp0" > > > } > > > } > > > cand-rp { > > > group-prefix 224.0.0.0/32 { > > > cand-rp-by-vif-name: "fxp0" > > > } > > > } > > > } > > > switch-to-spt-threshold { > > > disable: false > > > interval: 100 > > > bytes: 0 > > > } > > > } > > > rip { > > > interface em0 { > > > vif em0 { > > > address 192.168.2.1 { > > > metric: 1 > > > horizon: "split-horizon-poison-reverse" > > > disable: false > > > passive: false > > > accept-non-rip-requests: true > > > accept-default-route: true > > > advertise-default-route: true > > > route-timeout: 180 > > > deletion-delay: 120 > > > triggered-delay: 3 > > > triggered-jitter: 66 > > > update-interval: 30 > > > update-jitter: 16 > > > request-interval: 30 > > > interpacket-delay: 50 > > > } > > > } > > > } > > > interface fxp0 { > > > vif fxp0 { > > > address 10.10.0.2 { > > > metric: 1 > > > horizon: "split-horizon-poison-reverse" > > > disable: false > > > passive: false > > > accept-non-rip-requests: true > > > accept-default-route: true > > > advertise-default-route: true > > > route-timeout: 180 > > > deletion-delay: 120 > > > triggered-delay: 3 > > > triggered-jitter: 66 > > > update-interval: 30 > > > update-jitter: 16 > > > request-interval: 30 > > > interpacket-delay: 50 > > > } > > > } > > > } > > > export: "connected" > > > } > > > } > > > policy { > > > policy-statement connected { > > > term export { > > > from { > > > protocol: "connected" > > > } > > > } > > > } > > > } > > > fea { > > > unicast-forwarding4 { > > > disable: false > > > } > > > } > > > interfaces { > > > restore-original-config-on-shutdown: false > > > interface em0 { > > > disable: false > > > discard: false > > > description: "LAN" > > > vif em0 { > > > disable: false > > > address 192.168.2.1 { > > > prefix-length: 24 > > > broadcast: 192.168.2.255 > > > disable: false > > > } > > > } > > > } > > > interface fxp0 { > > > disable: false > > > discard: false > > > description: "WAN" > > > vif fxp0 { > > > disable: false > > > address 10.10.0.2 { > > > prefix-length: 24 > > > broadcast: 10.10.0.255 > > > disable: false > > > } > > > } > > > } > > > interface lo0 { > > > disable: false > > > discard: false > > > description: "Loopback interface" > > > vif lo0 { > > > disable: false > > > } > > > } > > > } > > > plumbing { > > > mfea4 { > > > disable: false > > > interface em0 { > > > vif em0 { > > > disable: false > > > } > > > } > > > interface fxp0 { > > > vif fxp0 { > > > disable: false > > > } > > > } > > > interface "register_vif" { > > > vif "register_vif" { > > > disable: false > > > } > > > } > > > traceoptions { > > > flag { > > > all { > > > disable: false > > > } > > > } > > > } > > > } > > > } > > > > > > > > > I also sniffed the network packets from switch and looked them in > > wireshark, > > > igmp join/ unjoin and rip request/response seems to be working properly. > > I > > > can also see PIM hello and bootstrap messages exchanged. I used show pim > > > bootstrap to check, it also seems to be correct as it is electing one of > > the > > > wan addresses of the 2 routers as bsr. > > > > > > Thanks > > > Regards > > > Viney Khera > > > IPVN > > > _______________________________________________ > > > Xorp-users mailing list > > > Xorp-users at xorp.org > > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > From pavlin at ICSI.Berkeley.EDU Tue Jul 22 15:35:13 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 22 Jul 2008 15:35:13 -0700 Subject: [Xorp-users] [Xorp-hackers] Announcing XORP Release Candidate 1.5 In-Reply-To: <20080722175249.GB58197@spritelink.se> References: <60045.1215643917@tigger.icir.org> <4876AE18.7060509@candelatech.com> <200807110133.m6B1WcrJ022663@fruitcake.ICSI.Berkeley.EDU> <200807182321.m6INKeVM015068@fruitcake.ICSI.Berkeley.EDU> <20080722175249.GB58197@spritelink.se> Message-ID: <200807222235.m6MMZDbg020884@fruitcake.ICSI.Berkeley.EDU> Thanks for the feedbacks. Reply below. Kristian Larsson wrote: > Having only read through half of the manual, these > are my current nitpickings... ;) > > In the definitions section.. > EGP is not only a term covering, basically only, > BGP but it is also a protocol of it's own. Would > be nice if that was reflected in the manual. EGP (the protocol) is considered obsolete, and probably the set of people who know about it will know the difference :) Anyway, I just added a footnote to clarify that. > You write 'an user' throughout the paper while I > believe that 'a user' would be the correct > article. I bring forth evidence A ;) > http://www.googlefight.com/index.php?lang=en_GB&word1=%22a+user%22&word2=%22an+user%22 > For those seeking an explanation I found the > following two pages excellent: > http://en.allexperts.com/q/English-Second-Language-1815/vs.htm > http://owl.english.purdue.edu/handouts/esl/esliart.html > Now given that English is not my native > tongue I might be wrong.. I will leave this to the native English speakers :) > In the OSPF section I would like to change the > router-id part, as it's not an IPv4 address, it's > rather just an 4 byte ID usually displayed in > dotted quad notation. > "The smallest IP address of an interface belonging > to the router is a good choice." > An address belonging to a loopback is probably a > better choice if available and I think 'lowest' > instead of 'smallest' is more correct, no? Technically, I think you are correct about the 4 byte ID. My preference for the smallest vs lowest would be to say "the numerically smallest IP address". In any case I will leave the OSPF editing to the OSPF folks. > page 57, source->vif section: > "The value mist be" should probably be "The value > must be", same thing in vif section. Both fixed. > page 61 > "packets and then forwards then from one" ==> > "packets and then forwards _them_ from one" Fixed. Thanks, Pavlin > I'll continue reading when I get home :) > > Kind regards, > Kristian. > > > -- > Kristian Larsson KLL-RIPE > Network Engineer / Internet Core Tele2 / SWIPnet [AS1257] > +46 704 910401 kll at spritelink.net > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From tushar.mehta at einfochips.com Tue Jul 22 23:16:23 2008 From: tushar.mehta at einfochips.com (Tushar Mehta) Date: Wed, 23 Jul 2008 11:46:23 +0530 Subject: [Xorp-users] How to decide Unsolicited Report Interval in IGMPv3 XORP In-Reply-To: <200807221909.m6MJ8S45017553@fruitcake.ICSI.Berkeley.EDU> References: <48856D06.1090802@einfochips.com> <200807221909.m6MJ8S45017553@fruitcake.ICSI.Berkeley.EDU> Message-ID: <4886CCB7.3000101@einfochips.com> I want to configure my OS(on which XORP is running) for IGMPv3 host also and want to set parameter Unsolicited Report Interval. which file i have to modify for configuring my OS as IGMPv3 host. I am attaching the XORP configuration file which is used by me for running IGMPv3(IPv4). Robustness variable is set to 5(high) just for increasing the retransmission for the state change report so that i can check whether interval between them is ( 0, Unsolicited Report Interval) or not. OS specification on which XORP is running: OS: Fedora Core 5 kernel version: 2.6.15-1.2054_FC5 architecture: i686 XORP version: 1.4 IGMP version: 3( for IPv4) Pavlin Radoslavov wrote: > Tushar Mehta wrote: > > >> Can anyone tell me how i can find the Unsolicited Report Interval that >> is used when any IGMP host use while transmitting state change record? >> >> according to the rfc-3376: >> - To cover the possibility of the State-Change Report being missed by >> one or more multicast routers, it is retransmitted [Robustness >> Variable] - 1 more times, at intervals chosen at random from the range >> (0, [Unsolicited Report Interval]). >> >> - Unsolicited Report Interval >> The Unsolicited Report Interval is the time between repetitions of a >> host's initial report of membership in a group. Default: 1 second. >> >> by default Unsolicited Report Interval should be 1 but XORP is not >> following it. it is picking up this interval randamly. >> > > As Bruce mentioned in another email on the subject, this is > kernel-related config. > > To clarify: > IGMP/MLD has two parts: router-side and host-side. > The host-side is typically implemented by the OS (in the kernel). > The router-side is typically an userland process. > > XORP implements only the router-side, and for the host-side relies > on the kernel implementation. > The configuration changes in XORP apply only to the router side; the > host-side configuration changes are OS specific and you should refer > to the particular OS/kernel documentation for that. > In the future we might expose the host-side configuration in the > xorpsh, but right now this is a very low priority for us. > > Hope that helps, > Pavlin > > > > >> i m attaching the configuration file that i am using for my set up. >> >> >> -- >> _____________________________________________________________________ >> Disclaimer: This e-mail message and all attachments transmitted with it >> are intended solely for the use of the addressee and may contain legally >> privileged and confidential information. If the reader of this message >> is not the intended recipient, or an employee or agent responsible for >> delivering this message to the intended recipient, you are hereby >> notified that any dissemination, distribution, copying, or other use of >> this message or its attachments is strictly prohibited. If you have >> received this message in error, please notify the sender immediately by >> replying to this message and please delete it from your computer. Any >> views expressed in this message are those of the individual sender >> unless otherwise stated.Company has taken enough precautions to prevent >> the spread of viruses. However the company accepts no liability for any >> damage caused by any virus transmitted by this email. >> _____________________________________________________________________ >> >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> > > > Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080723/dfa8f6a9/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config.boot.sample_igmp Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080723/dfa8f6a9/attachment.ksh From bms at ICSI.Berkeley.EDU Wed Jul 23 01:47:26 2008 From: bms at ICSI.Berkeley.EDU (Bruce M. Simpson) Date: Wed, 23 Jul 2008 09:47:26 +0100 Subject: [Xorp-users] SPF Calculations In-Reply-To: <20080722220231.GD58197@spritelink.se> References: <9863411DEA890E458E57C11C5A1A18EAB8247C@IMCSRV7.MITRE.ORG> <17396.1209652996@tigger.icir.org> <20080722220231.GD58197@spritelink.se> Message-ID: <4886F01E.7030809@icsi.berkeley.edu> Hi, Thanks for your suggestion. A patch for this would be even more useful. Kristian Larsson wrote: > It'd be nice if XORP would. > show ospf spf-log in IOS is often quite helpful > when seeking to make your network more stable or > for tuning spf-parameters. > > I've created a BugZilla entry for this. > Both OSPF and OLSR use the Spt meta-class. One fundamental difference with how OLSR uses it is that it actually tears down and re-instantiates the Spt, due to how the OLSR components fit together -- so such a counter would need to be maintained with its RouteManager. cheers BMS From atanu at ICSI.Berkeley.EDU Wed Jul 23 08:42:32 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 23 Jul 2008 08:42:32 -0700 Subject: [Xorp-users] Announcing XORP Release 1.5 Message-ID: <81050.1216827752@tigger.icir.org> Today is a big day for XORP. First off, we're announcing the XORP 1.5 Release and would like to extend our sincere thanks to the contributors and other community members who helped make it happen. We hope you'll visit our site (http://xorp.org), download our code, play with it, challenge it, build on it, extend it ... And, most importantly, send us feedback about your experience and what you'd like to see in XORP and do with XORP going forward. We're also announcing today the formation of XORP, Inc. (http://xorp.net), a startup founded by the leaders of the XORP.org project, funded by two top-tier VC's, Onset Ventures and Highland Capital Partners, and led by network industry veteran and seasoned entrepreneur, Vivek Ragavan. XORP, Inc. is committed both to supporting the XORP.org community and code base and to building a successful open source business. XORP 1.5 is the first community release to be made under the auspices of XORP, Inc. and we will continue to release community versions of XORP on a regular basis. You'll hear more about XORP, Inc.'s product plans in the months to come. Finally, we want to thank the International Computer Science Institute (ICSI) in Berkeley, CA which until now has hosted the XORP.org project and housed the core team of developers. ICSI's support, together with that of XORP.org's industrial and government sponsors, has been essential in making this a big day. --The XORP Team P.S. Release notes are included below. ------------------------------------------------------------------ XORP RELEASE NOTES Release 1.5 (2008/07/22) ======================== ALL: - XORP now builds on DragonFlyBSD-1.10.1, DragonFlyBSD-1.12.2, FreeBSD-7.0, Linux Debian-4.0 (etch), Linux Fedora 7, Linux Fedora 8, Linux Fedora 9, Linux Gentoo 2008.0, Linux Ubuntu-7.04, Linux Ubuntu-7.10, Linux Ubuntu-8.04.1, NetBSD-4.0, OpenBSD-4.1, OpenBSD-4.2, OpenBSD-4.3, Mac OS X 10.5.2, Mac OS 10.5.3, and Mac OS X 10.5.4. CONFIGURATION: - Addition of new FEA configuration statements to set the IPv4/IPv6 unicast forwarding table IDs: fea { unicast-forwarding4 { table-id: 254 } unicast-forwarding6 { table-id: 254 } } If the table ID is not configured, the FEA will use the default table ID for the system. Note that not all systems support multiple forwarding tables. Currently, they exist only on Linux (among all systems supported by XORP). - The "DISCARD" network interface flag is printed as appropriate when displaying the list of interfaces in the CLI. - Addition of new FEA configuration statement to support "unreachable" interfaces. Such interfaces are similar to "discard" interfaces, except that instead of silently throwing away packets, the system will respond with "ICMP destination unreachable". interfaces { interface my_unreachable { unreachable: true vif my_unreachable { } } } The default value for the "unreachable" statement is false. - Addition of new FEA configuration statement to flag an interface for "management" purpose. An interface that is flagged as "management" might be used in the future by some of the protocols for protocol-specific purpose. interfaces { interface fxp0 { management: true vif fxp0 { address 10.10.10.10 { prefix-length: 24 } } } } The default value for the "management" statement is false. - Addition of support to configure VLANs on an interface. A VLAN is configured by using a "vlan" block that includes the VLAN ID: interfaces { interface fxp0 { vif fxp0 { address 10.10.10.10 { prefix-length: 24 } } vif vlan1 { vlan { vlan-id: 1 } address 10.10.20.20 { prefix-length: 24 } } } } - Addition of preliminary support to configure firewall rules. Firewall rules are configured by using numbered entries: firewall { rule4 100 { action: "drop" protocol: 6 /* TCP */ source { interface: "fxp0" vif: "fxp0" network: 0.0.0.0/0 port-begin: 0 port-end: 65535 } destination { network: 10.10.0.0/24 port-begin: 0 port-end: 1024 } } } Note that compiling firewall support on Linux systems require patching some of the system header files. See ERRATA for details. - The following PIM-SM configuration statements have been deprecated, because PIM-SM doesn't use Router Alert IP option anymore: protocols { pimsm4 { interface foo { vif foo { enable-ip-router-alert-option-check: true } } } } protocols { pimsm6 { interface foo { vif foo { enable-ip-router-alert-option-check: true } } } } LIBXORP: - The local system-independent xorp_random() implemenation is used instead of the random(3) provided by the system. - Improved MAC address support (classes Mac and EtherMac). - More consistent usage of XORP_OK and XORP_ERROR to return error codes. LIBXIPC: - Bug fix in the internal mechanism for obtaining the IPv4 addresses from the system. After the bug fix, a secondary (alias) IP address can be specified with the "-i " command-line option to the xorp_rtrmgr or xorp_finder binaries. LIBFEACLIENT: - No significant changes. XRL: - Critical bug fix that can be triggered by malformatted XRLs. - Addition of support for 64-bit integers: i64 and u64 for signed and unsigned respectively. RTRMGR: - Addition of preliminary mechanism to log events to a file or to a syslog facility. - Addition of support to run XORP in background (in daemon mode). XORPSH: - Bug fix related to assigning the node ID position in case the previous (sibling) node was deleted at the same time a new node was added. This fixes "Found out-of-order term(s) inside policy ..." error inside the policy manager. - The "-c " command line option can be used more than once to run multiple commands. - Fix a long configuration delay when using xorpsh in non-interactive mode (e.g., "cat commands.txt | xorpsh"). - Addition of a new "-e" command line option. It can be used to tell xorpsh to exit immediately if the connection to the Finder fails. POLICY: - No significant changes. FEA/MFEA: - Major refactoring of the FEA/MFEA internals. - Critical bug fix that affects recent NetBSD and OpenBSD releases. - Critical IPv6-related bug fix when adding unicast forwarding entries to the kernel. This bug was exposed only on *BSD systems with 64-bit CPU. - If MFEA is started, it will explicitly enable the multicast forwarding flags that have been added to recent OpenBSD releases: net.inet.ip.mforwarding (for OpenBSD-3.9 and later) and net.inet6.ip6.mforwarding (for OpenBSD-4.0 and later). RIB: - No significant changes. RIP/RIPng: - Addition of support for "show ripng" xorpsh operational commands. - Critical RIPng-related bug fix. Previously the RIPng installed routes had incorrect outgoing interface toward the destination. - Bug fix related to the TTL for RIPng multicast packets: now it is set to 255 as specified in the protocol specification (RFC 2080) instead of 1. OLSR: - Added support for RFC 3626 Optimized Link State Routing Protocol. This is a fully fledged XORP routing process with policy route redistribution capability. The work was generously funded over 2007/2008 by CenGen, Inc. OSPF: - Bug fix related to OSPFv3 link-local scope LSAs. Previously the link-local scope LSAs were incorrectly flooded to links other than the one they belonged to. - Bug fix related to OSPFv3 Inter-Area-Prefix-LSAs. The check for the minimum size of an Inter-Area-Prefix-LSA was incorrect so short prefixes such as the default route would be rejected. - Added a clear database command. - In the OSPFv2 configuration "passive" is no longer a bool but a directive. Previously setting an interface to passive would set the interface to loopback and announce a host route for the interface. Using the passive keyword will still set the interface to loopback but now the network will be announced. If the previous behaviour of of announcing the host route is required the host variable can be set to true. BGP: - Added support for 4-byte AS numbers, as detailed in RFC 4893. From 1st Jan 2009 4-byte AS numbers will be allocated by default by RIPE, so it is desirable that all BGP implementations support four-byte AS numbers by that time. Currently 4-byte support is not enabled in XORP by default, but can be enabled using the "enable-4byte-as-numbers" configuration option. STATIC_ROUTES: - Bug fix that prevented the deletion of interface-specific routes using xorpsh. MLD/IGMP: - No significant changes. MLD/IGMP-Lite: - An implementation of Lightweight IGMP/MLD is available in directory ${XORP}/contrib/mld6igmp_lite. It can be used instead of the existing MLD/IGMP vanilla implementation by using the following command before compiling XORP: ./configure --with-mld6igmp_lite PIM-SM: - No significant changes. FIB2MRIB: - No significant changes. CLI: - No significant changes. SNMP: - No significant changes. From viney.khera at ipvidnet.com Tue Jul 22 13:46:04 2008 From: viney.khera at ipvidnet.com (Viney Khera) Date: Tue, 22 Jul 2008 13:46:04 -0700 Subject: [Xorp-users] Multicast not working In-Reply-To: <200807221947.m6MJkI7i023509@fruitcake.ICSI.Berkeley.EDU> References: <29b76190807211814r4017a425y73f8b9dbaa80c728@mail.gmail.com> <200807221947.m6MJkI7i023509@fruitcake.ICSI.Berkeley.EDU> Message-ID: <29b76190807221346n6dd40f5fq338a9de46a2f8278@mail.gmail.com> I got it working now. Thanks Viney On Tue, Jul 22, 2008 at 12:46 PM, Pavlin Radoslavov < pavlin at icsi.berkeley.edu> wrote: > Viney Khera wrote: > > > Hi, > > > > I'm new to Xorp router, i want to configure xorp routers for > multicasting. I > > want to route multicast packets through the routers. I began with a > simple > > network and unicasting worked on it, but i don't know why multicast is > not > > working. Please any one can look at the configuration of my routers and > tell > > me what's wrong? > > > > Here is what my network looks like : 2 xorp routers PC's running on XORP > > version: Release-1.4 live cd's, one connected to transmitting video > source > > and other to the recieving VLC streaming PC. Routers WAN side connected > to > > the cisco switch. > > > > > > > > Transmitter Receiver > > > > | | > > XORP Router 1 > > XORP Router 2 > > > > | | > > > > |-------------Cisco Switch---------------| > > Sorry, your diagram is mis-aligned, so it wasn't clear. > Anyway, here are two issues with your config: > > * The following config statement seems bogus and should be deleted: > cand-bsr-by-vif-addr: 0.0.0.0 > If you want to be explicitly abou the Cand BSR IP address, it > should be that address instead of 0.0.0.0 > > * fib2mrib is missing from both configuration files: > > protocols { > fib2mrib { > disable: false > } > } > > If the above two changes don't fix the problem, then please send the > following info (from xorpsh operational mode): > > show igmp group > show pim rp > show pim join > > > Pavlin > > > > > *Here is the configuration of 1st Router : > > * > > /*XORP Configuration File, v1.0*/ > > protocols { > > igmp { > > disable: false > > interface bge0 { > > vif bge0 { > > disable: false > > version: 2 > > enable-ip-router-alert-option-check: false > > query-interval: 125 > > query-last-member-interval: 1 > > query-response-interval: 10 > > robust-count: 2 > > } > > } > > interface bge1 { > > vif bge1 { > > disable: false > > version: 2 > > enable-ip-router-alert-option-check: false > > query-interval: 125 > > query-last-member-interval: 1 > > query-response-interval: 10 > > robust-count: 2 > > } > > } > > traceoptions { > > flag { > > all { > > disable: false > > } > > } > > } > > } > > pimsm4 { > > disable: false > > interface bge1 { > > vif bge1 { > > disable: false > > enable-ip-router-alert-option-check: false > > dr-priority: 1 > > hello-period: 30 > > hello-triggered-delay: 5 > > } > > } > > interface "register_vif" { > > vif "register_vif" { > > disable: false > > enable-ip-router-alert-option-check: false > > dr-priority: 1 > > hello-period: 30 > > hello-triggered-delay: 5 > > } > > } > > bootstrap { > > disable: false > > cand-bsr { > > scope-zone 224.0.0.0/32 { > > is-scope-zone: false > > cand-bsr-by-vif-name: "bge1" > > cand-bsr-by-vif-addr: 0.0.0.0 > > bsr-priority: 1 > > hash-mask-len: 30 > > } > > } > > cand-rp { > > group-prefix 224.0.0.0/32 { > > is-scope-zone: false > > cand-rp-by-vif-name: "bge1" > > cand-rp-by-vif-addr: 0.0.0.0 > > rp-priority: 192 > > rp-holdtime: 150 > > } > > } > > } > > switch-to-spt-threshold { > > disable: false > > interval: 100 > > bytes: 0 > > } > > traceoptions { > > flag { > > all { > > disable: false > > } > > } > > } > > } > > rip { > > interface bge0 { > > vif bge0 { > > address 192.168.1.1 { > > metric: 1 > > horizon: "split-horizon-poison-reverse" > > disable: false > > passive: false > > accept-non-rip-requests: true > > accept-default-route: true > > advertise-default-route: true > > route-timeout: 180 > > deletion-delay: 120 > > triggered-delay: 3 > > triggered-jitter: 66 > > update-interval: 30 > > update-jitter: 16 > > request-interval: 30 > > interpacket-delay: 50 > > } > > } > > } > > interface bge1 { > > vif bge1 { > > address 10.10.0.1 { > > metric: 1 > > horizon: "split-horizon-poison-reverse" > > disable: false > > passive: false > > accept-non-rip-requests: true > > accept-default-route: true > > advertise-default-route: true > > route-timeout: 180 > > deletion-delay: 120 > > triggered-delay: 3 > > triggered-jitter: 66 > > update-interval: 30 > > update-jitter: 16 > > request-interval: 30 > > interpacket-delay: 50 > > } > > } > > } > > export: "connected" > > } > > } > > policy { > > policy-statement connected { > > term export { > > from { > > protocol: "connected" > > } > > } > > } > > } > > fea { > > unicast-forwarding4 { > > disable: false > > } > > } > > interfaces { > > restore-original-config-on-shutdown: false > > interface bge0 { > > disable: false > > discard: false > > description: "LAN" > > vif bge0 { > > disable: false > > address 192.168.1.1 { > > prefix-length: 24 > > broadcast: 192.168.1.255 > > disable: false > > } > > } > > } > > interface bge1 { > > disable: false > > discard: false > > description: "WAN" > > vif bge1 { > > disable: false > > address 10.10.0.1 { > > prefix-length: 24 > > broadcast: 10.10.0.255 > > disable: false > > } > > } > > } > > interface lo0 { > > disable: false > > discard: false > > description: "Loopback interface" > > vif lo0 { > > disable: false > > } > > } > > } > > plumbing { > > mfea4 { > > disable: false > > interface bge0 { > > vif bge0 { > > disable: false > > } > > } > > interface bge1 { > > vif bge1 { > > disable: false > > } > > } > > interface "register_vif" { > > vif "register_vif" { > > disable: false > > } > > } > > traceoptions { > > flag { > > all { > > disable: false > > } > > } > > } > > } > > } > > > > > > *Here is the configuration of 2nd Router : > > * > > /*XORP Configuration File, v1.0*/ > > protocols { > > igmp { > > disable: false > > interface em0 { > > vif em0 { > > disable: false > > version: 2 > > enable-ip-router-alert-option-check: false > > query-interval: 125 > > query-last-member-interval: 1 > > query-response-interval: 10 > > robust-count: 2 > > } > > } > > interface fxp0 { > > vif fxp0 { > > disable: false > > version: 2 > > enable-ip-router-alert-option-check: false > > query-interval: 125 > > query-last-member-interval: 1 > > query-response-interval: 10 > > robust-count: 2 > > } > > } > > traceoptions { > > flag { > > all { > > disable: false > > } > > } > > } > > } > > pimsm4 { > > disable: false > > interface fxp0 { > > vif fxp0 { > > disable: false > > enable-ip-router-alert-option-check: false > > dr-priority: 1 > > hello-period: 30 > > hello-triggered-delay: 5 > > } > > } > > interface "register_vif" { > > vif "register_vif" { > > disable: false > > enable-ip-router-alert-option-check: false > > dr-priority: 1 > > hello-period: 30 > > hello-triggered-delay: 5 > > } > > } > > bootstrap { > > disable: false > > cand-bsr { > > scope-zone 224.0.0.0/32 { > > cand-bsr-by-vif-name: "fxp0" > > } > > } > > cand-rp { > > group-prefix 224.0.0.0/32 { > > cand-rp-by-vif-name: "fxp0" > > } > > } > > } > > switch-to-spt-threshold { > > disable: false > > interval: 100 > > bytes: 0 > > } > > } > > rip { > > interface em0 { > > vif em0 { > > address 192.168.2.1 { > > metric: 1 > > horizon: "split-horizon-poison-reverse" > > disable: false > > passive: false > > accept-non-rip-requests: true > > accept-default-route: true > > advertise-default-route: true > > route-timeout: 180 > > deletion-delay: 120 > > triggered-delay: 3 > > triggered-jitter: 66 > > update-interval: 30 > > update-jitter: 16 > > request-interval: 30 > > interpacket-delay: 50 > > } > > } > > } > > interface fxp0 { > > vif fxp0 { > > address 10.10.0.2 { > > metric: 1 > > horizon: "split-horizon-poison-reverse" > > disable: false > > passive: false > > accept-non-rip-requests: true > > accept-default-route: true > > advertise-default-route: true > > route-timeout: 180 > > deletion-delay: 120 > > triggered-delay: 3 > > triggered-jitter: 66 > > update-interval: 30 > > update-jitter: 16 > > request-interval: 30 > > interpacket-delay: 50 > > } > > } > > } > > export: "connected" > > } > > } > > policy { > > policy-statement connected { > > term export { > > from { > > protocol: "connected" > > } > > } > > } > > } > > fea { > > unicast-forwarding4 { > > disable: false > > } > > } > > interfaces { > > restore-original-config-on-shutdown: false > > interface em0 { > > disable: false > > discard: false > > description: "LAN" > > vif em0 { > > disable: false > > address 192.168.2.1 { > > prefix-length: 24 > > broadcast: 192.168.2.255 > > disable: false > > } > > } > > } > > interface fxp0 { > > disable: false > > discard: false > > description: "WAN" > > vif fxp0 { > > disable: false > > address 10.10.0.2 { > > prefix-length: 24 > > broadcast: 10.10.0.255 > > disable: false > > } > > } > > } > > interface lo0 { > > disable: false > > discard: false > > description: "Loopback interface" > > vif lo0 { > > disable: false > > } > > } > > } > > plumbing { > > mfea4 { > > disable: false > > interface em0 { > > vif em0 { > > disable: false > > } > > } > > interface fxp0 { > > vif fxp0 { > > disable: false > > } > > } > > interface "register_vif" { > > vif "register_vif" { > > disable: false > > } > > } > > traceoptions { > > flag { > > all { > > disable: false > > } > > } > > } > > } > > } > > > > > > I also sniffed the network packets from switch and looked them in > wireshark, > > igmp join/ unjoin and rip request/response seems to be working properly. > I > > can also see PIM hello and bootstrap messages exchanged. I used show pim > > bootstrap to check, it also seems to be correct as it is electing one of > the > > wan addresses of the 2 routers as bsr. > > > > Thanks > > Regards > > Viney Khera > > IPVN > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080722/96a0ba9d/attachment-0001.html From tushar.mehta at einfochips.com Thu Jul 24 06:30:23 2008 From: tushar.mehta at einfochips.com (Tushar Mehta) Date: Thu, 24 Jul 2008 19:00:23 +0530 Subject: [Xorp-users] IGMP host version problem Message-ID: <488883EF.4030004@einfochips.com> in my setup, when XORP(IGMPv3 for IPv4 router sends IGMP version 1 or 2 query then IGMPv3 host is changed to version 1 or 2 respectively but when XORP turns back to IGMPv3 querier, host is not coming back to version 3 and still sending report with version or 2 what is the reason? here i have attached the configuration file and my setup. XORP machine specification: OS: Fedora Core 5 kernel version: 2.6.15-1.2054_FC5 architecture: i686 XORP version: 1.4 IGMP version: 3( for IPv4) Host Machine specification: OS: RHEL 4 kernel version: 2.6.9-5.EL architecture: i686 -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. _____________________________________________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config.boot.sample_igmp Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080724/76a6028f/attachment-0001.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.jpg Type: image/jpeg Size: 27756 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080724/76a6028f/attachment-0001.jpg From tushar.mehta at einfochips.com Wed Jul 23 23:39:37 2008 From: tushar.mehta at einfochips.com (Tushar Mehta) Date: Thu, 24 Jul 2008 12:09:37 +0530 Subject: [Xorp-users] Getting problem in Querier Election Message-ID: <488823A9.7070508@einfochips.com> I want to check whether XORP is performing Querier Election when one of the IGMPv3 router detect that some another router also sending query. I am attaching my setup design and also my configuration file. i am running IGMPv3 for IPv4 on the both interfaces. both interfaces of the XORP is connected to port-1 and port-2 respectively and i am checking at the port-3. Can any one tell what is the problem with the setup or in the configuration file? I want to the check the election process of IGMPv3. OS specification on which XORP is running: OS: Fedora Core 5 kernel version: 2.6.15-1.2054_FC5 architecture: i686 XORP version: 1.4 IGMP version: 3( for IPv4) -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. _____________________________________________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config.boot.sample_igmp Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080724/2f3771b4/attachment-0001.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: election process.jpg Type: image/jpeg Size: 50968 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080724/2f3771b4/attachment-0001.jpg From pavlin at ICSI.Berkeley.EDU Thu Jul 24 09:37:30 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 24 Jul 2008 09:37:30 -0700 Subject: [Xorp-users] How to decide Unsolicited Report Interval in IGMPv3 XORP In-Reply-To: <4886CCB7.3000101@einfochips.com> References: <48856D06.1090802@einfochips.com> <200807221909.m6MJ8S45017553@fruitcake.ICSI.Berkeley.EDU> <4886CCB7.3000101@einfochips.com> Message-ID: <200807241637.m6OGbUjI021756@fruitcake.ICSI.Berkeley.EDU> Tushar Mehta wrote: > I want to configure my OS(on which XORP is running) for IGMPv3 host also and > want to set parameter Unsolicited Report Interval. > which file i have to modify for configuring my OS as IGMPv3 host. As I mentioned in my earlier email, those settings are OS specific, so the Linux folks are a better source of information. Anyway, after a quick check, I guess you can use the following command (as a root) to explicitly set the IGMP version to 3: sysctl -w net.ipv4.conf.all.force_igmp_version=3 Regarding the setting the Unsolicited Report Interval in the kernel, I guess you cannot change it without recomping the kernel. A quick search in file linux/net/ipv4/igmp.c (Linux kernel 2.6.15.1) reveals that it is defined there and is not configuratble: #define IGMP_Unsolicited_Report_Interval (10*HZ) Hence, if you want to change it, you must modify the above value and recompile the kernel. Hope that helps, Pavlin > I am attaching the XORP configuration file which is used by me for running > IGMPv3(IPv4). > Robustness variable is set to 5(high) just for increasing the retransmission > for the state change report > so that i can check whether interval between them is ( 0, Unsolicited Report > Interval) or not. > > OS specification on which XORP is running: > OS: Fedora Core 5 > kernel version: 2.6.15-1.2054_FC5 > architecture: i686 > XORP version: 1.4 > IGMP version: 3( for IPv4) > > Pavlin Radoslavov wrote: > > Tushar Mehta wrote: > > > > > >> Can anyone tell me how i can find the Unsolicited Report Interval that is > >> used when any IGMP host use while transmitting state change record? > >> > >> according to the rfc-3376: > >> - To cover the possibility of the State-Change Report being missed by one > >> or more multicast routers, it is retransmitted [Robustness > >> Variable] - 1 more times, at intervals chosen at random from the range > >> (0, [Unsolicited Report Interval]). > >> > >> - Unsolicited Report Interval > >> The Unsolicited Report Interval is the time between repetitions of a > >> host's initial report of membership in a group. Default: 1 second. > >> > >> by default Unsolicited Report Interval should be 1 but XORP is not > >> following it. it is picking up this interval randamly. > >> > > > > As Bruce mentioned in another email on the subject, this is > > kernel-related config. > > > > To clarify: > > IGMP/MLD has two parts: router-side and host-side. > > The host-side is typically implemented by the OS (in the kernel). > > The router-side is typically an userland process. > > > > XORP implements only the router-side, and for the host-side relies > > on the kernel implementation. > > The configuration changes in XORP apply only to the router side; the > > host-side configuration changes are OS specific and you should refer > > to the particular OS/kernel documentation for that. > > In the future we might expose the host-side configuration in the > > xorpsh, but right now this is a very low priority for us. > > > > Hope that helps, > > Pavlin > > > > > > > > > >> i m attaching the configuration file that i am using for my set up. > >> > >> > >> -- > >> _____________________________________________________________________ > >> Disclaimer: This e-mail message and all attachments transmitted with it > >> are intended solely for the use of the addressee and may contain legally > >> privileged and confidential information. If the reader of this message > >> is not the intended recipient, or an employee or agent responsible for > >> delivering this message to the intended recipient, you are hereby > >> notified that any dissemination, distribution, copying, or other use of > >> this message or its attachments is strictly prohibited. If you have > >> received this message in error, please notify the sender immediately by > >> replying to this message and please delete it from your computer. Any > >> views expressed in this message are those of the individual sender > >> unless otherwise stated.Company has taken enough precautions to prevent > >> the spread of viruses. However the company accepts no liability for any > >> damage caused by any virus transmitted by this email. > >> _____________________________________________________________________ > >> _______________________________________________ > >> Xorp-users mailing list > >> Xorp-users at xorp.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > >> > > > > > > Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com > > > > > > > > /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu Exp $ */ > > > interfaces { > restore-original-config-on-shutdown: false > interface eth0 { > description: "ethernet interface" > disable: false > default-system-config > } > } > > > fea { > unicast-forwarding4 { > disable: false > forwarding-entries { > retain-on-startup: false > retain-on-shutdown: false > } > } > } > > > policy { > /* Describe connected routes for redistribution */ > policy-statement connected { > term export { > from { > protocol: "connected" > } > } > } > } > > policy { > /* Describe static routes for redistribution */ > policy-statement static { > term export { > from { > protocol: "static" > } > } > } > } > > plumbing { > mfea4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > igmp { > disable: false > interface eth0 { > vif eth0 { > disable: false > version: 3 > enable-ip-router-alert-option-check: true > query-interval: 5 > query-last-member-interval: 5 > query-response-interval: 2 > robust-count: 5 > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at ICSI.Berkeley.EDU Thu Jul 24 09:58:37 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 24 Jul 2008 09:58:37 -0700 Subject: [Xorp-users] IGMP host version problem In-Reply-To: <488883EF.4030004@einfochips.com> References: <488883EF.4030004@einfochips.com> Message-ID: <200807241658.m6OGwbwC025796@fruitcake.ICSI.Berkeley.EDU> Tushar Mehta wrote: > in my setup, when XORP(IGMPv3 for IPv4 router sends IGMP version 1 or 2 query > then IGMPv3 host is changed to version 1 or 2 respectively > but when XORP turns back to IGMPv3 querier, host is not coming back to version > 3 and still sending report with version or 2 > > what is the reason? According to RFC 3376, the host should switch back to the higher IGMP version after the "Older Version Querier Interval". That interval is defined in Section 8.12 to: ((the Robustness Variable) times (the Query Interval in the last Query received)) plus (one Query Response Interval) and the default value is 2 * 125 + 10 = 260 seconds. If the host doesn't switch back after 260 seconds (or whatever the value is for your config), then it is probably a bug in the kernel's IGMP implementation. Pavlin > here i have attached the configuration file and my setup. > > XORP machine specification: > OS: Fedora Core 5 > kernel version: 2.6.15-1.2054_FC5 > architecture: i686 > XORP version: 1.4 > IGMP version: 3( for IPv4) > > Host Machine specification: > OS: RHEL 4 > kernel version: 2.6.9-5.EL > architecture: i686 > > > -- > _____________________________________________________________________ > Disclaimer: This e-mail message and all attachments transmitted with it > are intended solely for the use of the addressee and may contain legally > privileged and confidential information. If the reader of this message > is not the intended recipient, or an employee or agent responsible for > delivering this message to the intended recipient, you are hereby > notified that any dissemination, distribution, copying, or other use of > this message or its attachments is strictly prohibited. If you have > received this message in error, please notify the sender immediately by > replying to this message and please delete it from your computer. Any > views expressed in this message are those of the individual sender > unless otherwise stated.Company has taken enough precautions to prevent > the spread of viruses. However the company accepts no liability for any > damage caused by any virus transmitted by this email. > _____________________________________________________________________ > > /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu Exp $ */ > > > interfaces { > restore-original-config-on-shutdown: false > interface eth0 { > description: "ethernet interface" > disable: false > default-system-config > } > } > > > fea { > unicast-forwarding4 { > disable: false > forwarding-entries { > retain-on-startup: false > retain-on-shutdown: false > } > } > } > > > policy { > /* Describe connected routes for redistribution */ > policy-statement connected { > term export { > from { > protocol: "connected" > } > } > } > } > > policy { > /* Describe static routes for redistribution */ > policy-statement static { > term export { > from { > protocol: "static" > } > } > } > } > > plumbing { > mfea4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > igmp { > disable: false > interface eth0 { > vif eth0 { > disable: false > version: 3 > enable-ip-router-alert-option-check: true > query-interval: 5 > query-last-member-interval: 5 > query-response-interval: 2 > robust-count: 2 > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at ICSI.Berkeley.EDU Thu Jul 24 11:16:03 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 24 Jul 2008 11:16:03 -0700 Subject: [Xorp-users] Getting problem in Querier Election In-Reply-To: <488823A9.7070508@einfochips.com> References: <488823A9.7070508@einfochips.com> Message-ID: <200807241816.m6OIG3iQ010544@fruitcake.ICSI.Berkeley.EDU> Tushar Mehta wrote: > I want to check whether XORP is performing Querier Election when one of the > IGMPv3 router detect that some another router also sending query. > I am attaching my setup design and also my configuration file. > i am running IGMPv3 for IPv4 on the both interfaces. > both interfaces of the XORP is connected to port-1 and port-2 > respectively and i am checking at the port-3. > > Can any one tell what is the problem with the setup or in the configuration > file? > I want to the check the election process of IGMPv3. What are you trying to achieve by connecting two interfaces to the same subnet? For multicast purpose this could be a bit dangerous (to say the least), and you might be better off by using VLANs (if you really want two interfaces connected to the same LAN). Anyway, below is some info that might help you get the Querier Election working in your setup. The issue you are seeing is that both XORP interfaces are connected to the same subnet. As a result of that: * The IGMP router side implementation in XORP will ignore its own queries even though they were originated from a different interface. You could try to change this by modifying the following code inside file mld6igmp/mld6igmp_proto.cc : // Ignore my own queries if (mld6igmp_node().is_my_addr(src)) return (XORP_ERROR); to: // Ignore my own queries if (is_my_addr(src)) return (XORP_ERROR); * The Query from the other interface will appear as coming from a router that is not directly connected to the subnet (because of the different subnet address). To get around this you might want to comment-out the following code inside same file: // Source address must be directly connected if (! mld6igmp_node().is_directly_connected(*this, src)) { error_msg = c_format("RX %s from %s to %s on vif %s: " "source must be directly connected", proto_message_type2ascii(message_type), cstring(src), cstring(dst), name().c_str()); XLOG_WARNING("%s", error_msg.c_str()); return (XORP_ERROR); } Hope that helps, Pavlin > OS specification on which XORP is running: > OS: Fedora Core 5 > kernel version: 2.6.15-1.2054_FC5 > architecture: i686 > XORP version: 1.4 > IGMP version: 3( for IPv4) > > > > -- > _____________________________________________________________________ > Disclaimer: This e-mail message and all attachments transmitted with it > are intended solely for the use of the addressee and may contain legally > privileged and confidential information. If the reader of this message > is not the intended recipient, or an employee or agent responsible for > delivering this message to the intended recipient, you are hereby > notified that any dissemination, distribution, copying, or other use of > this message or its attachments is strictly prohibited. If you have > received this message in error, please notify the sender immediately by > replying to this message and please delete it from your computer. Any > views expressed in this message are those of the individual sender > unless otherwise stated.Company has taken enough precautions to prevent > the spread of viruses. However the company accepts no liability for any > damage caused by any virus transmitted by this email. > _____________________________________________________________________ > > /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu Exp $ */ > > > interfaces { > restore-original-config-on-shutdown: false > interface eth0 { > description: "ethernet interface" > disable: false > default-system-config > } > interface eth1 { > description: "ethernet interface" > disable: false > default-system-config > } > } > > > fea { > unicast-forwarding4 { > disable: false > forwarding-entries { > retain-on-startup: false > retain-on-shutdown: false > } > } > } > > > policy { > /* Describe connected routes for redistribution */ > policy-statement connected { > term export { > from { > protocol: "connected" > } > } > } > } > > policy { > /* Describe static routes for redistribution */ > policy-statement static { > term export { > from { > protocol: "static" > } > } > } > } > > plumbing { > mfea4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1 { > vif eth1 { > disable: false > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > igmp { > disable: false > interface eth0 { > vif eth0 { > disable: false > version: 3 > enable-ip-router-alert-option-check: true > query-interval: 5 > query-last-member-interval: 5 > query-response-interval: 2 > robust-count: 2 > } > } > interface eth1 { > vif eth1 { > disable: false > version: 3 > enable-ip-router-alert-option-check: true > query-interval: 5 > query-last-member-interval: 5 > query-response-interval: 2 > robust-count: 2 > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at ICSI.Berkeley.EDU Thu Jul 24 11:17:29 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 24 Jul 2008 11:17:29 -0700 Subject: [Xorp-users] XORP IGMPv3 is not accepting the report with source IP 0.0.0.0 In-Reply-To: <200807221938.m6MJbkbl022277@fruitcake.ICSI.Berkeley.EDU> References: <48856F61.8070304@einfochips.com> <200807221938.m6MJbkbl022277@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200807241817.m6OIHTM7010761@fruitcake.ICSI.Berkeley.EDU> Tushar, Were you able to verify whether the patch actually fixes the problem. Thanks, Pavlin Pavlin Radoslavov wrote: > Tushar Mehta wrote: > > > according to rfc-3376: > > An IGMP report is sent with a valid IP source address for the > > destination subnet. The 0.0.0.0 source address may be used by a > > system that has not yet acquired an IP address. Note that the > > 0.0.0.0 source address may simultaneously be used by multiple systems > > on a LAN. Routers MUST accept a report with a source address of > > 0.0.0.0. > > > > but in my case it is showing me this error message on the terminal "source > > must be unicast".... > > > > XORP is accepting my IGMPv3 report with source IP address "0.0.0.0". > ~~~~ > I guess you meant to say that "XORP is NOT accepting..." > > Is the "source must be unicast" error message coming from the FEA or > IGMP? The beginning of the error message should tell that. > > If it is coming from IGMP, please try the included patch (vs latest > XORP code in CVS) and see whether it fixes the problem. > > Note that you must have enabled IGMPv3, because the acceptance of > 0.0.0.0 is specified only in RFC 3376 (but not in earlier IGMP > versions). Also, note that RFC 3810 doesn't say anything about IP > source addresses that are zero, hence this won't apply for MLDv2 > either. > > Pavlin > > Index: mld6igmp_vif.cc > =================================================================== > RCS file: /usr/local/www/data/cvs/xorp/mld6igmp/mld6igmp_vif.cc,v > retrieving revision 1.88 > diff -u -p -r1.88 mld6igmp_vif.cc > --- mld6igmp_vif.cc 4 Jan 2008 03:16:52 -0000 1.88 > +++ mld6igmp_vif.cc 22 Jul 2008 19:35:09 -0000 > @@ -1192,7 +1192,7 @@ Mld6igmpVif::mld6igmp_process(const IPvX > // > // Source address check. > // > - if (! src.is_unicast()) { > + if (! (src.is_unicast() || (allow_src_zero_address && src.is_zero()))) { > // > // Source address must always be unicast. > // The kernel should have checked that, but just in case... > @@ -1216,7 +1216,8 @@ Mld6igmpVif::mld6igmp_process(const IPvX > src.af(), family()); > } > // Source address must be directly connected > - if (! mld6igmp_node().is_directly_connected(*this, src)) { > + if (! (mld6igmp_node().is_directly_connected(*this, src) > + || (allow_src_zero_address && src.is_zero()))) { > error_msg = c_format("RX %s from %s to %s on vif %s: " > "source must be directly connected", > proto_message_type2ascii(message_type), > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From dave at fishherder.dyndns.org Mon Jul 28 10:36:46 2008 From: dave at fishherder.dyndns.org (dave) Date: Mon, 28 Jul 2008 10:36:46 -0700 Subject: [Xorp-users] help me understand 224.0.0.22 Message-ID: <20080728173646.GA25783@fishherder.dyndns.org> I'm relatively new to multicast networking and IGMP, so I apologize in advance if my question seems obvioius. >From RFC 2236 section 9 9. Message destinations This information is provided elsewhere in the document, but is summarized here for convenience. Message Type Destination Group ------------ ----------------- General Query ALL-SYSTEMS (224.0.0.1) Group-Specific Query The group being queried Membership Report The group being reported Leave Message ALL-ROUTERS (224.0.0.2) I interpret this as meaning that multicast processes have 3 destinations to send IGMP messages to : all-systems, all-routers, and the desired group address. So what is the IGMP group addr (224.0.0.22) for? What problem does it solve that isn't addressed by the table above? How important is it that I allow this group in my security policies (firewalls, etc)? Thanks in advance - Dave From asaeda at sfc.wide.ad.jp Mon Jul 28 10:54:26 2008 From: asaeda at sfc.wide.ad.jp (Hitoshi Asaeda) Date: Mon, 28 Jul 2008 18:54:26 +0100 (IST) Subject: [Xorp-users] help me understand 224.0.0.22 In-Reply-To: <20080728173646.GA25783@fishherder.dyndns.org> References: <20080728173646.GA25783@fishherder.dyndns.org> Message-ID: <20080728.185426.89654579.asaeda@sfc.wide.ad.jp> > So what is the IGMP group addr (224.0.0.22) for? What problem does it > solve that isn't addressed by the table above? How important is it that Destination address for IGMPv3 report messages. See RFC3376. > I allow this group in my security policies (firewalls, etc)? If you want to support IGMPv3 and/or SSM, the answer is "yes". -- Hitoshi Asaeda From dave at fishherder.dyndns.org Mon Jul 28 11:10:44 2008 From: dave at fishherder.dyndns.org (dave) Date: Mon, 28 Jul 2008 11:10:44 -0700 Subject: [Xorp-users] help me understand 224.0.0.22 In-Reply-To: <20080728.185426.89654579.asaeda@sfc.wide.ad.jp> References: <20080728173646.GA25783@fishherder.dyndns.org> <20080728.185426.89654579.asaeda@sfc.wide.ad.jp> Message-ID: <20080728181044.GA26047@fishherder.dyndns.org> On Mon, Jul 28, 2008 at 06:54:26PM +0100, Hitoshi Asaeda wrote: > > So what is the IGMP group addr (224.0.0.22) for? What problem does it > > solve that isn't addressed by the table above? How important is it that > > Destination address for IGMPv3 report messages. See RFC3376. > > > I allow this group in my security policies (firewalls, etc)? > > If you want to support IGMPv3 and/or SSM, the answer is "yes". > -- > Hitoshi Asaeda That's it, thank you. From jose.spam at netvisao.pt Wed Jul 30 16:43:27 2008 From: jose.spam at netvisao.pt (Jose Manuel dos Santos Calhariz) Date: Thu, 31 Jul 2008 00:43:27 +0100 Subject: [Xorp-users] Compiling xorp with olsr Message-ID: <20080730234327.GA28029@calhariz.com> What is the proprer way to compile xorp 1.5 with olsr enabled? When I configure xorp without options, ./configure generates in the end a contrib/olsr/Makefile file. When I add the option --with-olsr ./configure don't generate a contrib/olsr/makefile. I am preparing a new package of xorp for Debian, so I would like to know the proper way of compiling it. I don't know enough about olsr to test if the binary of xorp have olsr enabled or not. But it seams to me is a bug of ./configure that disable olsr support with the option --with-olsr. Jos? Calhariz -- -- Quando as contas s?o pagas, ningu?m presta aten??o no tamanho delas --Marion Davies -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080731/565405c2/attachment.bin From bms at incunabulum.net Thu Jul 31 01:11:39 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 31 Jul 2008 09:11:39 +0100 Subject: [Xorp-users] Compiling xorp with olsr In-Reply-To: <20080730234327.GA28029@calhariz.com> References: <20080730234327.GA28029@calhariz.com> Message-ID: <489173BB.70507@incunabulum.net> Hi, OLSR is turned on by default at the moment and should build w/o any additional options, if adding --with-olsr it won't do anything due to how configure.in is currently set up. Jose Manuel dos Santos Calhariz wrote: > I am preparing a new package of xorp for Debian, so I would like to > know the proper way of compiling it. I don't know enough about olsr > to test if the binary of xorp have olsr enabled or not. But it seams > to me is a bug of ./configure that disable olsr support with the > option --with-olsr. > If adding --with-olsr is causing it not to generate a makefile thne that is most likely a bug, however, we are using documented configure.in practice to implement the --with-... options. Any suggestions about how to fix this at autoconf level would be appreciated. thanks! BMS From jose.spam at netvisao.pt Thu Jul 31 03:10:39 2008 From: jose.spam at netvisao.pt (Jose Manuel dos Santos Calhariz) Date: Thu, 31 Jul 2008 11:10:39 +0100 Subject: [Xorp-users] Compiling xorp with olsr In-Reply-To: <489173BB.70507@incunabulum.net> References: <20080730234327.GA28029@calhariz.com> <489173BB.70507@incunabulum.net> Message-ID: <20080731101038.GA14676@calhariz.com> On Thu, Jul 31, 2008 at 09:11:39AM +0100, Bruce M Simpson wrote: > Hi, > > OLSR is turned on by default at the moment and should build w/o any > additional options, if adding --with-olsr it won't do anything due to > how configure.in is currently set up. Thank you for the information, I will correct my ./configure command. > > Jose Manuel dos Santos Calhariz wrote: > >I am preparing a new package of xorp for Debian, so I would like to > >know the proper way of compiling it. I don't know enough about olsr > >to test if the binary of xorp have olsr enabled or not. But it seams > >to me is a bug of ./configure that disable olsr support with the > >option --with-olsr. > > > > If adding --with-olsr is causing it not to generate a makefile thne that > is most likely a bug, however, we are using documented configure.in > practice to implement the --with-... options. > > Any suggestions about how to fix this at autoconf level would be > appreciated. I will see what I can do about it. > > thanks! > BMS > > Thanks Jose Calhariz -- -- Quando as contas s?o pagas, ningu?m presta aten??o no tamanho delas --Marion Davies -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080731/c6a667a6/attachment.bin