[Xorp-users] Issues related to OSPF path selection

Atanu Ghosh atanu at ICSI.Berkeley.EDU
Mon Jun 30 08:26:10 PDT 2008


Hi,

Could you try this experiment with the latest code from CVS.

      Atanu.

arvind <arvind at macil.in> wrote:

> 
> 
> 
> A , B--> Server running router manager with 2 ethernet ports (With OSPF)
> C------> Its a server running router manager with 10 ethernet ports(with
> static and OSPF protocols)
> 
> 
> This picture May not be clear in some systems for those I have explained 
> the setup below.
> 
> 	_________				_________				|	|   172.16.3.1	     172.16.3.2	|	|
> 	|   A  1|<----------------------------->|1  B	|
> 	|   0  	|				|   0	|				---------				---------			172.16.2.1  ^		 
>                      ^  172.16.1.1
> 	    |				           |
>      	    |				           |
> 	    |					   |
> 	    |				           |
> 	    |					   |
> 	    |					   |
> 	    |					   |
> 	    |					   |
> 	    |					   |
> 	    |                                      |
> 	    |		_________		   |					    |		|	|		   |		
> 	    ----------->|   C	|<-----------------
> 	172.16.2.2	|	|  	 172.16.1.2
> 			---------					
> 
> 
> 
> Server C has the following in configuration file:
> 
> 
> 	protocols {
> 	        static {
>          		disable: false
> 		        route 10.10.10.0/24 {
>          		    next-hop: 172.16.10.10
> 	        	    metric: 1
> 	        	}
> 		        route 10.10.11.0/24 {
>          		    next-hop: 172.16.11.10
> 		            metric: 1
>          		}
> 		}
> 		ospf4 {
>          		router-id: 172.16.1.2
> 		        area 0.0.0.0 {
>          		    interface eth2 {
>                  		vif eth2.0 {
> 		                    address 172.16.2.2 {
>                  		    }
> 		                }
> 		            }
> 		            interface eth4 {
> 		                vif eth4.0 {
> 		                    address 172.16.1.2 {
> 		                    }
>                  		}
> 		            }
> 		        }
>          	export: "connected,static"
> 		}
> 	}
> 
> policy {
>      policy-statement connected {
>          term export {
>              from {
>                  protocol: "connected"
>              }
>          }
>      }
>      policy-statement static {
>          term export {
>              from {
>                  protocol: "static"
>              }
>          }
>      }
> }
> 
> interfaces {
>      restore-original-config-on-shutdown: true
>      interface eth0 {
>          disable: false
>          discard: false
>          description: "data interface"
>          mac: 00:bb:cc:dd:ee:00
>          mtu: 1500
>          vif eth0.0 {
>              disable: false
>                  vlan {
>                          vlan-id: 0
>                  }
>                          address 172.16.10.2 {
>                  prefix-length: 24
>                  broadcast: 172.16.10.255
>                  disable: false
>              }
>          }
>      }
>      interface eth1 {
> 	disable: false
>          discard: false
>          description: "data interface"
>          mac: 00:bb:cc:dd:ee:01
>          mtu: 1500
>          vif eth1.0 {
>              disable: false
>                  vlan {
>                          vlan-id: 0
>                  }
>                          address 172.16.11.2 {
>                  prefix-length: 24
>                  broadcast: 172.16.11.255
>                  disable: false
>              }
>          }
>      }
>      interface eth2 {
>          disable: false
>          discard: false
>          description: "data interface"
> 	mac: 00:bb:cc:dd:ee:02
>          mtu: 1500
>          vif eth2.0 {
>              disable: false
>                  vlan {
>                          vlan-id: 0
>                  }
>                          address 172.16.2.2 {
>                  prefix-length: 24
>                  broadcast: 172.16.2.255
>                  disable: false
>              }
>          }
>      }
>      interface eth4 {
>          disable: false
>          discard: false
>          description: "data interface"
>          mac: 00:bb:cc:dd:ee:04
>          mtu: 1500
>          vif eth4.0 {
>              disable: false
>                  vlan {
>                          vlan-id: 0
>                  }
>                          address 172.16.1.2 {
>                  prefix-length: 24
>                  broadcast: 172.16.1.255
>                  disable: false
>              }
>          }
>      }
> }
> 
> 
> 
> I will explain the set-up (the Above diagram may not be clear while 
> receiving)
> 	3 systems are there running with router manager A,B,C
> 
> 	A and B is connected with the network 172.16.3.1 nad 172.16.3.2
> 
> 	A and C is connected with the network 172.16.2.1 nad 172.16.2.2
> 
> 	B and C is connected with the network 172.16.1.1 nad 172.16.1.2
> 
> 
> After running router manager in all the systems the OSPF states are 
> "full" and the "show route table ipv4 unicast ospf" is showing the 
> shortest path.But the issue is whenever the path is remove/broken (2 or 
> 3 times) between any 2 systems and replacing then the back again it was 
> not showing the shortest path..
> 
> 
> By giving "clear ospf database" the shortest paths are coming back again.
> 
> 
> 
> 
> My Test:
> 	I remove the path between A and C and replaced it back again but it was 
> not showing the shortest path.
> 
> Output checked in A:
> output before removing the connection:
> 
> 
> root at test1> show ospf4 neighbor
>    Address         Interface             State      ID              Pri 
>   Dead
> 172.16.2.2       eth0/eth0              Full      172.16.1.2       128    30
> 172.16.3.2       eth1/eth1              Full      172.16.1.1       128    30
> 
> root at test1> show route table ipv4 unicast ospf
> 10.10.10.0/24   [ospf(110)/1]
>                  > to 172.16.2.2 via eth0/eth0
> 10.10.11.0/24   [ospf(110)/1]
>                  > to 172.16.2.2 via eth0/eth0
> 172.16.1.0/24   [ospf(110)/2]
>                  > to 172.16.3.2 via eth1/eth1
> 172.16.10.0/24  [ospf(110)/1]
>                  > to 172.16.2.2 via eth0/eth0
> 172.16.11.0/24  [ospf(110)/1]
>                  > to 172.16.2.2 via eth0/eth0
> root at test1>
> 
> 
> 
> 
> 
> output after removing the connection:
> 
> root at test1> show ospf4 neighbor
>    Address         Interface             State      ID              Pri 
>   Dead
> 172.16.2.2       eth0/eth0              Down      172.16.1.2         0     0
> 172.16.3.2       eth1/eth1              Full      172.16.1.1       128    38
> 
> root at test1> show route table ipv4 unicast ospf
> 10.10.10.0/24   [ospf(110)/1]
>                  > to 172.16.3.2 via eth1/eth1
> 10.10.11.0/24   [ospf(110)/1]
>                  > to 172.16.3.2 via eth1/eth1
> 172.16.1.0/24   [ospf(110)/2]
>                  > to 172.16.3.2 via eth1/eth1
> 172.16.10.0/24  [ospf(110)/1]
>                  > to 172.16.3.2 via eth1/eth1
> 172.16.11.0/24  [ospf(110)/1]
>                  > to 172.16.3.2 via eth1/eth1
> root at test1>
> 
> 
> Its fine still now, but the problem is after replacing the path between 
> A and C, It was not taking....
> 
> 
> 
> 
> output after replacing the connection:
> 
> 
> root at test1> show route table ipv4 unicast ospf
> 10.10.10.0/24   [ospf(110)/1]
>                  > to 172.16.3.2 via eth1/eth1
> 10.10.11.0/24   [ospf(110)/1]
>                  > to 172.16.3.2 via eth1/eth1
> 172.16.1.0/24   [ospf(110)/2]
>                  > to 172.16.3.2 via eth1/eth1
> 172.16.10.0/24  [ospf(110)/1]
>                  > to 172.16.3.2 via eth1/eth1
> 172.16.11.0/24  [ospf(110)/1]
>                  > to 172.16.3.2 via eth1/eth1
> root at test1>
> 
> 
> 
> 
> If I give "clear ospf database" and then  "show route table ipv4 unicast 
> ospf" then the paths are coming as shortest path.
> 
> 
> At this situation If I remove the path between C and B,
> 
> System A doesnot know any route about the neighbors.
> 
> 
> 
> Can any one give the solution/idea for the above problem.
> 
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users



More information about the Xorp-users mailing list