On Wed, May 30, 2007 at 08:04:45PM +0200, Christian Plattner wrote:
quoted text > Hi,
>
> I am testing OpenBGPD and OpenOSPFD on a couple of Soekris boxes.
> Even though I am using the latest code (-stable with ospfd kroute.c
> revision 1.48), I am having problems with the kernel routing table
> when OSPFD has to react to changes in the topology. I verified the
> problem on a virtual setup (a couple of OpenBSD machines on an ESX
> server), same result.
>
> The problem can be summarized as follows: When I take down an interface
> on one machine manually (e.g., ifconfig em1 down), then the OpenOSPFD
> on another machine has no problems to detect this, routes to subnets in
> the same AS will be adapted. However, the kernel continues to route
> packets to destinations outside of the AS still over the dead link.
>
> Fix: When I restart ospfd, the kernel routing table is OK again.
>
> Here is an example with 3 routers that I have put together using
> ESX/VMWare:
>
> /em1-(.1) --- 10.74.96.0/27 --- (.2)--em0\
> +-- (.22)-em0-[R1] [R2]
> | \em2-(.33) -- 10.74.96.32/27 -- (.34)--em1/
> 10.0.0.0/24
> |
> +--- (.1)-em1-[R0]-em0 -- (62.2.0.0/16)
>
> Router R0: AS65002 announces 62.2.0.0/16 to R1
> Router R1: AS65001 announces 10.74.96.0/21 to R0
> Router R2: AS65001 has an IBGP session with R1
> Loopback (lo1) addresses: R1=10.74.97.1, R2=10.74.97.2
>
> This setting works fine, I can ping from R2 to machines in 62.2.0.0/16.
> Traffic between R1 and R2 flows over the upper link.
>
> However, lets assume that one of the links between R1 and R2 fails.
>
> [R1] # ifconfig em1 down (so eventually R2 will find out that I does
> not receive any OSPF packets on em0 anymore).
>
> It takes a while, but then ospfd on R2 has calculated the new topology:
>
> [R2] # ospfctl show rib
> Destination Nexthop Path Type Type Cost
> 0.0.0.1 10.74.96.33 Intra-Area Router 11
> 10.74.96.0/27 10.74.96.33 Intra-Area Network 21
> 10.74.96.32/27 10.74.96.34 Intra-Area Network 11
> 10.74.97.1/32 10.74.96.33 Intra-Area Network 21
> 10.0.0.0/24 10.74.96.33 Type 1 ext Network 111
> (uptime column deleted, to comply with the 72 char restriction
> of the mailing list).
>
> [R2] # ospfctl show fib
> flags: * = valid, O = OSPF, C = Connected, S = Static
> Flags Destination Nexthop
> *O 10.0.0.0/24 10.74.96.33
> * 10.74.96.0/21 10.74.96.1
> *C 10.74.96.0/27 link#1
> *C 10.74.96.32/27 link#2
> *O 10.74.97.1/32 10.74.96.33
> * 10.74.97.2/32 10.74.97.2
> * 62.2.0.0/16 10.74.96.1
> *S 127.0.0.0/8 127.0.0.1
> *C 127.0.0.1/8 link#0
> * 127.0.0.1/32 127.0.0.1
> *S 224.0.0.0/4 127.0.0.1
>
> This is not good, as the (via IBGP learned) route to 62.2.0.0/16 still
> points to 10.74.96.1 (which is not directly reachable anymore).
>
> Now let's kill and restart ospfd on R2, then check again:
>
> # ospfctl show fib
> flags: * = valid, O = OSPF, C = Connected, S = Static
> Flags Destination Nexthop
> *O 10.0.0.0/24 10.74.96.33
> * 10.74.96.0/21 10.74.96.33
> *C 10.74.96.0/27 link#1
> *C 10.74.96.32/27 link#2
> *O 10.74.97.1/32 10.74.96.33
> * 10.74.97.2/32 10.74.97.2
> * 62.2.0.0/16 10.74.96.33
> *S 127.0.0.0/8 127.0.0.1
> *C 127.0.0.1/8 link#0
> * 127.0.0.1/32 127.0.0.1
> *S 224.0.0.0/4 127.0.0.1
>
> Voil`, now it looks OK =)
>
> This is the ospfd.conf of R2:
>
> password="gurke"
> router-id 0.0.0.2
> redistribute connected
> redistribute static
>
> area 0.0.0.0 {
>
> interface lo1
>
> interface em0 {
> metric 10
> auth-type simple
> auth-key $password
> }
> interface em1 {
> metric 11
> auth-type simple
> auth-key $password
> }
> }
>
> Any suggstions? Am I making a substantial error?
>
> I did not want to make this posting too long, so if somebody is
> interested in the detailed config files then I can make them
> available.
>
This is a bgpd bug. Because the 62.2/16 network is handled by bgpd.
I'm currently having a look at this. Not sure why the network does not
swing over to the working link but hopefully I will find it out.
--
:wq Claudio
