Mailing List Archive

Hi Birger,

On Mon, Jun 14, 2004 at 11:42:25AM +0200, Birger Schmidt wrote:
> i want to have a point-to-point ospf interface on ethernet.
>
> configuration (on RT1 - RT2 same with swaped addresses) as follows:
>
> # ip configuration
> ip link set dev eth1 up
> ip address add 172.16.0.1 peer 172.16.0.2 dev eth1
>
>
> has anyone an idea how to get this config working?

Why are you trying to set up an ethernet interface as point-to-point?
And why are you using a /32 prefix length on that network? If you can explain
what you're trying to accomplish, I'm sure a solution is possible...

-Andy

Am Montag, 14. Juni 2004 14:32 schrieb Andrew J. Schorr:
> On Mon, Jun 14, 2004 at 11:42:25AM +0200, Birger Schmidt wrote:
> > i want to have a point-to-point ospf interface on ethernet.
> >
> > configuration (on RT1 - RT2 same with swaped addresses) as follows:
> >
> > # ip configuration
> > ip link set dev eth1 up
> > ip address add 172.16.0.1 peer 172.16.0.2 dev eth1
> >
> > has anyone an idea how to get this config working?
>
> Why are you trying to set up an ethernet interface as point-to-point?
in my example it is an ethX interface because i do my tests in user mode linux.
in my real world case it will be wlan interfaces (with point to point radio links)
that act exactly the same as ethernet interfaces.

> And why are you using a /32 prefix length on that network?
this is because i dont want to waste ip addresses on what are in fact point to
point links. i dont want to waste a /30 net for every link.

i want to give any wlan interface on a router the same ip address and this way
simplify the routing complexity. and i dont want a /30 net between rt1 and rt2
cause of the bad ecmp route into this net from rt4.

scenario:
a bunch of routers connected via point-to-point radio links like this for example:
+------+ +------+ +------+
| rt 1 |--------| rt 2 |--------| rt 3 |
+------+ +------+ +------+
| \ / \ / \
| \ +------+ / \ +------+ +------+
| \| rt 4 |--------| rt 5 |--------| rt 6 |
| +------+ +------+ +------+
\------------------------/

bye bye birger

On Mon, Jun 14, 2004 at 03:18:53PM +0200, Birger Schmidt wrote:
> in my example it is an ethX interface because i do my tests in user mode linux.
> in my real world case it will be wlan interfaces (with point to point radio links)
> that act exactly the same as ethernet interfaces.

OK, now I understand. When you use PtP interfaces with /32 addressing,
then zebra/ospfd assumes that the local address is not unique to
that interface, so it identifies the interface by the peer address.

I suspect that the neighbor is not being detected because your PtP
config is simply incompatible with the ethernet link layer. I think
it will probably work when you use an actual point-to-point link
layer (as it does when you set up the tunnel).

Why do you want to test without the GRE tunnel?

-Andy

P.S. I think that the current quagga code prefers you to specify the OSPF
network command using the exact peer address (when using PtP links). So, in
your example, it should say "network 172.16.0.2/32 area 0". It still matches
with your statement because it falls through to a test that was not designed
for PtP interfaces and gives you no actual control over which interfaces OSPF
will run on.

P.P.S. It is possible to use /31 addressing if you install my PtP patch.

On Monday 14 June 2004 15:46, Andrew J. Schorr wrote:
> On Mon, Jun 14, 2004 at 03:18:53PM +0200, Birger Schmidt wrote:
> > in my example it is an ethX interface because i do my tests in user mode linux.
> > in my real world case it will be wlan interfaces (with point to point radio links)
> > that act exactly the same as ethernet interfaces.
>
> OK, now I understand. When you use PtP interfaces with /32 addressing,
> then zebra/ospfd assumes that the local address is not unique to
> that interface, so it identifies the interface by the peer address.
and this assumtion is correct. i want to have the same ip on EVERY interface
of one router. this way one router uses less recources on the routing table.
and the routing is much more readable.

> I suspect that the neighbor is not being detected because your PtP
> config is simply incompatible with the ethernet link layer.
what do you mean whith this? the underlaying link in my working example
[quagga-dev 1268] is an working (pingable) ptp link configured via
ip a a localip peer remoteip dev ethX.

> I think it will probably work when you use an actual point-to-point link
> layer (as it does when you set up the tunnel).
this is proved by the tests presented in this mail: [quagga-dev 1268]

> Why do you want to test without the GRE tunnel?
for the test it is not realy important to me. but for production use
i dont want the overhead of the tunnel on the wireless link.

> P.S. I think that the current quagga code prefers you to specify the OSPF
> network command using the exact peer address (when using PtP links). So, in
> your example, it should say "network 172.16.0.2/32 area 0". It still matches
> with your statement because it falls through to a test that was not designed
> for PtP interfaces and gives you no actual control over which interfaces OSPF
> will run on.
i tried this too and it didnt work either.

> P.P.S. It is possible to use /31 addressing if you install my PtP patch.
i didnt tried this but i dont want it. cause i want to use ip addresses more than
one away from each other.

in my example say 192.168.0.X is the ip of a router (on every interface)
where X is the number in rt X.
+------+ +------+ +------+
| rt 1 |--------| rt 2 |--------| rt 3 |
+------+ +------+ +------+
| \ / \ / \
| \ +------+ / \ +------+ +------+
| \| rt 4 |--------| rt 5 |--------| rt 6 |
| +------+ +------+ +------+
\------------------------/

and the number of routers will go up to 200 in production.

bye bye birger

On Mon, Jun 14, 2004 at 04:24:07PM +0200, Birger Schmidt wrote:
> > Why do you want to test without the GRE tunnel?
> for the test it is not realy important to me. but for production use
> i dont want the overhead of the tunnel on the wireless link.

Is the wireless link a broadcast medium like an ethernet? Or is it
a point-to-point link more like the GRE tunnel? If it's essentially
a PtP link, then I don't think you'll have any problems. If broadcast,
then you may need that tunnel. But I'm not clear on whether this
is a quagga issue or a kernel issue, since I have never tried to
run an ethernet interface in point-to-point mode.

Do you have any of these wireless links up and running? What do you
get when you run "ip link show"? For example, my ethernet interfaces
look like this:

$ ip link show eth0
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:e0:81:27:ca:33 brd ff:ff:ff:ff:ff:ff

And here's what a point-to-point T1 link looks like:

$ ip link show hdlc0
9: hdlc0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc teql0 qlen 100
link/rawhdlc

So which flag applies to the link: BROADCAST or POINTOPOINT?
If it says POINTOPOINT, I don't think you will have any problems...

-Andy

On Monday 14 June 2004 17:17, Andrew J. Schorr wrote:
> Is the wireless link a broadcast medium like an ethernet?
> If broadcast, then you may need that tunnel. But I'm not clear
> on whether this is a quagga issue or a kernel issue, since
> I have never tried to run an ethernet interface in point-to-point
> mode.
if i wanna patch quagga for my issue - where i have to do this.
say which part of the code is the decission ptp vs. broadcast is made?
> Do you have any of these wireless links up and running? What do you
> get when you run "ip link show"?
9: ath1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc prio qlen 199
link/ether 00:01:24:70:49:e1 brd ff:ff:ff:ff:ff:ff

> So which flag applies to the link: BROADCAST or POINTOPOINT?
> If it says POINTOPOINT, I don't think you will have any problems...
as you can see: BROADCAST
so what should i do now?

bye bye birger

On Mon, Jun 14, 2004 at 05:56:03PM +0200, Birger Schmidt wrote:
> On Monday 14 June 2004 17:17, Andrew J. Schorr wrote:
> > Is the wireless link a broadcast medium like an ethernet?
> > If broadcast, then you may need that tunnel. But I'm not clear
> > on whether this is a quagga issue or a kernel issue, since
> > I have never tried to run an ethernet interface in point-to-point
> > mode.
> if i wanna patch quagga for my issue - where i have to do this.
> say which part of the code is the decission ptp vs. broadcast is made?

I'm not certain. I must confess that I do not understand why your
tcpdump shows the ospf hello packet with a source address that equals
the peer address. I'm looking at the ospfd code in ospf_packet.c to
construct the hello packet, but I don't see why that happens.
The code in ospf_write seems to set the packet source address here:
iph.ip_src.s_addr = oi->address->u.prefix4.s_addr;
and that should not be the peer address...

If you run the "show interface ptp" command inside zebra, does it show
the interface configured properly with the correct local and
peer addresses? Does it say something like this:

inet 172.16.0.1/32 pointopoint 172.16.0.2

Or does it instead think that 172.16.0.2 is a broadcast address?

What does tcpdump show when you just ping across that interface
(ethernet configured as PtP)? Does it look normal?

-Andy

On Monday 14 June 2004 18:28, Andrew J. Schorr wrote:
> I'm not certain. I must confess that I do not understand why your
> tcpdump shows the ospf hello packet with a source address that equals
> the peer address. I'm looking at the ospfd code in ospf_packet.c to
> construct the hello packet, but I don't see why that happens.
> The code in ospf_write seems to set the packet source address here:
> iph.ip_src.s_addr = oi->address->u.prefix4.s_addr;
> and that should not be the peer address...
>
> If you run the "show interface ptp" command inside zebra, does it show
> the interface configured properly with the correct local and
> peer addresses? Does it say something like this:
>
> inet 172.16.0.1/32 pointopoint 172.16.0.2
>
> Or does it instead think that 172.16.0.2 is a broadcast address?
zebra# show interface eth1
Interface eth1 is up, line protocol detection is disabled
index 5 metric 1 mtu 1500 <UP,BROADCAST,RUNNING,ALLMULTI,MULTICAST>
HWaddr: 00:00:af:fe:01:01
inet 172.16.0.2/32
inet6 fe80::200:afff:fefe:101/64
input packets 172, bytes 11360, dropped 0, multicast packets 0
input errors 0, length 0, overrun 0, CRC 0, frame 0, fifo 0, missed 0
output packets 131, bytes 10294, dropped 0
output errors 0, aborted 0, carrier 0, fifo 0, heartbeat 0, window 0
collisions 0

# ip a l eth1
5: eth1: <BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:00:af:fe:01:01 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.1 peer 172.16.0.2/32 scope global eth1
inet6 fe80::200:afff:fefe:101/64 scope link

this two dumps are from the same machine. looks wrong to me.
zebra thinks that the peer address is the interface address of the eth device.

> What does tcpdump show when you just ping across that interface
> (ethernet configured as PtP)? Does it look normal?
yes it does.

# tcpdump -i eth1 -vv
17:09:22.884817 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 84) 172.16.0.1 > 172.16.0.2: icmp 64: echo request seq 0
17:09:22.884829 IP (tos 0x0, ttl 64, id 40512, offset 0, flags [none], length: 84) 172.16.0.2 > 172.16.0.1: icmp 64: echo reply seq 0

bye bye birger

On Mon, Jun 14, 2004 at 07:15:39PM +0200, Birger Schmidt wrote:
> zebra# show interface eth1
> Interface eth1 is up, line protocol detection is disabled
> index 5 metric 1 mtu 1500 <UP,BROADCAST,RUNNING,ALLMULTI,MULTICAST>
> HWaddr: 00:00:af:fe:01:01
> inet 172.16.0.2/32
> inet6 fe80::200:afff:fefe:101/64
> input packets 172, bytes 11360, dropped 0, multicast packets 0
> input errors 0, length 0, overrun 0, CRC 0, frame 0, fifo 0, missed 0
> output packets 131, bytes 10294, dropped 0
> output errors 0, aborted 0, carrier 0, fifo 0, heartbeat 0, window 0
> collisions 0
>
> # ip a l eth1
> 5: eth1: <BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc pfifo_fast qlen 1000
> link/ether 00:00:af:fe:01:01 brd ff:ff:ff:ff:ff:ff
> inet 172.16.0.1 peer 172.16.0.2/32 scope global eth1
> inet6 fe80::200:afff:fefe:101/64 scope link
>
> this two dumps are from the same machine. looks wrong to me.
> zebra thinks that the peer address is the interface address of the eth device.

Great, now we're making some progress. You're running linux, right?
This looks like a problem in zebra/rt_netlink.c in the netlink_interface_addr()
function. For a non-point-to-point interface, the code
is using RTA_DATA (tb[IFA_ADDRESS]) as the local interface address.
I suspect that what you really need is to have addr = RTA_DATA (tb[IFA_LOCAL])
and broad = RTA_DATA (tb[IFA_ADDRESS]) (just like for PtP interface0.

Here is what appears to be a relevant comment from <linux/rtnetlink.h>:

/*
Important comment:
IFA_ADDRESS is prefix address, rather than local interface address.
It makes no difference for normally configured broadcast interfaces,
but for point-to-point IFA_ADDRESS is DESTINATION address,
local address is supplied in IFA_LOCAL attribute.
*/

So perhaps the code in netlink_interface_addr() should use IFA_LOCAL
instead of IFA_ADDRESS? I'm not sure whether this would break anything.

Unfortunately, this still doesn't solve the problem of getting the
peer address into zebra, and I think you will need that to get this
working. For that, you may have to patch zebra to allow you to set
the peer address. Unfortunately, the zebra "ip address" command
currently allows you to set only the local address, not the peer address.
So you may need to add an interface subcommand that allows you to set
the peer address manually.

If you could somehow convince the kernel that this was a point-to-point
device instead of a broadcast device, that would be ideal, then zebra
would load the interface properly (if IFF_POINTOPOINT were set on
the interface). So an alternative might be to try to patch the
device driver for the wireless link to configure it as point-to-point
instead of broadcast.

-Andy

On Mon, Jun 14, 2004 at 02:53:22PM -0400, Andrew J. Schorr wrote:
> > zebra thinks that the peer address is the interface address of the eth device.
> Great, now we're making some progress. You're running linux, right?
correct.

> This looks like a problem in zebra/rt_netlink.c in the netlink_interface_addr()
> function. For a non-point-to-point interface, the code
> is using RTA_DATA (tb[IFA_ADDRESS]) as the local interface address.
> I suspect that what you really need is to have addr = RTA_DATA (tb[IFA_LOCAL])
> and broad = RTA_DATA (tb[IFA_ADDRESS]) (just like for PtP interface0.
>
> Here is what appears to be a relevant comment from <linux/rtnetlink.h>:
>
> /*
> Important comment:
> IFA_ADDRESS is prefix address, rather than local interface address.
> It makes no difference for normally configured broadcast interfaces,
> but for point-to-point IFA_ADDRESS is DESTINATION address,
> local address is supplied in IFA_LOCAL attribute.
> */
>
> So perhaps the code in netlink_interface_addr() should use IFA_LOCAL
> instead of IFA_ADDRESS? I'm not sure whether this would break anything.
>
> Unfortunately, this still doesn't solve the problem of getting the
> peer address into zebra, and I think you will need that to get this
> working. For that, you may have to patch zebra to allow you to set
> the peer address. Unfortunately, the zebra "ip address" command
> currently allows you to set only the local address, not the peer address.
> So you may need to add an interface subcommand that allows you to set
> the peer address manually.
>
> If you could somehow convince the kernel that this was a point-to-point
> device instead of a broadcast device, that would be ideal, then zebra
> would load the interface properly (if IFF_POINTOPOINT were set on
> the interface). So an alternative might be to try to patch the
> device driver for the wireless link to configure it as point-to-point
> instead of broadcast.

ok. at least one of that options should work. i will take a
further look into it this week.
no time tomorow. :-(

thanx a lot andy and

bye bye birger

On Mon, 14 Jun 2004, Birger Schmidt wrote:

> 9: ath1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc prio qlen 199
> link/ether 00:01:24:70:49:e1 brd ff:ff:ff:ff:ff:ff

> as you can see: BROADCAST
> so what should i do now?

Run OSPF in ye normal broadcast interface mode (ie using multicast).
If your broadcast links have problems with multicast you can in
theory specify 'no broadcast' and explicitely configure neighbours
via 'neighour <address> ...' to operate in unicast mode (effectively
PtP iirc).

> bye bye birger

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
"Thank heaven for startups; without them we'd never have any advances."
-- Seymour Cray

On Mon, Jun 14, 2004 at 10:54:53PM -0400, Paul Jakma wrote:
> Run OSPF in ye normal broadcast interface mode (ie using multicast).
> If your broadcast links have problems with multicast you can in
> theory specify 'no broadcast' and explicitely configure neighbours
> via 'neighour <address> ...' to operate in unicast mode (effectively
> PtP iirc).

That makes sense to me, but Birger says he wants to do this without
allocating any address space for the wireless links...

-Andy

On Tue, 15 Jun 2004, Andrew J. Schorr wrote:

> That makes sense to me, but Birger says he wants to do this without
> allocating any address space for the wireless links...

Each link will need address space of some kind.

> -Andy

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Just because I turn down a contract on a guy doesn't mean he isn't going
to get hit.
-- Joey

On Tue, Jun 15, 2004 at 07:04:07AM -0400, Paul Jakma wrote:
> On Tue, 15 Jun 2004, Andrew J. Schorr wrote:
>
> >That makes sense to me, but Birger says he wants to do this without
> >allocating any address space for the wireless links...
>
> Each link will need address space of some kind.
>

Based on his previous messages, I think he wants to assign one IP address to
each system, but each system will have multiple wireless links. Please correct
me if I'm wrong, but I think then that the kernel routing can only work if each
interface is set up as a PtP interface that is essentially identified by the
remote peer address. If he configures the interfaces as normal broadcast
links, I think he will need to provide unique local addresses for each
interface, won't he?

-Andy

hi paul,

On Tuesday 15 June 2004 04:54, Paul Jakma wrote:
> > 9: ath1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc prio qlen 199
> > link/ether 00:01:24:70:49:e1 brd ff:ff:ff:ff:ff:ff
> > as you can see: BROADCAST
> > so what should i do now?
> Run OSPF in ye normal broadcast interface mode (ie using multicast).
> If your broadcast links have problems with multicast you can in
> theory specify 'no broadcast' and explicitely configure neighbours
> via 'neighour <address> ...' to operate in unicast mode (effectively
> PtP iirc).
i think NO ospf configuration will work on a ethernet link configured via
ip address add x.x.x.x peer y.y.y.y
because zebra takes the peer address as source - that is as wrong as it could be.
and of course i testet it. without success.

take a deeeeeep look at the ip addresses in my testnet (all from the same host):

# ip address list eth1
1: eth1: <BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:00:af:fe:01:01 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.1 peer 172.16.0.2/32 scope global eth1

zebra# show interface eth1
Interface eth1 is up, line protocol detection is disabled
index 5 metric 1 mtu 1500 <UP,BROADCAST,RUNNING,ALLMULTI,MULTICAST>
HWaddr: 00:00:af:fe:01:01
inet 172.16.0.2/32
input packets 108, bytes 7076, dropped 0, multicast packets 0
input errors 0, length 0, overrun 0, CRC 0, frame 0, fifo 0, missed 0
output packets 78, bytes 5960, dropped 0
output errors 0, aborted 0, carrier 0, fifo 0, heartbeat 0, window 0
collisions 0

this dosn't hapens if the link type is link/gre (POINTOPOINT)
like it is if i define it via:

ip tunnel add tunnel mode gre remote 172.16.0.2
ip address add 192.168.0.1 peer 192.168.0.2 dev tunnel

# ip address list tunnel
8: tunnel@NONE: <POINTOPOINT,NOARP,UP> mtu 1476 qdisc noqueue
link/gre 0.0.0.0 peer 172.16.0.2
inet 192.168.0.1 peer 192.168.0.2/32 scope global bio

bye bye birger

On Tuesday 15 June 2004 13:04, Paul Jakma wrote:
> > That makes sense to me, but Birger says he wants to do this without
> > allocating any address space for the wireless links...
> Each link will need address space of some kind.
of course i will use some addresses on the links. but not more than nesesary.
just one address per router. and this address on every interface.

my scenario is described at the bottom of the [quagga-dev 1274] mail.

bye bye birger

It seems like it works as expected. In PtP, OSPF is supposed to announce
the peer.

I remember that it is supposed to be for some very obscure reasons like
allowing for network boots and for allowing pings to be directed into
the interface address specified.

If you don't want it to do this, then you need to have the two
interfaces share a subnet.

Vik

-----Original Message-----
From: quagga-dev-bounces@lists.quagga.net
[mailto:quagga-dev-bounces@lists.quagga.net] On Behalf Of Birger Schmidt
Sent: Monday, June 14, 2004 2:42 AM
To: quagga-dev@lists.quagga.net
Subject: [quagga-dev 1269] point-to-point ospf on ethernet not working

hi there,

i want to have a point-to-point ospf interface on ethernet.

configuration (on RT1 - RT2 same with swaped addresses) as follows:

# ip configuration
ip link set dev eth1 up
ip address add 172.16.0.1 peer 172.16.0.2 dev eth1


# ospfd.conf
interface ptp
description point-to-point link
ip ospf network point-to-point
router ospf
ospf router-id 192.168.0.1
network 172.16.0.0/24 area 0


and now the strange tcpdump!
09:08:06.232633 IP (tos 0xc0, ttl 1, id 6605, offset 0, flags [none],
length: 64) 172.16.0.2 > 224.0.0.5: OSPFv2, Hello (1), length: 44
Router-ID: 192.168.0.1, Backbone Area, Authentication Type: none
(0)
Options: [External]
Hello Timer: 10s, Dead Timer 40s, Mask: 0.0.0.0, Priority: 1
09:08:07.392806 IP (tos 0xc0, ttl 1, id 44817, offset 0, flags [none],
length: 64) 172.16.0.1 > 224.0.0.5: OSPFv2, Hello (1), length: 44
Router-ID: 192.168.0.2, Backbone Area, Authentication Type: none
(0)
Options: [External]
Hello Timer: 10s, Dead Timer 40s, Mask: 0.0.0.0, Priority: 1

RT1 (192.168.0.1) sends hello with source address 172.16.0.2 and vice
versa.


as expected (1-ospf> show ip ospf interface):
eth1 is up
Internet Address 172.16.0.2/32, Area 0.0.0.0
Router ID 192.168.0.1, Network Type POINTOPOINT, Cost: 10
Transmit Delay is 1 sec, State Point-To-Point, Priority 1
No designated router on this network
No backup designated router on this network
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:07
Neighbor Count is 0, Adjacent neighbor count is 0


and the coresponding lines form ospfd.log:
2004/06/14 09:25:24 OSPF: interface 172.16.0.2 join AllSPFRouters
Multicast group.
2004/06/14 09:25:24 OSPF: ISM[eth1:172.16.0.2]: Down (InterfaceUp)
2004/06/14 09:25:24 OSPF: ISM[eth1:172.16.0.2]: State change Down ->
Point-To-Point
2004/06/14 09:25:24 OSPF: ospf_apiserver_ism_change
2004/06/14 09:25:24 OSPF: oi->ifp->name=eth1
2004/06/14 09:25:24 OSPF: old_state=1
2004/06/14 09:25:24 OSPF: oi->state=4
2004/06/14 09:25:24 OSPF: interface 172.16.0.2 join AllSPFRouters
Multicast group.
2004/06/14 09:25:24 OSPF: ISM[eth1:172.16.0.2]: ism_ignore called
2004/06/14 09:25:24 OSPF: ISM[eth1:172.16.0.2]: Point-To-Point
(InterfaceUp)


has anyone an idea how to get this config working?

thanx in advance and

bye bye birger

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev

On Tue, 22 Jun 2004, Anantha, Vik wrote:

> ip link set dev eth1 up
> ip address add 172.16.0.1 peer 172.16.0.2 dev eth1

PtP on ethernet??

> RT1 (192.168.0.1) sends hello with source address 172.16.0.2 and vice
> versa.

hmm.

> and the coresponding lines form ospfd.log:
> 2004/06/14 09:25:24 OSPF: interface 172.16.0.2 join AllSPFRouters
> Multicast group.
> 2004/06/14 09:25:24 OSPF: ISM[eth1:172.16.0.2]: Down (InterfaceUp)
> 2004/06/14 09:25:24 OSPF: ISM[eth1:172.16.0.2]: State change Down ->
> Point-To-Point
> 2004/06/14 09:25:24 OSPF: ospf_apiserver_ism_change
> 2004/06/14 09:25:24 OSPF: oi->ifp->name=eth1
> 2004/06/14 09:25:24 OSPF: old_state=1
> 2004/06/14 09:25:24 OSPF: oi->state=4
> 2004/06/14 09:25:24 OSPF: interface 172.16.0.2 join AllSPFRouters
> Multicast group.
> 2004/06/14 09:25:24 OSPF: ISM[eth1:172.16.0.2]: ism_ignore called
> 2004/06/14 09:25:24 OSPF: ISM[eth1:172.16.0.2]: Point-To-Point
> (InterfaceUp)

can you run with 'debug ospf zebra', how is zebra describing the
link?

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Stellar rays prove fibbing never pays. Embezzlement is another matter.

Maybe Birger can follow up as it was his question, but I was under the
impression that the "ip ospf network "<network-type>" command could
override the default network-type that got picked.

So, even though the device type is Ethernet, the following configuration
command as detailed in mail [quagga-dev 1269] should make the ethernet
interface as a point to point.

interface ptp
description point-to-point link
ip ospf network point-to-point



-----Original Message-----
From: Paul Jakma [mailto:paul@clubi.ie]
Sent: Tuesday, June 22, 2004 8:40 PM
To: Anantha, Vik
Cc: quagga-dev@lists.quagga.net
Subject: Re: [quagga-dev 1309] Re: point-to-point ospf on ethernet not
working

On Tue, 22 Jun 2004, Anantha, Vik wrote:

> ip link set dev eth1 up
> ip address add 172.16.0.1 peer 172.16.0.2 dev eth1

PtP on ethernet??

> RT1 (192.168.0.1) sends hello with source address 172.16.0.2 and vice
> versa.

hmm.

> and the coresponding lines form ospfd.log:
> 2004/06/14 09:25:24 OSPF: interface 172.16.0.2 join AllSPFRouters
> Multicast group.
> 2004/06/14 09:25:24 OSPF: ISM[eth1:172.16.0.2]: Down (InterfaceUp)
> 2004/06/14 09:25:24 OSPF: ISM[eth1:172.16.0.2]: State change Down ->
> Point-To-Point
> 2004/06/14 09:25:24 OSPF: ospf_apiserver_ism_change
> 2004/06/14 09:25:24 OSPF: oi->ifp->name=eth1
> 2004/06/14 09:25:24 OSPF: old_state=1
> 2004/06/14 09:25:24 OSPF: oi->state=4
> 2004/06/14 09:25:24 OSPF: interface 172.16.0.2 join AllSPFRouters
> Multicast group.
> 2004/06/14 09:25:24 OSPF: ISM[eth1:172.16.0.2]: ism_ignore called
> 2004/06/14 09:25:24 OSPF: ISM[eth1:172.16.0.2]: Point-To-Point
> (InterfaceUp)

can you run with 'debug ospf zebra', how is zebra describing the
link?

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Stellar rays prove fibbing never pays. Embezzlement is another matter.

On Tue, Jun 22, 2004 at 07:25:32PM -0700, Anantha, Vik wrote:
> It seems like it works as expected. In PtP, OSPF is supposed to announce
> the peer.
>
> I remember that it is supposed to be for some very obscure reasons like
> allowing for network boots and for allowing pings to be directed into
> the interface address specified.
>
> If you don't want it to do this, then you need to have the two
> interfaces share a subnet.

As discussed previously in this thread, there are problems with how
zebra reads the address information from the netlink socket when
the ethernet is configured as a PtP link. Please take a look
at [quagga-dev 1280].

-Andy