[Xorp-users] (no subject)

David Davidson david at commroom.net
Mon May 14 22:13:19 PDT 2012


Hi Folks,

I have tested this and I agree with Adrian. It seems that the only way 
to get an OSPF adjacency formed again is to disable the authentication 
and then force the OSPF4 daemon to be restarted (either by saving the 
new configuration and then restarting the router manager, OR deleting 
OSPF, committing, and reconfiguring OSPF without the authentication, and 
then committing again). One should not have to cause the ospf4 daemon to 
restart completely in order to load up the new OSPF configuration for 
that interface.

Upon committing the configuration change, there should be a way for the 
OSPF4 daemon to detect the configuration change, and to notice that the 
authentication was just removed from that interface, the OSPF 
process/protocol should only be modified just for that interface, 
without having to reload the OSPF daemon, and also without having to 
disrupt any other OSPF processes and/or adjacencies on that router (i.e. 
on other interfaces).

Another user mentioned trying this with MD5 authentication, but I have 
found this to be the same result. Upon changing the configuration and 
completely removing the authentication for that interface, and also 
following the commit, no non-authenticated OSPF adjacency can be formed 
on that interface - the OSPF4 daemon continues to send OSPF4 packets 
with the authentication parameter set, it continues to send the MD5 
authentication key in the OSPF header, and, like Adrian mentions, it 
ignores any packets from directly-connected OSPF neighbors whose OSPF 
header has no authentication key. It perpetually sends the key and 
ignores any OSPF hello's where there is no MD5 key in in the header.

This happens whether I use simple password authentication, and it also 
happens if I use MD5 authentication. Upon deleting the authentication 
requirement for a particular interface, no non-authenticated OSPF 
adjacencies can be formed on that interface, regardless of whether MD5 
or simple password authentication was used. The result is the same for both.

I have included an attachment that documents the way I tested this. This 
was tested on a GIT clone from 4/17/2012. a "show version" output is as 
follows:

root at XORPROUTER> show version
Version 1.8.5

Launching the xorpsh shell produces the following version information:

Welcome to XORP v1.8.6-WIP on XORPROUTER
Version tag: 08cde50  Build Date: 2012-04-17 10:35 32-bit

Also, clearing the OSPF database after the change didn't have any effect 
either. If anyone has some more thoughts or anything they would like me 
to try, please let me know.

Thank you Adrian for the interesting find...

David








On 05/14/2012 12:11 PM, Adrian Fernández Morales wrote:
>
> Currently I'm testing some options of XORP and have found myself into 
> a problem with authentication.
> When I use that functionality it works correctly but when I try to 
> disable it, nothing happens. The software keeps setting authentication 
> parameters in messages and discarding the received ones that doesn't 
> use authentication at all.
> To delete the previouly configured authentication in OSPF I use the 
> command:
> delete protocols ospf4 area x.x.x.x interface ethy vif ethy address 
> z.z.z.z authentication simple-password "password"
> I also use the same command without specifying the password explitcily 
> but result is the same. When I'm inserting commands I use tab to 
> complete, to avoid mistakes and be sure of correctness.
> Thanks in advance.
>
> Participe en la XVI Convención Científica de Ingeniería y Arquitectura 
> del 26 al 30 de noviembre de 2012. La Habana, Cuba: 
> http://ccia.cujae.edu.cu
> Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
>
>
>
> _______________________________________________
> 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/20120514/ff238911/attachment-0001.html 
-------------- next part --------------
###############################################################
#TOPOLOGY
#   [eth1 xorp1 eth0]----------[eth0 xorp2 eth1]----------[eth0 xorp3 eth1]
###############################################################


##########################
#xorp1
##########################
configure exclusive
set rtrmgr config-directory /etc/xorp
set protocols ospf4 router-id 10.10.10.1
set protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 10.10.10.1 disable false
set protocols ospf4 area 0.0.0.0 interface eth1 vif eth1 address 10.20.20.1 disable false
set protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 10.10.10.1 authentication simple-password "password"
set interfaces interface eth0 vif eth0 address 10.10.10.1 prefix-length 24
set interfaces interface eth1 vif eth1 address 10.20.20.1 prefix-length 24
set fea unicast-forwarding4 disable false
commit
exit configuration-mode



##########################
#xorp2
##########################
configure exclusive
set rtrmgr config-directory /etc/xorp
set protocols ospf4 router-id 172.16.10.1
set protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 10.10.10.2 disable false
set protocols ospf4 area 0.0.0.0 interface eth1 vif eth1 address 172.16.10.1 disable false
set interfaces interface eth0 vif eth0 address 10.10.10.2 prefix-length 24
set interfaces interface eth1 vif eth1 address 172.16.10.1 prefix-length 24
set fea unicast-forwarding4 disable false
commit
exit configuration-mode



##########################
#xorp3
##########################
configure exclusive
set rtrmgr config-directory /etc/xorp
set protocols ospf4 router-id 172.16.10.2
set protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 172.16.10.2 disable false
set protocols ospf4 area 0.0.0.0 interface eth1 vif eth1 address 192.168.10.1 disable false
set interfaces interface eth0 vif eth0 address 172.16.10.2 prefix-length 24
set interfaces interface eth1 vif eth1 address 192.168.10.1 prefix-length 24
set fea unicast-forwarding4 disable false
commit
exit configuration-mode



##########################
#Okay, now, delete the authentication on xorp1.
##########################
configure exclusive
delete protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 10.10.10.1 authentication
commit
exit configuration-mode
#[at this point, the OSPF adjacency with xorp2 should form successfully, but it never does.]



#The following causes the adjacency to form, but it kills the ospf4 daemon in the process and then forces ospf4
#to re-initialize. The adjacency forms without authentication then, but one should never have to manually kill the ospf4
#daemon this way. The router should be intelligent enough to modify the protocol for just that interface, without having
#to reinitialize or interrupt the OSPF4 daemon at all. This is a clunky way of doing it, because we have to rebuild
#the whole OSPF database and do all the SPF calculations again, and then wait for the network to reconverge.
configure exclusive
delete protocols ospf4
commit
#[ospf4 daemon killed now]
set protocols ospf4 router-id 10.10.10.1
set protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 10.10.10.1 disable false
set protocols ospf4 area 0.0.0.0 interface eth1 vif eth1 address 10.20.20.1 disable false
set interfaces interface eth0 vif eth0 address 10.10.10.1 prefix-length 24
set interfaces interface eth1 vif eth1 address 10.20.20.1 prefix-length 24
commit









More information about the Xorp-users mailing list