[Xorp-users] Route redistribution...

[Sproat, Jackalynn]

I am trying to get RIP-OSPF route redistribution working and not having
much success. Hoping someone can shed some light on the following:

Three Linux 2.6.24-19 generic xorp routers:

--|R1|--eth1---.---eth2--|R2|--eth3---.--eth4--|R3|---

Configuration on R1:

interfaces {
	interface eth1 {
		description: "Rip LAN 1"
		disable: false
		vif eth1 {
			disable: false
			address 10.1.0.5 {
				prefix-length: 24
				broadcast: 10.1.0.255
			}
		}
	}
	
}

fea { 
	unicast-forwarding4 {
		disable: false
		forwarding-entries {
		}
	}
} /* end fea */

protocols {
	rip {
		interface eth1 {
			vif eth1 {
				address 10.1.0.5 {
				}
			}
		}
	}
}

Configuration on R2:
interfaces {
	interface eth2 {
		description: "Rip LAN 1"
		disable: false
		vif eth2 {
			disable: false
			address 10.1.0.50 {
				prefix-length: 24
				broadcast: 10.1.0.255
			}
		}
	}
	interface eth3 {
		description: "OSPF LAN 1"
		disable: false
		vif eth3 {
			disable: false
			address 10.10.0.50 {
				prefix-length: 24
				broadcast: 10.10.0.255
			}
		}
	}
}

fea { 
	unicast-forwarding4 {
		disable: false
		forwarding-entries {
		}
	}
} /* end fea */
policy {
	policy-statement connected-to-rip {
		term export {
			from {
				protocol: "connected"
			}
			then {
				accept
			}
		}
	}
}
protocols {
	rip {
		export: "connected-to-rip" /* 10.10.0.x (connected,OSPF
route)is advertised via rip*/
		interface eth2 {
			vif eth2 {
				address 10.1.0.50 {
				}
			}
		}
	}
	ospf {
		router-id: 10.10.0.50
		
		area 0.0.0.0 {
			interface eth3 {
				vif eth3 {
					address 10.10.0.50 {
					}
				}
			}
		}
	}
	
}
Configuration on R3:
interfaces {
	interface eth4 {
		description: "OSPF LAN 1"
		disable: false
		vif eth4 {
			disable: false
			address 10.10.0.5 {
				prefix-length: 24
				broadcast: 10.10.0.255
			}
		}
	}
}

fea { 
	unicast-forwarding4 {
		disable: false
		forwarding-entries {
		}
	}
} /* end fea */
 
protocols {
	
	ospf {
		router-id: 10.10.0.5
		
		area 0.0.0.0 {
			interface eth4 {
				vif eth4 {
					address 10.10.0.5 {
					}
				}
			}
		}
	}
	
}
In summary:

|R1|-10.1.0.5--rip---10.1.0.50-|R2|-10.10.0.50--ospf---10.10.0.5-|R3|

R1 learns of the 10.10.0.x subnet via R2 exporting all "connected
routes" into rip.
However,  R2 does not by default advertise (export) it's "connected" rip
subnet to its OSPF neighbors.  I.e., R3 doesn't have a route to 10.1.0.0
network in routing table. Is this expected?

Therefore, I can either:
1. have R2 export "connected" to ospf (similar to how it how it is
redistributing routes for connected interfaces into rip.
NOTE: However if the network is expanded - learnt ospf routes would not
be redistributed; only "connected".
So, a better option:

2. have R2 export rip into ospf, by adding the following policy:

policy {
	policy-statement rip-to-ospf {
		term export {
			from {
				protocol: "rip"
			}
			then {
				accept
			}
		}
	}
}
protocols {
	
	ospf {
		router-id: 10.10.0.50
		export: "rip-to-ospf"
		area 0.0.0.0 {
			
			interface eth3 {
			....

However, this didn't work. Why??? Do I have to set the OSPF "ebit" to
true or false when exporting RIP entries to OSPF? Should export command
be inside "area 0.0.0.0{}"?

So, then I decided to try option 1 on R2:
policy {
	policy-statement connected-to-ospf {
		term export {
			from {
				protocol: "connected"
			}
			then {
				accept
			}
		}
	}
}
ospf {
		router-id: 10.10.0.50
		export: "connected-to-ospf"
		area 0.0.0.0 {
			
			interface eth3 {
			.....
This worked. I.e., R3 learnt of route to 10.1.0.x via redistribution of
connected routes into OSPF.  However, R1 no longer had route to
10.10.0.x eventhough redistribution of connected-to-rip was still
configured.  Why is this?

Cheers,
Jackie

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. 
Thank you.