From Yves.Pauchard at hefr.ch Tue May 9 05:51:11 2006 From: Yves.Pauchard at hefr.ch (Pauchard Yves) Date: Tue, 9 May 2006 14:51:11 +0200 Subject: [Xorp-users] FW: Unwanted Multicast ipv4 forwarding Message-ID: Hello, I think I found the error: The source, destination and both XORP machine ports are connected to the same switch... The XORP machine does not need to route the Multicast packets, since the switch already forwards them to all the ports (like a broadcast). I found this when the destination received the multicast packets without XORP running. I am sorry for the inquiry - it was not a XORP problem. Regards, Yves ________________________________ From: Pauchard Yves Sent: May 8, 2006 9:01 AM To: 'xorp-users at xorp.org' Subject: Unwanted Multicast ipv4 forwarding Hello, I have the following network architecture : RP \ --------- XORP ----- Destination Source / I want to use PIM on XORP to forward multicast streams from a VLC server to one network to the other. See the configuration of XORP at the end of this email. Everything seems to work fine, Multicast SAP announcements are propagated from the RP and the Source to the destination and I can connect to a multicast stream from a VLC server on Source with a VLC client on Destination. The problem is, that as soon as the VLC server stream is turned on (RTP, IP_destination=239.255.12.42), XORP forwards all these packets to the Destination network, although no client is connected to the stream. Why would that be? I get these messages in the stdout from XORP when the VLC server is running: [ 2006/05/05 16:49:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 2 vif_index = 1 src = XX.XX.31.32 dst = 239.255.12.42 [ 2006/05/05 16:49:07 TRACE xorp_pimsm4 PIM ] RX WRONGVIF signal from MFEA_4: vif_index = 1 src = XX.XX.31.32 dst = 239.255.12.42 Thanks for your help. Regards, Yves -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060509/071807f4/attachment.html From I.FernandezDiaz at telecom.tno.nl Tue May 9 08:07:34 2006 From: I.FernandezDiaz at telecom.tno.nl (I.FernandezDiaz at telecom.tno.nl) Date: Tue, 9 May 2006 17:07:34 +0200 Subject: [Xorp-users] OSPF/connectivity problem Message-ID: <81FEC275650AE14EBD5245E624762B9701F4F3D2@ds07.tnoase.telecom.tno.nl> Dear All, I have a setup with one XORP platform (Release 1.2 RC on FreeBSD) and one cisco router, both running OSPF. The physical layer part seams to be ok (the common interface is up at both sides, the line protocol is up, the speed is the same at both sides, both full duplex). But I cannot ping one router from the other router. xorp-------------------------------------------------------------------- -cisco em1: 192.168.2.2 f0/0 192.168.2.3 In the cisco's routing table I see the network address which I am trying to ping as directly connected. In the xorp router I see the network I am trying to ping as directly connected, but no ospf routing table and no OSPF neighbours. The cisco router sends hello messages. this is the configuration which I am using /*XORP Configuration File, v1.0*/ interfaces { restore-original-config-on-shutdown: false interface em0 { description: "data interface" disable: false discard: false vif em0 { address 192.168.1.2 { prefix-length: 24 disable: false broadcast: 192.168.1.255 } disable: false } } interface em1 { description: "data interface" disable: false discard: false vif em1 { address 192.168.2.2 { disable: false prefix-length: 24 broadcast: 192.168.2.255 } disable: false } } } fea { unicast-forwarding4 { disable: false } } protocols { ospf4 { area 0.0.0.0 { area-type: "normal" interface em0 { link-type: "broadcast" vif em0 } interface em1 { link-type: "broadcast" vif em1 { address 192.168.2.2 { priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 retransmit-interval: 5 transit-delay: 1 passive: false disable: false } } } } ip-router-alert: false router-id: 192.168.2.2 } } Can anybody tell me if I am forgetting something? How can I see if the ospf process at the xorp side is doing something. Is there something as debug in xorp? Thank you, Irene -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060509/383ba7c0/attachment.html From mhorn at vyatta.com Tue May 9 08:46:55 2006 From: mhorn at vyatta.com (Mike Horn) Date: Tue, 9 May 2006 09:46:55 -0600 Subject: [Xorp-users] OSPF/connectivity problem In-Reply-To: <81FEC275650AE14EBD5245E624762B9701F4F3D2@ds07.tnoase.telecom.tno.nl> Message-ID: <01b701c6737f$cd1c69b0$6502a8c0@caddisconsulting.com> Hi Irene, It sounds like the issue is a Layer 2 / 3 connectivity issue and not necessarily an OSPF issue (since you do not need OSPF to be able to ping another router on the same IP subnet). Here are some questions that might help identify the problem: How are the two routers connected? Do they go through an Ethernet switch? Are VLANs configured on the switch? Have you tried directly connecting the devices via a crossover cable? -mike _____ From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of I.FernandezDiaz at telecom.tno.nl Sent: Tuesday, May 09, 2006 9:08 AM To: xorp-users at xorp.org Subject: [Xorp-users] OSPF/connectivity problem Dear All, I have a setup with one XORP platform (Release 1.2 RC on FreeBSD) and one cisco router, both running OSPF. The physical layer part seams to be ok (the common interface is up at both sides, the line protocol is up, the speed is the same at both sides, both full duplex). But I cannot ping one router from the other router. xorp---------------------------------------------------------------------cis co em1: 192.168.2.2 f0/0 192.168.2.3 In the cisco's routing table I see the network address which I am trying to ping as directly connected. In the xorp router I see the network I am trying to ping as directly connected, but no ospf routing table and no OSPF neighbours. The cisco router sends hello messages. this is the configuration which I am using /*XORP Configuration File, v1.0*/ interfaces { restore-original-config-on-shutdown: false interface em0 { description: "data interface" disable: false discard: false vif em0 { address 192.168.1.2 { prefix-length: 24 disable: false broadcast: 192.168.1.255 } disable: false } } interface em1 { description: "data interface" disable: false discard: false vif em1 { address 192.168.2.2 { disable: false prefix-length: 24 broadcast: 192.168.2.255 } disable: false } } } fea { unicast-forwarding4 { disable: false } } protocols { ospf4 { area 0.0.0.0 { area-type: "normal" interface em0 { link-type: "broadcast" vif em0 } interface em1 { link-type: "broadcast" vif em1 { address 192.168.2.2 { priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 retransmit-interval: 5 transit-delay: 1 passive: false disable: false } } } } ip-router-alert: false router-id: 192.168.2.2 } } Can anybody tell me if I am forgetting something? How can I see if the ospf process at the xorp side is doing something. Is there something as debug in xorp? Thank you, Irene -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060509/d8c902bd/attachment-0001.html From Yves.Pauchard at hefr.ch Mon May 8 00:01:09 2006 From: Yves.Pauchard at hefr.ch (Pauchard Yves) Date: Mon, 8 May 2006 09:01:09 +0200 Subject: [Xorp-users] Unwanted Multicast ipv4 forwarding Message-ID: Hello, I have the following network architecture : RP \ --------- XORP ----- Destination Source / I want to use PIM on XORP to forward multicast streams from a VLC server to one network to the other. See the configuration of XORP at the end of this email. Everything seems to work fine, Multicast SAP announcements are propagated from the RP and the Source to the destination and I can connect to a multicast stream from a VLC server on Source with a VLC client on Destination. The problem is, that as soon as the VLC server stream is turned on (RTP, IP_destination=239.255.12.42), XORP forwards all these packets to the Destination network, although no client is connected to the stream. Why would that be? I get these messages in the stdout from XORP when the VLC server is running: [ 2006/05/05 16:49:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 2 vif_index = 1 src = XX.XX.31.32 dst = 239.255.12.42 [ 2006/05/05 16:49:07 TRACE xorp_pimsm4 PIM ] RX WRONGVIF signal from MFEA_4: vif_index = 1 src = XX.XX.31.32 dst = 239.255.12.42 Thanks for your help. Regards, Yves ----------------------------- XORP configuration ----------------------------- /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.35 2006/03/09 12:18:20 pavlin Exp $ */ interfaces { restore-original-config-on-shutdown: false interface dev8914 { description: "Link to Net1" disable: false vif dev8914 { disable: false address XX.XX.30.173 { prefix-length: 23 broadcast: 160.98.31.255 disable: false } } } interface eth0 { description: "Link to Net2" disable: false vif eth0 { disable: false address XX.XX.44.1 { prefix-length: 24 broadcast: 160.98.44.255 disable: false } } } } fea { unicast-forwarding4 { disable: false } /* unicast-forwarding6 { disable: false } */ } protocols { static { route4 XX.XX.40.0/24 { next-hop: XX.XX.44.4 metric: 1 } route4 XX.XX.41.0/24 { next-hop: XX.XX.44.4 metric: 1 } route4 XX.XX.38.128/25 { next-hop: XX.XX.44.2 metric: 1 } route4 XX.XX.38.0/25 { next-hop: XX.XX.44.3 metric: 1 } route4 XX.XX.39.0/24 { next-hop: XX.XX.44.2 metric: 1 } } } plumbing { mfea4 { disable: false interface dev8914 { vif dev8914 { 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 } } } /* mfea6 { disable: false interface dc0 { vif dc0 { disable: false } } interface register_vif { vif register_vif { disable: false } } traceoptions { flag all { disable: false } } } */ } protocols { igmp { disable: false interface dev8914 { vif dev8914 { 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 eth0 { vif eth0 { 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 } } } /* mld { disable: false interface dev8914 { vif dev8914 { disable: false version: 1 enable-ip-router-alert-option-check: false query-interval: 125 query-last-member-interval: 1 query-response-interval: 10 robust-count: 2 } } interface eth0 { vif eth0 { disable: false version: 1 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 } } } */ } protocols { pimsm4 { disable: false interface dev8914 { vif dev8914 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ /* hello-period: 30 */ /* hello-triggered-delay: 5 */ /* alternative-subnet 10.40.0.0/16 */ } } interface eth0 { vif eth0 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ /* hello-period: 30 */ /* hello-triggered-delay: 5 */ /* alternative-subnet 10.40.0.0/16 */ } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } static-rps { rp XX.XX.17.17 { group-prefix 224.0.0.0/4 { /* rp-priority: 192 */ /* hash-mask-len: 30 */ } } } switch-to-spt-threshold { /* approx. 1K bytes/s (10Kbps) threshold */ disable: false interval-sec: 100 bytes: 102400 } traceoptions { flag all { disable: false } } } } /* * Note: fib2mrib is needed for multicast only if the unicast protocols * don't populate the MRIB with multicast-specific routes. */ protocols { fib2mrib { disable: false } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060508/5da3fecb/attachment-0001.html From p.pradeep09 at gmail.com Fri May 12 02:44:19 2006 From: p.pradeep09 at gmail.com (Pradeep Kumar PALAPARTHY) Date: Fri, 12 May 2006 02:44:19 -0700 Subject: [Xorp-users] Error in Multicast router setup on Linux machine Message-ID: <8daef9c70605120244j7bd8e66fy606dcbdf02d7212d@mail.gmail.com> Hi All, Recently i have intalled xorp on my Suse Linux machine. I have two network cards in my machine. One card is on 192.168.1.XX Lan & the other is on 10.0.1.XX lan. My machine ip is 192.168.1.206 I have installed xorp by compling the source code. There were no errors during compiling. Below is my xorp configuration file. xorp is running. I was broadcasting a media file to the address 239.255.42.43 from one of the machine with ip address 192.168.1.60. And im trying to connect multicast address using player from another machine which is on 10.0.1.XX nettwork. I was unable to receive the packets. I couldnt see the log messages that membership is added or left from the group. Please can anyone help me is solving this problem. ##########XORP Configuration file############# * $XORP: xorp/rtrmgr/config.boot.sample,v 1.35 2006/03/09 12:18:20 pavlin Exp $ */ interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "data interface" disable: false default-system-config } } 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" } } } } protocols { rip { /* Connected interfaces will only be advertised if explicitly exported */ export: "connected" /* Run on specified network interface addresses */ interface eth0 { vif eth0 { address 192.168.1.206 { disable: false } } } } }lumbing { 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: 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 } } } } fea { unicast-forwarding4 { disable: false } /* unicast-forwarding6 { disable: false } */ } protocols { pimsm4 { disable: false interface eth0 { vif eth0 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ /* hello-period: 30 */ /* hello-triggered-delay: 5 */ /* alternative-subnet 10.40.0.0/16 */ } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } bootstrap { disable: false cand-bsr { scope-zone 224.0.0.0/4 { /* is-scope-zone: false */ cand-bsr-by-vif-name: "eth0" /* cand-bsr-by-vif-addr: 10.10.10.10 */ /* bsr-priority: 1 */ /* hash-mask-len: 30 */ } } cand-rp { group-prefix 224.0.0.0/4 { /* is-scope-zone: false */ cand-rp-by-vif-name: "eth0" /* cand-rp-by-vif-addr: 10.10.10.10 */ /* rp-priority: 192 */ /* rp-holdtime: 150 */ } } } switch-to-spt-threshold { /* approx. 1K bytes/s (10Kbps) threshold */ disable: false interval-sec: 100 bytes: 102400 } traceoptions { flag all { disable: false } } } } /* * Note: fib2mrib is needed for multicast only if the unicast protocols * don't populate the MRIB with multicast-specific routes. */ protocols { fib2mrib { disable: false } } Any help could me appreciated. Thanks & Regards, Pradeep From pavlin at icir.org Fri May 12 08:27:57 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 12 May 2006 08:27:57 -0700 Subject: [Xorp-users] Error in Multicast router setup on Linux machine In-Reply-To: Message from "Pradeep Kumar PALAPARTHY" of "Fri, 12 May 2006 02:44:19 PDT." <8daef9c70605120244j7bd8e66fy606dcbdf02d7212d@mail.gmail.com> Message-ID: <97448.1147447677@possum.icir.org> > Recently i have intalled xorp on my Suse Linux machine. > I have two network cards in my machine. One card is on 192.168.1.XX > Lan & the other is on 10.0.1.XX lan. My machine ip is 192.168.1.206 > I have installed xorp by compling the source code. There were no > errors during compiling. > Below is my xorp configuration file. > xorp is running. > > I was broadcasting a media file to the address 239.255.42.43 from one > of the machine with ip address 192.168.1.60. And im trying to connect > multicast address using player from another machine which is on > 10.0.1.XX nettwork. > > I was unable to receive the packets. I couldnt see the log messages > that membership is added or left from the group. > > Please can anyone help me is solving this problem. You need to configure the second interface (eth1?) as well. Also, because you are using the Bootstrap mechanism, on startup it may take up to 2-3 minutes or so until the Bootstrap information is converged and you can forward traffic. For testing purpose, you can use static-rp instead (set to your own IP address) and then you don't have to wait that long on startup. Few other potential issues to watch for: * Make sure the sender's TTL is large enough to reach the receiver. The default multicast TTL is 1 and such packets won't be forwarded. * If the appropriate multicast forwarding entry is in the kernel, but forwarding still doesn't work, then check your firewall rules. BTW, given that you haven't configured the "static" routes, you don't need the "static" policy statement, but this is orthogonal to the multicast routing. Hope that helps, Pavlin > ##########XORP Configuration file############# > * $XORP: xorp/rtrmgr/config.boot.sample,v 1.35 2006/03/09 12:18:20 > pavlin Exp $ */ > > > interfaces { > restore-original-config-on-shutdown: false > interface eth0 { > description: "data interface" > disable: false > default-system-config > } > } > > > 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" > } > } > } > } > > protocols { > rip { > > /* Connected interfaces will only be advertised if explicitly exported */ > export: "connected" > > /* Run on specified network interface addresses */ > interface eth0 { > vif eth0 { > address 192.168.1.206 { > disable: false > } > } > } > } > }lumbing { > 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: 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 > } > } > } > } > > > fea { > unicast-forwarding4 { > disable: false > } > /* > unicast-forwarding6 { > disable: false > } > */ > > } > > protocols { > pimsm4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > /* enable-ip-router-alert-option-check: false */ > /* dr-priority: 1 */ > /* hello-period: 30 */ > /* hello-triggered-delay: 5 */ > /* alternative-subnet 10.40.0.0/16 */ > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > > > bootstrap { > disable: false > cand-bsr { > scope-zone 224.0.0.0/4 { > /* is-scope-zone: false */ > cand-bsr-by-vif-name: "eth0" > /* cand-bsr-by-vif-addr: 10.10.10.10 */ > /* bsr-priority: 1 */ > /* hash-mask-len: 30 */ > } > } > > cand-rp { > group-prefix 224.0.0.0/4 { > /* is-scope-zone: false */ > cand-rp-by-vif-name: "eth0" > /* cand-rp-by-vif-addr: 10.10.10.10 */ > /* rp-priority: 192 */ > > /* rp-holdtime: 150 */ > } > } > } > > switch-to-spt-threshold { > /* approx. 1K bytes/s (10Kbps) threshold */ > disable: false > interval-sec: 100 > bytes: 102400 > } > > traceoptions { > flag all { > disable: false > } > } > } > } > /* > * Note: fib2mrib is needed for multicast only if the unicast protocols > * don't populate the MRIB with multicast-specific routes. > */ > protocols { > fib2mrib { > disable: false > } > } > > > Any help could me appreciated. > > Thanks & Regards, > Pradeep > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From bms at spc.org Sat May 13 16:33:43 2006 From: bms at spc.org (Bruce M Simpson) Date: Sun, 14 May 2006 00:33:43 +0100 Subject: [Xorp-users] [PATCH] IPv4 multicast limits on BSD-derived machines Message-ID: <20060513233343.GE46921@spc.org> Hi all, Anyone who plans to run OSPF on a BSD-derived machine (FreeBSD, NetBSD, OpenBSD, Darwin/MacOS X) may wish to take a look at this kernel patch for FreeBSD 6.1: http://people.freebsd.org/~bms/ipmaxgroups.diff The BSD IPv4 stack has a limitation of 20 groups-per-interface-per-socket. Various individuals ran into this limit when running OSPF on a machine with 20 or more interfaces due to how the group memberships work. This patch removes this limitation by dynamically expanding the vector holding the memberships. Regards, BMS From qye at trlabs.ca Sat May 13 21:01:31 2006 From: qye at trlabs.ca (Qinghua Ye) Date: Sat, 13 May 2006 22:01:31 -0600 (MDT) Subject: [Xorp-users] gmake check problem Message-ID: <1563.199.185.97.62.1147579291.squirrel@mail.trlabs.ca> Hi All, I am a new user of XORP, but encoutnered a problem when I did "gmake check". The error is: Running "ping" from 127.0.0.1 to 127.0.0.1 [ 2006/05/12 17:22:52 WARNING test_rawsock4 FEA ] proto_socket_read() failed: RX packet from 127.0.0.1 to 127.0.0.1: no vif found [ 2006/05/12 17:22:52 WARNING test_rawsock4 FEA ] proto_socket_read() failed: RX packet from 127.0.0.1 to 127.0.0.1: no vif found Sequence number 1 timed out. [ 2006/05/12 17:22:53 WARNING test_rawsock4 FEA ] proto_socket_read() failed: RX packet from 127.0.0.1 to 127.0.0.1: no vif found [ 2006/05/12 17:22:53 WARNING test_rawsock4 FEA ] proto_socket_read() failed: RX packet from 127.0.0.1 to 127.0.0.1: no vif found Sequence number 2 timed out. [ 2006/05/12 17:22:54 WARNING test_rawsock4 FEA ] proto_socket_read() failed: RX packet from 127.0.0.1 to 127.0.0.1: no vif found [ 2006/05/12 17:22:54 WARNING test_rawsock4 FEA ] proto_socket_read() failed: RX packet from 127.0.0.1 to 127.0.0.1: no vif found Sequence number 3 timed out. Received 0 good responses and 3 bad responses. FAIL: test_rawsock4 PASS: test_ifmanager_transaction =================== 1 of 3 tests failed =================== Will this error affect the use of XORP? The "gmake" complete without any problem. Thanks. Qinghua From pavlin at icir.org Sat May 13 22:28:21 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sat, 13 May 2006 22:28:21 -0700 Subject: [Xorp-users] gmake check problem In-Reply-To: Message from "Qinghua Ye" of "Sat, 13 May 2006 22:01:31 MDT." <1563.199.185.97.62.1147579291.squirrel@mail.trlabs.ca> Message-ID: <200605140528.k4E5SLY5026481@possum.icir.org> > I am a new user of XORP, but encoutnered a problem when I did "gmake > check". The error is: > > Running "ping" from 127.0.0.1 to 127.0.0.1 > [ 2006/05/12 17:22:52 WARNING test_rawsock4 FEA ] proto_socket_read() > failed: RX packet from 127.0.0.1 to 127.0.0.1: no vif found > [ 2006/05/12 17:22:52 WARNING test_rawsock4 FEA ] proto_socket_read() > failed: RX packet from 127.0.0.1 to 127.0.0.1: no vif found > Sequence number 1 timed out. > [ 2006/05/12 17:22:53 WARNING test_rawsock4 FEA ] proto_socket_read() > failed: RX packet from 127.0.0.1 to 127.0.0.1: no vif found > [ 2006/05/12 17:22:53 WARNING test_rawsock4 FEA ] proto_socket_read() > failed: RX packet from 127.0.0.1 to 127.0.0.1: no vif found > Sequence number 2 timed out. > [ 2006/05/12 17:22:54 WARNING test_rawsock4 FEA ] proto_socket_read() > failed: RX packet from 127.0.0.1 to 127.0.0.1: no vif found > [ 2006/05/12 17:22:54 WARNING test_rawsock4 FEA ] proto_socket_read() > failed: RX packet from 127.0.0.1 to 127.0.0.1: no vif found > Sequence number 3 timed out. > Received 0 good responses and 3 bad responses. > FAIL: test_rawsock4 > PASS: test_ifmanager_transaction > =================== > 1 of 3 tests failed > =================== I presume you are using XORP-1.2. This is a known problem (in case of Linux and probably other OS) which is fixed in CVS: http://www.xorp.org/bugzilla/show_bug.cgi?id=619 > Will this error affect the use of XORP? The "gmake" complete without any > problem. Thanks. No, the problem is in the test program itself. Pavlin From vbranca at av.it.pt Mon May 15 04:23:35 2006 From: vbranca at av.it.pt (Vitor Miguel de Sousa Branca) Date: Mon, 15 May 2006 12:23:35 +0100 Subject: [Xorp-users] multicast without static routes Message-ID: Hi! We have the following scenario RP \ xorp1------xorp2----destination / source We multi cast traffic using the RIP and mrib-route4, and works well the destination receives the UDP packets fine. But when we don?t define static routes with route4 or mrib-route4,(still using RIP) we don?t receive any UDP packets, because xorp2 don?t know how to send the join to the RP. We would like to know how to put the multicast working without static routes or mrib-route4, (and using RIP). vbranca at av.it.pt aafreixo at av.it.pt From pavlin at icir.org Mon May 15 08:39:51 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 15 May 2006 08:39:51 -0700 Subject: [Xorp-users] multicast without static routes In-Reply-To: Message from "Vitor Miguel de Sousa Branca" of "Mon, 15 May 2006 12:23:35 BST." Message-ID: <200605151539.k4FFdpg6051312@possum.icir.org> Vitor Miguel de Sousa Branca wrote: > Hi! > We have the following scenario > > RP > \ > xorp1------xorp2----destination > / > source > > We multi cast traffic using the RIP and mrib-route4, and > works well the destination receives the UDP packets fine. > But when we don?t define static routes with route4 or > mrib-route4,(still using RIP) we don?t receive any UDP > packets, because xorp2 don?t know how to send the join to > the RP. > > We would like to know how to put the multicast working > without static routes or mrib-route4, (and using RIP). If you configure/enable the fib2mrib, then you don't need to run static routes: protocols { fib2mrib { disable: false } } Pavlin > vbranca at av.it.pt > aafreixo at av.it.pt From vbranca at av.it.pt Mon May 15 12:45:26 2006 From: vbranca at av.it.pt (Vitor Miguel de Sousa Branca) Date: Mon, 15 May 2006 20:45:26 +0100 Subject: [Xorp-users] multicast without static routes In-Reply-To: <200605151539.k4FFdpg6051312@possum.icir.org> References: <200605151539.k4FFdpg6051312@possum.icir.org> Message-ID: On Mon, 15 May 2006 08:39:51 -0700 Pavlin Radoslavov wrote: > Vitor Miguel de Sousa Branca wrote: >> Hi! >> We have the following scenario >> >> RP >> \ >> xorp1------xorp2----destination >> / >> source >> >> We multi cast traffic using the RIP and mrib-route4, and >> works well the destination receives the UDP packets >>fine. >> But when we don?t define static routes with route4 or >> mrib-route4,(still using RIP) we don?t receive any UDP >> packets, because xorp2 don?t know how to send the join >>to >> the RP. >> >> We would like to know how to put the multicast working >> without static routes or mrib-route4, (and using RIP). > > If you configure/enable the fib2mrib, then you don't >need to run > static routes: > > protocols { > fib2mrib { > disable: false > } > } > > Pavlin > >> vbranca at av.it.pt >> aafreixo at av.it.pt Yes, i?m using fib2mrib, but doesn?t work! Thank you, for the help, any way, and to answer in a short time. From pavlin at icir.org Mon May 15 13:15:17 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 15 May 2006 13:15:17 -0700 Subject: [Xorp-users] multicast without static routes In-Reply-To: Message from "Vitor Miguel de Sousa Branca" of "Mon, 15 May 2006 20:45:26 BST." Message-ID: <200605152015.k4FKFHp0063861@possum.icir.org> > Yes, i?m using fib2mrib, but doesn?t work! In that case you need to do some debugging to find the missing routes. 1) Verify the RIP routes are inside the kernel by using the following UNIX command: netstat -rn 2) Verify whether fib2mrib installed them in the RIB by using the following xorpsh commands: show route table ipv4 multicast fib2mrib show route table ipv4 multicast final 3) Verify whether PIM received them from the RIB by using the following xorpsh command: show pim mrib The result from the above commands would determine the next steps in finding the real problem. Pavlin From binary.chen at gmail.com Mon May 15 23:17:18 2006 From: binary.chen at gmail.com (Bin Chen) Date: Tue, 16 May 2006 14:17:18 +0800 Subject: [Xorp-users] A simplest config.boot needed Message-ID: <5800c1cc0605152317v78e3b3f6n5c0a3ee86b8cb436@mail.gmail.com> Hi, I am just a newbie want to study how XORP works, I have compiled & installed XORP in my Linux machine(Ubuntu), it seems no problem, but when I copy config.boot.sample to /usr/local/xorp, it can't start with many errors. Could anybody send me the simplest form of config.boot so that I can make xorp_rtrmgr running? Even no routing function really needed, just can reside in memory. My ethernet interface is eth0, with fix ipaddr: 192.168.0.97, netmask 255.255.255.0. Your help will greatly appreciated, thanks. B.C I also attach the config.boot and the error message: /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.35 2006/03/09 12:18:20 pavlin Exp $ */ interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "data interface" disable: false /* default-system-config */ vif eth0 { disable: false address 10.10.10.10 { prefix-length: 24 broadcast: 10.10.10.255 disable: false } /* address 10:10:10:10:10:10:10:10 { prefix-length: 64 disable: false } */ } } /* interface tun0 { description: "tunnel interface" disable: false vif tun0 { disable: false address 10.10.10.11 { prefix-length: 32 destination: 10.20.20.20 disable: false } } } interface discard0 { description: "discard interface" disable: false discard: true vif discard0 { disable: false address 127.127.0.1 { prefix-length: 32 disable: false } } } */ } fea { unicast-forwarding4 { disable: false } /* unicast-forwarding6 { disable: false } */ click { disable: false /* * Set duplicate-routes-to-kernel to true if the XORP routes * added to Click should be added to the system kernel as well. */ duplicate-routes-to-kernel: false /* * Note: If both kernel-click and user-click are enabled, then * typically kernel-click-config-generator-file and * user-click-config-generator-file should point to different * generators. Otherwise, a single common generator * wouldn't know whether to generate configuration for kernel-level * Click or for user-level Click. */ kernel-click { disable: true install-on-startup: true kernel-click-modules: "/path/to/proclikefs.o:/path/to/click.o" /* XXX: On FreeBSD we need only module click.ko */ /* kernel-click-modules: "/path/to/click.ko" */ mount-directory: "/click" kernel-click-config-generator-file: "/usr/local/xorp/fea/xorp_fea_click_config_generator" } user-click { disable: false command-file: "/usr/local/bin/click" /* * Note: don't add "-p " as an extra argument, because it * will be in conflict with the FEA's addition of the same * argument. */ command-extra-arguments: "-R" command-execute-on-startup: true control-address: 127.0.0.1 control-socket-port: 13000 startup-config-file: "/dev/null" user-click-config-generator-file: "/usr/local/xorp/fea/xorp_fea_click_config_generator" } } } protocols { static { route4 10.20.0.0/16 { next-hop: 10.10.10.20 metric: 1 } mrib-route4 10.20.0.0/16 { next-hop: 10.10.10.30 metric: 1 } /* route6 20:20:20:20::/64 { next-hop: 10:10:10:10:10:10:10:20 metric: 1 } mrib-route6 20:20:20:20::/64 { next-hop: 10:10:10:10:10:10:10:30 metric: 1 } */ } } 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" } } } } protocols { rip { /* Connected interfaces will only be advertised if explicitly exported */ export: "connected" /* Run on specified network interface addresses */ interface eth0 { vif eth0 { address 10.10.10.10 { disable: false } } } } } protocols { ospf4 { router-id: 10.10.10.10 /* export: "static" */ /* traceoptions { flag { all { disable: false } } } */ area 0.0.0.0 { /* virtual-link 20.20.20.20 { transit-area: 0.0.0.1 } */ /* area-range: 10.0.0.0/8 { advertise: true } */ interface dco0 { /* link-type: "broadcast" */ vif eth0 { address 10.10.10.10 { /* priority: 128 */ /* hello-interval: 10 */ /* router-dead-interval: 40 */ /* interface-cost: 1 */ /* retransmit-interval: 5 */ /* transit-delay: 1 */ /* authentication { simple-password: "password"; md5 @: u32 { password: "password"; } } */ /* passive: false */ /* disable: false */ } } } } area 0.0.0.1 { /* area-type: "normal" */ interface dc1 { vif dc1 { address 10.10.11.10 { } } } } /* area 0.0.0.2 { area-type: "stub" default-lsa { metric: 0 } summaries { disable: false } interface dc2 { vif dc2 { address 10.10.12.10 { } } } } */ /* area 0.0.0.3 { area-type: "nssa" default-lsa { metric: 0 } summaries { disable: true } interface dc3 { vif dc3 { address 10.10.13.10 { } } } } */ } } protocols { bgp { bgp-id: 10.10.10.10 local-as: 65002 /* export: "static" */ /* traceoptions { flag { verbose message-in message-out state-change policy-configuration } } */ /* route-reflector { cluster-id: 20.20.20.20 } */ /* confederation { cluster-id: 65005 } */ peer 10.30.30.30 { local-ip: 10.10.10.10 as: 65000 next-hop: 10.10.10.20 /* Route reflector client */ /* client: false */ /* confederation-member: false */ /* local-port: 179 peer-port: 179 */ /* holdtime: 120 */ /* disable: false */ /* Optionally enable other AFI/SAFI combinations */ /* ipv4-multicast: true */ /* ipv6-unicast: true */ /* ipv6-multicast: true */ } /* Originate IPv4 Routes */ /* network4 10.10.10.0/24 { next-hop: 10.10.10.10 unicast: true multicast: true } */ /* Originate IPv6 Routes */ /* network6 10:10:10:10::/64 { next-hop: 10:10:10:10:10:10:10:10 unicast: true multicast: true } */ } } 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 } } } /* mfea6 { disable: false interface eth0 { vif eth0 { disable: false } } interface register_vif { vif register_vif { disable: false } } traceoptions { flag all { disable: false } } } */ } protocols { igmp { disable: false interface eth0 { vif eth0 { 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 } } } /* mld { disable: false interface eth0 { vif eth0 { disable: false version: 1 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 } } } */ } protocols { pimsm4 { disable: false interface eth0 { vif eth0 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ /* hello-period: 30 */ /* hello-triggered-delay: 5 */ /* alternative-subnet 10.40.0.0/16 */ } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } static-rps { rp 10.60.0.1 { group-prefix 224.0.0.0/4 { /* rp-priority: 192 */ /* hash-mask-len: 30 */ } } } bootstrap { disable: false cand-bsr { scope-zone 224.0.0.0/4 { /* is-scope-zone: false */ cand-bsr-by-vif-name: "eth0" /* cand-bsr-by-vif-addr: 10.10.10.10 */ /* bsr-priority: 1 */ /* hash-mask-len: 30 */ } } cand-rp { group-prefix 224.0.0.0/4 { /* is-scope-zone: false */ cand-rp-by-vif-name: "eth0" /* cand-rp-by-vif-addr: 10.10.10.10 */ /* rp-priority: 192 */ /* rp-holdtime: 150 */ } } } switch-to-spt-threshold { /* approx. 1K bytes/s (10Kbps) threshold */ disable: false interval-sec: 100 bytes: 102400 } traceoptions { flag all { disable: false } } } /* pimsm6 { disable: false interface eth0 { vif eth0 { disable: false enable-ip-router-alert-option-check: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 alternative-subnet 40:40:40:40::/64 } } interface register_vif { vif register_vif { disable: false } } static-rps { rp 50:50:50:50:50:50:50:50 { group-prefix ff00::/8 { rp-priority: 192 hash-mask-len: 126 } } } bootstrap { disable: false cand-bsr { scope-zone ff00::/8 { is-scope-zone: false cand-bsr-by-vif-name: "eth0" cand-bsr-by-vif-addr: 10:10:10:10:10:10:10:10 bsr-priority: 1 hash-mask-len: 126 } } cand-rp { group-prefix ff00::/8 { is-scope-zone: false cand-rp-by-vif-name: "eth0" cand-rp-by-vif-addr: 10:10:10:10:10:10:10:10 rp-priority: 192 rp-holdtime: 150 } } } switch-to-spt-threshold { disable: false interval-sec: 100 bytes: 102400 } traceoptions { flag all { disable: false } } } */ } /* * Note: fib2mrib is needed for multicast only if the unicast protocols * don't populate the MRIB with multicast-specific routes. */ protocols { fib2mrib { disable: false } } /* * See xorp/mibs/snmpdscripts/README on how to configure Net-SNMP in your host * before uncommenting the snmp section below. * Also check that the "bgp4_mib_1657.so" exists in the correct location. */ /* protocols { snmp { mib-module bgp4_mib_1657 { abs-path: "/usr/local/xorp/mibs/bgp4_mib_1657.so" } } } */ ------------------------------------------------------ ERROR messages: [ 2006/05/16 14:16:03 INFO xorp_rtrmgr:24664 RTRMGR +240 master_conf_tree.cc execute ] Changed modules: interfaces, fea, mfea4, rib, fib2mrib, igmp, pimsm4, policy, rip, static_routes, bgp, ospf4 [ 2006/05/16 14:16:03 INFO xorp_rtrmgr:24664 RTRMGR +99 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2006/05/16 14:16:03 ERROR xorp_fea:24665 LIBCOMM +110 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol [ 2006/05/16 14:16:03 ERROR xorp_fea:24665 LIBCOMM +110 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol [ 2006/05/16 14:16:03 INFO xorp_fea MFEA ] MFEA enabled [ 2006/05/16 14:16:03 INFO xorp_fea MFEA ] CLI enabled [ 2006/05/16 14:16:03 INFO xorp_fea MFEA ] CLI started [ 2006/05/16 14:16:03 INFO xorp_fea MFEA ] MFEA enabled [ 2006/05/16 14:16:03 INFO xorp_fea MFEA ] CLI enabled [ 2006/05/16 14:16:03 INFO xorp_fea MFEA ] CLI started [ 2006/05/16 14:16:05 INFO xorp_rtrmgr:24664 RTRMGR +99 module_manager.cc execute ] Executing module: fea (fea/xorp_fea) [ 2006/05/16 14:16:09 ERROR xorp_fea:24665 LIBCOMM +728 comm_sock.c comm_sock_connect4 ] Error connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = 13000): Connection refused [ 2006/05/16 14:16:09 WARNING xorp_fea FEA ] Could not open user-level Click socket: Connection refused. Trying again... [ 2006/05/16 14:16:09 ERROR xorp_fea:24665 LIBCOMM +728 comm_sock.c comm_sock_connect4 ] Error connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = 13000): Connection refused [ 2006/05/16 14:16:09 WARNING xorp_fea FEA ] Could not open user-level Click socket: Connection refused. Trying again... [ 2006/05/16 14:16:10 ERROR xorp_fea:24665 LIBCOMM +728 comm_sock.c comm_sock_connect4 ] Error connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = 13000): Connection refused [ 2006/05/16 14:16:10 WARNING xorp_fea FEA ] Could not open user-level Click socket: Connection refused. Trying again... [ 2006/05/16 14:16:10 ERROR xorp_fea:24665 LIBCOMM +728 comm_sock.c comm_sock_connect4 ] Error connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = 13000): Connection refused [ 2006/05/16 14:16:10 WARNING xorp_fea XrlFeaTarget ] Handling method for fea_click/0.1/start_click failed: XrlCmdError 102 Command failed Could not open user-level Click socket: Connection refused [ 2006/05/16 14:16:10 ERROR xorp_rtrmgr:24664 RTRMGR +671 master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed Could not open user-level Click socket: Connection refused [ 2006/05/16 14:16:10 ERROR xorp_rtrmgr:24664 RTRMGR +252 master_conf_tree.cc config_done ] Configuration failed: 102 Command failed Could not open user-level Click socket: Connection refused [ 2006/05/16 14:16:10 INFO xorp_rtrmgr:24664 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2006/05/16 14:16:10 INFO xorp_rtrmgr:24664 RTRMGR +174 module_manager.cc terminate ] Terminating module: fea [ 2006/05/16 14:16:10 INFO xorp_rtrmgr:24664 RTRMGR +174 module_manager.cc terminate ] Terminating module: interfaces [ 2006/05/16 14:16:10 INFO xorp_rtrmgr:24664 RTRMGR +197 module_manager.cc terminate ] Killing module: interfaces [ 2006/05/16 14:16:10 ERROR xorp_rtrmgr:24664 RTRMGR +747 module_manager.cc done_cb ] Command "/usr/local/xorp/fea/xorp_fea": terminated with signal 15. [ 2006/05/16 14:16:10 INFO xorp_rtrmgr:24664 RTRMGR +285 module_manager.cc module_exited ] Module killed during shutdown: interfaces From mhorn at vyatta.com Tue May 16 07:03:38 2006 From: mhorn at vyatta.com (Mike Horn) Date: Tue, 16 May 2006 08:03:38 -0600 Subject: [Xorp-users] A simplest config.boot needed In-Reply-To: <5800c1cc0605152317v78e3b3f6n5c0a3ee86b8cb436@mail.gmail.com> Message-ID: <004e01c678f1$87d73fc0$6502a8c0@caddisconsulting.com> Hi Bin, If you want a really simple config.boot, you can just use: /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.35 2006/03/09 12:18:20 pavlin Exp $ */ interfaces { interface eth0 { } } Once you boot with that you can then add your interface and other configuration information via the xorpsh. Let me know if that doesn't work for you. -mike -----Original Message----- From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Bin Chen Sent: Tuesday, May 16, 2006 12:17 AM To: Xorp-users at xorp.org Subject: [Xorp-users] A simplest config.boot needed Hi, I am just a newbie want to study how XORP works, I have compiled & installed XORP in my Linux machine(Ubuntu), it seems no problem, but when I copy config.boot.sample to /usr/local/xorp, it can't start with many errors. Could anybody send me the simplest form of config.boot so that I can make xorp_rtrmgr running? Even no routing function really needed, just can reside in memory. My ethernet interface is eth0, with fix ipaddr: 192.168.0.97, netmask 255.255.255.0. Your help will greatly appreciated, thanks. B.C I also attach the config.boot and the error message: /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.35 2006/03/09 12:18:20 pavlin Exp $ */ interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "data interface" disable: false /* default-system-config */ vif eth0 { disable: false address 10.10.10.10 { prefix-length: 24 broadcast: 10.10.10.255 disable: false } /* address 10:10:10:10:10:10:10:10 { prefix-length: 64 disable: false } */ } } /* interface tun0 { description: "tunnel interface" disable: false vif tun0 { disable: false address 10.10.10.11 { prefix-length: 32 destination: 10.20.20.20 disable: false } } } interface discard0 { description: "discard interface" disable: false discard: true vif discard0 { disable: false address 127.127.0.1 { prefix-length: 32 disable: false } } } */ } fea { unicast-forwarding4 { disable: false } /* unicast-forwarding6 { disable: false } */ click { disable: false /* * Set duplicate-routes-to-kernel to true if the XORP routes * added to Click should be added to the system kernel as well. */ duplicate-routes-to-kernel: false /* * Note: If both kernel-click and user-click are enabled, then * typically kernel-click-config-generator-file and * user-click-config-generator-file should point to different * generators. Otherwise, a single common generator * wouldn't know whether to generate configuration for kernel-level * Click or for user-level Click. */ kernel-click { disable: true install-on-startup: true kernel-click-modules: "/path/to/proclikefs.o:/path/to/click.o" /* XXX: On FreeBSD we need only module click.ko */ /* kernel-click-modules: "/path/to/click.ko" */ mount-directory: "/click" kernel-click-config-generator-file: "/usr/local/xorp/fea/xorp_fea_click_config_generator" } user-click { disable: false command-file: "/usr/local/bin/click" /* * Note: don't add "-p " as an extra argument, because it * will be in conflict with the FEA's addition of the same * argument. */ command-extra-arguments: "-R" command-execute-on-startup: true control-address: 127.0.0.1 control-socket-port: 13000 startup-config-file: "/dev/null" user-click-config-generator-file: "/usr/local/xorp/fea/xorp_fea_click_config_generator" } } } protocols { static { route4 10.20.0.0/16 { next-hop: 10.10.10.20 metric: 1 } mrib-route4 10.20.0.0/16 { next-hop: 10.10.10.30 metric: 1 } /* route6 20:20:20:20::/64 { next-hop: 10:10:10:10:10:10:10:20 metric: 1 } mrib-route6 20:20:20:20::/64 { next-hop: 10:10:10:10:10:10:10:30 metric: 1 } */ } } 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" } } } } protocols { rip { /* Connected interfaces will only be advertised if explicitly exported */ export: "connected" /* Run on specified network interface addresses */ interface eth0 { vif eth0 { address 10.10.10.10 { disable: false } } } } } protocols { ospf4 { router-id: 10.10.10.10 /* export: "static" */ /* traceoptions { flag { all { disable: false } } } */ area 0.0.0.0 { /* virtual-link 20.20.20.20 { transit-area: 0.0.0.1 } */ /* area-range: 10.0.0.0/8 { advertise: true } */ interface dco0 { /* link-type: "broadcast" */ vif eth0 { address 10.10.10.10 { /* priority: 128 */ /* hello-interval: 10 */ /* router-dead-interval: 40 */ /* interface-cost: 1 */ /* retransmit-interval: 5 */ /* transit-delay: 1 */ /* authentication { simple-password: "password"; md5 @: u32 { password: "password"; } } */ /* passive: false */ /* disable: false */ } } } } area 0.0.0.1 { /* area-type: "normal" */ interface dc1 { vif dc1 { address 10.10.11.10 { } } } } /* area 0.0.0.2 { area-type: "stub" default-lsa { metric: 0 } summaries { disable: false } interface dc2 { vif dc2 { address 10.10.12.10 { } } } } */ /* area 0.0.0.3 { area-type: "nssa" default-lsa { metric: 0 } summaries { disable: true } interface dc3 { vif dc3 { address 10.10.13.10 { } } } } */ } } protocols { bgp { bgp-id: 10.10.10.10 local-as: 65002 /* export: "static" */ /* traceoptions { flag { verbose message-in message-out state-change policy-configuration } } */ /* route-reflector { cluster-id: 20.20.20.20 } */ /* confederation { cluster-id: 65005 } */ peer 10.30.30.30 { local-ip: 10.10.10.10 as: 65000 next-hop: 10.10.10.20 /* Route reflector client */ /* client: false */ /* confederation-member: false */ /* local-port: 179 peer-port: 179 */ /* holdtime: 120 */ /* disable: false */ /* Optionally enable other AFI/SAFI combinations */ /* ipv4-multicast: true */ /* ipv6-unicast: true */ /* ipv6-multicast: true */ } /* Originate IPv4 Routes */ /* network4 10.10.10.0/24 { next-hop: 10.10.10.10 unicast: true multicast: true } */ /* Originate IPv6 Routes */ /* network6 10:10:10:10::/64 { next-hop: 10:10:10:10:10:10:10:10 unicast: true multicast: true } */ } } 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 } } } /* mfea6 { disable: false interface eth0 { vif eth0 { disable: false } } interface register_vif { vif register_vif { disable: false } } traceoptions { flag all { disable: false } } } */ } protocols { igmp { disable: false interface eth0 { vif eth0 { 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 } } } /* mld { disable: false interface eth0 { vif eth0 { disable: false version: 1 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 } } } */ } protocols { pimsm4 { disable: false interface eth0 { vif eth0 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ /* hello-period: 30 */ /* hello-triggered-delay: 5 */ /* alternative-subnet 10.40.0.0/16 */ } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } static-rps { rp 10.60.0.1 { group-prefix 224.0.0.0/4 { /* rp-priority: 192 */ /* hash-mask-len: 30 */ } } } bootstrap { disable: false cand-bsr { scope-zone 224.0.0.0/4 { /* is-scope-zone: false */ cand-bsr-by-vif-name: "eth0" /* cand-bsr-by-vif-addr: 10.10.10.10 */ /* bsr-priority: 1 */ /* hash-mask-len: 30 */ } } cand-rp { group-prefix 224.0.0.0/4 { /* is-scope-zone: false */ cand-rp-by-vif-name: "eth0" /* cand-rp-by-vif-addr: 10.10.10.10 */ /* rp-priority: 192 */ /* rp-holdtime: 150 */ } } } switch-to-spt-threshold { /* approx. 1K bytes/s (10Kbps) threshold */ disable: false interval-sec: 100 bytes: 102400 } traceoptions { flag all { disable: false } } } /* pimsm6 { disable: false interface eth0 { vif eth0 { disable: false enable-ip-router-alert-option-check: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 alternative-subnet 40:40:40:40::/64 } } interface register_vif { vif register_vif { disable: false } } static-rps { rp 50:50:50:50:50:50:50:50 { group-prefix ff00::/8 { rp-priority: 192 hash-mask-len: 126 } } } bootstrap { disable: false cand-bsr { scope-zone ff00::/8 { is-scope-zone: false cand-bsr-by-vif-name: "eth0" cand-bsr-by-vif-addr: 10:10:10:10:10:10:10:10 bsr-priority: 1 hash-mask-len: 126 } } cand-rp { group-prefix ff00::/8 { is-scope-zone: false cand-rp-by-vif-name: "eth0" cand-rp-by-vif-addr: 10:10:10:10:10:10:10:10 rp-priority: 192 rp-holdtime: 150 } } } switch-to-spt-threshold { disable: false interval-sec: 100 bytes: 102400 } traceoptions { flag all { disable: false } } } */ } /* * Note: fib2mrib is needed for multicast only if the unicast protocols * don't populate the MRIB with multicast-specific routes. */ protocols { fib2mrib { disable: false } } /* * See xorp/mibs/snmpdscripts/README on how to configure Net-SNMP in your host * before uncommenting the snmp section below. * Also check that the "bgp4_mib_1657.so" exists in the correct location. */ /* protocols { snmp { mib-module bgp4_mib_1657 { abs-path: "/usr/local/xorp/mibs/bgp4_mib_1657.so" } } } */ ------------------------------------------------------ ERROR messages: [ 2006/05/16 14:16:03 INFO xorp_rtrmgr:24664 RTRMGR +240 master_conf_tree.cc execute ] Changed modules: interfaces, fea, mfea4, rib, fib2mrib, igmp, pimsm4, policy, rip, static_routes, bgp, ospf4 [ 2006/05/16 14:16:03 INFO xorp_rtrmgr:24664 RTRMGR +99 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2006/05/16 14:16:03 ERROR xorp_fea:24665 LIBCOMM +110 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol [ 2006/05/16 14:16:03 ERROR xorp_fea:24665 LIBCOMM +110 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol [ 2006/05/16 14:16:03 INFO xorp_fea MFEA ] MFEA enabled [ 2006/05/16 14:16:03 INFO xorp_fea MFEA ] CLI enabled [ 2006/05/16 14:16:03 INFO xorp_fea MFEA ] CLI started [ 2006/05/16 14:16:03 INFO xorp_fea MFEA ] MFEA enabled [ 2006/05/16 14:16:03 INFO xorp_fea MFEA ] CLI enabled [ 2006/05/16 14:16:03 INFO xorp_fea MFEA ] CLI started [ 2006/05/16 14:16:05 INFO xorp_rtrmgr:24664 RTRMGR +99 module_manager.cc execute ] Executing module: fea (fea/xorp_fea) [ 2006/05/16 14:16:09 ERROR xorp_fea:24665 LIBCOMM +728 comm_sock.c comm_sock_connect4 ] Error connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = 13000): Connection refused [ 2006/05/16 14:16:09 WARNING xorp_fea FEA ] Could not open user-level Click socket: Connection refused. Trying again... [ 2006/05/16 14:16:09 ERROR xorp_fea:24665 LIBCOMM +728 comm_sock.c comm_sock_connect4 ] Error connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = 13000): Connection refused [ 2006/05/16 14:16:09 WARNING xorp_fea FEA ] Could not open user-level Click socket: Connection refused. Trying again... [ 2006/05/16 14:16:10 ERROR xorp_fea:24665 LIBCOMM +728 comm_sock.c comm_sock_connect4 ] Error connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = 13000): Connection refused [ 2006/05/16 14:16:10 WARNING xorp_fea FEA ] Could not open user-level Click socket: Connection refused. Trying again... [ 2006/05/16 14:16:10 ERROR xorp_fea:24665 LIBCOMM +728 comm_sock.c comm_sock_connect4 ] Error connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = 13000): Connection refused [ 2006/05/16 14:16:10 WARNING xorp_fea XrlFeaTarget ] Handling method for fea_click/0.1/start_click failed: XrlCmdError 102 Command failed Could not open user-level Click socket: Connection refused [ 2006/05/16 14:16:10 ERROR xorp_rtrmgr:24664 RTRMGR +671 master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed Could not open user-level Click socket: Connection refused [ 2006/05/16 14:16:10 ERROR xorp_rtrmgr:24664 RTRMGR +252 master_conf_tree.cc config_done ] Configuration failed: 102 Command failed Could not open user-level Click socket: Connection refused [ 2006/05/16 14:16:10 INFO xorp_rtrmgr:24664 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2006/05/16 14:16:10 INFO xorp_rtrmgr:24664 RTRMGR +174 module_manager.cc terminate ] Terminating module: fea [ 2006/05/16 14:16:10 INFO xorp_rtrmgr:24664 RTRMGR +174 module_manager.cc terminate ] Terminating module: interfaces [ 2006/05/16 14:16:10 INFO xorp_rtrmgr:24664 RTRMGR +197 module_manager.cc terminate ] Killing module: interfaces [ 2006/05/16 14:16:10 ERROR xorp_rtrmgr:24664 RTRMGR +747 module_manager.cc done_cb ] Command "/usr/local/xorp/fea/xorp_fea": terminated with signal 15. [ 2006/05/16 14:16:10 INFO xorp_rtrmgr:24664 RTRMGR +285 module_manager.cc module_exited ] Module killed during shutdown: interfaces _______________________________________________ Xorp-users mailing list Xorp-users at xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From vbranca at av.it.pt Tue May 16 15:29:54 2006 From: vbranca at av.it.pt (Vitor Miguel de Sousa Branca) Date: Tue, 16 May 2006 23:29:54 +0100 Subject: [Xorp-users] multicast without static routes In-Reply-To: <200605152015.k4FKFHp0063861@possum.icir.org> References: <200605152015.k4FKFHp0063861@possum.icir.org> Message-ID: On Mon, 15 May 2006 13:15:17 -0700 Pavlin Radoslavov wrote: >> Yes, i?m using fib2mrib, but dozen?t work! > > In that case you need to do some debugging to find the >missing > routes. > > 1) Verify the RIP routes are inside the kernel by using >the > following UNIX command: > > netstat -rn > > 2) Verify whether fib2mrib installed them in the RIB by >using the > following xorpsh commands: > > show route table ipv4 multicast fib2mrib > show route table ipv4 multicast final > > 3) Verify whether PIM received them from the RIB by >using the > following xorpsh command: > > show pim mrib > > The result from the above commands would determine the >next steps in > finding the real problem. > > Pavlin > > > First tank you for answer me again The scenario: RP \ xorp1------xorp2----destination / source in relation to point 1) Verify the RIP routes are inside the kernel by using the following UNIX command: netstat -rn everyting is ok all xorps know all the networks in this scenario including the networks related with the source and destination in relation to point 2) Verify whether fib2mrib installed them in the RIB by >using the > following xorpsh commands: > first with > show route table ipv4 multicast fib2mrib it?s where the problems start, because the routers only know the networks that they are directly connected,and not the networks that they have to jump by the next router > show route table ipv4 multicast final the same result we get with the second command. In relation to point 3 > 3) Verify whether PIM received them from the RIB by >using the > following xorpsh command: > > show pim mrib the mrib only have the routes to the directly connected networks for each router it?s the same result as in point 2. I also checked the RIP with the command >show route table ipv4 unicast rip and everything is ok all routers know all the networks that exist in he scenario For me is a problem with the transposition of the routes from the RIB to the MRIB but I don?t know how to solve it. Once again Tank you for the help. PS:another question just to confirm, to configure the SPT trigger we only need to configure the switch-to-spt-threshold Wright? From Ali.Sahibzada at brunel.ac.uk Tue May 16 13:04:16 2006 From: Ali.Sahibzada at brunel.ac.uk (Ali Sahibzada) Date: Tue, 16 May 2006 21:04:16 +0100 Subject: [Xorp-users] IMportant Message-ID: <740A0C221BAEA84BAFC3D17F8C23618F70558B@UXEXMBU116.academic.windsor> Dear XORP users, I am new to this community and i have just started work on my routing protocol. I wanted to know since XORP depends on gcc and since its available in the packages installed by the cygwin software, so would XORP run properly on Windows XP if it has cygwin installed? Another question is that if i have the code for the routing protocol written in C++, then how would i run and check it in Xorp. Kindly help. Thanks a lot. Regards, Sahibzada Ali Mahmud Wireless Networks and Communications Group, School of Engineering and Design. Brunel University, West London Ph: (0) 1895 267 308 (0) 1895 420 996 Cell: (0) 7947847049 From pavlin at icir.org Tue May 16 17:19:00 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 16 May 2006 17:19:00 -0700 Subject: [Xorp-users] multicast without static routes In-Reply-To: Message from "Vitor Miguel de Sousa Branca" of "Tue, 16 May 2006 23:29:54 BST." Message-ID: <200605170019.k4H0J0Hw000699@possum.icir.org> > The scenario: > > RP > \ > xorp1------xorp2----destination > / > source > > > in relation to point > 1) Verify the RIP routes are inside the kernel by using > the > following UNIX command: > > netstat -rn > > everyting is ok all xorps know all the networks in this > scenario including the networks related with the source > and destination > > > in relation to point > 2) Verify whether fib2mrib installed them in the RIB by > >using the > > following xorpsh commands: > > > first with > > show route table ipv4 multicast fib2mrib > > it?s where the problems start, because the routers only > know the networks that they are directly connected,and > not the networks that they have to jump by the next router Could you confirm that you are using XORP-1.2 or latest code from CVS. If you are using older version, please upgrade and see if the problem goes away. Also, what OS are you using? It appears to be a problem with either distributing the kernel routes from the FEA to the FIB2MRIB module, or from the FIB2MRIB module to the RIB. To answer that, could you set the XRLTRACE variable in your shell environment and then run XORP (e.g., "setenv XRLTRACE yes" in csh/tcsh). This will generate lots of entries (for all XRLs invoked in the system), so the best way to save this output is to run the script(1) program and then run XORP. After you stop XORP and exit script(1) the result will be in file typescript. If you like, you could send me the output (you don't need to send it to the list) and I will try to find the missing XRLs. Otherwise, look for XRLs fea_fib_client/0.1/add_route4 and rib/0.1/add_route4. The former should be send from the FEA to FIB2MRIB. The latter should be send from FIB2MRIB, but look only for those that have protocol=fib2mrib. You should see such XRLs for each RIP route. E.g., pick a network address learned from RIP. The output should contain the following XRLs for that address: 1. rib/0.1/add_route4 (with protocol:txt = rip) from RIP to RIB 2. redist_transaction4/0.1/add_route from RIB to FEA 3. fea_fib_client/0.1/add_route4 from FEA to FIB2MRIB 4. rib/0.1/add_route4 (with protocol:txt = fib2mrib) from FIB2MRIB to RIB 5. redist_transaction4/0.1/add_route from RIB to PIM In your case, the routes are missing either in step 3 or step 4. > PS:another question just to confirm, to configure the SPT > trigger we only need to configure the > switch-to-spt-threshold Wright? Yes. Pavlin From pavlin at icir.org Tue May 16 17:28:06 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 16 May 2006 17:28:06 -0700 Subject: [Xorp-users] IMportant In-Reply-To: Message from "Ali Sahibzada" of "Tue, 16 May 2006 21:04:16 BST." <740A0C221BAEA84BAFC3D17F8C23618F70558B@UXEXMBU116.academic.windsor> Message-ID: <200605170028.k4H0S6Hi000834@possum.icir.org> > I am new to this community and i have just started work on my > routing protocol. I wanted to know since XORP depends on gcc and > since its available in the packages installed by the cygwin > software, so would XORP run properly on Windows XP if it has > cygwin installed? Another question is that if i have the code for > the routing protocol written in C++, then how would i run and > check it in Xorp. Kindly help. Thanks a lot. I believe that XORP won't run on Windows XP. File BUILD_NOTES in the top-level XORP directory says that you need to use Windows Server 2003 SP1. Bruce M. Simpson is the right person to answer any Windows-specific questions. Regarding integrating your routing protocol in XORP, the following document describes in details how to write a process for the XORP framework: "An Introduction to Writing a XORP Process" http://www.xorp.org/design_docs.html At very high level, it should use XRLs to communicate with the rest of the XORP processes: for sending and receiving control traffic via the FEA, installing routes into the RIB, etc. Of course, you could also use the libxorp library for basic stuff like creating an event loop, setting timers, etc. While this is not mandatory, it can simplify your own implementation. Please let us know if you have any specific questions. Pavlin From pavlin at icir.org Wed May 17 10:15:51 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 17 May 2006 10:15:51 -0700 Subject: [Xorp-users] multicast without static routes In-Reply-To: Message from "Vitor Miguel de Sousa Branca" of "Wed, 17 May 2006 18:05:16 BST." Message-ID: <200605171715.k4HHFpHj010581@possum.icir.org> > In relation to the version I?m using the xorp 1.1 on a FreeBSD 4.9 OS > in relation to the XRLTRACE I didn?t check yet but I will see it tomorow an > d I will report to you. I would strongly recommend that you upgrade to 1.2 and try again whether you still have the problem. There have been lots of bug fixes between 1.1 and 1.2 so it would be pointless chaising bugs in 1.1 that might be fixed already. Pavlin From vkaul at research.telcordia.com Tue May 23 09:10:06 2006 From: vkaul at research.telcordia.com (Vikram KAUL) Date: Tue, 23 May 2006 12:10:06 -0400 (Eastern Standard Time) Subject: [Xorp-users] IGMP/PIM question ? Message-ID: Hi, First post here. I am trying to check whether I will be able to use XORP. Specifically, here is what I am trying to do: The multicast applications reside on a linux box which acts as a router as well. There are no 'end hosts' per-se. A string of these linux 'routers/hosts' are connected to each other and unicast routes are available. Initially, I will set the unicast routes statically, but later on move to a xorp-rip or ospf daemon. What I intend to see is whether I will be able to run PIM-SM (with statically configured RPs) in a scenario like this. When the receiver application starts, I want the local PIM daemon to respond to the local IGMP Membership Report (which would have ordinarily used been used to join a group). Of course, the PIM daemon in the adjacent router that would have ordinarily responded to this IGMP message should neglect it in the scenario I want to create. Similar to the above functionality, a host of other IGMP/PIM interactions, also have to be limited to "local" daemons (IGMP and PIM) rather than the traditional relationships between 'end-hosts' and their corresponding "pure" routers. For example, an IGMP membership Query should be handled locally to trigger any PIM prunes or grafts I am open to modifying the code to suit my needs.. but would prefer if I could execute the above with configuration setups only. I am new to the XORP architecture, so I might be way off in what I think I can accomplish using XORP. In any case, any insight will be very welcome regards.. Vikram From solca at guug.org Tue May 23 09:37:42 2006 From: solca at guug.org (Otto Solares) Date: Tue, 23 May 2006 11:37:42 -0500 Subject: [Xorp-users] Linux IPv6 MR Message-ID: <20060523163742.GA31955@guug.org> Hi! *(sorry for my english, not a native speaker) I have a GNU/Linux router with 8 NICs doing routing for 8 segments of the whole network in my University, 1 of those segments is commercial Internet and 1 other segment is Internet2. All segments are directly connected to this Linux router and is working very well with latest kernel (2.6.16.18). I'm using BGP IPv4/IPv6 for importing all Internet2 routes and for exporting my routes and it also works fine. Now I need to do multicast routing so I enabled all respecting modules for IPv4/IPv6 in XORP but just IPv4 multicast routing works, IPv6 multicast routing doesn't work, neither it doesn't show a neighbor nor it register as neighbor in the next-hop router. I am using latest USAGI patch. The kernel shows this message: KERNEL: assertion (newskb->dst) failed at net/ipv6/ip6_output.c (113) Does somebody knows the state of IPv6 multicast routing in XORP and in Linux kernel? I'm not a routing expert but would like to know what exactly the 'enable-ip-router-alert-option-check' option do? I don't see a difference with true or false. If enabled is much verbose the output. Thanks in advance. -otto PS. config.boot attached. -------------- next part -------------- /* XORP UG Copyright (C) 2006, Universidad Galileo Otto Solares */ interfaces { restore-original-config-on-shutdown: false interface eth0 { disable: false description: "DMZ" default-system-config } interface eth1 { disable: false description: "PUB" default-system-config } interface eth2 { disable: false description: "ADM" default-system-config } interface eth3 { disable: false description: "LAB" default-system-config } interface eth4 { disable: false description: "GES" default-system-config } /* interface eth5 { disable: true description: "(unused)" default-system-config } */ interface eth6 { disable: false description: "RAGIE" default-system-config } /* interface eth7 { disable: true description: "OSI" default-system-config } */ } fea { unicast-forwarding4 { disable: false } unicast-forwarding6 { disable: false } } plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface eth2 { vif eth2 { disable: false } } interface eth3 { vif eth3 { disable: false } } interface eth4 { vif eth4 { disable: false } } interface eth6 { vif eth6 { disable: false } } interface register_vif { vif register_vif { disable: false } } traceoptions { flag all { disable: true } } } mfea6 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface eth2 { vif eth2 { disable: false } } interface eth3 { vif eth3 { disable: false } } interface eth4 { vif eth4 { disable: false } } interface eth6 { vif eth6 { disable: false } } interface register_vif { vif register_vif { disable: false } } traceoptions { flag all { disable: true } } } } protocols { igmp { disable: false interface eth0 { vif eth0 { disable: false version: 2 enable-ip-router-alert-option-check: true } } interface eth1 { vif eth1 { disable: false version: 2 enable-ip-router-alert-option-check: true } } interface eth2 { vif eth2 { disable: false version: 2 enable-ip-router-alert-option-check: true } } interface eth3 { vif eth3 { disable: false version: 2 enable-ip-router-alert-option-check: true } } interface eth4 { vif eth4 { disable: false version: 2 enable-ip-router-alert-option-check: true } } interface eth6 { vif eth6 { disable: false version: 2 enable-ip-router-alert-option-check: true } } traceoptions { flag all { disable: true } } } mld { disable: false interface eth0 { vif eth0 { disable: false version: 1 enable-ip-router-alert-option-check: true } } interface eth1 { vif eth1 { disable: false version: 1 enable-ip-router-alert-option-check: true } } interface eth2 { vif eth2 { disable: false version: 1 enable-ip-router-alert-option-check: true } } interface eth3 { vif eth3 { disable: false version: 1 enable-ip-router-alert-option-check: true } } interface eth4 { vif eth4 { disable: false version: 1 enable-ip-router-alert-option-check: true } } interface eth6 { vif eth6 { disable: false version: 1 enable-ip-router-alert-option-check: true } } traceoptions { flag all { disable: true } } } pimsm4 { disable: false interface eth0 { vif eth0 { disable: false enable-ip-router-alert-option-check: true dr-priority: 100 } } interface eth1 { vif eth1 { disable: false enable-ip-router-alert-option-check: true dr-priority: 100 } } interface eth2 { vif eth2 { disable: false enable-ip-router-alert-option-check: true dr-priority: 100 } } interface eth3 { vif eth3 { disable: false enable-ip-router-alert-option-check: true dr-priority: 100 } } interface eth4 { vif eth4 { disable: false enable-ip-router-alert-option-check: true dr-priority: 100 } } interface eth6 { vif eth6 { disable: false enable-ip-router-alert-option-check: true dr-priority: 1 } } interface register_vif { vif register_vif { disable: false } } static-rps { rp 10.10.26.14 { group-prefix 224.0.0.0/4 { rp-priority: 192 } } } switch-to-spt-threshold { disable: false interval-sec: 100 bytes: 102400 } traceoptions { flag all { disable: true } } } pimsm6 { disable: false interface eth0 { vif eth0 { disable: false enable-ip-router-alert-option-check: true dr-priority: 100 } } interface eth1 { vif eth1 { disable: false enable-ip-router-alert-option-check: true dr-priority: 100 } } interface eth2 { vif eth2 { disable: false enable-ip-router-alert-option-check: true dr-priority: 100 } } interface eth3 { vif eth3 { disable: false enable-ip-router-alert-option-check: true dr-priority: 100 } } interface eth4 { vif eth4 { disable: false enable-ip-router-alert-option-check: true dr-priority: 100 } } interface eth6 { vif eth6 { disable: false enable-ip-router-alert-option-check: true dr-priority: 1 } } interface register_vif { vif register_vif { disable: false } } static-rps { rp fe80::205:5dff:fe7c:61fd { group-prefix ff08::/8 { rp-priority: 192 } } } traceoptions { flag all { disable: true } } } fib2mrib { disable: false } } From pavlin at icir.org Tue May 23 10:17:40 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 23 May 2006 10:17:40 -0700 Subject: [Xorp-users] IGMP/PIM question ? In-Reply-To: Message from Vikram KAUL of "Tue, 23 May 2006 12:10:06 EDT." Message-ID: <200605231717.k4NHHeKr016177@possum.icir.org> > I am trying to check whether I will be able to use XORP. Specifically, > here is what I am trying to do: > > The multicast applications reside on a linux box which acts as a router as > well. There are no 'end hosts' per-se. A string of these linux > 'routers/hosts' are connected to each other and unicast routes are > available. Initially, I will set the unicast routes statically, but later > on move to a xorp-rip or ospf daemon. > > What I intend to see is whether I will be able to run PIM-SM (with > statically configured RPs) in a scenario like this. When the receiver > application starts, I want the local PIM daemon to respond to the local > IGMP Membership Report (which would have ordinarily used been used to join > a group). Of course, the PIM daemon in the adjacent router that would have > ordinarily responded to this IGMP message should neglect it in the > scenario I want to create. > > Similar to the above functionality, a host of other IGMP/PIM interactions, > also have to be limited to "local" daemons (IGMP and PIM) rather than the > traditional relationships between 'end-hosts' and their corresponding > "pure" routers. For example, an IGMP membership Query should be handled > locally to trigger any PIM prunes or grafts > > I am open to modifying the code to suit my needs.. but would prefer if I > could execute the above with configuration setups only. > > I am new to the XORP architecture, so I might be way off in what I think I > can accomplish using XORP. In any case, any insight will be very welcome In general, a router could act as a sender/receiver as well. If you don't care which particular router on the receiver's LAN reacts to the multicast Join/Leave events, etc, then it should work without any source modifications. However, if I understand correctly your question, you want to influence the choice of which router reacts to IGMP Join messages, and this choice should be a function of the receiver's address. This is not how the IGMP and PIM-SM protocols operate, so most likely you won't be able to do it even with source code modification (the answer depends on the details about what exactlty you need to achieve). Below are the issues with IGMP and PIM-SM reacting as a function of the receiver's address: * In case of IGMP, the adjacent routers need to elect the IGMP Querier. The Querier is elected per LAN and the router with the lowest IP address on the LAN is the winner. Though, from PIM-SM perspective you shouldn't care which router is the IGMP Querier, so the IGMP Querier choice shouldn't impact you. * In case of PIM-SM, the adjacent routers need to elect the Designated Router. The DR is elected per LAN, and the election is a function of the routers' IP addresses and their DR priority (configurable by the PIM-SM dr-priority configuration option). Only if a PIM-SM router is the DR for the LAN, it will take into account the IGMP Join event to initiate the PIM-SM Join message. The fundamental problem here is that the IGMP and PIM-SM protocols do not track the IP address of the multicast receiver. In other words, IGMP and PIM-SM care only if there is a multicast receiver for a particular multicast group, but they don't care about the particular IP address of the receiver. Hence, when the IGMP module detects an IGMP Join event, it tells the PIM-SM module about the joined multicast group, but it doesn't tell anything about the receiver's address. One of the reasons IGMP and PIM-SM cannot track the receivers' addresses is because the IGMP host protocol uses IGMP Join suppression: if there are two or more receivers on a LAN for the same multicast group, only one of the hosts originates IGMP Join messages. Please let me know if I have misunderstood your question and you need to do something different. Pavlin P.S. I should mention the following to avoid any surprises. Some time ago it was brought to my attention the following Linux kernel bug: if you are running PIM on a network interface, and if your multicast application running on the router joins a multicast group on that same interface, then the IGMP Join message will trigger a kernel NOCACHE upcall (even if there is no multicast data). This bogus upcall should be harmless, but could be confusing if you are debugging some multicast-related issues. Though, I haven't check whether the bug is still in the most recent Linux kernel. From vkaul at research.telcordia.com Tue May 23 11:03:32 2006 From: vkaul at research.telcordia.com (Vikram KAUL) Date: Tue, 23 May 2006 14:03:32 -0400 (Eastern Standard Time) Subject: [Xorp-users] IGMP/PIM question ? In-Reply-To: <200605231717.k4NHHeKr016177@possum.icir.org> References: <200605231717.k4NHHeKr016177@possum.icir.org> Message-ID: Thanks for your prompt responses. My comments interspersed. pavlin>However, if I understand correctly your question, you want to pavlin>influence the choice of which router reacts to IGMP Join messages, pavlin>and this choice should be a function of the receiver's address. pavlin>This is not how the IGMP and PIM-SM protocols operate, so most pavlin>likely you won't be able to do it even with source code modification pavlin>(the answer depends on the details about what exactlty you need to pavlin>achieve). I took a cursory look at the code. Specifically, In igmp_proto.cc in Mld6igmpVif::igmp_process(...) If right away, a check for source address is done as follows... // Only accept my own queries, neglect all others if (!(mld6igmp_node().is_my_addr(src))) return (XORP_ERROR); then all IGMP messages from other nodes/routers can be neglected. Of course this is not what the protocol is supposed to do, but I am merely looking at all alternatives. Because if this check, the procedures for selecting/electing IGMP Queriers will not happen and all nodes will be IGMP Queriers only responding and taking care of 'themselves' Similarly, In pim_proto_hello.cc in static bool pim_dr_is_better(...) could be made to return "false" all the time so the initial selection of this node/router as the designated router for PIM Join/Leaves is maintained. These two mods, in essence, should make each node/router A) An IGMP Querier taking care of only itself B) A Designated Router taking care of only itself It is almost like reverting back to old times when Quering and DR was shared by the same router.. except this is much more drastic pavlin> pavlin>Below are the issues with IGMP and PIM-SM reacting as a function of pavlin>the receiver's address: pavlin> pavlin> * In case of IGMP, the adjacent routers need to elect the IGMP pavlin> Querier. The Querier is elected per LAN and the router with the pavlin> lowest IP address on the LAN is the winner. Though, from PIM-SM pavlin> perspective you shouldn't care which router is the IGMP Querier, so pavlin> the IGMP Querier choice shouldn't impact you. See above pavlin> pavlin> * In case of PIM-SM, the adjacent routers need to elect the pavlin> Designated Router. The DR is elected per LAN, and the election is pavlin> a function of the routers' IP addresses and their DR priority pavlin> (configurable by the PIM-SM dr-priority configuration pavlin> option). Only if a PIM-SM router is the DR for the LAN, it will pavlin> take into account the IGMP Join event to initiate the PIM-SM Join pavlin> message. Once the IGMP messages from any other node/router other than self have been neglected (above hack in igmp_proto.cc), then the DR will look at IGMP Join events from itself alone. pavlin> pavlin> The fundamental problem here is that the IGMP and PIM-SM pavlin> protocols do not track the IP address of the multicast pavlin> receiver. In other words, IGMP and PIM-SM care only if there is pavlin> a multicast receiver for a particular multicast group, but they pavlin> don't care about the particular IP address of the receiver. pavlin> Hence, when the IGMP module detects an IGMP Join event, it tells the pavlin> PIM-SM module about the joined multicast group, but it doesn't pavlin> tell anything about the receiver's address. I understand the functionality of the protocols as they are supposed to be used. I am merely experimenting with them and was wondering if I could use the current implementations in XORP (of course, after some mods) to achieve my objectives. pavlin> One of the reasons IGMP and PIM-SM cannot track the receivers' pavlin> addresses is because the IGMP host protocol uses IGMP Join pavlin> suppression: if there are two or more receivers on a LAN for the pavlin> same multicast group, only one of the hosts originates IGMP Join pavlin> messages. pavlin> Unfortunately, the above mods will eliminate that supression. But I am willing to give something to get something in return. Of course, a more careful look into the implementation could guide me into making (or at least think of making) other mods which have minimal impact on the protocols. What is your take on whether I could get what I want by doing the above regards.. Vikram From pavlin at icir.org Tue May 23 11:58:43 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 23 May 2006 11:58:43 -0700 Subject: [Xorp-users] IGMP/PIM question ? In-Reply-To: Message from Vikram KAUL of "Tue, 23 May 2006 14:03:32 EDT." Message-ID: <200605231858.k4NIwhfW016873@possum.icir.org> > pavlin>However, if I understand correctly your question, you want to > pavlin>influence the choice of which router reacts to IGMP Join messages, > pavlin>and this choice should be a function of the receiver's address. > pavlin>This is not how the IGMP and PIM-SM protocols operate, so most > pavlin>likely you won't be able to do it even with source code modification > pavlin>(the answer depends on the details about what exactlty you need to > pavlin>achieve). > > I took a cursory look at the code. Specifically, > > In igmp_proto.cc in Mld6igmpVif::igmp_process(...) > > If right away, a check for source address is done as follows... > > // Only accept my own queries, neglect all others > > if (!(mld6igmp_node().is_my_addr(src))) > return (XORP_ERROR); > > then all IGMP messages from other nodes/routers can be neglected. Of > course this is not what the protocol is supposed to do, but I am merely > looking at all alternatives. Because if this check, the procedures for > selecting/electing IGMP Queriers will not happen and all nodes will be > IGMP Queriers only responding and taking care of 'themselves' Yes, modifying the above code will have impact on accepting the IGMP control messages by XORP. However, this modification won't have impact on the IGMP host-side implementation inside the kernel. This is where the IGMP Join suppression happens. Hence, even if you reject the IGMP Queries and Membership Report inside XORP, they will still be processed inside the kernel. The processing of the IGMP Membership Report messages inside the kernel may trigger the IGMP Membership Report suppression (if there are 2+ receivers on the same LAN). As a result, you may never see the IGMP Join event by multicast application running on the local host. > Similarly, > > In pim_proto_hello.cc in static bool pim_dr_is_better(...) > > could be made to return "false" all the time so the initial selection of > this node/router as the designated router for PIM Join/Leaves is > maintained. Yes, the above modification inside PIM can make each PIM-SM router believe it is the DR, but then you have to be very careful if there is a sender with 2+ PIM-SM routers on same LAN. Each of the routers will think it is the DR and will eccapsulate same multicast data packet in PIM Registers and unicast it to the RP. As a result, you will see duplicated packets from the sender. > These two mods, in essence, should make each node/router > > A) An IGMP Querier taking care of only itself > B) A Designated Router taking care of only itself > > It is almost like reverting back to old times when Quering and DR was > shared by the same router.. except this is much more drastic > > pavlin> > pavlin>Below are the issues with IGMP and PIM-SM reacting as a function of > pavlin>the receiver's address: > pavlin> > pavlin> * In case of IGMP, the adjacent routers need to elect the IGMP > pavlin> Querier. The Querier is elected per LAN and the router with the > pavlin> lowest IP address on the LAN is the winner. Though, from PIM-SM > pavlin> perspective you shouldn't care which router is the IGMP Querier, so > pavlin> the IGMP Querier choice shouldn't impact you. > > See above > > pavlin> > pavlin> * In case of PIM-SM, the adjacent routers need to elect the > pavlin> Designated Router. The DR is elected per LAN, and the election is > pavlin> a function of the routers' IP addresses and their DR priority > pavlin> (configurable by the PIM-SM dr-priority configuration > pavlin> option). Only if a PIM-SM router is the DR for the LAN, it will > pavlin> take into account the IGMP Join event to initiate the PIM-SM Join > pavlin> message. > > Once the IGMP messages from any other node/router other than self have > been neglected (above hack in igmp_proto.cc), then the DR will look at > IGMP Join events from itself alone. > > pavlin> > pavlin> The fundamental problem here is that the IGMP and PIM-SM > pavlin> protocols do not track the IP address of the multicast > pavlin> receiver. In other words, IGMP and PIM-SM care only if there is > pavlin> a multicast receiver for a particular multicast group, but they > pavlin> don't care about the particular IP address of the receiver. > pavlin> Hence, when the IGMP module detects an IGMP Join event, it tells the > pavlin> PIM-SM module about the joined multicast group, but it doesn't > pavlin> tell anything about the receiver's address. > > I understand the functionality of the protocols as they are supposed to be > used. I am merely experimenting with them and was wondering if I could use > the current implementations in XORP (of course, after some mods) to > achieve my objectives. > > pavlin> One of the reasons IGMP and PIM-SM cannot track the receivers' > pavlin> addresses is because the IGMP host protocol uses IGMP Join > pavlin> suppression: if there are two or more receivers on a LAN for the > pavlin> same multicast group, only one of the hosts originates IGMP Join > pavlin> messages. > pavlin> > > Unfortunately, the above mods will eliminate that supression. But I am > willing to give something to get something in return. Of course, a more > careful look into the implementation could guide me into making (or at > least think of making) other mods which have minimal impact on the > protocols. Unfortunately, those mods won't eliminate the suppression problem, because as I mentioned above it happens inside the kernel, and you cannot disable it by userland programs. Also, they won't eliminate the PIM Register encapsulation issue. Though, if you always switch to the shortest path (to the sender) after the first data packet, then the PIM Register duplicated packet will happen only when a new sender becomes active (until the SPT switch to that sender is completed). Pavlin From pavlin at icir.org Tue May 23 12:10:15 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 23 May 2006 12:10:15 -0700 Subject: [Xorp-users] IGMP/PIM question ? In-Reply-To: Message from Pavlin Radoslavov of "Tue, 23 May 2006 11:58:43 PDT." <200605231858.k4NIwhfW016873@possum.icir.org> Message-ID: <200605231910.k4NJAFrE017108@possum.icir.org> > Unfortunately, those mods won't eliminate the suppression problem, > because as I mentioned above it happens inside the kernel, and you > cannot disable it by userland programs. On second thought, you might be able to use the following hack to get around the IGMP suppression problem: Install firewall filters to each router so the IGMP messages from everybody else will be dropped. Thus, the kernel IGMP stack won't see any IGMP messages from other hosts/routers. With this hack then probably you don't need to modify the XORP IGMP code because the filtering will be done by the firewall rules. > Also, they won't eliminate the PIM Register encapsulation issue. > Though, if you always switch to the shortest path (to the sender) > after the first data packet, then the PIM Register duplicated packet > will happen only when a new sender becomes active (until the SPT > switch to that sender is completed). If you can live with the initial data duplicates as described above, then you need to hack only the PIM-SM DR election (and configure your PIM-SM routers to perform the SPT switch after the first data packet). I believe you understand well that such modifications can be very dangerous and you should use them only on your testbed for experimental purpose. Please let me know if you run into any issues. Pavlin From pavlin at icir.org Tue May 23 12:20:14 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 23 May 2006 12:20:14 -0700 Subject: [Xorp-users] IGMP/PIM question ? In-Reply-To: Message from Pavlin Radoslavov of "Tue, 23 May 2006 12:10:15 PDT." <200605231910.k4NJAFrE017108@possum.icir.org> Message-ID: <200605231920.k4NJKEQ9017379@possum.icir.org> > > Also, they won't eliminate the PIM Register encapsulation issue. > > Though, if you always switch to the shortest path (to the sender) > > after the first data packet, then the PIM Register duplicated packet > > will happen only when a new sender becomes active (until the SPT > > switch to that sender is completed). > > If you can live with the initial data duplicates as described above, > then you need to hack only the PIM-SM DR election (and configure > your PIM-SM routers to perform the SPT switch after the first data > packet). On a third thought, you could hack the PIM-SM implementation to ignore WHOLEPKT kernel upcalls that indicate the sender address doesn't belong to the router. This will automatically prevent the PIM Register encapsulation. Note that this will work for Linux, but in case of *BSD you also need to use the --disable-advanced-multicast-api configure switch to disable the PIM Register encapsulation inside the kernel (the Linux kernel doesn't implement the Register encapsulation inside the kernel). To achieve that you need to modify PimMrt::signal_message_wholepkt_recv() inside pim_mrt_mfc.cc. With such modification you don't need to worry about the SPT switch threshold. Pavlin From c-otto at gmx.de Tue May 23 14:24:07 2006 From: c-otto at gmx.de (Carsten Otto) Date: Tue, 23 May 2006 23:24:07 +0200 Subject: [Xorp-users] Cand-RP is ignored Message-ID: <20060523212406.GD3389@localhost.halifax.rwth-aachen.de> Hi! I had to restart Xorp after several months, because another university decided to announce 224.0.0.0/4 as RP (which is bad, because the "network guys" for the whole network already do that (not the whole network though)) which (sort of) crashed my Xorp. Ironically other Xorp's in this university network had no problems and still have no problems. However, this issue is solved and a new problem arose. I need to start a local RP for the group used for local streams (which should go out into the university), but the Cand-RP mechanism seems to not work at all. I did not update anything in between the restart of Xorp and the time it was still running fine. After I noticed that something was wrong I updated Xorp to latest CVS and installed a recent kernel. Even with TRACE options I do not see anything that indicates a working (Cand-)RP. Furthermore I do not see any packet indicating something in this direction. Other users with the same setup can start RPs without a problem. I tried setting up a RP for "my" group and indeed the packets are sent to the host running Xorp with that RP (but are answered with "Stop" messages, confusing). Please tell me how to debug this problem. Thanks a lot, -- Carsten Otto c-otto at gmx.de www.c-otto.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060523/973b0239/attachment.bin From pavlin at icir.org Tue May 23 17:46:03 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 23 May 2006 17:46:03 -0700 Subject: [Xorp-users] Cand-RP is ignored In-Reply-To: Message from "Carsten Otto" of "Tue, 23 May 2006 23:24:07 +0200." <20060523212406.GD3389@localhost.halifax.rwth-aachen.de> Message-ID: <200605240046.k4O0k3PS001471@possum.icir.org> > I had to restart Xorp after several months, because another university > decided to announce 224.0.0.0/4 as RP (which is bad, because the > "network guys" for the whole network already do that (not the whole > network though)) which (sort of) crashed my Xorp. Ironically other Xorp's > in this university network had no problems and still have no problems. What XORP version did you run at that time, and do you have any additional info about the crash (coredump image for the backtrace, log messages, etc). > However, this issue is solved and a new problem arose. I need to start a > local RP for the group used for local streams (which should go out into the > university), but the Cand-RP mechanism seems to not work at all. I did > not update anything in between the restart of Xorp and the time it was > still running fine. After I noticed that something was wrong I updated > Xorp to latest CVS and installed a recent kernel. > > Even with TRACE options I do not see anything that indicates a working > (Cand-)RP. Furthermore I do not see any packet indicating something in > this direction. > > Other users with the same setup can start RPs without a problem. I tried > setting up a RP for "my" group and indeed the packets are sent to the > host running Xorp with that RP (but are answered with "Stop" messages, > confusing). In general, all PIM-SM routers in the middle (at least, between the receivers and the RP, and the sender's DR) must have consistent Cand-RP information. Hence, if you have configured your own Cand-RP, make sure that all affected routers have that information. If you used a static RP configuration, then obviously the other routers also need to be configured with that static RP info. If you configured a Cand-RP using the Bootstrap mechanism, make sure that this information is propagated properly to the rest of the routers. In xorpsh, the following commands can be useful to make sure the Cand-RP information is consistent: show pim rps show pim bootstrap show pim bootstrap rps Futhermore, if you have your "own" multicast group with its own Cand-RP, then make sure that its rp-priority has higher priority than the other Cand-RPs for overlapping multicast prefixes such as 224.0.0.0/4. Note that smaller value for rp-priority means higher priority, while in case of bsr-priority and dr-priority is just the opposite. Hope that helps, Pavlin From pavlin at icir.org Tue May 23 23:53:04 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 23 May 2006 23:53:04 -0700 Subject: [Xorp-users] Linux IPv6 MR In-Reply-To: Message from Otto Solares of "Tue, 23 May 2006 11:37:42 CDT." <20060523163742.GA31955@guug.org> Message-ID: <200605240653.k4O6r4nl005266@possum.icir.org> > I have a GNU/Linux router with 8 NICs doing routing > for 8 segments of the whole network in my University, > 1 of those segments is commercial Internet and 1 other > segment is Internet2. > > All segments are directly connected to this Linux > router and is working very well with latest kernel > (2.6.16.18). I'm using BGP IPv4/IPv6 for importing > all Internet2 routes and for exporting my routes and > it also works fine. > > Now I need to do multicast routing so I enabled all > respecting modules for IPv4/IPv6 in XORP but just > IPv4 multicast routing works, IPv6 multicast routing > doesn't work, neither it doesn't show a neighbor nor > it register as neighbor in the next-hop router. I > am using latest USAGI patch. > > The kernel shows this message: > > KERNEL: assertion (newskb->dst) failed at net/ipv6/ip6_output.c (113) It appears to be a kernel bug. For testing purpose can you try pim6sd and see whether you can still trigger that bug. BTW, I believe that mrd6 (the other IPv6 multicast routing alternative) performs the multicast forwarding in user space, hence it won't be a good candidate to test the bug. Also, can you provide some additional info when the assertion is triggered. E.g., does it happen when the first data packet is forwarded, etc. > Does somebody knows the state of IPv6 multicast > routing in XORP and in Linux kernel? We have done very limited testing with an older USAGI snapshot. See the following email for details: http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2005-November/000901.html > I'm not a routing expert but would like to know what > exactly the 'enable-ip-router-alert-option-check' > option do? I don't see a difference with true or > false. If enabled is much verbose the output. If it is enabled, then certain PIM-SM control packets must have the IP Router Alert option set to be accepted, otherwise those packets will be dropped with a warning like: "RX %s from %s to %s on vif %s: missing IP Router Alert option" If all appropriate PIM control messages from your PIM-SM neighbors contain the IP Router Alert message (as specified in the PIM-SM spec), then you won't see any difference even if you enable the enable-ip-router-alert-option-check option. Please let us know if you find anything about the kernel crash. Pavlin P.S. BTW, the static RP address in your configuration (fe80::205:5dff:fe7c:61fd) appears to be a link-local address. In general, this should be a domain-wide reachable address. From c-otto at gmx.de Wed May 24 00:11:43 2006 From: c-otto at gmx.de (Carsten Otto) Date: Wed, 24 May 2006 09:11:43 +0200 Subject: [Xorp-users] Cand-RP is ignored In-Reply-To: <200605240046.k4O0k3PS001471@possum.icir.org> References: <20060523212406.GD3389@localhost.halifax.rwth-aachen.de> <200605240046.k4O0k3PS001471@possum.icir.org> Message-ID: <20060524071142.GF3389@localhost.halifax.rwth-aachen.de> On Tue, May 23, 2006 at 05:46:03PM -0700, Pavlin Radoslavov wrote: > What XORP version did you run at that time, and do you have any > additional info about the crash (coredump image for the backtrace, > log messages, etc). It was an old (but then recent) CVS version. The crash was the old "too much memory" problem we already discussed. This problem never appeared again after the university enabled the right multicast routing (there was some mistake in the next hop). As far as I understand it Xorp always behaves incorrectly when it receives a lot of packets (here: 160 MBit/sec at this time) and does not know where to put them, because no RP is known for these groups. > If you configured a Cand-RP using the Bootstrap mechanism, make sure > that this information is propagated properly to the rest of the > routers. My Xorp is DR in the network where the groups are generated. I use bootstrap's Cand-RP. Using this configuration the other Xorp users here (a few hops away) managed to configure their own Cand-RP for their groups, but here it does not work anymore. As already set I see no indication that anything is being propagated at all. > show pim rps Everything but mine. As soon as another Xorp creates a Cand-RP it appears here, though. The list of RPs is identical to the list a few months ago, but without my Xorp. > show pim bootstrap Seems to be correct: Active zones: BSR Pri LocalAddress Pri State Timeout SZTimeout 188.1.42.50 0 0.0.0.0 0 AcceptPreferred 103 1273 Expiring zones: BSR Pri LocalAddress Pri State Timeout SZTimeout Configured zones: BSR Pri LocalAddress Pri State Timeout SZTimeout 0.0.0.0 0 0.0.0.0 0 Init -1 -1 This is BSR I know. > show pim bootstrap rps Oh. Did not know that.. My Cand-RP appears in "Configured RPs": Configured RPs: RP Pri Timeout GroupPrefix BSR CandRpAdvTimeout 137.226.119.114 0 -1 239.254.16.0/24 0.0.0.0 22 Is it this packet? 09:06:18.553773 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto: PIM (103), length: 58, options ( RA (148) len 4 )) fw.halifax.RWTH-Aachen.DE > PIM-ROUTERS.MCAST.NET: PIMv2, length: 34 Hello Hold Time Option (1), length: 2, Value: 1m45s 0x0000: 0069 LAN Prune Delay Option (2), length: 4, Value: T-bit=0, LAN delay 500ms, Override interval 2500ms 0x0000: 01f4 09c4 DR Priority Option (19), length: 4, Value: 1 0x0000: 0000 0001 Generation ID Option (20), length: 4, Value: 0x75e88d51 0x0000: 75e8 8d51 0x0000: 46c0 003a 0000 4000 0167 0237 89e2 7772 F..:.. at ..g.7..wr 0x0010: e000 000d 9404 0000 2000 d06b 0001 0002 ...........k.... 0x0020: 0069 0002 0004 01f4 09c4 0013 0004 0000 .i.............. 0x0030: 0001 0014 0004 75e8 8d51 ......u..Q I do not see any reaction to that. > Futhermore, if you have your "own" multicast group with its own > Cand-RP, then make sure that its rp-priority has higher priority > than the other Cand-RPs for overlapping multicast prefixes such as > 224.0.0.0/4. There is no overlapping prefix. > Note that smaller value for rp-priority means higher priority, > while in case of bsr-priority and dr-priority is just the opposite. I know :) Thanks for your help, -- Carsten Otto c-otto at gmx.de www.c-otto.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060524/bc2003a4/attachment.bin From c-otto at gmx.de Wed May 24 00:27:52 2006 From: c-otto at gmx.de (Carsten Otto) Date: Wed, 24 May 2006 09:27:52 +0200 Subject: [Xorp-users] Cand-RP is ignored In-Reply-To: <20060524071142.GF3389@localhost.halifax.rwth-aachen.de> References: <20060523212406.GD3389@localhost.halifax.rwth-aachen.de> <200605240046.k4O0k3PS001471@possum.icir.org> <20060524071142.GF3389@localhost.halifax.rwth-aachen.de> Message-ID: <20060524072752.GG3389@localhost.halifax.rwth-aachen.de> On Wed, May 24, 2006 at 09:11:43AM +0200, Carsten Otto wrote: > It was an old (but then recent) CVS version. The crash was the old "too > much memory" problem we already discussed. This problem never appeared > again after the university enabled the right multicast routing (there > was some mistake in the next hop). As far as I understand it Xorp always > behaves incorrectly when it receives a lot of packets (here: 160 > MBit/sec at this time) and does not know where to put them, because no > RP is known for these groups. That information is wrong, sorry. When no RP is there I just get a lot of messages about that. When there _is_ a RP, but not the right one (I get "stop" messages), the described problem appears. In my case the RP is far away and should not be used by me anyway. In the case of this other university with a 224.0.0.0/4 RP the problem reappeared with the same results. -- Carsten Otto c-otto at gmx.de www.c-otto.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060524/462f1e5f/attachment.bin From c-otto at gmx.de Wed May 24 06:10:39 2006 From: c-otto at gmx.de (Carsten Otto) Date: Wed, 24 May 2006 15:10:39 +0200 Subject: [Xorp-users] Cand-RP is ignored In-Reply-To: <20060524071142.GF3389@localhost.halifax.rwth-aachen.de> References: <20060523212406.GD3389@localhost.halifax.rwth-aachen.de> <200605240046.k4O0k3PS001471@possum.icir.org> <20060524071142.GF3389@localhost.halifax.rwth-aachen.de> Message-ID: <20060524131038.GB30490@localhost.halifax.rwth-aachen.de> On Wed, May 24, 2006 at 09:11:43AM +0200, Carsten Otto wrote: > Is it this packet? > [...] > I do not see any reaction to that. I tested the scenario with another Xorp machine (in another network) and noticed that the following packet is being sent: 14:52:58.531991 IP (tos 0x0, ttl 64, id 2787, offset 0, flags [none], proto 103, length: 42) fw-kullenhof.rz.rwth-aachen.de > mr-frankfurt2.x-win.dfn.de: PIMv2, length: 22 Candidate RP Advertisement (8) prefix-cnt=1 prio=0 holdtime=2m30s RP=fw-kullenhof.rz.rwth-aachen.de Group0=239.255.255.255 mr-frankfurt... is the BSR, 239.255.255.255/32 is the group for the Cand-RP and fw-kullenhof... is the machine running Xorp. The local machine, which has the problem, does not send this packet. Ciao, -- Carsten Otto c-otto at gmx.de www.c-otto.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060524/1671dfc1/attachment-0001.bin From p.pradeep09 at gmail.com Wed May 24 08:50:41 2006 From: p.pradeep09 at gmail.com (Pradeep Kumar PALAPARTHY) Date: Wed, 24 May 2006 21:20:41 +0530 Subject: [Xorp-users] junk values in /proc/net/ip_mr_cachw Message-ID: <8daef9c70605240850v27578bfei1a8f03f65cbd77d4@mail.gmail.com> hi , i am able to run xorp. its running properly . but its not forwarding multicast traffic. when i see /proc/net/ip_mr_cache there are some junk values for iif(internal interface ) and for oif. i am multicasting to two groups . and /proc/net/ip_mr_cache entries are as following. Group Origin Iif Pkts Bytes Wrong Oifs 230001E1 0A05A8C0 65535 1 4 -559067475 2D0100E1 0A05A8C0 65535 1 4 -559067475 group and origin values are correct. can anybody tell the what's the problem. can anybody send me the config.boot file for which mulricast forwarding is working. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060524/269f53a6/attachment.html From solca at guug.org Wed May 24 10:17:00 2006 From: solca at guug.org (Otto Solares) Date: Wed, 24 May 2006 12:17:00 -0500 Subject: [Xorp-users] Linux IPv6 MR In-Reply-To: <200605240653.k4O6r4nl005266@possum.icir.org> References: <20060523163742.GA31955@guug.org> <200605240653.k4O6r4nl005266@possum.icir.org> Message-ID: <20060524171700.GA1518@guug.org> On Tue, May 23, 2006 at 11:53:04PM -0700, Pavlin Radoslavov wrote: > > The kernel shows this message: > > > > KERNEL: assertion (newskb->dst) failed at net/ipv6/ip6_output.c (113) > > It appears to be a kernel bug. For testing purpose can you try > pim6sd and see whether you can still trigger that bug. > BTW, I believe that mrd6 (the other IPv6 multicast routing > alternative) performs the multicast forwarding in user > space, hence it won't be a good candidate to test the bug. Ok, will try both daemons and report back. > Also, can you provide some additional info when the assertion is > triggered. E.g., does it happen when the first data packet is > forwarded, etc. It actually starts when XORP's pim6d is launched, before any forwarding attempt, that assertion floods the logs, sometimes tenths of times per second and it nevers stops until XORP is taken down. > > Does somebody knows the state of IPv6 multicast > > routing in XORP and in Linux kernel? > > We have done very limited testing with an older USAGI snapshot. > See the following email for details: > http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2005-November/000901.html Yea, I used the information and links in that message for "fixing" the mroute6.h header so XORP could compile IPv6 multicast routing support. > > I'm not a routing expert but would like to know what > > exactly the 'enable-ip-router-alert-option-check' > > option do? I don't see a difference with true or > > false. If enabled is much verbose the output. > > If it is enabled, then certain PIM-SM control packets must have the > IP Router Alert option set to be accepted, otherwise those packets > will be dropped with a warning like: > "RX %s from %s to %s on vif %s: missing IP Router Alert option" > > If all appropriate PIM control messages from your PIM-SM neighbors > contain the IP Router Alert message (as specified in the PIM-SM > spec), then you won't see any difference even if you enable the > enable-ip-router-alert-option-check option. >From your experience, in necessary to disable in any modern environment (with other linux, bsds, macosx, solaris, winxp)? > Please let us know if you find anything about the kernel crash. I will. I posted in usagi-users, hopefully somebody will tell me what's going on, if not, that daemon in user space you mention would be the only option for IPv6 multicast routing in Linux. > P.S. BTW, the static RP address in your configuration > (fe80::205:5dff:fe7c:61fd) appears to be a link-local address. > In general, this should be a domain-wide reachable address. I questioned myself about this one, will fix it, thank you. -otto From solca at guug.org Wed May 24 11:01:46 2006 From: solca at guug.org (Otto Solares) Date: Wed, 24 May 2006 13:01:46 -0500 Subject: [Xorp-users] junk values in /proc/net/ip_mr_cachw In-Reply-To: <8daef9c70605240850v27578bfei1a8f03f65cbd77d4@mail.gmail.com> References: <8daef9c70605240850v27578bfei1a8f03f65cbd77d4@mail.gmail.com> Message-ID: <20060524180146.GB1518@guug.org> On Wed, May 24, 2006 at 09:20:41PM +0530, Pradeep Kumar PALAPARTHY wrote: > hi , > > i am able to run xorp. its running properly . > but its not forwarding multicast traffic. when i see /proc/net/ip_mr_cache > there are some junk values for iif(internal interface ) and for oif. > i am multicasting to two groups . and /proc/net/ip_mr_cache entries are as > following. > > Group Origin Iif Pkts Bytes Wrong Oifs > > 230001E1 0A05A8C0 65535 1 4 -559067475 > > 2D0100E1 0A05A8C0 65535 1 4 -559067475 > > group and origin values are correct. > > can anybody tell the what's the problem. > > can anybody send me the config.boot file for which mulricast > forwarding is working. I have attached my config.boot as I have IPv4 multicast routing working. I'm using Linux kernel 2.6.16.18 with Debian Sarge. -otto -------------- next part -------------- interfaces { restore-original-config-on-shutdown: false interface eth0 { disable: false description: "DMZ" default-system-config } interface eth1 { disable: false description: "PUB" default-system-config } interface eth2 { disable: false description: "ADM" default-system-config } interface eth3 { disable: false description: "LAB" default-system-config } interface eth4 { disable: false description: "GES" default-system-config } /* interface eth5 { disable: true description: "(unused)" default-system-config } */ interface eth6 { disable: false description: "RAGIE" default-system-config } /* interface eth7 { disable: true description: "OSI" default-system-config } */ } fea { unicast-forwarding4 { disable: false } } plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface eth2 { vif eth2 { disable: false } } interface eth3 { vif eth3 { disable: false } } interface eth4 { vif eth4 { disable: false } } interface eth6 { vif eth6 { disable: false } } interface register_vif { vif register_vif { disable: false } } traceoptions { flag all { disable: true } } } } protocols { igmp { disable: false interface eth0 { vif eth0 { disable: false version: 2 enable-ip-router-alert-option-check: false } } interface eth1 { vif eth1 { disable: false version: 2 enable-ip-router-alert-option-check: false } } interface eth2 { vif eth2 { disable: false version: 2 enable-ip-router-alert-option-check: false } } interface eth3 { vif eth3 { disable: false version: 2 enable-ip-router-alert-option-check: false } } interface eth4 { vif eth4 { disable: false version: 2 enable-ip-router-alert-option-check: false } } interface eth6 { vif eth6 { disable: false version: 2 enable-ip-router-alert-option-check: false } } traceoptions { flag all { disable: true } } } pimsm4 { disable: false interface eth0 { vif eth0 { disable: false enable-ip-router-alert-option-check: false dr-priority: 100 } } interface eth1 { vif eth1 { disable: false enable-ip-router-alert-option-check: false dr-priority: 100 } } interface eth2 { vif eth2 { disable: false enable-ip-router-alert-option-check: false dr-priority: 100 } } interface eth3 { vif eth3 { disable: false enable-ip-router-alert-option-check: false dr-priority: 100 } } interface eth4 { vif eth4 { disable: false enable-ip-router-alert-option-check: false dr-priority: 100 } } interface eth6 { vif eth6 { disable: false enable-ip-router-alert-option-check: false dr-priority: 1 } } interface register_vif { vif register_vif { disable: false } } static-rps { rp 10.10.26.14 { group-prefix 224.0.0.0/4 { rp-priority: 1 } } } switch-to-spt-threshold { disable: false interval-sec: 100 bytes: 102400 } traceoptions { flag all { disable: true } } } fib2mrib { disable: false } } From pavlin at icir.org Wed May 24 11:40:06 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 24 May 2006 11:40:06 -0700 Subject: [Xorp-users] Cand-RP is ignored In-Reply-To: Message from "Carsten Otto" of "Wed, 24 May 2006 09:11:43 +0200." <20060524071142.GF3389@localhost.halifax.rwth-aachen.de> Message-ID: <200605241840.k4OIe6WJ012180@possum.icir.org> > > If you configured a Cand-RP using the Bootstrap mechanism, make sure > > that this information is propagated properly to the rest of the > > routers. > > My Xorp is DR in the network where the groups are generated. > I use bootstrap's Cand-RP. Using this configuration the other Xorp users > here (a few hops away) managed to configure their own Cand-RP for their > groups, but here it does not work anymore. > As already set I see no indication that anything is being propagated at > all. > > > show pim rps > > Everything but mine. As soon as another Xorp creates a Cand-RP it > appears here, though. The list of RPs is identical to the list a few > months ago, but without my Xorp. > > > show pim bootstrap > > Seems to be correct: > Active zones: > BSR Pri LocalAddress Pri State Timeout SZTimeout > 188.1.42.50 0 0.0.0.0 0 AcceptPreferred 103 1273 > Expiring zones: > BSR Pri LocalAddress Pri State Timeout SZTimeout > Configured zones: > BSR Pri LocalAddress Pri State Timeout SZTimeout > 0.0.0.0 0 0.0.0.0 0 Init -1 -1 > > This is BSR I know. > > > show pim bootstrap rps > > Oh. Did not know that.. > > My Cand-RP appears in "Configured RPs": > Configured RPs: > RP Pri Timeout GroupPrefix BSR CandRpAdvTimeout > 137.226.119.114 0 -1 239.254.16.0/24 0.0.0.0 22 OK, this looks fine (modulo the fact that your RP is not in the received Cand-RP set). > Is it this packet? > 09:06:18.553773 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto: PIM (103), length: 58, options ( RA (148) len 4 )) fw.halifax.RWTH-Aachen.DE > PIM-ROUTERS.MCAST.NET: PIMv2, length: 34 > Hello > Hold Time Option (1), length: 2, Value: 1m45s > 0x0000: 0069 > LAN Prune Delay Option (2), length: 4, Value: > T-bit=0, LAN delay 500ms, Override interval 2500ms > 0x0000: 01f4 09c4 > DR Priority Option (19), length: 4, Value: 1 > 0x0000: 0000 0001 > Generation ID Option (20), length: 4, Value: 0x75e88d51 > 0x0000: 75e8 8d51 > 0x0000: 46c0 003a 0000 4000 0167 0237 89e2 7772 F..:.. at ..g.7..wr > 0x0010: e000 000d 9404 0000 2000 d06b 0001 0002 ...........k.... > 0x0020: 0069 0002 0004 01f4 09c4 0013 0004 0000 .i.............. > 0x0030: 0001 0014 0004 75e8 8d51 ......u..Q > > I do not see any reaction to that. This is the PIM Hello packet, so it is not related to the Bootstrap problem you have. I will reply separately to your other emails. Pavlin From pavlin at icir.org Wed May 24 11:43:27 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 24 May 2006 11:43:27 -0700 Subject: [Xorp-users] Cand-RP is ignored In-Reply-To: Message from "Carsten Otto" of "Wed, 24 May 2006 09:27:52 +0200." <20060524072752.GG3389@localhost.halifax.rwth-aachen.de> Message-ID: <200605241843.k4OIhRxh012251@possum.icir.org> > On Wed, May 24, 2006 at 09:11:43AM +0200, Carsten Otto wrote: > > It was an old (but then recent) CVS version. The crash was the old "too > > much memory" problem we already discussed. This problem never appeared > > again after the university enabled the right multicast routing (there > > was some mistake in the next hop). As far as I understand it Xorp always > > behaves incorrectly when it receives a lot of packets (here: 160 > > MBit/sec at this time) and does not know where to put them, because no > > RP is known for these groups. > > That information is wrong, sorry. When no RP is there I just get a lot > of messages about that. When there _is_ a RP, but not the right one (I > get "stop" messages), the described problem appears. In my case the RP > is far away and should not be used by me anyway. In the case of this > other university with a 224.0.0.0/4 RP the problem reappeared with the > same results. Thanks for the info. I will get a look into the issue when I get the chance. Though, I would recommend you to open a bugzilla entry so the info doesn't get lost. If possible, please add the related log messages you see. Thanks, Pavlin From pavlin at icir.org Wed May 24 11:59:07 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 24 May 2006 11:59:07 -0700 Subject: [Xorp-users] Cand-RP is ignored In-Reply-To: Message from "Carsten Otto" of "Wed, 24 May 2006 15:10:39 +0200." <20060524131038.GB30490@localhost.halifax.rwth-aachen.de> Message-ID: <200605241859.k4OIx7Vf012412@possum.icir.org> > On Wed, May 24, 2006 at 09:11:43AM +0200, Carsten Otto wrote: > > Is it this packet? > > [...] > > I do not see any reaction to that. > > I tested the scenario with another Xorp machine (in another network) and > noticed that the following packet is being sent: > > 14:52:58.531991 IP (tos 0x0, ttl 64, id 2787, offset 0, flags [none], proto 103, length: 42) fw-kullenhof.rz.rwth-aachen.de > mr-frankfurt2.x-win.dfn.de: PIMv2, length: 22 > Candidate RP Advertisement (8) prefix-cnt=1 prio=0 holdtime=2m30s RP=fw-kullenhof.rz.rwth-aachen.de Group0=239.255.255.255 > > mr-frankfurt... is the BSR, 239.255.255.255/32 is the group for the Cand-RP and fw-kullenhof... is the machine running Xorp. > > The local machine, which has the problem, does not send this packet. Yes, once the elected BSR is known, each Cand-RP must unicast a PIM Cand-RP-Adv message to it. If your XORP router doesn't send such Cand-RP-Adv message, you need to find-out why it doesn't send it. As a starter, enable the PIM traceoptions, and look for log messages that indicate a Bootstrap message has been received. After it is received with the elected Bootstrap router, the XORP router should unicast the PIM Cand-RP-Adv message to it. The sending of the Cand-RP-Adv message happens inside PimVif::pim_cand_rp_adv_send(), so you may want to add some XLOG_INFO() there to print various info (BTW, don't use printf(), because the message may not be displayed immediately). Pavlin P.S. One possible issue that comes to mind is the following: There must be an elected BSR router for a group range that covers your own multicast group. If the received BSR info doesn't cover your multicast group, then no Cand-RP-Adv message will be send. From pavlin at icir.org Wed May 24 12:19:25 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 24 May 2006 12:19:25 -0700 Subject: [Xorp-users] junk values in /proc/net/ip_mr_cachw In-Reply-To: Message from "Pradeep Kumar PALAPARTHY" of "Wed, 24 May 2006 21:20:41 +0530." <8daef9c70605240850v27578bfei1a8f03f65cbd77d4@mail.gmail.com> Message-ID: <200605241919.k4OJJPYx012820@possum.icir.org> > i am able to run xorp. its running properly . > but its not forwarding multicast traffic. when i see /proc/net/ip_mr_cache > there are some junk values for iif(internal interface ) and for oif. > i am multicasting to two groups . and /proc/net/ip_mr_cache entries are as > following. > > Group Origin Iif Pkts Bytes Wrong Oifs > > 230001E1 0A05A8C0 65535 1 4 -559067475 > > 2D0100E1 0A05A8C0 65535 1 4 -559067475 > > group and origin values are correct. > > can anybody tell the what's the problem. First, could you confirm that you have enabled multicast routing and PIM-SM in your kernel as specified in the user manual (Section 13.3.1). If yes, could you enable the PIM-SM traceoptions in your config file: protocols { pimsm4 { ... traceoptions { flag all { disable: false } } } } For completeness, you may want to enable the traceoptions for mfea4 and igmp. Some of the log messages should show the MFC entries that are added to the kernel. If there is no obvious error, please send me your complete log output and I will have a look at it (you don't need to CC the list). Pavlin From pavlin at icir.org Wed May 24 12:31:31 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 24 May 2006 12:31:31 -0700 Subject: [Xorp-users] Linux IPv6 MR In-Reply-To: Message from Otto Solares of "Wed, 24 May 2006 12:17:00 CDT." <20060524171700.GA1518@guug.org> Message-ID: <200605241931.k4OJVVFp012959@possum.icir.org> > > Also, can you provide some additional info when the assertion is > > triggered. E.g., does it happen when the first data packet is > > forwarded, etc. > > It actually starts when XORP's pim6d is launched, before > any forwarding attempt, that assertion floods the logs, > sometimes tenths of times per second and it nevers stops > until XORP is taken down. Interesting. Do you know whether there were any multicast data packets on any of the directly connected interfaces. In my limited testing I didn't see such kernel assertion, but I was using an older USAGI tarball (from October 2005), and I didn't have IPv6 multicast traffic. > > > I'm not a routing expert but would like to know what > > > exactly the 'enable-ip-router-alert-option-check' > > > option do? I don't see a difference with true or > > > false. If enabled is much verbose the output. > > > > If it is enabled, then certain PIM-SM control packets must have the > > IP Router Alert option set to be accepted, otherwise those packets > > will be dropped with a warning like: > > "RX %s from %s to %s on vif %s: missing IP Router Alert option" > > > > If all appropriate PIM control messages from your PIM-SM neighbors > > contain the IP Router Alert message (as specified in the PIM-SM > > spec), then you won't see any difference even if you enable the > > enable-ip-router-alert-option-check option. > > From your experience, in necessary to disable in any modern > environment (with other linux, bsds, macosx, solaris, winxp)? You could safely disable it (and I think its default value is false, i.e., disabled). Thanks, Pavlin From c-otto at gmx.de Wed May 24 12:48:20 2006 From: c-otto at gmx.de (Carsten Otto) Date: Wed, 24 May 2006 21:48:20 +0200 Subject: [Xorp-users] Cand-RP is ignored In-Reply-To: <200605241859.k4OIx7Vf012412@possum.icir.org> References: <20060524131038.GB30490@localhost.halifax.rwth-aachen.de> <200605241859.k4OIx7Vf012412@possum.icir.org> Message-ID: <20060524194819.GA24142@localhost.halifax.rwth-aachen.de> On Wed, May 24, 2006 at 11:59:07AM -0700, Pavlin Radoslavov wrote: > The sending of the Cand-RP-Adv message happens inside > PimVif::pim_cand_rp_adv_send(), so you may want to add some > XLOG_INFO() there to print various info (BTW, don't use printf(), > because the message may not be displayed immediately). I will try this now as I will try to find something in the trace messages. > P.S. One possible issue that comes to mind is the following: > There must be an elected BSR router for a group range that covers > your own multicast group. If the received BSR info doesn't cover > your multicast group, then no Cand-RP-Adv message will be send. The other Xorp users are in the same (university) network and have the same multicast upstream. So this is not the problem. And where can I see the range of a BSR? I only know that RPs have a range. This is my BSR in "show pim bootstrap": BSR Pri LocalAddress Pri State Timeout SZTimeout 188.1.42.50 0 0.0.0.0 0 AcceptPreferred 118 1288 Thanks a lot, -- Carsten Otto c-otto at gmx.de www.c-otto.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060524/d412b097/attachment.bin From c-otto at gmx.de Wed May 24 15:04:44 2006 From: c-otto at gmx.de (Carsten Otto) Date: Thu, 25 May 2006 00:04:44 +0200 Subject: [Xorp-users] Cand-RP is ignored In-Reply-To: <200605241859.k4OIx7Vf012412@possum.icir.org> References: <20060524131038.GB30490@localhost.halifax.rwth-aachen.de> <200605241859.k4OIx7Vf012412@possum.icir.org> Message-ID: <20060524220444.GA8906@localhost.halifax.rwth-aachen.de> On Wed, May 24, 2006 at 11:59:07AM -0700, Pavlin Radoslavov wrote: > The sending of the Cand-RP-Adv message happens inside > PimVif::pim_cand_rp_adv_send(), so you may want to add some > XLOG_INFO() there to print various info (BTW, don't use printf(), > because the message may not be displayed immediately). The packet is being sent - but not with the right addresses I think. the "src_addr" (retrieved from domain__wide_addr()) is the internal interface IP (134.130.48.1). This IP is routable, but not part of the transport LAN which connects to the rest of the world (including the BSR). Is this wrong? eth0 UP Sparse 2 DR 1 134.130.48.1 0 eth1 UP Sparse 2 DR 1 137.226.119.114 1 register_vif UP Sparse 2 DR 1 134.130.48.1 0 eth1 is the outgoing interface, which has the default route. I think packets to the BSR should be sent with eth1's IP. Ciao, -- Carsten Otto c-otto at gmx.de www.c-otto.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060525/fbd4f0f4/attachment.bin From pavlin at icir.org Wed May 24 18:37:13 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 24 May 2006 18:37:13 -0700 Subject: [Xorp-users] Cand-RP is ignored In-Reply-To: Message from "Carsten Otto" of "Thu, 25 May 2006 00:04:44 +0200." <20060524220444.GA8906@localhost.halifax.rwth-aachen.de> Message-ID: <200605250137.k4P1bDfV031067@possum.icir.org> > The packet is being sent - but not with the right addresses I think. > the "src_addr" (retrieved from domain__wide_addr()) is the internal > interface IP (134.130.48.1). This IP is routable, but not part of the > transport LAN which connects to the rest of the world (including the BSR). > Is this wrong? > > eth0 UP Sparse 2 DR 1 134.130.48.1 0 > eth1 UP Sparse 2 DR 1 137.226.119.114 1 > register_vif UP Sparse 2 DR 1 134.130.48.1 0 > > eth1 is the outgoing interface, which has the default route. I think packets > to the BSR should be sent with eth1's IP. Yes, I believe this is the issue. Previously, the first interface that is UP was used to originate the Cand-RP-Adv message to the BSR. There is no strong justification about this particular choice, so I just committed some changes to CVS to use instead the RPF interface toward the BSR. Please check-out the lastest code from CVS and see whether you still have the issue. Make sure you are using the following files: Revision Changes Path 1.78 +31 -1; commitid: 98a64474fc547ea6; xorp/pim/pim_node.cc 1.61 +11 -2; commitid: 98a64474fc547ea6; xorp/pim/pim_node.hh 1.47 +34 -61; commitid: 9a624475067b7ea6; xorp/pim/pim_bsr.cc Pavlin From ramu.avula at gmail.com Wed May 24 22:47:24 2006 From: ramu.avula at gmail.com (Ramu k) Date: Thu, 25 May 2006 11:17:24 +0530 Subject: [Xorp-users] IPv4 multicast routing not supported Message-ID: Hi , I am tring to run xorp on fedora (2.6.11-1.1369_FC4smp). i have enabled kernel support for multicasting and rebuild the kernel and have igmpv2 . but still i am getting IPv4 multicast routing not supported error . i am sending full error report and attaching config.boot file. Thanks in advance. ./xorp_rtrmgr -b ~/config.boot.uni.txt [ 2006/05/25 11:11:56 INFO xorp_rtrmgr:3540 RTRMGR +240 master_conf_tree.cc execute ] Changed modules: interfaces, fea, mfea4, rib, fib2mrib, igmp, pimsm4 [ 2006/05/25 11:11:56 INFO xorp_rtrmgr:3540 RTRMGR +99 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2006/05/25 11:11:57 INFO xorp_fea MFEA ] MFEA enabled [ 2006/05/25 11:11:57 INFO xorp_fea MFEA ] CLI enabled [ 2006/05/25 11:11:57 INFO xorp_fea MFEA ] CLI started [ 2006/05/25 11:11:57 INFO xorp_fea MFEA ] MFEA enabled [ 2006/05/25 11:11:57 INFO xorp_fea MFEA ] CLI enabled [ 2006/05/25 11:11:57 INFO xorp_fea MFEA ] CLI started [ 2006/05/25 11:11:58 INFO xorp_rtrmgr:3540 RTRMGR +99 module_manager.cc execute ] Executing module: fea (fea/xorp_fea) [ 2006/05/25 11:12:04 INFO xorp_rtrmgr:3540 RTRMGR +99 module_manager.cc execute ] Executing module: mfea4 (fea/xorp_fea) [ 2006/05/25 11:12:04 ERROR xorp_fea:3541 MFEA +438 mfea_mrouter.cc adopt_mrouter_socket ] adopt_mrouter_socket() failed: IPv4 multicast routing not supported [ 2006/05/25 11:12:05 INFO xorp_fea MFEA ] Interface added: Vif[eth0] pif_index: 2 vif_index: 0 addr: 192.168.1.157 subnet: 192.168.1.0/24broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP [ 2006/05/25 11:12:05 INFO xorp_fea MFEA ] Interface added: Vif[eth1] pif_index: 3 vif_index: 1 addr: 192.168.5.1 subnet: 192.168.5.0/24broadcast: 192.168.5.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP [ 2006/05/25 11:12:05 INFO xorp_fea MFEA ] MFEA started [ 2006/05/25 11:12:05 INFO xorp_fea MFEA ] Interface enabled Vif[eth0] pif_index: 2 vif_index: 0 addr: 192.168.1.157 subnet: 192.168.1.0/24broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED [ 2006/05/25 11:12:05 ERROR xorp_fea:3541 MFEA +940 mfea_mrouter.cc add_multicast_vif ] add_multicast_vif() failed: IPv4 multicast routing not supported [ 2006/05/25 11:12:05 ERROR xorp_fea:3541 MFEA +908 mfea_node.cc start_vif ] Cannot start vif eth0: cannot add the multicast vif to the kernel [ 2006/05/25 11:12:05 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/start_vif failed: XrlCmdError 102 Command failed Cannot start vif eth0: cannot add the multicast vif to the kernel [ 2006/05/25 11:12:05 ERROR xorp_rtrmgr:3540 RTRMGR +671 master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed Cannot start vif eth0: cannot add the multicast vif to the kernel [ 2006/05/25 11:12:05 ERROR xorp_rtrmgr:3540 RTRMGR +252 master_conf_tree.cc config_done ] Configuration failed: 102 Command failed Cannot start vif eth0: cannot add the multicast vif to the kernel [ 2006/05/25 11:12:05 INFO xorp_rtrmgr:3540 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2006/05/25 11:12:05 INFO xorp_rtrmgr:3540 RTRMGR +174 module_manager.cc terminate ] Terminating module: fea [ 2006/05/25 11:12:05 INFO xorp_rtrmgr:3540 RTRMGR +174 module_manager.cc terminate ] Terminating module: interfaces [ 2006/05/25 11:12:05 INFO xorp_rtrmgr:3540 RTRMGR +174 module_manager.cc terminate ] Terminating module: mfea4 [ 2006/05/25 11:12:05 INFO xorp_rtrmgr:3540 RTRMGR +197 module_manager.cc terminate ] Killing module: mfea4 [ 2006/05/25 11:12:05 ERROR xorp_rtrmgr:3540 RTRMGR +747 module_manager.cc done_cb ] Command "/root/xorp-1.2/fea/xorp_fea": terminated with signal 15. [ 2006/05/25 11:12:05 INFO xorp_rtrmgr:3540 RTRMGR +285 module_manager.cc module_exited ] Module killed during shutdown: mfea4 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060525/abdfe4b4/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.boot Type: application/octet-stream Size: 1539 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060525/abdfe4b4/attachment-0001.obj From pavlin at icir.org Wed May 24 23:01:11 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 24 May 2006 23:01:11 -0700 Subject: [Xorp-users] IPv4 multicast routing not supported In-Reply-To: Message from "Ramu k" of "Thu, 25 May 2006 11:17:24 +0530." Message-ID: <200605250601.k4P61BYc060710@possum.icir.org> > I am tring to run xorp on fedora (2.6.11-1.1369_FC4smp). > i have enabled kernel support for multicasting and rebuild the kernel and > have igmpv2 . but still i am > getting IPv4 multicast routing not supported error . i am sending full > error report and attaching config.boot file. What XORP version are you using? If it is older than XORP-1.2, please try 1.2 (or the lastest code from CVS) and see whether you still have the problem. If you still have the problem with XORP-1.2, can you send the output of running ./configure and the content of your config.log file. It looks like that HAVE_IPV4_MULTICAST_ROUTING (auto-detected when running ./configure) is not defined in your config.h so for some reason ./configure has failed to detect that your system supports IPv4 multicast routing. Pavlin From c-otto at gmx.de Thu May 25 04:09:49 2006 From: c-otto at gmx.de (Carsten Otto) Date: Thu, 25 May 2006 13:09:49 +0200 Subject: [Xorp-users] Cand-RP is ignored In-Reply-To: <200605250137.k4P1bDfV031067@possum.icir.org> References: <20060524220444.GA8906@localhost.halifax.rwth-aachen.de> <200605250137.k4P1bDfV031067@possum.icir.org> Message-ID: <20060525110949.GA21454@localhost.halifax.rwth-aachen.de> On Wed, May 24, 2006 at 06:37:13PM -0700, Pavlin Radoslavov wrote: > Yes, I believe this is the issue. Previously, the first interface > that is UP was used to originate the Cand-RP-Adv message to the BSR. > There is no strong justification about this particular choice, so I > just committed some changes to CVS to use instead the RPF interface > toward the BSR. I updated and now packets are sent: 13:08:12.783037 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: PIM (103), length: 46, options ( RA (148) len 4 )) 137.226.119.114 > 188.1.42.50: PIMv2, length: 22 Candidate RP Advertisement prefix-cnt=1 prio=0 holdtime=2m30s RP=137.226.119.114 Group0=239.254.16.0/24 13:08:12.785113 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: PIM (103), length: 46, options ( RA (148) len 4 )) 137.226.119.114 > 188.1.42.50: PIMv2, length: 22 Candidate RP Advertisement prefix-cnt=1 prio=0 holdtime=2m30s RP=137.226.119.114 Group0=239.255.255.255 They are ignored, though. -- Carsten Otto c-otto at gmx.de www.c-otto.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060525/9e3afcde/attachment.bin From pavlin at icir.org Thu May 25 08:45:27 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 25 May 2006 08:45:27 -0700 Subject: [Xorp-users] Cand-RP is ignored In-Reply-To: Message from "Carsten Otto" of "Thu, 25 May 2006 13:09:49 +0200." <20060525110949.GA21454@localhost.halifax.rwth-aachen.de> Message-ID: <200605251545.k4PFjRUF073697@possum.icir.org> Carsten Otto wrote: > On Wed, May 24, 2006 at 06:37:13PM -0700, Pavlin Radoslavov wrote: > > Yes, I believe this is the issue. Previously, the first interface > > that is UP was used to originate the Cand-RP-Adv message to the BSR. > > There is no strong justification about this particular choice, so I > > just committed some changes to CVS to use instead the RPF interface > > toward the BSR. > > I updated and now packets are sent: > > 13:08:12.783037 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: PIM (103), length: 46, options ( RA (148) len 4 )) 137.226.119.114 > 188.1.42.50: PIMv2, length: 22 > Candidate RP Advertisement prefix-cnt=1 prio=0 holdtime=2m30s RP=137.226.119.114 Group0=239.254.16.0/24 > 13:08:12.785113 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: PIM (103), length: 46, options ( RA (148) len 4 )) 137.226.119.114 > 188.1.42.50: PIMv2, length: 22 > Candidate RP Advertisement prefix-cnt=1 prio=0 holdtime=2m30s RP=137.226.119.114 Group0=239.255.255.255 > > They are ignored, though. Could you double-check that the other XORP routers on campus see the same BSR. Another thing you could check is whether the BSR accepts the particular group prefixes you are using: those particular values belong to the Site-Local Scope, and the BSR may restrict their usage (see http://www.iana.org/assignments/multicast-addresses). If other XORP routers can successfully announce your multicast block, but the BSR is still ignoring your Cand-RP-Advertisements, then probably it has been configured to accept or drop the Cand-RP-Adv messages from particular addresses? You would need to confirm that with the netadmin for the BSR. Pavlin From ramu.avula at gmail.com Thu May 25 08:53:58 2006 From: ramu.avula at gmail.com (Ramu k) Date: Thu, 25 May 2006 21:23:58 +0530 Subject: [Xorp-users] IPv4 multicast routing not supported In-Reply-To: <200605250601.k4P61BYc060710@possum.icir.org> References: <200605250601.k4P61BYc060710@possum.icir.org> Message-ID: Hi , i defined HAVE_IPV4_MULTICAST_ROUTING in config.h and compiled the xorp once again. it was commented before. now i am runnung xorp but it is not forwarding multicast data. and there are no entries in /proc/net/ip_mr_cache . i got following errors while running xorp. it is saying interface eth1 is down even though eth1 is up. and i attched my config.boot file. can anybody tell me what is the problem? thanks in advance. Ramu. [ 2006/05/25 20:49:12 INFO xorp_rtrmgr:7801 RTRMGR +240 master_conf_tree.cc execute ] Changed modules: interfaces, fea, mf [ 2006/05/25 20:49:12 INFO xorp_rtrmgr:7801 RTRMGR +99 module_manager.cc execute ] Executing module: interfaces (fea/xorp_ [ 2006/05/25 20:49:13 INFO xorp_fea MFEA ] MFEA enabled [ 2006/05/25 20:49:13 INFO xorp_fea MFEA ] CLI enabled [ 2006/05/25 20:49:13 INFO xorp_fea MFEA ] CLI started [ 2006/05/25 20:49:13 INFO xorp_fea MFEA ] MFEA enabled [ 2006/05/25 20:49:13 INFO xorp_fea MFEA ] CLI enabled [ 2006/05/25 20:49:13 INFO xorp_fea MFEA ] CLI started [ 2006/05/25 20:49:14 INFO xorp_rtrmgr:7801 RTRMGR +99 module_manager.cc execute ] Executing module: fea (fea/xorp_fea) [ 2006/05/25 20:49:20 INFO xorp_rtrmgr:7801 RTRMGR +99 module_manager.cc execute ] Executing module: mfea4 (fea/xorp_fea) [ 2006/05/25 20:49:20 INFO xorp_fea MFEA ] Interface added: Vif[eth0] pif_index: 2 vif_index: 0 addr: 192.168.1.163 subnet: [ 2006/05/25 20:49:20 INFO xorp_fea MFEA ] Interface added: Vif[eth1] pif_index: 3 vif_index: 1 addr: 192.168.2.9 subnet: 1 [ 2006/05/25 20:49:20 INFO xorp_fea MFEA ] MFEA started [ 2006/05/25 20:49:21 INFO xorp_fea MFEA ] Interface enabled Vif[eth0] pif_index: 2 vif_index: 0 addr: 192.168.1.163 subnet [ 2006/05/25 20:49:21 INFO xorp_fea MFEA ] Interface started: Vif[eth0] pif_index: 2 vif_index: 0 addr: 192.168.1.163 subne [ 2006/05/25 20:49:21 INFO xorp_fea MFEA ] Interface added: Vif[register_vif] pif_index: 2 vif_index: 2 addr: 192.168.1.163 [ 2006/05/25 20:49:21 INFO xorp_fea MFEA ] Interface enabled Vif[register_vif] pif_index: 2 vif_index: 2 addr: 192.168.1.16 [ 2006/05/25 20:49:21 INFO xorp_fea MFEA ] Interface started: Vif[register_vif] pif_index: 2 vif_index: 2 addr: 192.168.1.1 [ 2006/05/25 20:49:21 INFO xorp_rtrmgr:7801 RTRMGR +99 module_manager.cc execute ] Executing module: rib (rib/xorp_rib) [ 2006/05/25 20:49:23 INFO xorp_rtrmgr:7801 RTRMGR +99 module_manager.cc execute ] Executing module: fib2mrib (fib2mrib/xo [ 2006/05/25 20:49:25 INFO xorp_rtrmgr:7801 RTRMGR +99 module_manager.cc execute ] Executing module: igmp (mld6igmp/xorp_i [ 2006/05/25 20:49:25 WARNING xorp_rtrmgr:7801 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolv [ 2006/05/25 20:49:25 INFO xorp_igmp MLD6IGMP ] Protocol enabled [ 2006/05/25 20:49:25 INFO xorp_igmp MLD6IGMP ] CLI enabled [ 2006/05/25 20:49:25 INFO xorp_igmp MLD6IGMP ] CLI started [ 2006/05/25 20:49:26 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[eth0] pif_index: 0 vif_index: 0 addr: 192.168.1.163 su [ 2006/05/25 20:49:26 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[eth1] pif_index: 0 vif_index: 1 addr: 192.168.2.9 subn [ 2006/05/25 20:49:26 INFO xorp_igmp MLD6IGMP ] Protocol started [ 2006/05/25 20:49:27 INFO xorp_igmp MLD6IGMP ] Interface enabled: Vif[eth0] pif_index: 0 vif_index: 0 addr: 192.168.1.163 [ 2006/05/25 20:49:27 INFO xorp_igmp MLD6IGMP ] Interface started: Vif[eth0] pif_index: 0 vif_index: 0 addr: 192.168.1.163 [ 2006/05/25 20:49:27 INFO xorp_igmp MLD6IGMP ] Interface enabled: Vif[eth1] pif_index: 0 vif_index: 1 addr: 192.168.2.9 su [ 2006/05/25 20:49:27 INFO xorp_igmp MLD6IGMP ] Interface started: Vif[eth1] pif_index: 0 vif_index: 1 addr: 192.168.2.9 su [ 2006/05/25 20:49:27 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdEr [ 2006/05/25 20:49:27 INFO xorp_rtrmgr:7801 RTRMGR +99 module_manager.cc execute ] Executing module: pimsm4 (pim/xorp_pims [ 2006/05/25 20:49:27 ERROR xorp_igmp:8393 MLD6IGMP +1519 xrl_mld6igmp_node.cc mfea_client_send_protocol_message_cb ] Cann [ 2006/05/25 20:49:27 WARNING xorp_rtrmgr:7801 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resol[ 2006/05/25 20:49:25 INFO xorp_igmp MLD6IGMP ] Protocol enabled [ 2006/05/25 20:49:25 INFO xorp_igmp MLD6IGMP ] CLI enabled [ 2006/05/25 20:49:25 INFO xorp_igmp MLD6IGMP ] CLI started [ 2006/05/25 20:49:26 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[eth0] pif_index: 0 vif_index: 0 addr: 192.168.1.163 su [ 2006/05/25 20:49:26 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[eth1] pif_index: 0 vif_index: 1 addr: 192.168.2.9 subn [ 2006/05/25 20:49:26 INFO xorp_igmp MLD6IGMP ] Protocol started [ 2006/05/25 20:49:27 INFO xorp_igmp MLD6IGMP ] Interface enabled: Vif[eth0] pif_index: 0 vif_index: 0 addr: 192.168.1.163 [ 2006/05/25 20:49:27 INFO xorp_igmp MLD6IGMP ] Interface started: Vif[eth0] pif_index: 0 vif_index: 0 addr: 192.168.1.163 [ 2006/05/25 20:49:27 INFO xorp_igmp MLD6IGMP ] Interface enabled: Vif[eth1] pif_index: 0 vif_index: 1 addr: 192.168.2.9 su [ 2006/05/25 20:49:27 INFO xorp_igmp MLD6IGMP ] Interface started: Vif[eth1] pif_index: 0 vif_index: 1 addr: 192.168.2.9 su [ 2006/05/25 20:49:27 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdEr [ 2006/05/25 20:49:27 INFO xorp_rtrmgr:7801 RTRMGR +99 module_manager.cc execute ] Executing module: pimsm4 (pim/xorp_pims [ 2006/05/25 20:49:27 ERROR xorp_igmp:8393 MLD6IGMP +1519 xrl_mld6igmp_node.cc mfea_client_send_protocol_message_cb ] Cann [ 2006/05/25 20:49:27 WARNING xorp_rtrmgr:7801 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolv [ 2006/05/25 20:49:28 WARNING xorp_igmp MLD6IGMP ] RX IGMP_V1_MEMBERSHIP_REPORT from 192.168.1.18 to 224.0.1.60 on vif eth0 [ 2006/05/25 20:49:28 INFO xorp_pimsm4 PIM ] Protocol enabled [ 2006/05/25 20:49:28 INFO xorp_pimsm4 PIM ] CLI enabled [ 2006/05/25 20:49:28 INFO xorp_pimsm4 PIM ] CLI started [ 2006/05/25 20:49:28 INFO xorp_pimsm4 PIM ] Interface added: Vif[eth0] pif_index: 0 vif_index: 0 addr: 192.168.1.163 subne [ 2006/05/25 20:49:28 INFO xorp_pimsm4 PIM ] Interface added: Vif[eth1] pif_index: 0 vif_index: 1 addr: 192.168.2.9 subnet: [ 2006/05/25 20:49:28 INFO xorp_pimsm4 PIM ] Interface added: Vif[register_vif] pif_index: 0 vif_index: 2 addr: 192.168.1.1 [ 2006/05/25 20:49:28 INFO xorp_pimsm4 PIM ] Protocol started [ 2006/05/25 20:49:28 WARNING xorp_igmp MLD6IGMP ] RX IGMP_V1_MEMBERSHIP_REPORT from 192.168.1.18 to 224.0.0.251 on vif eth [ 2006/05/25 20:49:29 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[eth0] pif_index: 0 vif_index: 0 addr: 192.168.1.163 sub [ 2006/05/25 20:49:29 INFO xorp_pimsm4 PIM ] Interface started: Vif[eth0] pif_index: 0 vif_index: 0 addr: 192.168.1.163 sub [ 2006/05/25 20:49:29 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[eth1] pif_index: 0 vif_index: 1 addr: 192.168.2.9 subne [ 2006/05/25 20:49:29 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = true: RP for group 239.255.255.253: not found [ 2006/05/25 20:49:29 INFO xorp_pimsm4 PIM ] Interface started: Vif[eth1] pif_index: 0 vif_index: 1 addr: 192.168.2.9 subne [ 2006/05/25 20:49:29 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[register_vif] pif_index: 0 vif_index: 2 addr: 192.168.1 [ 2006/05/25 20:49:29 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = true: RP for group 235.80.68.83: not found [ 2006/05/25 20:49:29 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = true: RP for group 239.255.255.250: not found [ 2006/05/25 20:49:29 INFO xorp_pimsm4 PIM ] Interface started: Vif[register_vif] pif_index: 0 vif_index: 2 addr: 192.168.1 [ 2006/05/25 20:49:29 INFO xorp_rtrmgr:7801 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2006/05/25 20:49:33 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdEr [ 2006/05/25 20:49:33 ERROR xorp_pimsm4:8418 PIM +2623 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send [ 2006/05/25 20:49:57 ERROR xorp_fea:7990 MFEA +1201 mfea_mrouter.cc add_mfc ] setsockopt(MRT_ADD_MFC, (192.168.1.21, 239 [ 2006/05/25 21:19:04 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send PIMSM_4 protocol message from 192.168.5.1 to 224.0.0.13 on vif eth1: Vif eth1 is DOWN [ 2006/05/25 21:19:04 ERROR xorp_pimsm4:20123 PIM +2623 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send PIMSM_4 protocol message from 192.168.5.1 to 224.0.0.13 on vif eth1: Vif eth1 is DOWN [ 2006/05/25 21:19:04 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send IGMP protocol message from 192.168.5.1 to 224.0.0.1 on vif eth1: Vif eth1 is DOWN [ 2006/05/25 21:19:04 ERROR xorp_igmp:20122 MLD6IGMP +1519 xrl_mld6igmp_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send IGMP protocol message from 192.168.5.1 to 224.0.0.1 on vif eth1: Vif eth1 is DOWN [ 2006/05/25 21:19:05 ERROR xorp_fea:20103 MFEA +1894 mfea_mrouter.cc get_sg_count ] ioctl(SIOCGETSGCNT, (192.168.1.21 239.255.255.250)) failed: Cannot assign requested address [ 2006/05/25 21:19:05 ERROR xorp_fea:20103 MFEA +126 mfea_dataflow.cc add_entry ] Cannot add dataflow monitor for (192.168.1.21, 239.255.255.250): invalid request [ 2006/05/25 21:19:05 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/add_dataflow_monitor4 failed: XrlCmdError 102 Command failed Cannot add dataflow monitor for (192.168.1.21, 239.255.255.250): invalid request [ 2006/05/25 21:19:05 ERROR xorp_pimsm4:20123 PIM +2133 xrl_pim_node.cc mfea_client_send_add_delete_dataflow_monitor_cb ] Cannot add a dataflow monitor with the MFEA: 102 Command failed Cannot add dataflow monitor for ( 192.168.1.21, 239.255.255.250): invalid request [ 2006/05/25 21:19:34 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed Cannot send PIMSM_4 protocol message from 192.168.5.1 to 224.0.0.13 on vif eth1: Vif eth1 is DOWN [ 2006/05/25 21:19:34 ERROR xorp_pimsm4:20123 PIM +2623 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send PIMSM_4 protocol message from 192.168.5.1 to 224.0.0.13 on vif eth1: Vif eth1 is DOWN ---------- Forwarded message ---------- From: Pavlin Radoslavov Date: May 25, 2006 11:31 AM Subject: Re: [Xorp-users] IPv4 multicast routing not supported To: Ramu k Cc: xorp-users at xorp.org > I am tring to run xorp on fedora (2.6.11-1.1369_FC4smp). > i have enabled kernel support for multicasting and rebuild the kernel and > have igmpv2 . but still i am > getting IPv4 multicast routing not supported error . i am sending full > error report and attaching config.boot file. What XORP version are you using? If it is older than XORP-1.2, please try 1.2 (or the lastest code from CVS) and see whether you still have the problem. If you still have the problem with XORP-1.2, can you send the output of running ./configure and the content of your config.log file. It looks like that HAVE_IPV4_MULTICAST_ROUTING (auto-detected when running ./configure) is not defined in your config.h so for some reason ./configure has failed to detect that your system supports IPv4 multicast routing. Pavlin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060525/2ac4b2fb/attachment-0001.html From pavlin at icir.org Thu May 25 09:10:19 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 25 May 2006 09:10:19 -0700 Subject: [Xorp-users] IPv4 multicast routing not supported In-Reply-To: Message from "Ramu k" of "Thu, 25 May 2006 21:23:58 +0530." Message-ID: <200605251610.k4PGAJYj073991@possum.icir.org> > i defined HAVE_IPV4_MULTICAST_ROUTING in config.h and compiled the xorp once > > again. it was commented before. now i am runnung xorp but it is not > forwarding multicast data. > and there are no entries in /proc/net/ip_mr_cache . i got following errors > while running xorp. > it is saying interface eth1 is down even though eth1 is up. > and i attched my config.boot file. > can anybody tell me what is the problem? I see MFEA "Interface started" message for eth0, but I don't see such message for eth1: [ 2006/05/25 20:49:21 INFO xorp_fea MFEA ] Interface started: Vif[eth0] Can you double-check that eth1 is configured properly in your XORP config. Also, what is the output of the "ip addr" UNIX command, and can you double-check that the eth1 cable is connected properly. Finally, what is the output of the "show interfaces" and "show mfea interface" xorpsh commands. Pavlin > > thanks in advance. > Ramu. > > [ 2006/05/25 20:49:12 INFO xorp_rtrmgr:7801 RTRMGR +240 master_conf_tree.cc > execute ] Changed modules: interfaces, fea, mf > [ 2006/05/25 20:49:12 INFO xorp_rtrmgr:7801 RTRMGR +99 module_manager.cc > execute ] Executing module: interfaces (fea/xorp_ > [ 2006/05/25 20:49:13 INFO xorp_fea MFEA ] MFEA enabled > [ 2006/05/25 20:49:13 INFO xorp_fea MFEA ] CLI enabled > [ 2006/05/25 20:49:13 INFO xorp_fea MFEA ] CLI started > [ 2006/05/25 20:49:13 INFO xorp_fea MFEA ] MFEA enabled > [ 2006/05/25 20:49:13 INFO xorp_fea MFEA ] CLI enabled > [ 2006/05/25 20:49:13 INFO xorp_fea MFEA ] CLI started > [ 2006/05/25 20:49:14 INFO xorp_rtrmgr:7801 RTRMGR +99 module_manager.cc > execute ] Executing module: fea (fea/xorp_fea) > [ 2006/05/25 20:49:20 INFO xorp_rtrmgr:7801 RTRMGR +99 module_manager.cc > execute ] Executing module: mfea4 (fea/xorp_fea) > [ 2006/05/25 20:49:20 INFO xorp_fea MFEA ] Interface added: Vif[eth0] > pif_index: 2 vif_index: 0 addr: 192.168.1.163 subnet: > [ 2006/05/25 20:49:20 INFO xorp_fea MFEA ] Interface added: Vif[eth1] > pif_index: 3 vif_index: 1 addr: 192.168.2.9 subnet: 1 > [ 2006/05/25 20:49:20 INFO xorp_fea MFEA ] MFEA started > [ 2006/05/25 20:49:21 INFO xorp_fea MFEA ] Interface enabled Vif[eth0] > pif_index: 2 vif_index: 0 addr: 192.168.1.163 subnet > [ 2006/05/25 20:49:21 INFO xorp_fea MFEA ] Interface started: Vif[eth0] > pif_index: 2 vif_index: 0 addr: 192.168.1.163 subne > [ 2006/05/25 20:49:21 INFO xorp_fea MFEA ] Interface added: > Vif[register_vif] pif_index: 2 vif_index: 2 addr: 192.168.1.163 > [ 2006/05/25 20:49:21 INFO xorp_fea MFEA ] Interface enabled > Vif[register_vif] pif_index: 2 vif_index: 2 addr: 192.168.1.16 > [ 2006/05/25 20:49:21 INFO xorp_fea MFEA ] Interface started: > Vif[register_vif] pif_index: 2 vif_index: 2 addr: 192.168.1.1 > [ 2006/05/25 20:49:21 INFO xorp_rtrmgr:7801 RTRMGR +99 module_manager.cc > execute ] Executing module: rib (rib/xorp_rib) > [ 2006/05/25 20:49:23 INFO xorp_rtrmgr:7801 RTRMGR +99 module_manager.cc > execute ] Executing module: fib2mrib (fib2mrib/xo > [ 2006/05/25 20:49:25 INFO xorp_rtrmgr:7801 RTRMGR +99 module_manager.cc > execute ] Executing module: igmp (mld6igmp/xorp_i > [ 2006/05/25 20:49:25 WARNING xorp_rtrmgr:7801 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolv > [ 2006/05/25 20:49:25 INFO xorp_igmp MLD6IGMP ] Protocol enabled > [ 2006/05/25 20:49:25 INFO xorp_igmp MLD6IGMP ] CLI enabled > [ 2006/05/25 20:49:25 INFO xorp_igmp MLD6IGMP ] CLI started > [ 2006/05/25 20:49:26 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[eth0] > pif_index: 0 vif_index: 0 addr: 192.168.1.163 su > [ 2006/05/25 20:49:26 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[eth1] > pif_index: 0 vif_index: 1 addr: 192.168.2.9 subn > [ 2006/05/25 20:49:26 INFO xorp_igmp MLD6IGMP ] Protocol started > [ 2006/05/25 20:49:27 INFO xorp_igmp MLD6IGMP ] Interface enabled: Vif[eth0] > pif_index: 0 vif_index: 0 addr: 192.168.1.163 > [ 2006/05/25 20:49:27 INFO xorp_igmp MLD6IGMP ] Interface started: Vif[eth0] > pif_index: 0 vif_index: 0 addr: 192.168.1.163 > [ 2006/05/25 20:49:27 INFO xorp_igmp MLD6IGMP ] Interface enabled: Vif[eth1] > pif_index: 0 vif_index: 1 addr: 192.168.2.9 su > [ 2006/05/25 20:49:27 INFO xorp_igmp MLD6IGMP ] Interface started: Vif[eth1] > pif_index: 0 vif_index: 1 addr: 192.168.2.9 su > [ 2006/05/25 20:49:27 WARNING xorp_fea XrlMfeaTarget ] Handling method for > mfea/0.1/send_protocol_message4 failed: XrlCmdEr > [ 2006/05/25 20:49:27 INFO xorp_rtrmgr:7801 RTRMGR +99 module_manager.cc > execute ] Executing module: pimsm4 (pim/xorp_pims > [ 2006/05/25 20:49:27 ERROR xorp_igmp:8393 MLD6IGMP +1519 > xrl_mld6igmp_node.cc mfea_client_send_protocol_message_cb ] Cann > [ 2006/05/25 20:49:27 WARNING xorp_rtrmgr:7801 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resol[ 2006/05/25 20:49:25 > INFO xorp_igmp MLD6IGMP ] Protocol enabled > [ 2006/05/25 20:49:25 INFO xorp_igmp MLD6IGMP ] CLI enabled > [ 2006/05/25 20:49:25 INFO xorp_igmp MLD6IGMP ] CLI started > [ 2006/05/25 20:49:26 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[eth0] > pif_index: 0 vif_index: 0 addr: 192.168.1.163 su > [ 2006/05/25 20:49:26 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[eth1] > pif_index: 0 vif_index: 1 addr: 192.168.2.9 subn > [ 2006/05/25 20:49:26 INFO xorp_igmp MLD6IGMP ] Protocol started > [ 2006/05/25 20:49:27 INFO xorp_igmp MLD6IGMP ] Interface enabled: Vif[eth0] > pif_index: 0 vif_index: 0 addr: 192.168.1.163 > [ 2006/05/25 20:49:27 INFO xorp_igmp MLD6IGMP ] Interface started: Vif[eth0] > pif_index: 0 vif_index: 0 addr: 192.168.1.163 > [ 2006/05/25 20:49:27 INFO xorp_igmp MLD6IGMP ] Interface enabled: Vif[eth1] > pif_index: 0 vif_index: 1 addr: 192.168.2.9 su > [ 2006/05/25 20:49:27 INFO xorp_igmp MLD6IGMP ] Interface started: Vif[eth1] > pif_index: 0 vif_index: 1 addr: 192.168.2.9 su > [ 2006/05/25 20:49:27 WARNING xorp_fea XrlMfeaTarget ] Handling method for > mfea/0.1/send_protocol_message4 failed: XrlCmdEr > [ 2006/05/25 20:49:27 INFO xorp_rtrmgr:7801 RTRMGR +99 module_manager.cc > execute ] Executing module: pimsm4 (pim/xorp_pims > [ 2006/05/25 20:49:27 ERROR xorp_igmp:8393 MLD6IGMP +1519 > xrl_mld6igmp_node.cc mfea_client_send_protocol_message_cb ] Cann > [ 2006/05/25 20:49:27 WARNING xorp_rtrmgr:7801 XrlFinderTarget +406 > ../xrl/targets/finder_base.cc handle_finder_0_2_resolv > [ 2006/05/25 20:49:28 WARNING xorp_igmp MLD6IGMP ] RX > IGMP_V1_MEMBERSHIP_REPORT from 192.168.1.18 to 224.0.1.60 on vif eth0 > [ 2006/05/25 20:49:28 INFO xorp_pimsm4 PIM ] Protocol enabled > [ 2006/05/25 20:49:28 INFO xorp_pimsm4 PIM ] CLI enabled > [ 2006/05/25 20:49:28 INFO xorp_pimsm4 PIM ] CLI started > [ 2006/05/25 20:49:28 INFO xorp_pimsm4 PIM ] Interface added: Vif[eth0] > pif_index: 0 vif_index: 0 addr: 192.168.1.163 subne > [ 2006/05/25 20:49:28 INFO xorp_pimsm4 PIM ] Interface added: Vif[eth1] > pif_index: 0 vif_index: 1 addr: 192.168.2.9 subnet: > [ 2006/05/25 20:49:28 INFO xorp_pimsm4 PIM ] Interface added: > Vif[register_vif] pif_index: 0 vif_index: 2 addr: 192.168.1.1 > [ 2006/05/25 20:49:28 INFO xorp_pimsm4 PIM ] Protocol started > [ 2006/05/25 20:49:28 WARNING xorp_igmp MLD6IGMP ] RX > IGMP_V1_MEMBERSHIP_REPORT from 192.168.1.18 to 224.0.0.251 on vif eth > [ 2006/05/25 20:49:29 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[eth0] > pif_index: 0 vif_index: 0 addr: 192.168.1.163 sub > [ 2006/05/25 20:49:29 INFO xorp_pimsm4 PIM ] Interface started: Vif[eth0] > pif_index: 0 vif_index: 0 addr: 192.168.1.163 sub > [ 2006/05/25 20:49:29 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[eth1] > pif_index: 0 vif_index: 1 addr: 192.168.2.9 subne > [ 2006/05/25 20:49:29 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = true: RP > for group 239.255.255.253: not found > [ 2006/05/25 20:49:29 INFO xorp_pimsm4 PIM ] Interface started: Vif[eth1] > pif_index: 0 vif_index: 1 addr: 192.168.2.9 subne > [ 2006/05/25 20:49:29 INFO xorp_pimsm4 PIM ] Interface enabled: > Vif[register_vif] pif_index: 0 vif_index: 2 addr: 192.168.1 > [ 2006/05/25 20:49:29 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = true: RP > for group 235.80.68.83: not found > [ 2006/05/25 20:49:29 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = true: RP > for group 239.255.255.250: not found > [ 2006/05/25 20:49:29 INFO xorp_pimsm4 PIM ] Interface started: > Vif[register_vif] pif_index: 0 vif_index: 2 addr: 192.168.1 > [ 2006/05/25 20:49:29 INFO xorp_rtrmgr:7801 RTRMGR +2228 task.cc run_task ] > No more tasks to run > [ 2006/05/25 20:49:33 WARNING xorp_fea XrlMfeaTarget ] Handling method for > mfea/0.1/send_protocol_message4 failed: XrlCmdEr > [ 2006/05/25 20:49:33 ERROR xorp_pimsm4:8418 PIM +2623 xrl_pim_node.cc > mfea_client_send_protocol_message_cb ] Cannot send > [ 2006/05/25 20:49:57 ERROR xorp_fea:7990 MFEA +1201 mfea_mrouter.cc > add_mfc ] setsockopt(MRT_ADD_MFC, (192.168.1.21, 239 > > [ 2006/05/25 21:19:04 WARNING xorp_fea XrlMfeaTarget ] Handling method for > mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed > Cannot send PIMSM_4 protocol message from 192.168.5.1 to 224.0.0.13 on vif > eth1: Vif eth1 is DOWN > [ 2006/05/25 21:19:04 ERROR xorp_pimsm4:20123 PIM +2623 xrl_pim_node.cc > mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 > Command failed Cannot send PIMSM_4 protocol message from 192.168.5.1 to > 224.0.0.13 on vif eth1: Vif eth1 is DOWN > [ 2006/05/25 21:19:04 WARNING xorp_fea XrlMfeaTarget ] Handling method for > mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed > Cannot send IGMP protocol message from 192.168.5.1 to 224.0.0.1 on vif eth1: > Vif eth1 is DOWN > [ 2006/05/25 21:19:04 ERROR xorp_igmp:20122 MLD6IGMP +1519 > xrl_mld6igmp_node.cc mfea_client_send_protocol_message_cb ] Cannot send a > protocol message: 102 Command failed Cannot send IGMP protocol message from > 192.168.5.1 to 224.0.0.1 on vif eth1: Vif eth1 is DOWN > [ 2006/05/25 21:19:05 ERROR xorp_fea:20103 MFEA +1894 mfea_mrouter.cc > get_sg_count ] ioctl(SIOCGETSGCNT, (192.168.1.21 239.255.255.250)) failed: > Cannot assign requested address > [ 2006/05/25 21:19:05 ERROR xorp_fea:20103 MFEA +126 mfea_dataflow.cc > add_entry ] Cannot add dataflow monitor for (192.168.1.21, 239.255.255.250): > invalid request > [ 2006/05/25 21:19:05 WARNING xorp_fea XrlMfeaTarget ] Handling method for > mfea/0.1/add_dataflow_monitor4 failed: XrlCmdError 102 Command failed Cannot > add dataflow monitor for (192.168.1.21, 239.255.255.250): invalid request > [ 2006/05/25 21:19:05 ERROR xorp_pimsm4:20123 PIM +2133 xrl_pim_node.cc > mfea_client_send_add_delete_dataflow_monitor_cb ] Cannot add a dataflow > monitor with the MFEA: 102 Command failed Cannot add dataflow monitor for ( > 192.168.1.21, 239.255.255.250): invalid request > [ 2006/05/25 21:19:34 WARNING xorp_fea XrlMfeaTarget ] Handling method for > mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed > Cannot send PIMSM_4 protocol message from 192.168.5.1 to 224.0.0.13 on vif > eth1: Vif eth1 is DOWN > [ 2006/05/25 21:19:34 ERROR xorp_pimsm4:20123 PIM +2623 xrl_pim_node.cc > mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 > Command failed Cannot send PIMSM_4 protocol message from 192.168.5.1 to > 224.0.0.13 on vif eth1: Vif eth1 is DOWN > > > > > > ---------- Forwarded message ---------- > From: Pavlin Radoslavov > Date: May 25, 2006 11:31 AM > Subject: Re: [Xorp-users] IPv4 multicast routing not supported > To: Ramu k > Cc: xorp-users at xorp.org > > > I am tring to run xorp on fedora (2.6.11-1.1369_FC4smp). > > i have enabled kernel support for multicasting and rebuild the kernel and > > have igmpv2 . but still i am > > getting IPv4 multicast routing not supported error . i am sending full > > error report and attaching config.boot file. > > What XORP version are you using? > If it is older than XORP-1.2, please try 1.2 (or the lastest code > from CVS) and see whether you still have the problem. > > If you still have the problem with XORP-1.2, can you send the output > of running ./configure and the content of your config.log file. > > It looks like that HAVE_IPV4_MULTICAST_ROUTING (auto-detected when > running ./configure) is not defined in your config.h so for some > reason ./configure has failed to detect that your system supports > IPv4 multicast routing. > > Pavlin > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From c-otto at gmx.de Thu May 25 09:12:22 2006 From: c-otto at gmx.de (Carsten Otto) Date: Thu, 25 May 2006 18:12:22 +0200 Subject: [Xorp-users] Cand-RP is ignored In-Reply-To: <200605251545.k4PFjRUF073697@possum.icir.org> References: <20060525110949.GA21454@localhost.halifax.rwth-aachen.de> <200605251545.k4PFjRUF073697@possum.icir.org> Message-ID: <20060525161222.GC21454@localhost.halifax.rwth-aachen.de> On Thu, May 25, 2006 at 08:45:27AM -0700, Pavlin Radoslavov wrote: > Could you double-check that the other XORP routers on campus see the > same BSR. Another thing you could check is whether the BSR accepts > the particular group prefixes you are using: those particular values > belong to the Site-Local Scope, and the BSR may restrict their usage > (see http://www.iana.org/assignments/multicast-addresses). All the other Xorps have the same BSR and can set up a RP for my groups. The BSR admin told us to use the 239.255.0.0/16 area. > If other XORP routers can successfully announce your multicast block, > but the BSR is still ignoring your Cand-RP-Advertisements, then > probably it has been configured to accept or drop the Cand-RP-Adv > messages from particular addresses? You would need to confirm that > with the netadmin for the BSR. I changed the routers address (inside the transport LAN), but that does not help. I will ask the BSR admin for more information, perhaps they noticed something. Thanks, -- Carsten Otto c-otto at gmx.de www.c-otto.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060525/947a9ab3/attachment.bin From ramu.avula at gmail.com Thu May 25 23:34:58 2006 From: ramu.avula at gmail.com (Ramu k) Date: Fri, 26 May 2006 12:04:58 +0530 Subject: [Xorp-users] IPv4 multicast routing not supported In-Reply-To: <200605251610.k4PGAJYj073991@possum.icir.org> References: <200605251610.k4PGAJYj073991@possum.icir.org> Message-ID: I see MFEA "Interface started" message for eth0, but I don't see such message for eth1: -> sorry i didnt configured eth1 for mfea. now i configured it. still its not forwarding . the scenario is like this. and i am attaching config.boot eth0 eth1 eth0 eth0 LANA-------------------------| -------------------------xorp-----------------------------| LANB 192.168.5.xx 192.168.5.xx 192.168.1.xx 192.168.1.xx i am running multicast streamer in 192.168.5.xx to group 225.0.1.45 and want to access the stream in 192.168.1.xx show interfaces output is. eth0/eth0: Flags: mtu 1500 inet6 fe80::20f:feff:fe1f:913f prefixlen 64 inet 192.168.1.157 subnet 192.168.1.0/24 broadcast 192.168.1.255 physical index 2 ether 0:f:fe:1f:91:3f eth1/eth1: Flags: mtu 1500 inet6 fe80::211:95ff:fefc:a1d0 prefixlen 64 inet 192.168.5.1 subnet 192.168.5.0/24 broadcast 192.168.5.255 physical index 3 ether 0:11:95:fc:a1:d0 show mfea interface Interface State Vif/PifIndex Addr Flags eth0 UP 0/2 192.168.1.157 MULTICAST BROADCAST KERN_UP eth1 UP 1/3 192.168.5.1 MULTICAST BROADCAST KERN_UP register_vif UP 2/2 192.168.1.157 PIM_REGISTER KERN_UP show pim rps RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix 192.168.1.157 static 192 -1 -xorp at S04L-RAMU> show pim bootstrap Active zones: BSR Pri LocalAddress Pri State Timeout SZTimeout Expiring zones: BSR Pri LocalAddress Pri State Timeout SZTimeout Configured zones: BSR Pri LocalAddress Pri State Timeout SZTimeout 1 7 224.0.0.0/4 show pim bootstrap rps Active RPs: RP Pri Timeout GroupPrefix BSR CandRpAdvTimeout Expiring RPs: RP Pri Timeout GroupPrefix BSR CandRpAdvTimeout Configured RPs: RP Pri Timeout GroupPrefix BSR CandRpAdvTimeout ip addr 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0f:fe:1f:91:3f brd ff:ff:ff:ff:ff:ff inet 192.168.1.157/24 brd 192.168.1.255 scope global eth0 inet6 fe80::20f:feff:fe1f:913f/64 scope link valid_lft forever preferred_lft forever 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:11:95:fc:a1:d0 brd ff:ff:ff:ff:ff:ff inet 192.168.5.1/24 brd 192.168.5.255 scope global eth1 inet6 fe80::211:95ff:fefc:a1d0/64 scope link valid_lft forever preferred_lft forever 4: sit0: mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 11: pimreg at NONE: mtu 1472 qdisc noqueue link/pimreg entries in /proc/net/ip_mr_cache Group Origin Iif Pkts Bytes Wrong Oifs 2D0100E1 0A05A8C0 65535 1 4 -559067475 230001E1 0A05A8C0 65535 1 4 -559067475 thanks your help pavlin. and when run xorp output is something like following ./xorp_rtrmgr -b ~/config.boot.uni.txt [ 2006/05/26 12:01:40 INFO xorp_rtrmgr:29465 RTRMGR +240 master_conf_tree.cc execute ] Changed modules: interfaces, fea, mfea4, rib, fib2mrib, igmp, pimsm4 [ 2006/05/26 12:01:40 INFO xorp_rtrmgr:29465 RTRMGR +99 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2006/05/26 12:01:40 INFO xorp_fea MFEA ] MFEA enabled [ 2006/05/26 12:01:40 INFO xorp_fea MFEA ] CLI enabled [ 2006/05/26 12:01:40 INFO xorp_fea MFEA ] CLI started [ 2006/05/26 12:01:40 INFO xorp_fea MFEA ] MFEA enabled [ 2006/05/26 12:01:40 INFO xorp_fea MFEA ] CLI enabled [ 2006/05/26 12:01:40 INFO xorp_fea MFEA ] CLI started [ 2006/05/26 12:01:42 INFO xorp_rtrmgr:29465 RTRMGR +99 module_manager.cc execute ] Executing module: fea (fea/xorp_fea) [ 2006/05/26 12:01:48 INFO xorp_rtrmgr:29465 RTRMGR +99 module_manager.cc execute ] Executing module: mfea4 (fea/xorp_fea) [ 2006/05/26 12:01:48 INFO xorp_fea MFEA ] Interface added: Vif[eth0] pif_index: 2 vif_index: 0 addr: 192.168.1.157 subnet: 192.168.1.0/24broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP [ 2006/05/26 12:01:48 INFO xorp_fea MFEA ] Interface added: Vif[eth1] pif_index: 3 vif_index: 1 addr: 192.168.5.1 subnet: 192.168.5.0/24broadcast: 192.168.5.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP [ 2006/05/26 12:01:48 INFO xorp_fea MFEA ] MFEA started [ 2006/05/26 12:01:49 INFO xorp_fea MFEA ] Interface enabled Vif[eth0] pif_index: 2 vif_index: 0 addr: 192.168.1.157 subnet: 192.168.1.0/24broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED [ 2006/05/26 12:01:49 INFO xorp_fea MFEA ] Interface started: Vif[eth0] pif_index: 2 vif_index: 0 addr: 192.168.1.157 subnet: 192.168.1.0/24broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED [ 2006/05/26 12:01:49 INFO xorp_fea MFEA ] Interface added: Vif[register_vif] pif_index: 2 vif_index: 2 addr: 192.168.1.157 subnet: 192.168.1.157/32 broadcast: 192.168.1.157 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP [ 2006/05/26 12:01:49 INFO xorp_fea MFEA ] Interface enabled Vif[eth1] pif_index: 3 vif_index: 1 addr: 192.168.5.1 subnet: 192.168.5.0/24broadcast: 192.168.5.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED [ 2006/05/26 12:01:49 INFO xorp_fea MFEA ] Interface started: Vif[eth1] pif_index: 3 vif_index: 1 addr: 192.168.5.1 subnet: 192.168.5.0/24broadcast: 192.168.5.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED [ 2006/05/26 12:01:49 INFO xorp_fea MFEA ] Interface enabled Vif[register_vif] pif_index: 2 vif_index: 2 addr: 192.168.1.157 subnet: 192.168.1.157/32 broadcast: 192.168.1.157 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP DOWN IPv4 ENABLED [ 2006/05/26 12:01:49 INFO xorp_fea MFEA ] Interface started: Vif[register_vif] pif_index: 2 vif_index: 2 addr: 192.168.1.157 subnet: 192.168.1.157/32 broadcast: 192.168.1.157 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP UP IPv4 ENABLED [ 2006/05/26 12:01:49 INFO xorp_rtrmgr:29465 RTRMGR +99 module_manager.cc execute ] Executing module: rib (rib/xorp_rib) [ 2006/05/26 12:01:51 INFO xorp_rtrmgr:29465 RTRMGR +99 module_manager.cc execute ] Executing module: fib2mrib (fib2mrib/xorp_fib2mrib) [ 2006/05/26 12:01:53 INFO xorp_rtrmgr:29465 RTRMGR +99 module_manager.cc execute ] Executing module: igmp (mld6igmp/xorp_ [ 2006/05/26 12:01:53 WARNING xorp_rtrmgr:29465 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "IGMP" does not exist or is not enabled. [ 2006/05/26 12:01:53 INFO xorp_igmp MLD6IGMP ] Protocol enabled [ 2006/05/26 12:01:53 INFO xorp_igmp MLD6IGMP ] CLI enabled [ 2006/05/26 12:01:53 INFO xorp_igmp MLD6IGMP ] CLI started [ 2006/05/26 12:01:54 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[eth0] pif_index: 0 vif_index: 0 addr: 192.168.1.157 subnet: 192.168.1.0/24broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP [ 2006/05/26 12:01:54 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[eth1] pif_index: 0 vif_index: 1 addr: 192.168.5.1 subnet: 192.168.5.0/24broadcast: 192.168.5.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP [ 2006/05/26 12:01:54 INFO xorp_igmp MLD6IGMP ] Protocol started [ 2006/05/26 12:01:55 INFO xorp_igmp MLD6IGMP ] Interface enabled: Vif[eth0] pif_index: 0 vif_index: 0 addr: 192.168.1.157 subnet: 192.168.1.0/24broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED [ 2006/05/26 12:01:55 INFO xorp_igmp MLD6IGMP ] Interface started: Vif[eth0] pif_index: 0 vif_index: 0 addr: 192.168.1.157 subnet: 192.168.1.0/24broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED [ 2006/05/26 12:01:55 INFO xorp_igmp MLD6IGMP ] Interface enabled: Vif[eth1] pif_index: 0 vif_index: 1 addr: 192.168.5.1 subnet: 192.168.5.0/24broadcast: 192.168.5.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED [ 2006/05/26 12:01:55 INFO xorp_igmp MLD6IGMP ] Interface started: Vif[eth1] pif_index: 0 vif_index: 1 addr: 192.168.5.1 subnet: 192.168.5.0/24broadcast: 192.168.5.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED [ 2006/05/26 12:01:55 INFO xorp_rtrmgr:29465 RTRMGR +99 module_manager.cc execute ] Executing module: pimsm4 (pim/xorp_pimsm4) [ 2006/05/26 12:01:55 WARNING xorp_rtrmgr:29465 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "PIMSM_4" does not exist or is not enabled. [ 2006/05/26 12:01:56 INFO xorp_pimsm4 PIM ] Protocol enabled [ 2006/05/26 12:01:56 INFO xorp_pimsm4 PIM ] CLI enabled [ 2006/05/26 12:01:56 INFO xorp_pimsm4 PIM ] CLI started [ 2006/05/26 12:01:56 INFO xorp_pimsm4 PIM ] Interface added: Vif[eth0] pif_index: 0 vif_index: 0 addr: 192.168.1.157 subnet: 192.168.1.0/24broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP [ 2006/05/26 12:01:56 INFO xorp_pimsm4 PIM ] Interface added: Vif[eth1] pif_index: 0 vif_index: 1 addr: 192.168.5.1 subnet: 192.168.5.0/24broadcast: 192.168.5.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP [ 2006/05/26 12:01:56 INFO xorp_pimsm4 PIM ] Interface added: Vif[register_vif] pif_index: 0 vif_index: 2 addr: 192.168.1.157 subnet: 192.168.1.157/32 broadcast: 192.168.1.157 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP [ 2006/05/26 12:01:56 INFO xorp_pimsm4 PIM ] Protocol started [ 2006/05/26 12:01:57 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[eth0] pif_index: 0 vif_index: 0 addr: 192.168.1.157 subnet: 192.168.1.0/24broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED [ 2006/05/26 12:01:57 INFO xorp_pimsm4 PIM ] Interface started: Vif[eth0] pif_index: 0 vif_index: 0 addr: 192.168.1.157 subnet: 192.168.1.0/24broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED [ 2006/05/26 12:01:57 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[eth1] pif_index: 0 vif_index: 1 addr: 192.168.5.1 subnet: 192.168.5.0/24broadcast: 192.168.5.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED [ 2006/05/26 12:01:57 INFO xorp_pimsm4 PIM ] Interface started: Vif[eth1] pif_index: 0 vif_index: 1 addr: 192.168.5.1 subnet: 192.168.5.0/24broadcast: 192.168.5.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED [ 2006/05/26 12:01:57 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[register_vif] pif_index: 0 vif_index: 2 addr: 192.168.1.157 subnet: 192.168.1.157/32 broadcast: 192.168.1.157 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP DOWN IPv4 ENABLED [ 2006/05/26 12:01:57 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = true: RP for group 239.255.255.250: not found [ 2006/05/26 12:01:57 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = true: RP for group 224.0.1.24: not found [ 2006/05/26 12:01:57 INFO xorp_pimsm4 PIM ] Interface started: Vif[register_vif] pif_index: 0 vif_index: 2 addr: 192.168.1.157 subnet: 192.168.1.157/32 broadcast: 192.168.1.157 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP UP IPv4 ENABLED [ 2006/05/26 12:01:57 INFO xorp_rtrmgr:29465 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2006/05/26 12:01:59 ERROR xorp_fea:29466 MFEA +1201 mfea_mrouter.cc add_mfc ] setsockopt(MRT_ADD_MFC, (192.168.5.10, 225.0.1.45)) failed: Invalid argument [ 2006/05/26 12:01:59 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/add_mfc4 failed: XrlCmdError 102 Command failed Cannot add MFC for source 192.168.5.10 and group 225.0.1.45 with iif_vif_index = 1 [ 2006/05/26 12:01:59 ERROR xorp_pimsm4:29486 PIM +1854 xrl_pim_node.cc mfea_client_send_add_delete_mfc_cb ] Cannot add a multicast forwarding entry with the MFEA: 102 Command failed Cannot add MFC for source 192.168.5.10 and group 225.0.1.45 with iif_vif_index = 1 [ 2006/05/26 12:01:59 ERROR xorp_fea:29466 MFEA +1894 mfea_mrouter.cc get_sg_count ] ioctl(SIOCGETSGCNT, (192.168.5.10 225.0.1.45)) failed: Cannot assign requested address Also, what is the output of the "ip addr" UNIX command, and can you double-check that the eth1 cable is connected properly. Finally, what is the output of the "show interfaces" and "show mfea interface" xorpsh commands. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060526/68e1001e/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.boot Type: application/octet-stream Size: 1562 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060526/68e1001e/attachment-0001.obj From pavlin at icir.org Fri May 26 09:57:41 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 26 May 2006 09:57:41 -0700 Subject: [Xorp-users] IPv4 multicast routing not supported In-Reply-To: Message from "Ramu k" of "Fri, 26 May 2006 12:04:58 +0530." Message-ID: <200605261657.k4QGvfs5011808@possum.icir.org> > still its not forwarding . the scenario is like this. and i am attaching > config.boot > entries in /proc/net/ip_mr_cache > Group Origin Iif Pkts Bytes Wrong Oifs > 2D0100E1 0A05A8C0 65535 1 4 -559067475 > 230001E1 0A05A8C0 65535 1 4 -559067475 Interesting. From the above output it looks like the multicast forwarding entries were added to the kernel, but they seem corrupted. From your log messages below, the MFC entries failed to be added to the kerner, so ip_mr_cache should be empty. Could you double-check that ip_mr_cache was empty before XORP was started, and then it was populated with the above info while XORP was running. BTW, two days ago there was an email to xorp-users from another gmail account asking about such junk values. Interestingly, the output from that person's ip_mr_cache was exactly same as yours (including the values for the Origin and Group addresses). Are you same person, or are you working together on the same experiment? > and when run xorp output is something like following > > [ 2006/05/26 12:01:59 ERROR xorp_fea:29466 MFEA +1201 mfea_mrouter.cc > add_mfc ] setsockopt(MRT_ADD_MFC, (192.168.5.10, 225.0.1.45)) failed: > Invalid argument This seems the source of the problem. For some reason, the setsockopt(MRT_ADD_MFC) has failed with error code of EINVAL. I checked the source code for your kernel version, and it appears the only reasons MRT_ADD_MFC would fail are: * The size of the "struct mfcctl mc" argument doesn't match. OR * The group address inside (mc.mfcc_mcastgrp) is not multicast. >From the log messages, the group address seems fine, so probably there is something odd with the size of "struct mfcctl" as used by XORP. From the private email exchange with your config.log output, it looks like there is some bogus /usr/include/netinet/ip_mroute.h header file installed on your system. Usually, Linux systems shouldn't have that file and should have /usr/include/linux/mroute.h instead. If that file has some bogus "struct mfcctl" definition inside, this would explain why setsockopt(MRT_ADD_MFC) fails. Please move away the bogus file, rerun ./configure and make sure that this time the configure scripts shows that IPv4 multicast routing is supported. After that run "gmake clean; gmake" to recompile XORP with the right header files. Pavlin > [ 2006/05/26 12:01:59 WARNING xorp_fea XrlMfeaTarget ] Handling method for > mfea/0.1/add_mfc4 failed: XrlCmdError 102 Command failed Cannot add MFC for > source 192.168.5.10 and group 225.0.1.45 with iif_vif_index = 1 > [ 2006/05/26 12:01:59 ERROR xorp_pimsm4:29486 PIM +1854 xrl_pim_node.cc > mfea_client_send_add_delete_mfc_cb ] Cannot add a multicast forwarding entry > with the MFEA: 102 Command failed Cannot add MFC for source 192.168.5.10 and > group 225.0.1.45 with iif_vif_index = 1 From ramu.avula at gmail.com Mon May 29 00:33:22 2006 From: ramu.avula at gmail.com (Ramu k) Date: Mon, 29 May 2006 13:03:22 +0530 Subject: [Xorp-users] IPv4 multicast routing not supported In-Reply-To: <200605261657.k4QGvfs5011808@possum.icir.org> References: <200605261657.k4QGvfs5011808@possum.icir.org> Message-ID: Hi Pavlin, Thanks a lot .......... its working now. all the problems are because of header file ip_mroute.h so i removed it compiled XORP once again. its forwarding multicast traffic now. btw does XORP will have VLAN Support in next release. Thanks once again for ur sharp replies. Ramu.K ---------- Forwarded message ---------- From: Pavlin Radoslavov Date: May 26, 2006 10:27 PM Subject: Re: [Xorp-users] IPv4 multicast routing not supported To: Ramu k Cc: Xorp-users at xorp.org, Pavlin Radoslavov > still its not forwarding . the scenario is like this. and i am attaching > config.boot > entries in /proc/net/ip_mr_cache > Group Origin Iif Pkts Bytes Wrong Oifs > 2D0100E1 0A05A8C0 65535 1 4 -559067475 > 230001E1 0A05A8C0 65535 1 4 -559067475 Interesting. From the above output it looks like the multicast forwarding entries were added to the kernel, but they seem corrupted. From your log messages below, the MFC entries failed to be added to the kerner, so ip_mr_cache should be empty. Could you double-check that ip_mr_cache was empty before XORP was started, and then it was populated with the above info while XORP was running. BTW, two days ago there was an email to xorp-users from another gmail account asking about such junk values. Interestingly, the output from that person's ip_mr_cache was exactly same as yours (including the values for the Origin and Group addresses). Are you same person, or are you working together on the same experiment? > and when run xorp output is something like following > > [ 2006/05/26 12:01:59 ERROR xorp_fea:29466 MFEA +1201 mfea_mrouter.cc > add_mfc ] setsockopt(MRT_ADD_MFC, (192.168.5.10, 225.0.1.45)) failed: > Invalid argument This seems the source of the problem. For some reason, the setsockopt(MRT_ADD_MFC) has failed with error code of EINVAL. I checked the source code for your kernel version, and it appears the only reasons MRT_ADD_MFC would fail are: * The size of the "struct mfcctl mc" argument doesn't match. OR * The group address inside (mc.mfcc_mcastgrp) is not multicast. >From the log messages, the group address seems fine, so probably there is something odd with the size of "struct mfcctl" as used by XORP. From the private email exchange with your config.log output, it looks like there is some bogus /usr/include/netinet/ip_mroute.h header file installed on your system. Usually, Linux systems shouldn't have that file and should have /usr/include/linux/mroute.h instead. If that file has some bogus "struct mfcctl" definition inside, this would explain why setsockopt(MRT_ADD_MFC) fails. Please move away the bogus file, rerun ./configure and make sure that this time the configure scripts shows that IPv4 multicast routing is supported. After that run "gmake clean; gmake" to recompile XORP with the right header files. Pavlin > [ 2006/05/26 12:01:59 WARNING xorp_fea XrlMfeaTarget ] Handling method for > mfea/0.1/add_mfc4 failed: XrlCmdError 102 Command failed Cannot add MFC for > source 192.168.5.10 and group 225.0.1.45 with iif_vif_index = 1 > [ 2006/05/26 12:01:59 ERROR xorp_pimsm4:29486 PIM +1854 xrl_pim_node.cc > mfea_client_send_add_delete_mfc_cb ] Cannot add a multicast forwarding entry > with the MFEA: 102 Command failed Cannot add MFC for source 192.168.5.10and > group 225.0.1.45 with iif_vif_index = 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060529/421a4873/attachment.html From pavlin at icir.org Mon May 29 10:42:42 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 29 May 2006 10:42:42 -0700 Subject: [Xorp-users] IPv4 multicast routing not supported In-Reply-To: Message from "Ramu k" of "Mon, 29 May 2006 13:03:22 +0530." Message-ID: <200605291742.k4THggqo057994@possum.icir.org> > its working now. all the problems are because of header file ip_mroute.h > so i removed it compiled XORP once again. > its forwarding multicast traffic now. btw does XORP will have VLAN Support > in > > next release. We are aiming to have the next release after a month or so and most likely it won't have VLAN (management) support in it. However, if you configure your VLANs before starting XORP, then XORP should be able to use them. In other words, currently XORP can use VLANs that have been preconfigured, but it cannot manage them. Pavlin From cw at zte.com.cn Mon May 29 18:32:09 2006 From: cw at zte.com.cn (cw at zte.com.cn) Date: Tue, 30 May 2006 09:32:09 +0800 Subject: [Xorp-users] I cna not start xorp_rtrmgr, ask for help Message-ID: Hi, everyone! I am a greenhand to XORP. These days I will test the IGMP function of DUT, and I'd lile to use XORP to work as the multicast router(PIM). I have installed XORP 1.2 to FC4 successfully, the kernal version is 2.6.13.5. But when I start xorp_rtrmgr, it failed. This is information of "ifconfig -a" of my linux PC. eth0 Link encap:Ethernet HWaddr 00:01:02:9A:07:72 inet addr:10.61.90.56 Bcast:10.61.91.255 Mask:255.255.252.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:14475 errors:0 dropped:0 overruns:0 frame:0 TX packets:741 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1267179 (1.2 MiB) TX bytes:89808 (87.7 KiB) Interrupt:5 Base address:0xec00 eth1 Link encap:Ethernet HWaddr 00:B0:D0:3C:CC:34 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:5 Base address:0xe480 eth2 Link encap:Ethernet HWaddr 00:30:F1:25:EB:95 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:1 dropped:0 overruns:0 carrier:2 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:10 Base address:0xac00 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:13515 errors:0 dropped:0 overruns:0 frame:0 TX packets:13515 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3409180 (3.2 MiB) TX bytes:3409180 (3.2 MiB) Then config.boot is very simple, as this: # cat simple_config.boot interfaces { interface eth0 { disable: false } interface eth1 { disable: false } interface eth2 { disable: false } } [root at caowei117998 rtrmgr]# ./xorp_rtrmgr -b simple_config.boot [ 2006/05/30 09:18:20 INFO xorp_rtrmgr:3153 RTRMGR +240 master_conf_tree.cc execute ] Changed modules: interfaces [ 2006/05/30 09:18:20 INFO xorp_rtrmgr:3153 RTRMGR +99 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2006/05/30 09:18:20 ERROR xorp_fea:3158 LIBCOMM +110 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol [ 2006/05/30 09:18:20 ERROR xorp_fea:3158 LIBCOMM +110 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol [ 2006/05/30 09:18:22 INFO xorp_rtrmgr:3153 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2006/05/30 09:18:23 INFO xorp_fea MFEA ] MFEA enabled [ 2006/05/30 09:18:23 INFO xorp_fea MFEA ] CLI enabled [ 2006/05/30 09:18:23 INFO xorp_fea MFEA ] CLI started [ 2006/05/30 09:18:23 INFO xorp_fea MFEA ] MFEA enabled [ 2006/05/30 09:18:23 INFO xorp_fea MFEA ] CLI enabled [ 2006/05/30 09:18:23 INFO xorp_fea MFEA ] CLI started /* the console no response, even I press "Enter" , wait a while,I input "Ctrl+c" */ [ 2006/05/30 09:19:44 INFO xorp_rtrmgr:3153 RTRMGR +1019 task.cc shutdown ] Shutting down module: interfaces [ 2006/05/30 09:19:44 INFO xorp_fea MFEA ] CLI stopped [ 2006/05/30 09:19:44 INFO xorp_fea MFEA ] CLI stopped [ 2006/05/30 09:19:44 ERROR xorp_fea:3158 LIBXORP +238 selector.cc remove_ioevent_cb ] Attempting to remove fd = -1 that is outside range of file descriptors 0..41 [ 2006/05/30 09:19:44 INFO xorp_rtrmgr:3153 RTRMGR +278 module_manager.cc module_exited ] Module normal exit: interfaces [ 2006/05/30 09:19:45 INFO xorp_rtrmgr:3153 RTRMGR +2228 task.cc run_task ] No more tasks to run -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. From laxmanb at intoto.com Tue May 30 02:04:28 2006 From: laxmanb at intoto.com (laxmanb at intoto.com) Date: Tue, 30 May 2006 02:04:28 -0700 (PDT) Subject: [Xorp-users] Need Clarifications on XORP FEA! Message-ID: <33772.172.16.1.19.1148979868.squirrel@webmail.intoto.com> My dear friends, I am new to this group.We are trying to use the XORP as a router in linux environment.After going throgh the XORP FEA document, we understand that the packets meant for XORP router related to OSPF/RIP will be given to FEA module directly from the stack.Is this understanding correct?Or do we need to register any FEA hooks to get OSPF/RIP packets from the stack? i appreciate if any body from this group clarify my doubts. Thanks in advance. Laxman From mhorn at vyatta.com Tue May 30 07:30:57 2006 From: mhorn at vyatta.com (Mike Horn) Date: Tue, 30 May 2006 08:30:57 -0600 Subject: [Xorp-users] I cna not start xorp_rtrmgr, ask for help In-Reply-To: Message-ID: <01f201c683f5$aab3e3e0$0f02a8c0@caddisconsulting.com> Hi CW, The XORP process did not actually fail, it was running until you entered CRTL-C. Since you did not start the process as a background process it was running in the console window where you entered the "xorp_rtrmgr" command. To enter the XORP CLI from another terminal window enter "xorpsh" (this is located in the same directory as xorp_rtrmgr). You will need to re-run "xorp_rtrmgr" first, since the CTRL-C killed it. Also, in order to be able to enter configuration mode in the XORP CLI the user account that is logged in will need to be in group xorp. You should see something like: [mhorn at fedora rtrmgr]$ ./xorpsh Welcome to XORP on fedora mhorn at fedora> The error message you see is similar to another one that someone else is seeing, I'll make sure to CC you on the response for that issue. -mike -----Original Message----- From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of cw at zte.com.cn Sent: Monday, May 29, 2006 7:32 PM To: xorp-users at xorp.org Subject: [Xorp-users] I cna not start xorp_rtrmgr, ask for help Hi, everyone! I am a greenhand to XORP. These days I will test the IGMP function of DUT, and I'd lile to use XORP to work as the multicast router(PIM). I have installed XORP 1.2 to FC4 successfully, the kernal version is 2.6.13.5. But when I start xorp_rtrmgr, it failed. This is information of "ifconfig -a" of my linux PC. eth0 Link encap:Ethernet HWaddr 00:01:02:9A:07:72 inet addr:10.61.90.56 Bcast:10.61.91.255 Mask:255.255.252.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:14475 errors:0 dropped:0 overruns:0 frame:0 TX packets:741 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1267179 (1.2 MiB) TX bytes:89808 (87.7 KiB) Interrupt:5 Base address:0xec00 eth1 Link encap:Ethernet HWaddr 00:B0:D0:3C:CC:34 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:5 Base address:0xe480 eth2 Link encap:Ethernet HWaddr 00:30:F1:25:EB:95 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:1 dropped:0 overruns:0 carrier:2 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:10 Base address:0xac00 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:13515 errors:0 dropped:0 overruns:0 frame:0 TX packets:13515 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3409180 (3.2 MiB) TX bytes:3409180 (3.2 MiB) Then config.boot is very simple, as this: # cat simple_config.boot interfaces { interface eth0 { disable: false } interface eth1 { disable: false } interface eth2 { disable: false } } [root at caowei117998 rtrmgr]# ./xorp_rtrmgr -b simple_config.boot [ 2006/05/30 09:18:20 INFO xorp_rtrmgr:3153 RTRMGR +240 master_conf_tree.cc execute ] Changed modules: interfaces [ 2006/05/30 09:18:20 INFO xorp_rtrmgr:3153 RTRMGR +99 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2006/05/30 09:18:20 ERROR xorp_fea:3158 LIBCOMM +110 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol [ 2006/05/30 09:18:20 ERROR xorp_fea:3158 LIBCOMM +110 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol [ 2006/05/30 09:18:22 INFO xorp_rtrmgr:3153 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2006/05/30 09:18:23 INFO xorp_fea MFEA ] MFEA enabled [ 2006/05/30 09:18:23 INFO xorp_fea MFEA ] CLI enabled [ 2006/05/30 09:18:23 INFO xorp_fea MFEA ] CLI started [ 2006/05/30 09:18:23 INFO xorp_fea MFEA ] MFEA enabled [ 2006/05/30 09:18:23 INFO xorp_fea MFEA ] CLI enabled [ 2006/05/30 09:18:23 INFO xorp_fea MFEA ] CLI started /* the console no response, even I press "Enter" , wait a while,I input "Ctrl+c" */ [ 2006/05/30 09:19:44 INFO xorp_rtrmgr:3153 RTRMGR +1019 task.cc shutdown ] Shutting down module: interfaces [ 2006/05/30 09:19:44 INFO xorp_fea MFEA ] CLI stopped [ 2006/05/30 09:19:44 INFO xorp_fea MFEA ] CLI stopped [ 2006/05/30 09:19:44 ERROR xorp_fea:3158 LIBXORP +238 selector.cc remove_ioevent_cb ] Attempting to remove fd = -1 that is outside range of file descriptors 0..41 [ 2006/05/30 09:19:44 INFO xorp_rtrmgr:3153 RTRMGR +278 module_manager.cc module_exited ] Module normal exit: interfaces [ 2006/05/30 09:19:45 INFO xorp_rtrmgr:3153 RTRMGR +2228 task.cc run_task ] No more tasks to run -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. _______________________________________________ Xorp-users mailing list Xorp-users at xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From mhorn at vyatta.com Tue May 30 07:39:56 2006 From: mhorn at vyatta.com (Mike Horn) Date: Tue, 30 May 2006 08:39:56 -0600 Subject: [Xorp-users] IPv4 multicast routing not supported In-Reply-To: <200605291742.k4THggqo057994@possum.icir.org> Message-ID: <01f301c683f6$ec3445c0$0f02a8c0@caddisconsulting.com> Hi Ramu, You can also check out the Vyatta distribution of XORP, which includes CLI support for VLAN. We do not currently have multicast enabled, but that will be enabled in a future release. Basically Vyatta is a distribution of XORP, where Vyatta has added things like DHCP server, VRRP, a GUI interface, etc. to the base XORP distribution (the Vyatta code is also open source). These additional features are targeted at users that want to deploy an open source router in a production environment. www.vyatta.com -mike -----Original Message----- From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Pavlin Radoslavov Sent: Monday, May 29, 2006 11:43 AM To: Ramu k Cc: Xorp-users at xorp.org; Pavlin Radoslavov Subject: Re: [Xorp-users] IPv4 multicast routing not supported > its working now. all the problems are because of header file > ip_mroute.h so i removed it compiled XORP once again. > its forwarding multicast traffic now. btw does XORP will have VLAN > Support in > > next release. We are aiming to have the next release after a month or so and most likely it won't have VLAN (management) support in it. However, if you configure your VLANs before starting XORP, then XORP should be able to use them. In other words, currently XORP can use VLANs that have been preconfigured, but it cannot manage them. Pavlin _______________________________________________ Xorp-users mailing list Xorp-users at xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Tue May 30 11:48:21 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 30 May 2006 11:48:21 -0700 Subject: [Xorp-users] Need Clarifications on XORP FEA! In-Reply-To: Message from laxmanb@intoto.com of "Tue, 30 May 2006 02:04:28 PDT." <33772.172.16.1.19.1148979868.squirrel@webmail.intoto.com> Message-ID: <200605301848.k4UImLNr069699@possum.icir.org> > I am new to this group.We are trying to use the XORP as a > router in linux environment.After going throgh the XORP FEA > document, we understand that the packets meant for XORP > router related to OSPF/RIP will be given to FEA module > directly from the stack.Is this understanding correct?Or do > we need to register any FEA hooks to get OSPF/RIP packets > from the stack? Your process needs to explicitly register with the FEA to receive control packets. To register for receiving raw packets (e.g., OSPF IPv4 packets for example), you need to use the raw_packet4/0.1/register_receiver XRL (see file xrl/interfaces/fea_rawpkt4.xif) to register with the FEA, and then use the raw_packet4/0.1/join_multicast_group XRL to join the appropriate multicast group(s). In addition, your process must implement the raw_packet4_client/0.1 XRL interface (see file xrl/interfaces/fea_rawpkt4_client.xif) to handle the receiving of the packets. To send raw packets you need to use the raw_packet4/0.1/send XRL (see file file xrl/interfaces/fea_rawpkt4.xif). See files ospf/xrl_io.hh and ospf/xrl_io.cc for examples. To receive UDP packets (e.g., RIP IPv4 packets), you need to do something similar, except that the XRL interface is different. To open an UDP socket (via the FEA), you need to use one of the udp_onen_* XRLs described inside xrl/interfaces/socket4.xif, and then (optionally) use the udp_join_group XRL to join a multicast group on that socket. Then you process must implement the socket4_user/0.1 (see file xrl/interfaces/socket4_user.xif) to handle the receiving of the packets. To send UDP packets you need to use one of the socket4/0.1/send* XRLs (see file xrl/interfaces/socket4.xif). See files rip/xrl_target_rip.hh and rip/xrl_target_rip.cc for examples. Hope that helps, Pavlin From c-otto at gmx.de Wed May 31 05:16:28 2006 From: c-otto at gmx.de (Carsten Otto) Date: Wed, 31 May 2006 14:16:28 +0200 Subject: [Xorp-users] Cand-RP is ignored In-Reply-To: <20060525161222.GC21454@localhost.halifax.rwth-aachen.de> References: <20060525110949.GA21454@localhost.halifax.rwth-aachen.de> <200605251545.k4PFjRUF073697@possum.icir.org> <20060525161222.GC21454@localhost.halifax.rwth-aachen.de> Message-ID: <20060531121628.GA28188@localhost.halifax.rwth-aachen.de> The problem is solved with the latest stable release (1.2). Ciao, -- Carsten Otto c-otto at gmx.de www.c-otto.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20060531/0f6c0108/attachment.bin