How to configure an ethernet interface which has point to point link

[mrchit_2000]

Hi all,

I am having trouble with bringing up an ethernet interfaces on my system.
Here is my situation. I have a system which have 2 CPU. Each of the CPU has
a MAC interface connected directly to the other via RGMII without phys. This
makes me think this is a point-to-point link. When configuring the
interfaces on the 2 CPU, I use ifconfig :
ifconfig eth2 10.10.10.10 10.10.10.22 netmask 255.255.255.0

The interfaces are setup in driver with these flags: IFF_POINTOPOINT,
IFF_NO_ARP, IFF_SIMPLEX and IFF_NOTRAILER. Here is the display when do
ifconfig eth2:

ifconfig eth2
octmac2: flags=8f1<UP,POINTOPOINT,NOTRAILERS,RUNNING,NOARP,SIMPLEX> mtu 1500
context 0x40080001
address: 00:30:88:02:52:02
media: Ethernet manual (none)
inet 10.10.10.10 -> 10.10.10.22 netmask 0xffffffff


But when a packet is sent through eth2 from 10.10.10.10 to 10.10.10.22, the
kernel tries to do arp resolve for 10.10.10.22 by calling arpresolve
function in ether_output, and the arp resolve failed so the packet never
sent out. When doing arp -a, there is no arp entries, but route show showing
a route though.

My question is how should I configure/setup the interface in this situation,
where 2 CPU connected directly to each other via ethernet. I believe this
has nothing to do with kernel, but just an issue of configuration the
interface so that the kernel knows not to do arp or to handle it specially
for a point to point link.

Can someone please help pointing out what I did wrong and need to to?

Thanks a lot in advance,

-Ln

[David Young]

Post by mrchit_2000
Hi all,
I am having trouble with bringing up an ethernet interfaces on my system.
Here is my situation. I have a system which have 2 CPU. Each of the CPU has
a MAC interface connected directly to the other via RGMII without phys. This
makes me think this is a point-to-point link. When configuring the
ifconfig eth2 10.10.10.10 10.10.10.22 netmask 255.255.255.0
The interfaces are setup in driver with these flags: IFF_POINTOPOINT,
IFF_NO_ARP, IFF_SIMPLEX and IFF_NOTRAILER. Here is the display when do

Are you able to modify the driver? Throughout the ethernet common code,
NetBSD will assume a broadcast interface where ARP works. If you follow
the convention, you may have an easier time.

Dave

[mrchit_2000]

Post by David Young

Post by mrchit_2000
Hi all,
I am having trouble with bringing up an ethernet interfaces on my system.
Here is my situation. I have a system which have 2 CPU. Each of the CPU has
a MAC interface connected directly to the other via RGMII without phys. This
makes me think this is a point-to-point link. When configuring the
ifconfig eth2 10.10.10.10 10.10.10.22 netmask 255.255.255.0
The interfaces are setup in driver with these flags: IFF_POINTOPOINT,
IFF_NO_ARP, IFF_SIMPLEX and IFF_NOTRAILER. Here is the display when do

Are you able to modify the driver? Throughout the ethernet common code,
NetBSD will assume a broadcast interface where ARP works. If you follow
the convention, you may have an easier time.

I have access to the driver but not sure what to change. I want the kernel
not to do any arp on the interface, can I do that? I guess one way is to add
a static arp entry, but any other way? Anyway to tell the kernel just send
out the packet to the interface and the other end just pickup without
looking at the destination MAC address? How normally is a point to point
link interface configured?

Thanks a lot,
-Ln

[Manuel Bouyer]

Post by mrchit_2000

Post by David Young

Post by mrchit_2000
Hi all,
I am having trouble with bringing up an ethernet interfaces on my system.
Here is my situation. I have a system which have 2 CPU. Each of the CPU has
a MAC interface connected directly to the other via RGMII without phys. This
makes me think this is a point-to-point link. When configuring the
ifconfig eth2 10.10.10.10 10.10.10.22 netmask 255.255.255.0
The interfaces are setup in driver with these flags: IFF_POINTOPOINT,
IFF_NO_ARP, IFF_SIMPLEX and IFF_NOTRAILER. Here is the display when do

Are you able to modify the driver? Throughout the ethernet common code,
NetBSD will assume a broadcast interface where ARP works. If you follow
the convention, you may have an easier time.

I have access to the driver but not sure what to change. I want the kernel
not to do any arp on the interface, can I do that? I guess one way is to add
a static arp entry, but any other way? Anyway to tell the kernel just send
out the packet to the interface and the other end just pickup without
looking at the destination MAC address? How normally is a point to point
link interface configured?

I suspect even tough it's kind of point to point, your hardware still needs
an ethenet address to send the packet to. Real P2P links don't have address
at the physical layer. Soi I think in your case you still need to
have arp entries.

[Ignatios Souvatzis]

Post by David Young

Post by mrchit_2000
Hi all,
I am having trouble with bringing up an ethernet interfaces on my system.
Here is my situation. I have a system which have 2 CPU. Each of the CPU has
a MAC interface connected directly to the other via RGMII without phys. This
makes me think this is a point-to-point link. When configuring the
ifconfig eth2 10.10.10.10 10.10.10.22 netmask 255.255.255.0
The interfaces are setup in driver with these flags: IFF_POINTOPOINT,
IFF_NO_ARP, IFF_SIMPLEX and IFF_NOTRAILER. Here is the display when do

Are you able to modify the driver? Throughout the ethernet common code,
NetBSD will assume a broadcast interface where ARP works. If you follow
the convention, you may have an easier time.

Or... would arp -s 10.10.10.22 macaddress help you?

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[mrchit_2000]

Post by Ignatios Souvatzis

Post by mrchit_2000

Post by mrchit_2000
Hi all,
I am having trouble with bringing up an ethernet interfaces on my

system.

Post by mrchit_2000
Here is my situation. I have a system which have 2 CPU. Each of the CPU

has

Post by mrchit_2000
a MAC interface connected directly to the other via RGMII without phys.

This

Post by mrchit_2000
makes me think this is a point-to-point link. When configuring the
ifconfig eth2 10.10.10.10 10.10.10.22 netmask 255.255.255.0
The interfaces are setup in driver with these flags: IFF_POINTOPOINT,
IFF_NO_ARP, IFF_SIMPLEX and IFF_NOTRAILER. Here is the display when do

Are you able to modify the driver? Throughout the ethernet common code,
NetBSD will assume a broadcast interface where ARP works. If you follow
the convention, you may have an easier time.

Or... would arp -s 10.10.10.22 macaddress help you?
-is

I tried ' arp -s 10.10.10.22 macaddress ', it gives me this messages:

arp: writing to routing socket: No such process
arp: 10.10.10.22: No such process

What does it mean?

Thanks,
-Ln

[Ignatios Souvatzis]

Post by mrchit_2000
a static arp entry, but any other way? Anyway to tell the kernel just send
out the packet to the interface and the other end just pickup without
looking at the destination MAC address?

This won't work. The other end's *hardware* needs an ethernet address to
listen to.

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Gert Doering]

Post by Ignatios Souvatzis

Post by mrchit_2000
a static arp entry, but any other way? Anyway to tell the kernel just send
out the packet to the interface and the other end just pickup without
looking at the destination MAC address?

This won't work. The other end's *hardware* needs an ethernet address to
listen to.

Not necessarily - if the receiving end is in promiscuous mode, the
ethernet chip will happily accept whatever packets come in...

gert

[Gert Doering]

Hi,

Post by Manuel Bouyer

Post by Gert Doering
If it's a pure internal point-to-point link, you could save the effort of
maintaining ARP entries (either setting them up statically, or actually
running the ARP protocol). Less overhead...

No. You still need to send something in the ethernet header, that will
be properly received by the hardware engine on the other end.

"ff:ff:ff:ff:ff:ff"

gert

[Manuel Bouyer]

Post by Gert Doering
Hi,

Post by Manuel Bouyer

Post by Gert Doering
If it's a pure internal point-to-point link, you could save the effort of
maintaining ARP entries (either setting them up statically, or actually
running the ARP protocol). Less overhead...

No. You still need to send something in the ethernet header, that will
be properly received by the hardware engine on the other end.

"ff:ff:ff:ff:ff:ff"

Sure. This is close to getting an arp entry, though.

[Gert Doering]

Hi,

Post by Gert Doering

Post by Manuel Bouyer

Post by Gert Doering
If it's a pure internal point-to-point link, you could save the effort of
maintaining ARP entries (either setting them up statically, or actually
running the ARP protocol). Less overhead...

No. You still need to send something in the ethernet header, that will
be properly received by the hardware engine on the other end.

"ff:ff:ff:ff:ff:ff"

Ah. I smell a misunderstanding here - I wasn't talking about "packet
overhead" but about "processing overhead" due to ARP handling.

The packet format cannot change, of course, but it could carry the
broadcast MAC as destination address.

gert

[Ignatios Souvatzis]

Post by Steven M. Bellovin
On Fri, 15 Jun 2007 22:17:16 +0200

Post by Manuel Bouyer

Post by Gert Doering
Hi,

Post by Gert Doering

Post by Manuel Bouyer

Post by Gert Doering
If it's a pure internal point-to-point link, you could save
the effort of maintaining ARP entries (either setting them up
statically, or actually running the ARP protocol). Less
overhead...

No. You still need to send something in the ethernet header,
that will be properly received by the hardware engine on the
other end.

"ff:ff:ff:ff:ff:ff"

Ah. I smell a misunderstanding here - I wasn't talking about
"packet overhead" but about "processing overhead" due to ARP
handling.
The packet format cannot change, of course, but it could carry the
broadcast MAC as destination address.

Sure. But the ARP handling overhead should be very small, as you have
to lookup the route in the routing table anyway. When arp is needed
the entry is already in the cache. Intead of a lookup in the cache
you'd need a test to see if the interface is in p2p more or not. And
a similar test in the receive path, which would not be needed
otherwise.

Right. And I believe that packets sent to a broadcast address are
received by the sender, too, on some NICs. This is even more overhead.

_And_ packets being received as broadcast/multicast are flagged as
broadcast/multicast, and are dropped later, if their IP address is a
unicast one.

At least last I looked, which has been a few years.

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Ignatios Souvatzis

Post by Steven M. Bellovin
Right. And I believe that packets sent to a broadcast address are
received by the sender, too, on some NICs. This is even more overhead.

_And_ packets being received as broadcast/multicast are flagged as
broadcast/multicast, and are dropped later, if their IP address is a
unicast one.

Yes. But you can not flag them if the link is configured as P2P.
But it's yet another test in the path, compared to a single MAC address lookup
in the route cache.

[Manuel Bouyer]

Post by Gert Doering
Hi,

Post by Gert Doering

Post by Manuel Bouyer

Post by Gert Doering
If it's a pure internal point-to-point link, you could save the effort of
maintaining ARP entries (either setting them up statically, or actually
running the ARP protocol). Less overhead...

No. You still need to send something in the ethernet header, that will
be properly received by the hardware engine on the other end.

"ff:ff:ff:ff:ff:ff"

Ah. I smell a misunderstanding here - I wasn't talking about "packet
overhead" but about "processing overhead" due to ARP handling.
The packet format cannot change, of course, but it could carry the
broadcast MAC as destination address.

Sure. But the ARP handling overhead should be very small, as you have to
lookup the route in the routing table anyway. When arp is needed the entry
is already in the cache. Intead of a lookup in the cache you'd need a
test to see if the interface is in p2p more or not. And a similar test
in the receive path, which would not be needed otherwise.

[Steven M. Bellovin]

On Fri, 15 Jun 2007 22:17:16 +0200

Post by Manuel Bouyer

Post by Gert Doering
Hi,

Post by Gert Doering

Post by Manuel Bouyer

Post by Gert Doering
If it's a pure internal point-to-point link, you could save
the effort of maintaining ARP entries (either setting them up
statically, or actually running the ARP protocol). Less
overhead...

No. You still need to send something in the ethernet header,
that will be properly received by the hardware engine on the
other end.

"ff:ff:ff:ff:ff:ff"

Ah. I smell a misunderstanding here - I wasn't talking about
"packet overhead" but about "processing overhead" due to ARP
handling.
The packet format cannot change, of course, but it could carry the
broadcast MAC as destination address.

Sure. But the ARP handling overhead should be very small, as you have
to lookup the route in the routing table anyway. When arp is needed
the entry is already in the cache. Intead of a lookup in the cache
you'd need a test to see if the interface is in p2p more or not. And
a similar test in the receive path, which would not be needed
otherwise.

Right. And I believe that packets sent to a broadcast address are
received by the sender, too, on some NICs. This is even more overhead.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by mrchit_2000

Post by David Young

Post by mrchit_2000
Hi all,
I am having trouble with bringing up an ethernet interfaces on my system.
Here is my situation. I have a system which have 2 CPU. Each of the CPU has
a MAC interface connected directly to the other via RGMII without phys. This
makes me think this is a point-to-point link. When configuring the
ifconfig eth2 10.10.10.10 10.10.10.22 netmask 255.255.255.0
The interfaces are setup in driver with these flags: IFF_POINTOPOINT,
IFF_NO_ARP, IFF_SIMPLEX and IFF_NOTRAILER. Here is the display when do

Are you able to modify the driver? Throughout the ethernet common code,
NetBSD will assume a broadcast interface where ARP works. If you follow
the convention, you may have an easier time.

I have access to the driver but not sure what to change. I want the kernel
not to do any arp on the interface, can I do that? I guess one way is to add
a static arp entry, but any other way? Anyway to tell the kernel just send
out the packet to the interface and the other end just pickup without
looking at the destination MAC address? How normally is a point to point
link interface configured?

I believe this interface will "just work" if you treat the ethernet as
an ethernet: i.e., BROADCAST instead of POINTOPOINT. ARP enabled.

Dave

[Ignatios Souvatzis]

Post by Gert Doering

Post by Ignatios Souvatzis

Post by mrchit_2000
a static arp entry, but any other way? Anyway to tell the kernel just send
out the packet to the interface and the other end just pickup without
looking at the destination MAC address?

This won't work. The other end's *hardware* needs an ethernet address to
listen to.

Not necessarily - if the receiving end is in promiscuous mode, the
ethernet chip will happily accept whatever packets come in...

of course - but where's the point when you still have to create the same
header format that the receiving driver expects?

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Gert Doering]

Hi,

Post by Ignatios Souvatzis

Post by Gert Doering
Not necessarily - if the receiving end is in promiscuous mode, the
ethernet chip will happily accept whatever packets come in...

of course - but where's the point when you still have to create the same
header format that the receiving driver expects?

If it's a pure internal point-to-point link, you could save the effort of
maintaining ARP entries (either setting them up statically, or actually
running the ARP protocol). Less overhead...

gert

[Manuel Bouyer]

Post by Gert Doering
Hi,

Post by Ignatios Souvatzis

Post by Gert Doering
Not necessarily - if the receiving end is in promiscuous mode, the
ethernet chip will happily accept whatever packets come in...

of course - but where's the point when you still have to create the same
header format that the receiving driver expects?

If it's a pure internal point-to-point link, you could save the effort of
maintaining ARP entries (either setting them up statically, or actually
running the ARP protocol). Less overhead...

No. You still need to send something in the ethernet header, that will
be properly received by the hardware engine on the other end.