>Number: 6597
>Category: system
>Synopsis: default IPv4 route does not install on ospf client linked via
>GIF interfaces
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Thu Apr 28 19:30:02 GMT 2011
>Closed-Date:
>Last-Modified:
>Originator:
>Release:
>Organization:
>Environment:
System : OpenBSD 4.8
Details : OpenBSD 4.8 (GENERIC) #0: Thu Apr 21 00:11:28 MDT 2011
[email protected]:/usr/src/sys/arch/i386/compile/GENERIC
Architecture: OpenBSD.i386
Machine : i386
The environment is a pair of 4.8 system with patches 001
through 010 installed and then a full kernel and world
build/install cycle as per the FAQ. They are running as
virtualbox-ose-3.2.12_1 virtual hosts under FreeBSD 8.2.
(I've run some largish 4.5 OpenBSD network sims under vbox
with complete success, FWTW - including the same OSPF hack
that this note addresses; I'm reasonably sure this is a
regression.)
>Description:
Consider two nets (192.168.2/24 and 192.168.4/24 for concreteness)
routed via two 4.8 i386 systems (details as above); between the
two routing hosts there is an auxiliary network: 172.16.16/28.
I will call the hosts LEFT and RIGHT. Crude ascii art:
192.168.2/24 <--> (192.168.2.10) em0
[LEFT]
em1 (172.16.16.1)
|
em0 (172.16.16.2)
[RIGHT]
192.168.4/24 <--> (192.168.2.250) em1
Also imagine a GIF tunnel set up with the 172.16.16/28 addrs
as physicals and 172.31.1/30 logicals + a 1400 byte MTU -
LEFT # ifconfig gif1
gif1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1400
physical address inet 172.16.16.1 --> 172.16.16.2
inet 172.31.1.1 --> 172.31.1.2 netmask 0xfffffffc
RIGHT # ifconfig gif1
gif1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1400
physical address inet 172.16.16.2 --> 172.16.16.1
inet 172.31.1.2 --> 172.31.1.1 netmask 0xfffffffc
Here's a recap of the interfaces and static routes for LEFT
myname LEFT
mygate 192.168.2.250
hostname.em0 {
inet 192.168.2.10 255.255.255.0 NONE
description 'front public net'
}
hostname.em1 {
inet 172.16.16.1 255.255.255.240 NONE
description 'mid private net'
}
hostname.gif1 {
inet 172.31.1.1 255.255.255.252 NONE
dest 172.31.1.2 tunnel 172.16.16.1 172.16.16.2
mtu 1400
description 'logical left/right link'
}
and for RIGHT, it is
myname RIGHT
hostname.em0 {
inet 172.16.16.2 255.255.255.240 NONE
description 'mid private net'
up
}
hostname.em1 {
inet 192.168.4.250 255.255.255.0 NONE
description 'back public net'
up
}
hostname.gif1 {
inet 172.31.1.2 255.255.255.252 NONE
dest 172.31.1.1 tunnel 172.16.16.2 172.16.16.1
mtu 1400
description 'logical right/left link'
up
}
Note that RIGHT has no default route, but LEFT does (to 192.168.2.250)
Both machines have /etc/sysctl.conf as follows:
#
# reasonable localizations for an intermediate router
#
ddb.panic=0 # 0=Do not drop into ddb on a
kernel panic
net.inet.ah.enable=1 # Enable AH IPsec protocol
net.inet.esp.enable=1 # Enable ESP IPsec protocol
net.inet.etherip.allow=1 # Enable gif-tunnels
net.inet.ip.forwarding=1 # allow forwarding (routing)
of packets
net.inet.tcp.sendspace=49152
net.inet.tcp.recvspace=65536
>How-To-Repeat:
To demonstrate the issue, configure OSPF on LEFT as follows
# $OpenBSD: ospfd.conf,v 1.4 2007/06/19 16:49:56 reyk Exp $
EXT='100'
LCL='25'
TUN='35'
router-id 192.168.2.10 # LEFT
no redistribute static
redistribute default set metric $EXT
area 0.0.0.0 {
auth-md 1 "FwUz30F4MpX4rRI2"
auth-md 2 "lWV0TusGgpU+aNVQ"
hello-interval 3
router-dead-time 12
interface em0 {
# 192.168.1/24
auth-type crypt
auth-md-keyid 2
metric $LCL
}
# interface em1 {
# # 172.16.16/28
# #
# auth-type crypt
# auth-md-keyid 1
# metric $LCL
# }
interface gif1 {
# 172.31.1/32
#
auth-type crypt
auth-md-keyid 1
metric $TUN
}
}
and on the RIGHT side, use this config:
# $OpenBSD: ospfd.conf,v 1.4 2007/06/19 16:49:56 reyk Exp $
EXT='100'
LCL='25'
TUN='35'
router-id 192.168.4.250 # RIGHT
no redistribute static
redistribute default set metric $EXT
area 0.0.0.0 {
auth-md 1 "FwUz30F4MpX4rRI2"
auth-md 2 "lWV0TusGgpU+aNVQ"
hello-interval 3
router-dead-time 12
interface gif1 {
# 172.31.1/32
#
auth-type crypt
auth-md-keyid 1
metric $TUN
}
# interface em0 {
# # 172.16.16/28
# #
# auth-type crypt
# auth-md-keyid 1
# metric $LCL
# }
interface em1 {
# 192.168.4/24
# (could be "passive" just as easily.)
#
auth-type crypt
auth-md-keyid 2
metric $LCL
}
}
The intent is to make the two OSPF daemons communicate via the
GIF tunnel rather than directly over the ethernet via their
em1/em0 link on the "mid private net". For various (sad,
tiresome) reasons, we don't want the physical addresses of the
mid net to leak out - we want the GIF logicals to be visible
instead.
BTW, I am seeing this on RIGHT:
gif1: DAD detected duplicate IPv6 address
fe80:0007::0a00:27ff:fe0e:734e: NS in/out=0/1, NA in=1
gif1: DAD complete for fe80:0007::0a00:27ff:fe0e:734e - duplicate found
gif1: manual intervention required
What's *that* about, I wonder? But it's an IPv6 thing, and this is
strictly an IPv4 bug report.
Anyway, fire up the respective OSPF daemons. Start order seems to
be immaterial. LEFT doesn't report any trouble, and the routing
state is all good:
LEFT:~ # ospfctl sho ne
ID Pri State DeadTime Address Iface
Uptime
192.168.4.250 1 FULL/P2P 00:00:09 172.31.1.2 gif1
02:33:02
LEFT:~ # ospfctl sho fib
flags: * = valid, O = OSPF, C = Connected, S = Static
Flags Prio Destination Nexthop
*S 8 0.0.0.0/0 192.168.2.250
*C 0 127.0.0.0/8 link#0
*S 8 127.0.0.0/8 127.0.0.1
* 4 127.0.0.1/32 127.0.0.1
*C 4 172.16.16.0/28 link#2
*O 32 172.31.1.1/32 172.31.1.2
* 4 172.31.1.2/32 172.31.1.1
*C 4 192.168.2.0/24 link#1
*O 32 192.168.4.0/24 172.31.1.2
*S 8 224.0.0.0/4 127.0.0.1
LEFT:~ # netstat -rnfinet
Routing tables
Internet:
Destination Gateway Flags Refs Use
Mtu Prio Iface
default 192.168.2.250 UGS 1 520
- 8 em0
127/8 127.0.0.1 UGRS 0 0
33200 8 lo0
127.0.0.1 127.0.0.1 UH 1 85
33200 4 lo0
172.16.16.0/28 link#2 UC 2 0
- 4 em1
172.16.16.1 08:00:27:8b:20:af UHLc 0 0
- 4 lo0
172.16.16.2 08:00:27:0e:73:4e UHLc 0 24023
- 4 em1
172.31.1.1/32 172.31.1.2 UG 0 0
- 32 gif1
172.31.1.2 172.31.1.1 UH 2 14
- 4 gif1
192.168.2/24 link#1 UC 2 0
- 4 em0
192.168.2.1 00:15:17:8a:c1:ee UHLc 1 4456
- 4 em0
192.168.2.250 00:00:24:cd:94:05 UHLc 1 0
- 4 em0
192.168.4/24 172.31.1.2 UG 0 0
- 32 gif1
224/4 127.0.0.1 URS 0 0
33200 8 lo0
However, on RIGHT not so good; first we see in /var/log/daemon as
follows:
Apr 28 10:21:07 right ospfd[22673]: startup
Apr 28 10:21:24 right ospfd[22673]: send_rtmsg: action 1,
prefix 0.0.0.0/0: Network is unreachable
and the default route isn't installed when we look -
RIGHT:~ # netstat -rnfinet
Routing tables
Internet:
Destination Gateway Flags Refs Use
Mtu Prio Iface
127/8 127.0.0.1 UGRS 0 0
33200 8 lo0
127.0.0.1 127.0.0.1 UH 1 87
33200 4 lo0
172.16.16.0/28 link#1 UC 2 0
- 4 em0
172.16.16.1 08:00:27:8b:20:af UHLc 0 22340
- 4 em0
172.16.16.2 08:00:27:0e:73:4e UHLc 0 0
- 4 lo0
172.31.1.1 172.31.1.2 UH 2 9
- 4 gif1
172.31.1.2/32 172.31.1.1 UG 0 0
- 32 gif1
192.168.2/24 172.31.1.1 UG 1 322
- 32 gif1
192.168.4/24 link#2 UC 0 0
- 4 em1
224/4 127.0.0.1 URS 0 0
33200 8 lo0
But even more oddly, the ospf daemon has a tangled-up view of the world:
right:~ # ospfctl sho fib
flags: * = valid, O = OSPF, C = Connected, S = Static
Flags Prio Destination Nexthop
*O 32 0.0.0.0/0 192.168.2.250
*C 0 127.0.0.0/8 link#0
*S 8 127.0.0.0/8 127.0.0.1
* 4 127.0.0.1/32 127.0.0.1
*C 4 172.16.16.0/28 link#1
* 4 172.31.1.1/32 172.31.1.2
*O 32 172.31.1.2/32 172.31.1.1
*O 32 192.168.2.0/24 172.31.1.1
*C 4 192.168.4.0/24 link#2
*S 8 224.0.0.0/4 127.0.0.1
right:~ # ospfctl sho rib de
Router Routing Table (Area 0.0.0.0)
Destination Nexthop Adv Router Path type
Cost Type
192.168.2.10 172.31.1.1 192.168.2.10 Intra-Area
35 AS
Network Routing Table (Area 0.0.0.0)
Destination Nexthop Adv Router Path type
Cost
172.31.1.2/32 172.31.1.1 192.168.2.10 Intra-Area
70
192.168.2.0/24 172.31.1.1 192.168.2.10 Intra-Area
60
External Routing Table
Destination Nexthop Adv Router Path type
Cost Cost 2
0.0.0.0/0 192.168.2.250 192.168.2.10 Type 1 ext
160 0
The bit about "*O 32 0.0.0.0/0 192.168.2.250" in the FIB looks
pretty darn bogus to me, 192.168.2.250/32 isn't reachable from
RIGHT. Ditto the 'Nexthop' value in the External Routing
Table from the RIB dump.
>Fix:
The fix is easy. Turn off the GIF clauses in the ospfd.confs, and
substitute the em[01] clauses that are commented out into
their places, and restart. The FIB on RIGHT becomes
RIGHT:~ # ospfctl sho fib
flags: * = valid, O = OSPF, C = Connected, S = Static
Flags Prio Destination Nexthop
*O 32 0.0.0.0/0 172.16.16.1
*C 0 127.0.0.0/8 link#0
*S 8 127.0.0.0/8 127.0.0.1
* 4 127.0.0.1/32 127.0.0.1
*C 4 172.16.16.0/28 link#1
*O 32 172.16.16.0/28 172.16.16.2
* 4 172.31.1.1/32 172.31.1.2
*O 32 192.168.2.0/24 172.16.16.1
*C 4 192.168.4.0/24 link#2
*S 8 224.0.0.0/4 127.0.0.1
and a correct default route shows up in 'netstat -rnfinet'.
regards,
Ross
--
Ross Alexander, (780) 675-6823 desk / (780) 689-0749 cell, [email protected]
"Always do right. This will gratify some people,
and astound the rest." -- Samuel Clemens
__
This communication is intended for the use of the recipient to whom it
is addressed, and may contain confidential, personal, and or privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take
action relying on it. Any communications received in error, or
subsequent reply, should be deleted or destroyed.
>Audit-Trail:
>Unformatted:
