From ganeshreddyk at gmail.com Fri Mar 2 06:27:50 2012 From: ganeshreddyk at gmail.com (Ganesh Reddy K) Date: Fri, 2 Mar 2012 19:57:50 +0530 Subject: [Xorp-users] Regarding pimsm4 and igmp protocols configuration. Message-ID: Hi, I have installed XORP on a PC. Below is the configuration. >From H1 i am sending Multicast UDP traffic (DIP is 239.11.11.12) On H2 i subscribed (IGMP JOIN) to the same Group using a utility and waiting for the stream to receive.. In summary i have enabled IGMP protocol configuration on both the interfaces of PC. pimsm configuration is disabled for the same. After starting UDP stream on H1 and Subcription from H2, i am unable to see the stream on H2 side. I verified in the XORP show configuration that, JOIN to the group 239.11.11.12 is registered properly. But Dataflow has not been established. The multicast route is verified in /proc/net/ip_mr_cache also. The route is not completely formed. OutIface is given as -1 only. Is the configuration correct ? What should be the expected behavior ? H1 --------- eth1 PC (XORP) eth0 ------- H2 ======================================== BEGIN interfaces { restore-original-config-on-shutdown: false interface eth0{ disable: false default-system-config } interface eth1{ disable: false default-system-config } } fea { unicast-forwarding4 { disable: false } unicast-forwarding6 { 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 } } interface eth1 { vif eth1 { 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 } } } } protocols { pimsm4 { disable: false interface eth0 { vif eth0 { disable: true dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } interface eth1 { vif eth1 { disable: true dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } interface register_vif { vif register_vif { disable: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } static-rps { } bootstrap{ disable: false cand-bsr { } cand-rp { } } switch-to-spt-threshold{ disable: true interval: 100 bytes: 102400 } traceoptions{ flag all{ disable: false } } } } plumbing { mfea4 { disable: false interface eth0{ vif eth0{ disable: false } } interface eth1{ vif eth1{ disable: false } } interface register_vif { vif register_vif { disable: false } } traceoptions{ flag all{ disable: false } } } } protocols { fib2mrib { disable: false } } ======================================== END -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120302/655f7457/attachment.html From vvm at tut.by Mon Mar 19 09:20:02 2012 From: vvm at tut.by (Victor Miasnikov) Date: Mon, 19 Mar 2012 19:20:02 +0300 Subject: [Xorp-users] What exactly wrong in policy-statement bgp_out / bgp_in? This settings work fine with OSPF . . . Fw: XORP on Windows 8 -- OSPF and BGP Message-ID: <22F9C8892D3E4B248A57911EE22BAF51@local.st.by> Hi! After some changes ( see .diff) I'm see in log: === ... [ 2012/3/19 13:56:54.305000 ERROR ..\lib\xorp\sbin\xorp_bgp.exe:4764 BGP bgp/xrl_target.cc:418 bgp_0_3_change_local_ip ] local ip 10.99.93.77 local port 179 peer ip 10.99.93.123 peer port 179 new_local_ip 10.99.93.77 new_local_dev: [ 2012/3/19 13:56:54.306000 ERROR ..\lib\xorp\sbin\xorp_bgp.exe:4764 BGP bgp/xrl_target.cc:418 bgp_0_3_change_local_ip ] local ip 10.99.93.77 local port 179 peer ip 10.99.93.123 peer port 179 new_local_ip 10.99.93.77 new_local_dev: [ 2012/3/19 13:56:54.316000 WARNING ..\lib\xorp\sbin\xorp_policy.exe:3772 XrlPolicyTarget obj/i386-pc-mingw32/xrl/targets/policy_base.cc:1601 handle_policy_0_1_import ] Handling method for policy/0.1/import failed: XrlCmdError 102 Command failed Import of bgp failed: sem_error from line 278 of policy/visitor_semantic.cc: May not define protocol for import policy at line 1 [ 2012/3/19 13:56:54.317000 ERROR xorp_rtrmgr.exe:2256 RTRMGR rtrmgr/master_conf_tree.cc:700 commit_pass2_done ] Commit failed: 102 Command failed Import of bgp failed: sem_error from line 278 of policy/visitor_semantic.cc: May not define protocol for import policy at line 1 [ 2012/3/19 13:56:54.317000 ERROR xorp_rtrmgr.exe:2256 RTRMGR rtrmgr/master_conf_tree.cc:269 config_done ] Configuration failed: 102 Command failed Import of bgp failed: sem_error from line 278 of policy/visitor_semantic.cc: May not define protocol for import policy at line 1 ... === what exactly wrong in term 10 { term 20 { term 30 { of policy-statement bgp_out policy-statement bgp_in ? This settings work fine with OSPF . . . .diff : == --- config.boot-Ok-OSPF_and_BGP Public ##.txt Mon Mar 19 18:51:40 2012 +++ config.boot-With_Errors-OSPF_and_BGP Public ##.txt Mon Mar 19 18:55:09 2012 @@ -217,7 +217,8 @@ */ policy { policy-statement bgp_out { -/* +/* { */ + term 10 { from { protocol: "connected" @@ -248,7 +249,7 @@ } } } -*/ +/* } */ term 98 { from { protocol: "static" @@ -272,7 +273,7 @@ } policy-statement bgp_in { -/* +/* { */ term 10 { from { protocol: "connected" @@ -303,7 +304,7 @@ } } } -*/ +/* } */ term 99 { from { } == _Worked_ config: == /*XORP Configuration File, v1.0*/ fea { unicast-forwarding4 { disable: false /* { * / forwarding-entries { retain-on-startup: true retain-on-shutdown: true } / * } */ } } interfaces { restore-original-config-on-shutdown: true /* =========================================================================== Interface List 16...e0 69 95 98 9c 92 ......ZZZZZZZ ZZZZZZ PCI-E Gigabit Ethernet Controller (NDIS 6.30) - ZZZZZZZ ZZZZZZ 1...........................Software Loopback Interface 1 13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter =========================================================================== Iface name: dc0 idx: 16 iftree: system-config oper-status: 1 Iface name: Loopback Pseudo-Interface 1 idx: 1 iftree: system-config oper-status: 1 Iface name: isatap.local.st.by idx: 13 iftree: system-config oper-status: 2 @VVMComp> show interfaces Software Loopback Interface 1: Flags:<> mtu 0 speed unknown physical index 0 dc0/dc0: Flags: mtu 1500 speed unknown inet 10.99.93.77 subnet 10.99.93.0/24 broadcast 10.99.93.255 physical index 16 ether e0:69:95:a8:ac:92 isatap.local.st.by/isatap.local.st.by: Flags: mtu 1280 speed unknown */ /* =========================================================================== Interface List 16...e0 69 95 98 9c 92 ......ZZZZZZZ ZZZZZZ PCI-E Gigabit Ethernet Controller (NDIS 6.30) - ZZZZZZZ ZZZZZZ =========================================================================== */ /* Iface name: dc0 idx: 16 iftree: system-config oper-status: 1 @VVMComp> show interfaces dc0/dc0: Flags: mtu 1500 speed unknown inet 10.99.93.77 subnet 10.99.93.0/24 broadcast 10.99.93.255 physical index 16 ether e0:69:95:98:9c:92 */ interface lo0 { disable: false discard: false description: "MS LoopBack Adapter -- Windows 8" default-system-config } interface dc0 { description: "dc0 LanCard" disable: false discard: false default-system-config /* unreachable: false management: false vif dc0 { disable: false address 10.99.93.77 { prefix-length: 24 disable: false } } */ } /* =========================================================================== Interface List 1...........................Software Loopback Interface 1 =========================================================================== */ /* Iface name: Loopback Pseudo-Interface 1 idx: 1 iftree: system-config oper-status: 1 @VVMComp> show interfaces Software Loopback Interface 1: Flags:<> mtu 0 speed unknown physical index 0 */ interface "Software Loopback Interface 1" { disable: false discard: false description: "MS TCP Loopback interface -- Windows 8" default-system-config } /* =========================================================================== Interface List 13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter =========================================================================== Iface name: isatap.local.st.by idx: 13 iftree: system-config oper-status: 2 == @VVMComp> show interfaces isatap.local.st.by/isatap.local.st.by: Flags: mtu 1280 speed unknown == */ interface "isatap.local.st.by" { disable: false discard: false description: "Microsoft ISATAP Adapter -- Windows 8" default-system-config } } protocols { /* fib2mrib { disable: true } */ static { disable: false route 10.101.23.0/24 { next-hop: 10.99.93.254 metric: 201 } route 10.101.22.0/24 { next-hop: 10.99.93.254 metric: 201 } route 10.101.30.0/24 { next-hop: 10.99.93.254 metric: 201 } route 0.0.0.0/0 { next-hop: 10.99.93.254 metric: 60 } } /* { */ ospf4 { router-id: 10.99.93.77 rfc1583-compatibility: false ip-router-alert: false area 0.0.0.10 { area-type: "normal" default-lsa { disable: false metric: 0 } interface dc0 { link-type: "broadcast" vif dc0 { address 10.99.93.77 { priority: 255 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 retransmit-interval: 5 transit-delay: 1 authentication { simple-password: "pa$$w0rd" } disable: false } } } } export: "Route_Export" } /* } */ /* { */ bgp { export: "bgp_out" import: "bgp_in" bgp-id: 10.99.93.77 local-as: 65001 peer 10.99.93.123 { local-ip: 10.99.93.77 as: 65002 next-hop: 10.99.93.77 } } /* } */ } /* policy { policy-statement connected { term export { from { protocol: "connected" } } } policy-statement static { term export { from { protocol: "static" } } } } */ policy { policy-statement bgp_out { /* term 10 { from { protocol: "connected" network4-list: "Default_Route" } then { reject { } } } term 20 { from { protocol: "connected" network4-list: "No_Advertise" } then { reject { } } } term 30 { from { protocol: "connected" prefix-length4 < 32..32 } then { accept { } } } */ term 98 { from { protocol: "static" } then { accept } } term 99 { from { protocol: "bgp" } then { accept } } then { reject { } } } policy-statement bgp_in { /* term 10 { from { protocol: "connected" network4-list: "Default_Route" } then { reject { } } } term 20 { from { protocol: "connected" network4-list: "No_Advertise" } then { reject { } } } term 30 { from { protocol: "connected" prefix-length4 < 32..32 } then { accept { } } } */ term 99 { from { } then { accept } } then { reject { } } } policy-statement "Route_Export" { term 10 { from { protocol: "connected" network4-list: "Default_Route" } then { reject { } } } term 20 { from { protocol: "connected" network4-list: "No_Advertise" } then { reject { } } } term 30 { from { protocol: "connected" prefix-length4 < 32..32 } then { accept { } } } then { reject { } } } network4-list "No_Advertise" { network 127.0.0.0/8 { modifier: "orlonger" } /* network 10.0.0.0/8 { modifier: "orlonger" } */ network 172.16.0.0/12 { modifier: "orlonger" } network 192.168.0.0/16 { modifier: "orlonger" } } network4-list "Default_Route" { network 0.0.0.0/0 } } /* rtrmgr { config-directory: "" load-file-command: "fetch" load-file-command-args: "-o" load-ftp-command: "fetch" load-ftp-command-args: "-o" load-http-command: "fetch" load-http-command-args: "-o" load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" load-tftp-command-args: "" save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-file-command-args: "" save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-ftp-command-args: "" save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-http-command-args: "" save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-tftp-command-args: "" } */ == Best regards, Victor Miasnikov Blog: http://vvm.blog.tut.by/ From vvm at tut.by Tue Mar 20 04:27:30 2012 From: vvm at tut.by (Victor Miasnikov) Date: Tue, 20 Mar 2012 14:27:30 +0300 Subject: [Xorp-users] What exactly wrong in policy-statement bgp_out / bgp_in? This settings work fine with OSPF . . . Fw: XORP on Windows 8 -- OSPF and BGP Message-ID: Hi! > what exactly wrong in > > term 10 { > term 20 { > term 30 { > > of > > > policy-statement bgp_out > policy-statement bgp_in > > > ? This policy-statement bgp_out work Ok: == . . . policy { policy-statement bgp_out { /* { */ term 10 { from { protocol: "connected" network4-list: "Default_Route" } then { reject { } } } term 20 { from { protocol: "connected" network4-list: "No_Advertise" } then { reject { } } } term 30 { from { protocol: "connected" prefix-length4 < 32..32 } then { accept { } } } /* } */ term 98 { from { protocol: "static" } then { accept } } term 99 { from { protocol: "bgp" } then { accept } } then { reject { } } } . . . == How about policy-statement bgp_in ? Best regards, Victor Miasnikov Blog: http://vvm.blog.tut.by/ From swdickey at rockwellcollins.com Thu Mar 22 07:52:15 2012 From: swdickey at rockwellcollins.com (swdickey at rockwellcollins.com) Date: Thu, 22 Mar 2012 10:52:15 -0400 Subject: [Xorp-users] Route Redist between RIP and OSPF - working? Message-ID: Hi Xorp Users, I am trying to get some simple route redistribution going between OSPF and RIP. Setup: OSPF RIP Xorp1 [30.1] - - - - - - [30.2] Xorp2 [40.1] - - - - - - [40.2] Xorp3 What I am seeing is that on Xorp2 the RIP will send out Response messages with its routes' metric set to 16 (infinite) when OSPF is running on Xorp2 (the bridge node). After playing with the config file on Xorp2 it seems OSPF just has to be a configured protocol on the router, it doesnt even have to be enabled on an interface. All the routes that Xorp2 will send out will be metric 16, even the connected routes. The OSPF seems to be fine, just a RIP problem happening. Has anyone else run with a similar setup? I don't see much information out there about policytags - is that a possible solution? Has anyone any config files that they could send me that have successfully worked for route redist between OSPF and RIP? I'm not sure, but this could be related to issue others have raised: http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2008-September/002774.html http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2008-September/002773.html Thanks guys, Steve Dickey swdickey at rockwellcollins.com Xorp2 config file: /* $XORP$ */ interfaces { interface "eth4" { disable: false default-system-config } interface "eth5" { disable: false default-system-config } } fea { unicast-forwarding4 { disable: false } } protocols { ospf4 { router-id: 192.168.30.2 export: "connected,rip" area 0.0.0.0 { interface "eth4" { vif "eth4" { address 192.168.30.2 { hello-interval: 10 router-dead-interval: 40 interface-cost: 100 disable: false } } } } } rip { export: "export-connected,ospf" interface "eth5" { vif "eth5" { address 192.168.40.1 { metric: 1 horizon: "split-horizon-poison-reverse" disable: false passive: false accept-non-rip-requests: true accept-default-route: false route-timeout: 180 deletion-delay: 120 triggered-delay: 3 triggered-jitter: 66 update-interval: 30 update-jitter: 16 request-interval: 30 interpacket-delay: 50 } } } } } policy { policy-statement export-connected { term 100 { from { protocol: "connected" } } } } policy { policy-statement connected { term export { from { protocol: "connected" } } } } policy { policy-statement rip { term export { from { protocol: "rip" } } } } policy { policy-statement ospf { term export { from { protocol: "ospf4" } } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120322/3c695a53/attachment.html From vvm at tut.by Thu Mar 22 09:43:14 2012 From: vvm at tut.by (Victor Miasnikov) Date: Thu, 22 Mar 2012 19:43:14 +0300 Subject: [Xorp-users] Route Redist between RIP and OSPF - working? References: Message-ID: Hi! > route redistribution going between OSPF and RIP. I'm try reproduce this on stend with XORP on Windows . . . Best regards, Victor Miasnikov Blog: http://vvm.blog.tut.by/ From david at commroom.net Fri Mar 23 19:13:28 2012 From: david at commroom.net (David Davidson) Date: Fri, 23 Mar 2012 19:13:28 -0700 Subject: [Xorp-users] Route Redist between RIP and OSPF - working? In-Reply-To: References: Message-ID: <4F6D2DC8.8020509@commroom.net> Hey Steve: I concur. I reproduced this in a lab and I see the same problem. On my core router, AKA 192.168.30.1 and also addressed as 192.168.40.1, (I prefer to use "core router" for my xorp2 node - I don't use the term "bridge node" for this router - this could possibly be misconstrued by some for a L2 bridge) I have the following configuration: ######################################################################################### cat /etc/xorp/config /* XORP configuration file * * Configuration format: 1.1 * XORP version: 1.8.5 * Date: 2012/03/23 18:32:01.840943 * User: root */ protocols { ospf4 { router-id: 192.168.30.2 rfc1583-compatibility: false ip-router-alert: false area 0.0.0.0 { area-type: "normal" interface eth0 { link-type: "broadcast" vif eth0 { address 192.168.30.2 { priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 retransmit-interval: 5 transit-delay: 1 disable: false } } } } export: "EXPORT-OSPF-SIDE" } rip { interface eth1 { vif eth1 { address 192.168.40.1 { metric: 1 horizon: "split-horizon-poison-reverse" disable: false passive: false accept-non-rip-requests: true accept-default-route: true advertise-default-route: true route-timeout: 180 deletion-delay: 120 triggered-delay: 3 triggered-jitter: 66 update-interval: 30 update-jitter: 16 request-interval: 30 interpacket-delay: 50 } } } export: "EXPORT-RIP-SIDE" } } policy { policy-statement "EXPORT-RIP-SIDE" { term 1 { from { protocol: "connected" } then { accept { } } } term 2 { from { protocol: "ospf4" } then { accept { } } } term 3 { then { reject { } } } } policy-statement "EXPORT-OSPF-SIDE" { term 1 { from { protocol: "connected" } then { accept { } } } term 2 { from { protocol: "rip" } then { accept { } } } term 3 { then { reject { } } } } } fea { unicast-forwarding4 { disable: false } } interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "" disable: false discard: false unreachable: false management: false parent-ifname: "" iface-type: "" vid: "" vif eth0 { disable: false address 192.168.30.2 { prefix-length: 24 disable: false } } } interface eth1 { description: "" disable: false discard: false unreachable: false management: false parent-ifname: "" iface-type: "" vid: "" vif eth1 { disable: false address 192.168.40.1 { prefix-length: 24 disable: false } } } } ######################################################################################### And using this, I have the exact same issue you described. I should also note that I tried the policy configuration using both ways, including creating a separate policy for connected nodes, and then exporting both policies. Both configurations produced the same result that you described: The OSPF routes are in fact exported into the RIP and then they are learned by the RIP routers, but the OSPF routers don't learn about the RIP routes, and hence, don't have routes to the routers running RIP. I agree with you - I think this perhaps a RIP issue because there is something weird about the RIP protocol related to this topology. I am going to do some more work on this and if I find anything different, I will report it out and let you know. Good find! David On 03/22/2012 07:52 AM, swdickey at rockwellcollins.com wrote: > Hi Xorp Users, > > I am trying to get some simple route redistribution going between OSPF > and RIP. > > Setup: > > OSPF > RIP > Xorp1 [30.1] - - - - - - [30.2] Xorp2 [40.1] - - - - - - [40.2] Xorp3 > > > What I am seeing is that on Xorp2 the RIP will send out Response > messages with its routes' metric set to 16 (infinite) when OSPF is > running on Xorp2 (the bridge node). After playing with the config > file on Xorp2 it seems OSPF just has to be a configured protocol on > the router, it doesnt even have to be enabled on an interface. All > the routes that Xorp2 will send out will be metric 16, even the > connected routes. The OSPF seems to be fine, just a RIP problem > happening. > > Has anyone else run with a similar setup? I don't see much > information out there about policytags - is that a possible solution? > Has anyone any config files that they could send me that have > successfully worked for route redist between OSPF and RIP? > > I'm not sure, but this could be related to issue others have raised: > _http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2008-September/002774.html_ > _http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2008-September/002773.html_ > > Thanks guys, > > Steve Dickey > swdickey at rockwellcollins.com > > > > Xorp2 config file: > > /* $XORP$ */ > interfaces { > interface "eth4" { > disable: false > default-system-config > } > interface "eth5" { > disable: false > default-system-config > } > } > fea { > unicast-forwarding4 { > disable: false > } > } > protocols { > ospf4 { > router-id: 192.168.30.2 > export: "connected,rip" > area 0.0.0.0 { > interface "eth4" { > vif "eth4" { > address 192.168.30.2 { > hello-interval: 10 > router-dead-interval: 40 > interface-cost: 100 > disable: false > } > } > } > } > } > rip { > export: "export-connected,ospf" > interface "eth5" { > vif "eth5" { > address 192.168.40.1 { > metric: 1 > horizon: > "split-horizon-poison-reverse" > disable: false > passive: false > accept-non-rip-requests: true > accept-default-route: false > route-timeout: 180 > deletion-delay: 120 > triggered-delay: 3 > triggered-jitter: 66 > update-interval: 30 > update-jitter: 16 > request-interval: 30 > interpacket-delay: 50 > } > } > } > } > } > policy { > policy-statement export-connected { > term 100 { > from { > protocol: "connected" > } > } > } > } > policy { > policy-statement connected { > term export { > from { > protocol: "connected" > } > } > } > } > policy { > policy-statement rip { > term export { > from { > protocol: "rip" > } > } > } > } > policy { > policy-statement ospf { > term export { > from { > protocol: "ospf4" > } > } > } > } > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120323/fdac68f3/attachment-0001.html From david at commroom.net Sun Mar 25 09:41:24 2012 From: david at commroom.net (David Davidson) Date: Sun, 25 Mar 2012 09:41:24 -0700 Subject: [Xorp-users] Fwd: Re: Route Redist between RIP and OSPF - working? In-Reply-To: <4F6D2DC8.8020509@commroom.net> References: <4F6D2DC8.8020509@commroom.net> Message-ID: <4F6F4AB4.7070106@commroom.net> Hey Steve: There was one thing I forgot to mention: my connected routes (exported VIA policy) seemed to work okay on the OSPF side; so I should back-pedal a little and say that my results weren't >exactly< like yours because my connected routes were injected into OSPF, just the RIP routes were not. Hence, I am going to explain what I think you might try out below. Please read on... I tested this with 5 routers instead of 3. I added a router xorp4, connected to another interface on xorp3 using 10.0.0.1/24 on xorp3 and 10.0.0.2/24 on this xorp4, also using RIP so I can see how the RIP routes from further away would behave. Likewise, I added a xorp5 router on the OSPF side, connected to xorp1 using a 172.16.1.1/24 on xorp1 and 172.16.1.2/24 on xorp5, here again so I could see how the ospf routes from further away behaved. For better clarity, I have attached a text document which documents the configuration for each of the 5 routers. The core router, xorp2, is where I have tried to implement the RIP and OSPF policies. Back to the issue, so I think this might have something to do with the way the XORP developers decided to implement the RIP protocol, and/or maybe just the RIP export policies. Some network vendors are different in the way they implement export policies, and also what gets exported by default (if anything at all). For example, I believe that at least one network vendor's default export policy for RIP, whose syntax is very similar to that of XORP's, for RIP, is not to export ANYTHING at all, by default (RIP export policy: "reject everything" by default, per at least one official document I have here). Perhaps the XORP developers also intended this to be the same way on the RIP implementation for XORP, or its RIP export policies under XORP. Please let me know if this works: Go ahead and assign a "connected" policy export on your xorp3 router (40.2). For example, I added this to my xorp3 router in this particular lab: configure exclusive set policy policy-statement RIPCON term 1 from protocol connected set policy policy-statement RIPCON term 1 then accept set protocols rip export RIPCON commit What do you think? Did that do the trick? This worked for me. After I added that policy to xorp3, the OSPF router on the left (xorp1) learns about the RIP routes and vice-versa (my rip routers on the right, xorp3, learn about the OSPF routes, but this was already happening before anyway). If that worked, then also, consider, if you had other routers upstream RIP routers from xorp3 (like here in the lab I did, I have a xorp5 RIP router connected to xorp3, like I mentioned above) then you would add RIP also and then use a policy like this one instead: configure exclusive set policy policy-statement RIPCON-and-RIP term 1 from protocol connected set policy policy-statement RIPCON-and-RIP term 1 then accept set policy policy-statement RIPCON-and-RIP term 2 from protocol rip set policy policy-statement RIPCON-and-RIP term 2 then accept set policy policy-statement RIPCON-and-RIP term 3 then reject set protocols rip export RIPCON-and-RIP commit These worked for me. If they work for you, then my bet is - this implementation closely follows the RIP export policies like some of the other network vendors out there that have similarly implemented RIP export policies and defaults for export policies (i.e. by default, reject all on RIP export policies). David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120325/9fa77a60/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: steves_lab_on_xorp.txt Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120325/9fa77a60/attachment.txt From david at commroom.net Sun Mar 25 10:04:42 2012 From: david at commroom.net (David Davidson) Date: Sun, 25 Mar 2012 10:04:42 -0700 Subject: [Xorp-users] Fwd: Fwd: Re: Route Redist between RIP and OSPF - working? In-Reply-To: <4F6F4AB4.7070106@commroom.net> References: <4F6F4AB4.7070106@commroom.net> Message-ID: <4F6F502A.6040702@commroom.net> Hey folks, Please ignore the last attachment - I had the router numbers mis-numbered. This attachment is a corrected version. The configurations were correct, but the routers were numbered wrong. This one is the correct one. Sorry for the error. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: steves_lab_on_xorp.txt Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120325/71dce474/attachment.txt From david at commroom.net Sun Mar 25 11:19:04 2012 From: david at commroom.net (David Davidson) Date: Sun, 25 Mar 2012 11:19:04 -0700 Subject: [Xorp-users] Fwd: Fwd: Fwd: Re: Route Redist between RIP and OSPF - working? In-Reply-To: <4F6F502A.6040702@commroom.net> References: <4F6F502A.6040702@commroom.net> Message-ID: <4F6F6198.8010103@commroom.net> Ahhhhh grrr there is still an issue. I will keep testing this and let you know if I find something. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120325/0e5a292d/attachment.html From aidan at highrise.ca Sun Mar 25 17:44:37 2012 From: aidan at highrise.ca (Aidan Van Dyk) Date: Sun, 25 Mar 2012 20:44:37 -0400 Subject: [Xorp-users] Fwd: Fwd: Fwd: Re: Route Redist between RIP and OSPF - working? In-Reply-To: <4F6F6198.8010103@commroom.net> References: <4F6F502A.6040702@commroom.net> <4F6F6198.8010103@commroom.net> Message-ID: So, it seems like many of us have hit this issue in one way or an other. I did some experiments with it, and I found that as long as I didn't "export:" *AT ALL* in the protocol ospf section, I could manipulate rip exports just fine with policies. I could export any routes from static, or from other protocols, or from connected, filter on anything, etc. But, what I saw was that as soon as OSPF was exporting any policy (even if they were completely seperate policies, completely sepeate selections, i.e mutually exclusive), all the routes were pulled from rip (deleted in the rib->rip redist, then flooded out via RIP with metric 16, and then stopped. So, since OSPF takes longer to "start up", and rip started quickly, I acutally found that rip would start, and start advertising connected (because my policy was for it to do that), and ospf would be starting, and as soon as ospf came up (and as long as I had an export policy in the ospf protocol), the routes would get pulled from rip. If ospf came up with no export in it's protocol section, then the routes wouldn't be removed from rip. So it seems like it's something in the policy that only happens once OSPF actually uses it. But I haven't dug into any of the policy code/implementation so yet. And I haven't been able to see if it happens with any other pairs of protocols, OSPF and RIP are the only ones I've played with so far... On Sun, Mar 25, 2012 at 2:19 PM, David Davidson wrote: > Ahhhhh grrr there is still an issue. I will keep testing this and let you > know if I find something. > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > -- Aidan Van Dyk ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Create like a god, aidan at highrise.ca ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? command like a king, http://www.highrise.ca/ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? work like a slave. From david at commroom.net Sun Mar 25 20:09:07 2012 From: david at commroom.net (David Davidson) Date: Sun, 25 Mar 2012 20:09:07 -0700 Subject: [Xorp-users] Route Redist between RIP and OSPF - working? In-Reply-To: References: <4F6F502A.6040702@commroom.net> <4F6F6198.8010103@commroom.net> Message-ID: <4F6FDDD3.7060809@commroom.net> Thank you for your testing and your report. it seems to me that you did find something anomalous related to the OSPF export policies that seem to affect RIP routes. It seems like somebody should look into that a little further and maybe we could help to discover why that behavior is going on. I would be open to helping or testing if anyone wants more volunteers to try to get to the bottom of it. Steve was right - connected routes aren't working in some cases also. I finally did figure out a way to solve it, for this scenario. I still think that there is an issue because this was a little convoluted and this was very tricky and it seems like too much clever work for exporting routes. The thing I noticed was this: I was able to export OSPF routes into RIP, and RIP routers would see those OSPF routes. I was also able to export RIP routes into OSPF, and the OSPF routers would correctly see those RIP routes. What wasn't happening in this scenario was this problem: Routes that were learned via "CONNECTED" protocol were NOT necessarily injected back into either protocol on the OSPF side. For example, had I written the export policies like so: Policy A (to be exported into the RIP domain): 1. if proto=connected then accept 2. if proto=ospf then accept and: Policy B (to be exported into the OSPF domain): 1. if proto=connected then accept 2. if proto=rip then accept Policy "A" seemed to work fine on the RIP side in the RIP domain. I could see connected routes, and I could see OSPF routes. I still had to configure a "connected" policy on xorp3 (same with other vendors' RIP implementation so I am not worried about that). But policy "B" did NOT work on the OSPF side. The connected routes would not propagate. For example, xorp1 could not see any route to 192.168.40.0/24. Since eth1 on xorp1 was assigned 192.168.40.1/24, and this is a "connected" protocol, this policy B should have injected that route back into the OSPF domain, but it did not. The way I solved this particular problem in the end was to for that interface into OSPF and then make it a passive interface. This forces xorp1 and xorp5 to learn about that network. This changes the "learning method" in that it becomes an OSPF interface (albeit, a passive one) and LSA's are forced back into the OSPF domain because it's part of the OSPF domain. When this worked, I decided to pull out the "if proto=connected" on the OSPF side since it didn't appear to be working anyway and all the routes were still good. My final configurations are attached. Using the attachment, I was able to get certain and predictable converging of all routes, from every router. All routers could reach all destinations using these configurations. Again, this seems like too much clever work was needed in order to get this accomplished. I suspect something is anomalous because, like you mentioned, many of us are seeing this same kind of weirdness. Thank you again for your input. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: steves_lab_on_xorp.txt Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120325/70e463ca/attachment.txt From rps at maine.edu Mon Mar 26 10:35:51 2012 From: rps at maine.edu (Ray Soucy) Date: Mon, 26 Mar 2012 13:35:51 -0400 Subject: [Xorp-users] Route Redist between RIP and OSPF - working? In-Reply-To: References: Message-ID: You might try looking at: http://soucy.org/xorp/xorp-1.6/CONFIG I've always put policy statements in a single policy block; I've also always used numbers for terms, and explicit "accept" or "reject". It has worked fine in both pre- and post-CT configurations. On Thu, Mar 22, 2012 at 10:52 AM, wrote: > Hi Xorp Users, > > I am trying to get some simple route redistribution going between OSPF and > RIP. > > Setup: > > OSPF > RIP > Xorp1 [30.1] - - - - - - [30.2] Xorp2 [40.1] - - - - - - [40.2] Xorp3 > > > What I am seeing is that on Xorp2 the RIP will send out Response messages > with its routes' metric set to 16 (infinite) when OSPF is running on Xorp2 > (the bridge node). After playing with the config file on Xorp2 it seems > OSPF just has to be a configured protocol on the router, it doesnt even > have to be enabled on an interface. All the routes that Xorp2 will send > out will be metric 16, even the connected routes. The OSPF seems to be > fine, just a RIP problem happening. > > Has anyone else run with a similar setup? I don't see much information > out there about policytags - is that a possible solution? Has anyone any > config files that they could send me that have successfully worked for > route redist between OSPF and RIP? > > I'm not sure, but this could be related to issue others have raised: > * > http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2008-September/002774.html > * > * > http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2008-September/002773.html > * > > Thanks guys, > > Steve Dickey > swdickey at rockwellcollins.com > > > > Xorp2 config file: > > /* $XORP$ */ > interfaces { > interface "eth4" { > disable: false > default-system-config > } > interface "eth5" { > disable: false > default-system-config > } > } > fea { > unicast-forwarding4 { > disable: false > } > } > protocols { > ospf4 { > router-id: 192.168.30.2 > export: "connected,rip" > area 0.0.0.0 { > interface "eth4" { > vif "eth4" { > address 192.168.30.2 { > hello-interval: 10 > router-dead-interval: 40 > interface-cost: 100 > disable: false > } > } > } > } > } > rip { > export: "export-connected,ospf" > interface "eth5" { > vif "eth5" { > address 192.168.40.1 { > metric: 1 > horizon: > "split-horizon-poison-reverse" > disable: false > passive: false > accept-non-rip-requests: true > accept-default-route: false > route-timeout: 180 > deletion-delay: 120 > triggered-delay: 3 > triggered-jitter: 66 > update-interval: 30 > update-jitter: 16 > request-interval: 30 > interpacket-delay: 50 > } > } > } > } > } > policy { > policy-statement export-connected { > term 100 { > from { > protocol: "connected" > } > } > } > } > policy { > policy-statement connected { > term export { > from { > protocol: "connected" > } > } > } > } > policy { > policy-statement rip { > term export { > from { > protocol: "rip" > } > } > } > } > policy { > policy-statement ospf { > term export { > from { > protocol: "ospf4" > } > } > } > } > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120326/dd59baab/attachment-0001.html From vvm at tut.by Mon Mar 26 23:45:14 2012 From: vvm at tut.by (Victor Miasnikov) Date: Tue, 27 Mar 2012 09:45:14 +0300 Subject: [Xorp-users] Route Redist between RIP and OSPF - working? References: Message-ID: Hi! > You might try looking at: http://soucy.org/xorp/xorp-1.6/CONFIG and TUNING http://www.soucy.org/xorp/xorp-1.7-pre/ to Ray Soucy : good job, thanks! > I've always put policy statements in a single policy block; I've also > always used numbers for terms, and explicit "accept" or "reject". It has > worked fine in both pre- and post-CT configurations. Yes: I'm use policy and Co from CONFIG -- all work fine Best regards, Victor Miasnikov Blog: http://vvm.blog.tut.by/ From swdickey at rockwellcollins.com Tue Mar 27 14:01:47 2012 From: swdickey at rockwellcollins.com (swdickey at rockwellcollins.com) Date: Tue, 27 Mar 2012 17:01:47 -0400 Subject: [Xorp-users] Route Redist between RIP and OSPF - working? In-Reply-To: References: Message-ID: Ray: Thanks for your response. I tried your config files running RIP and OSPF; RIP will send out Response messages with a metric of 16. This is on xorp 1.8.5 on Fedora 11. So I have the same issue that I've always had running with your config files as well :S When you say it worked fine for you, maybe these particular protocols/policies weren't tested specifically? Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120327/2fbd7d39/attachment.html From rps at maine.edu Wed Mar 28 08:38:13 2012 From: rps at maine.edu (Ray Soucy) Date: Wed, 28 Mar 2012 11:38:13 -0400 Subject: [Xorp-users] Route Redist between RIP and OSPF - working? In-Reply-To: References: Message-ID: Sorry. ?I didn't read into your?original?mail much. ?This sounds like the behavior of: horizon: "split-horizon-poison-reverse" Piratically?the "poison reverse" part. ?Do you get the same result with only "split-horizon" instead? Sounds like your routers might be trying to share the same routes ... On Tue, Mar 27, 2012 at 5:01 PM, wrote: > > Ray: Thanks for your response. ?I tried your config files running RIP and OSPF; RIP will send out Response messages with a metric of 16. ?This is on xorp 1.8.5 on Fedora 11. ?So I have the same issue that I've always had running with your config files as well :S > > When you say it worked fine for you, maybe these particular protocols/policies weren't tested specifically? > > Steve -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From swdickey at rockwellcollins.com Wed Mar 28 08:57:35 2012 From: swdickey at rockwellcollins.com (swdickey at rockwellcollins.com) Date: Wed, 28 Mar 2012 11:57:35 -0400 Subject: [Xorp-users] Route Redist between RIP and OSPF - working? In-Reply-To: References: Message-ID: That doesn't seem to affect the result. Poison-reverse on or off, still sends metric 16. I can get RIP to work just fine on its own. As soon as I add OSPF as a protocol in the config file (not even connected to an interface, just running) then RIP will always send out the metric of 16. Steve Ray Soucy 03/28/2012 11:38 AM To swdickey at rockwellcollins.com cc Victor Miasnikov , xorp-users at xorp.org Subject Re: [Xorp-users] Route Redist between RIP and OSPF - working? Sorry. I didn't read into your original mail much. This sounds like the behavior of: horizon: "split-horizon-poison-reverse" Piratically the "poison reverse" part. Do you get the same result with only "split-horizon" instead? Sounds like your routers might be trying to share the same routes ... On Tue, Mar 27, 2012 at 5:01 PM, wrote: > > Ray: Thanks for your response. I tried your config files running RIP and OSPF; RIP will send out Response messages with a metric of 16. This is on xorp 1.8.5 on Fedora 11. So I have the same issue that I've always had running with your config files as well :S > > When you say it worked fine for you, maybe these particular protocols/policies weren't tested specifically? > > Steve -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120328/1ecb952f/attachment.html From david at commroom.net Wed Mar 28 17:03:38 2012 From: david at commroom.net (David Davidson) Date: Wed, 28 Mar 2012 17:03:38 -0700 Subject: [Xorp-users] Regarding pimsm4 and igmp protocols configuration. In-Reply-To: References: Message-ID: <4F73A6DA.4050000@commroom.net> Hi Ganesh: So for this XORP PC, are eth1 and eth0 in different networks? If so, shouldn't PIM-SM4 be enabled? Multicast packets will not cross subnet boundaries (layer3 segmented broadcast domains) without a multicast routing protocol (such as PIM-SM) to allow multicast forwarding. The only exception is if these two interfaces were in a bridged configuration, but then you wouldn't need XORP for that, so my bet is, these eth0 and eth1 interfaces are in different networks and you need a multicast routing protocol enabled, so maybe try enabling the PIM-SM; your configuration below shows "disable true" on eth1 and eth0 - maybe change that to "disable false." You will also need to be certain that the stream you're sending on 239.11.11.12 has a ttl more than 1 (at least 2, but set it higher than this). This is done by the application sending on that group (make sure the application you're using to send on 239.11.11.12 sets the time to live higher than one or XORP will drop the traffic as routers decrement the TTL until it's zero and then it's dropped!). That help? Please let us know. David On 03/02/2012 06:27 AM, Ganesh Reddy K wrote: > Hi, > > I have installed XORP on a PC. Below is the configuration. > > From H1 i am sending Multicast UDP traffic (DIP is 239.11.11.12) > On H2 i subscribed (IGMP JOIN) to the same Group using a utility and > waiting for the stream to receive.. > > In summary i have enabled IGMP protocol configuration on both the > interfaces of PC. pimsm configuration is disabled for the same. > > After starting UDP stream on H1 and Subcription from H2, i am unable > to see the stream on H2 side. I verified in the XORP show > configuration that, JOIN to the group 239.11.11.12 is registered > properly. But Dataflow has not been established. > > The multicast route is verified in /proc/net/ip_mr_cache also. The > route is not completely formed. OutIface is given as -1 only. > > > Is the configuration correct ? What should be the expected behavior ? > > > H1 --------- eth1 PC (XORP) eth0 ------- H2 > > ======================================== BEGIN > > interfaces { > restore-original-config-on-shutdown: false > interface eth0{ > disable: false > default-system-config > } > interface eth1{ > disable: false > default-system-config > } > } > > fea { > unicast-forwarding4 { > disable: false > } > unicast-forwarding6 { > 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 > } > } > interface eth1 { > vif eth1 { > 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 > } > } > } > } > > protocols { > pimsm4 { > disable: false > interface eth0 { > vif eth0 { > disable: true > dr-priority: 1 > hello-period: 30 > hello-triggered-delay: 5 > } > } > interface eth1 { > vif eth1 { > disable: true > dr-priority: 1 > hello-period: 30 > hello-triggered-delay: 5 > } > } > interface register_vif { > vif register_vif { > disable: false > dr-priority: 1 > hello-period: 30 > hello-triggered-delay: 5 > } > } > static-rps { > } > bootstrap{ > disable: false > cand-bsr { > } > cand-rp { > } > } > switch-to-spt-threshold{ > disable: true > interval: 100 > bytes: 102400 > } > traceoptions{ > flag all{ > disable: false > } > } > } > } > > plumbing { > mfea4 { > disable: false > interface eth0{ > vif eth0{ > disable: false > } > } > interface eth1{ > vif eth1{ > disable: false > } > } > interface register_vif { > vif register_vif { > disable: false > } > } > traceoptions{ > flag all{ > disable: false > } > } > } > } > > protocols { > fib2mrib { > disable: false > } > } > ======================================== END > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120328/cc956789/attachment.html From rps at maine.edu Thu Mar 29 09:24:43 2012 From: rps at maine.edu (Ray Soucy) Date: Thu, 29 Mar 2012 12:24:43 -0400 Subject: [Xorp-users] Route Redist between RIP and OSPF - working? In-Reply-To: References: Message-ID: Does this work? ----8<---- protocols { fib2mrib { disable: false } ospf4 { router-id: 192.168.30.2 rfc1583-compatibility: false ip-router-alert: false area 0.0.0.0 { area-type: "normal" default-lsa { disable: false metric: 0 } interface "eth4" { link-type: "broadcast" vif "eth4" { address 192.168.30.2 { priority: 255 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 retransmit-interval: 5 transit-delay: 1 disable: false } } } } export: "OSPF_Export" } rip { interface "eth5" { vif "eth5" { address 192.168.40.1 { metric: 1 horizon: "split-horizon-poison-reverse" disable: false passive: false accept-non-rip-requests: false accept-default-route: true advertise-default-route: false route-timeout: 180 deletion-delay: 120 triggered-delay: 3 triggered-jitter: 66 update-interval: 30 update-jitter: 16 request-interval: 30 interpacket-delay: 50 } } } export: "RIP_Export" } } policy { policy-statement "OSPF_Export" { term 101 { from { protocol: "connected" } then { accept { } } } term 102 { from { protocol: "rip" } then { external-type: 2 accept { } } } then { reject { } } } policy-statement "RIP_Export" { term 101 { from { protocol: "connected" } then { accept { } } } term 102 { from { protocol: "ospf4" } then { accept { } } } then { reject { } } } } fea { unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: true retain-on-shutdown: true } } } interfaces { restore-original-config-on-shutdown: true interface eth4 { description: "OSPF" disable: false discard: false unreachable: false management: false default-system-config { } } interface eth5 { description: "RIP" disable: false discard: false unreachable: false management: false default-system-config { } } } rtrmgr { config-directory: "/home/xorp/" load-file-command: "fetch" load-file-command-args: "-o" load-ftp-command: "fetch" load-ftp-command-args: "-o" load-http-command: "fetch" load-http-command-args: "-o" load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" load-tftp-command-args: "" save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-file-command-args: "" save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-ftp-command-args: "" save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-http-command-args: "" save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-tftp-command-args: "" } ----8<---- On Wed, Mar 28, 2012 at 11:57 AM, wrote: > That doesn't seem to affect the result. Poison-reverse on or off, still > sends metric 16. > > I can get RIP to work just fine on its own. As soon as I add OSPF as a > protocol in the config file (not even connected to an interface, just > running) then RIP will always send out the metric of 16. > > Steve > > > *Ray Soucy * > > 03/28/2012 11:38 AM > To > swdickey at rockwellcollins.com > cc > Victor Miasnikov , xorp-users at xorp.org > Subject > Re: [Xorp-users] Route Redist between RIP and OSPF - working? > > > > > Sorry. I didn't read into your original mail much. This sounds like > the behavior of: > > horizon: "split-horizon-poison-reverse" > > Piratically the "poison reverse" part. Do you get the same result > with only "split-horizon" instead? > > Sounds like your routers might be trying to share the same routes ... > > > > On Tue, Mar 27, 2012 at 5:01 PM, wrote: > > > > Ray: Thanks for your response. I tried your config files running RIP > and OSPF; RIP will send out Response messages with a metric of 16. This is > on xorp 1.8.5 on Fedora 11. So I have the same issue that I've always had > running with your config files as well :S > > > > When you say it worked fine for you, maybe these particular > protocols/policies weren't tested specifically? > > > > Steve > > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ > > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120329/fba72a49/attachment-0001.html From swdickey at rockwellcollins.com Fri Mar 30 09:00:43 2012 From: swdickey at rockwellcollins.com (swdickey at rockwellcollins.com) Date: Fri, 30 Mar 2012 12:00:43 -0400 Subject: [Xorp-users] Route Redist between RIP and OSPF - working? In-Reply-To: References: Message-ID: Ray: No, I wasn't able to get that working... :S I have made some progress with investigating this issue however... Update: The RIP routes are being put into the RIB with a metric of 0 and everything is A-ok. Then RIB quickly executes rib/rt_tab_pol_redist.cc method PolicyRedistTable::replace_policytags which calls deletes all the routes then re-adds them based on policy tags. [_redist_map.get_protocols(add_protos, route.policytags()... add_redist(route, add_protos) lines 241 and 251). As a test/hack, you can comment out rt_tab_pol_redist.cc line 249 del_redist(route, del_protos) to prevent the Redist Table from expiring routes, and RIP response messages will be sent out with a metric of 0 as expected. So I'm close to figuring this out, but I cant find any information/config files to help be better understand policytags except the one xorp document (http://www.xorp.org/papers/policy.pdf) which seems outdated. Any help with policytags would be appreciated. I will continue to look into this issue. Steve Dickey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120330/53461e8c/attachment.html