Re: OpenOSPFd and kernel routing table (new variant)
I applied the diff manually to -stable (watch out for path_updateall/prefix_updateall), and now it works perfectly. Thanks, Claudio! And here is a preliminary diff for all the curious ones. bgpd needs to track changes of routes with F_NEXTHOP checked and report them to the RDE. The RDE will then update all active routes that use this nexthop. Seems to work for me.
Re: OpenOSPFd and kernel routing table (new variant)
On Thu, May 31, 2007 at 11:45:08PM +0200, Claudio Jeker wrote:
> On Wed, May 30, 2007 at 08:04:45PM +0200, Christian Plattner wrote:
> > 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 TypeType Cost
> > 0.0.0.1 10.74.96.33 Intra-Area Router11
> > 10.74.96.0/2710.74.96.33 Intra-Area Network 21
> > 10.74.96.32/27 10.74.96.34 Intra-Area Network 11
> > 10.74.97.1/3210.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/2110.74.96.1
> > *C 10.74.96.0/27link#1
> > *C 10.74.96.32/27 link#2
> > *O 10.74.97.1/3210.74.96.33
> > * 10.74.97.2/3210.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/2110.74.96.33
> > *C 10.74.96.0/27link#1
> > *C 10.74.96.32/27 link#2
> > *O 10.74.97.1/3210.74.96.33
> > * 10.74.97.2/3210.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.
>
And here is a preliminary diff for all the curious ones. bgpd needs to
track changes of routes with F_
Re: OpenOSPFd and kernel routing table (new variant)
On Wed, May 30, 2007 at 08:04:45PM +0200, Christian Plattner wrote:
> 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 TypeType Cost
> 0.0.0.1 10.74.96.33 Intra-Area Router11
> 10.74.96.0/2710.74.96.33 Intra-Area Network 21
> 10.74.96.32/27 10.74.96.34 Intra-Area Network 11
> 10.74.97.1/3210.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/2110.74.96.1
> *C 10.74.96.0/27link#1
> *C 10.74.96.32/27 link#2
> *O 10.74.97.1/3210.74.96.33
> * 10.74.97.2/3210.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/2110.74.96.33
> *C 10.74.96.0/27link#1
> *C 10.74.96.32/27 link#2
> *O 10.74.97.1/3210.74.96.33
> * 10.74.97.2/3210.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
OpenOSPFd and kernel routing table (new variant)
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 TypeType Cost
0.0.0.1 10.74.96.33 Intra-Area Router11
10.74.96.0/2710.74.96.33 Intra-Area Network 21
10.74.96.32/27 10.74.96.34 Intra-Area Network 11
10.74.97.1/3210.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/2110.74.96.1
*C 10.74.96.0/27link#1
*C 10.74.96.32/27 link#2
*O 10.74.97.1/3210.74.96.33
* 10.74.97.2/3210.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/2110.74.96.33
*C 10.74.96.0/27link#1
*C 10.74.96.32/27 link#2
*O 10.74.97.1/3210.74.96.33
* 10.74.97.2/3210.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.
Thanks,
- Christian
Re: OpenOSPFd and kernel routing table
On 2007/02/23 12:52, Falk Brockerhoff wrote: > Claudio Jeker schrieb: > > Hmm. For some reasons the carp route is not cleared correctly. > > I'll have a look at it. > > > Do you have any news on this topic? I like to run OpenOSPFd on my > routers, but since the bugfix there isn't any redundancy. Hope to hear > some good news :) try kroute.c 1.43
Re: OpenOSPFd and kernel routing table
Claudio Jeker schrieb: > Hmm. For some reasons the carp route is not cleared correctly. > I'll have a look at it. > Do you have any news on this topic? I like to run OpenOSPFd on my routers, but since the bugfix there isn't any redundancy. Hope to hear some good news :) Thanks! Falk
Re: OpenOSPFd and kernel routing table
Claudio Jeker wrote: Hmm. For some reasons the carp route is not cleared correctly. I'll have a look at it. Thanks, I would be happy if this works. Btw. I think for your simple setup with two bgpd routers and one carped LAN network behind them does not need ospfd. Try to keep it simple until you know that you need ospf. I'm thinking about alternatives for this setup. But as the routes are dynamic in dependence of the state of the carp-interfaces such an IGP fits all the needs, doesn't it? Falk
Re: OpenOSPFd and kernel routing table
On Sun, Feb 18, 2007 at 02:46:09PM +0100, Falk Brockerhoff wrote: > >And the output of the forwarding database with the unexpected nexthop of > >the local interface instead of the opsf-neighbor: > > > ># ospfctl sh fib > >flags: * = valid, O = OSPF, C = Connected, S = Static > >Flags Destination Nexthop > > C 195.140.212.0/24 link#22 > > I killed the ospfd-process and started it again, and the fib looks better: > > # ospfctl sh fib > flags: * = valid, O = OSPF, C = Connected, S = Static > Flags Destination Nexthop > *O 195.140.212.0/24 10.0.0.2 > > Hm, killing and restarting ospfd isn't the way I want to do it everytime > the state of the carp-interface changes :-) > Hmm. For some reasons the carp route is not cleared correctly. I'll have a look at it. Btw. I think for your simple setup with two bgpd routers and one carped LAN network behind them does not need ospfd. Try to keep it simple until you know that you need ospf. -- :wq Claudio
Re: OpenOSPFd and kernel routing table
And the output of the forwarding database with the unexpected nexthop of the local interface instead of the opsf-neighbor: # ospfctl sh fib flags: * = valid, O = OSPF, C = Connected, S = Static Flags Destination Nexthop C 195.140.212.0/24 link#22 I killed the ospfd-process and started it again, and the fib looks better: # ospfctl sh fib flags: * = valid, O = OSPF, C = Connected, S = Static Flags Destination Nexthop *O 195.140.212.0/24 10.0.0.2 Hm, killing and restarting ospfd isn't the way I want to do it everytime the state of the carp-interface changes :-) Falk
OpenOSPFd and kernel routing table
Hello,
I just set up OSPF to talk within two OpenBSD-Boxes (Pinky and Brain, do
you remember? :-). On both machines I configured a carp interface to
provide a default gateway for my local VLANs. The configuration was very
easy and intuitive. OSPF is redistributing routes only for
carp-interfaces which are in master-state, this is exact the way I was
looking for.
But if I take down the actual carp-master interface (195.140.212.1/24),
the (until now) backup interface take over the master-state, ospfd is
redistributing the changed routing information, I can see it in the
output of "ospfctl sh rib".
But if I take a look at "opsfctl sh fib" there is still the local link
and not the new route via the ospf-neighbor, as I expected.
"fib-update" should be on by default, but I tried to write it explicitly
into the configuration file, but it's not getting better.
This is my configuration on both sides (only the router-id is adapted):
# global configuration
router-id 194.9.86.1
fib-update yes
# route redistribution
redistribute connected
redistribute static
# areas
area 0.0.0.0 {
interface lo1
interface em1 {
metric 10
auth-type crypt
auth-md-keyid 1
auth-md 1"foobar"
}
}
The correct output of the routing information:
# ospfctl sh rib
Destination Nexthop Path TypeType Cost
Uptime
194.9.86.2 10.0.0.2 Intra-Area Router10
00:22:17
10.0.0.0/30 10.0.0.1 Intra-Area Network 10
00:22:24
194.9.86.2/3210.0.0.2 Intra-Area Network 10
00:22:17
195.140.212.0/24 10.0.0.2 Type 1 ext Network 110
00:21:45
195.140.212.3/32 10.0.0.2 Type 1 ext Network 110
00:22:17
195.140.213.3/32 10.0.0.2 Type 1 ext Network 110
00:22:17
And the output of the forwarding database with the unexpected nexthop of
the local interface instead of the opsf-neighbor:
# ospfctl sh fib
flags: * = valid, O = OSPF, C = Connected, S = Static
Flags Destination Nexthop
*C 10.0.0.0/30 link#2
*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
*C 192.168.13.0/24 link#1
* 194.9.86.1/32194.9.86.1
*O 194.9.86.2/3210.0.0.2
C 195.140.212.0/24 link#22
*C 195.140.212.2/32 link#16
*O 195.140.212.3/32 10.0.0.2
*C 195.140.213.0/24 link#19
*C 195.140.213.2/32 link#17
*O 195.140.213.3/32 10.0.0.2
*C 195.225.134.4/30 link#3
*S 224.0.0.0/4 127.0.0.1
Any hints?
Thanks,
Falk
