[Xorp-users] Route Redist between RIP and OSPF - working?
David Davidson
david at commroom.net
Fri Mar 23 19:13:28 PDT 2012
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
More information about the Xorp-users
mailing list