[Xorp-users] Re: help establishing OSPF adjacencies
Atanu Ghosh
atanu@ICSI.Berkeley.EDU
Sat, 29 Oct 2005 01:07:50 -0700
Hi,
I don't think that you have the latest code, I still see an Assertion in
the trace (Assertion (do_dr_or_bdr()) failed).
Atanu.
>>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:
Nick> Spoke a bit too soon. I'm still getting these error logs on
Nick> p4: [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
Nick> Event(DataDescriptionReceived-pse udo-event)
Nick> Interface(eth0/eth0) Neighbour(128.31.1.15) State(ExStart) [
Nick> 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
Nick> Event(NegotiationDone) Interface( eth0/eth0)
Nick> Neighbour(128.31.1.15) State(ExStart) [ 2005/10/29 00:10:27
Nick> TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pse
Nick> udo-event) Interface(eth0/eth0) Neighbour(128.31.1.15)
Nick> State(Exchange) [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
Nick> Event(ExchangeDone) Interface(eth 0/eth0)
Nick> Neighbour(128.31.1.15) State(Exchange) [ 2005/10/29 00:10:27
Nick> TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pse
Nick> udo-event) Interface(eth0/eth0) Neighbour(128.31.1.13)
Nick> State(Loading) [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
Nick> Event(LoadingDone) Interface(eth0 /eth0)
Nick> Neighbour(128.31.1.13) State(Loading) [ 2005/10/29 00:10:27
Nick> FATAL xorp_ospfv2:2866 OSPF +914 peer.cc is_neighbour_DR_
Nick> or_BDR ] Assertion (do_dr_or_bdr()) failed [ 2005/10/29
Nick> 00:10:37 ERROR xorp_fea:2175 FEA +433
Nick> fticonfig_entry_set_click.cc delete_entry ] User-level Click
Nick> command error: 520-Write handler '_xorp_rt4.rem ove' error:
Nick> 520 route '10.0.1.0/24 - -1' not found [ 2005/10/29 00:10:37
Nick> ERROR xorp_fea:2175 FEA +71 fti_transaction.cc operation_
Nick> result ] FTI transaction commit failed on DeleteEntry4: net =
Nick> 10.0.1.0/24 nextho p = 0.0.0.0 ifname = vifname = metric = 0
Nick> admin_distance = 0 xorp_route = fals e is_deleted = false
Nick> is_unresolved = false is_connected_route = false [ 2005/10/29
Nick> 00:10:37 ERROR xorp_fea:2175 FEA +433
Nick> fticonfig_entry_set_click.cc delete_entry ] User-level Click
Nick> command error: 520-Write handler '_xorp_rt4.rem ove' error:
Nick> 520 route '10.0.2.0/24 - -1' not found [ 2005/10/29 00:10:37
Nick> ERROR xorp_fea:2175 FEA +433 fticonfig_entry_set_click.cc
Nick> delete_entry ] User-level Click command error: 520-Write
Nick> handler '_xorp_rt4.rem ove' error: 520 route '10.0.3.0/24 -
Nick> -1' not found [ 2005/10/29 00:10:37 WARNING xorp_fea
Nick> XrlFeaTarget ] Handling method for redist
Nick> _transaction4/0.1/commit_transaction failed: XrlCmdError 102
Nick> Command failed Dele teEntry4: net = 10.0.1.0/24 nexthop =
Nick> 0.0.0.0 ifname = vifname = metric = 0 ad min_distance = 0
Nick> xorp_route = false is_deleted = false is_unresolved = false
Nick> is_ connected_route = false
Nick> On Fri, Oct 21, 2005 at 02:53:59AM -0700, Atanu Ghosh wrote:
>> >>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:
>>
Nick> On Wed, Oct 19, 2005 at 03:27:03PM -0700, Atanu Ghosh wrote:
>> >> of the routers neighbours are the designated router or backup
>> >> designated router. This method should only be called if the
>> the >> link type is Broadcast or NBMA, as these are the only link
>> types >> that perform DR election. I assume that the link-type is
>> set to >> point-to-multipoint (p2m), in when case the assert is
>> signalling >> a programming error. The OSPF process will have
>> exited. A stack >> backtrace might yield some clues.
>>
Nick> Yes, the link-type is p2m in our case, so perhaps this method
Nick> should not be called? It appears that the OSPF process dies
Nick> completely as a result. Sure, I will send along a backtrace.
>> This problem is now fixed in CVS.
>>
>> >> If the problem is reproducible with the latest code from CVS
>> then >> the configuration files and some information about the
>> topology >> would be useful.
>>
Nick> Simple topology:
>>
Nick> A <-> B <-> C, where both links are p2m links. I've attached
Nick> the configuration files.
>> I'v included a cut down configuration files that worked for
>> me. I had to modify the prefix length from 32 to 24 on the first
>> router. Also you shouldn't be setting discard to true on
>> interfaces that you want to route traffic through.
>>
>> >> If an attempt was made to add a route to the RIB and it failed
>> >> you should error messages in the log.
>>
Nick> How do I ensure that routes are in the RIB, then? Here's what
Nick> I see in the log.
>> Use the show route command:
Xorp> show route table ipv4 unicast ospf
>> Network 128.31.1.15/32 Nexthop := 128.31.1.14 Metric := 10
>> Protocol := ospf Interface := eth0 Vif := eth0
>>
>> To see the final table:
Xorp> show route table ipv4 unicast final
>> Network 128.31.1.0/24 Nexthop := 128.31.1.13 Metric := 0 Protocol
>> := connected Interface := eth0 Vif := eth0 Network 128.31.1.15/32
>> Nexthop := 128.31.1.14 Metric := 10 Protocol := ospf Interface :=
>> eth0 Vif := eth0
>>
>> Atanu.
>>
Nick> Content-Description: p3
>> interfaces { interface eth0 { vif eth0 { address 128.31.1.13 {
>> prefix-length: 24 } } } } protocols { ospf4 { router-id:
>> 128.31.1.13
>>
>> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 {
>> address 128.31.1.13 { interface-cost: 5 neighbour 128.31.1.14 {
>> router-id: 128.31.1.14 } } } } } } } }
Nick> Content-Description: p4
>> interfaces { interface eth0 { vif eth0 { address 128.31.1.14 {
>> prefix-length: 24 } } } } protocols { ospf4 { router-id:
>> 128.31.1.14
>>
>> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 {
>> address 128.31.1.14 { interface-cost: 5 neighbour 128.31.1.13 {
>> router-id: 128.31.1.13 } neighbour 128.31.1.15 { router-id:
>> 128.31.1.15 } } } } } } } }
Nick> Content-Description: p5
>> interfaces { interface eth0 { vif eth0 { address 128.31.1.15 {
>> prefix-length: 24 } } } } protocols { ospf4 { router-id:
>> 128.31.1.15
>>
>> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 {
>> address 128.31.1.15 { interface-cost: 5 neighbour 128.31.1.13 {
>> router-id: 128.31.1.13 } neighbour 128.31.1.14 { router-id:
>> 128.31.1.14 } } } } } } } }