Skip to contentSkip to conversation

Ethernet on 8260

DISCUSSION Murray Jensen 2 participants 5 messages Jul 17, 2001 – Jul 18, 2001 1 message not in the archive

lore
Share & tools
lore
#1 lore raw
In reply to a message not in the archive
Quoted 2 lines · Brad Bonkoski

Essentailly, I have them all set up on the same
network: 192.168.0.X.

Use different IP network numbers for each ethernet interface. e.g.

FCC1 - eth0 - 192.168.1.x
FCC2 - eth1 - 192.168.2.x
FCC3 - eth2 - 192.168.3.x

(assuming a netmask of 255.255.255.0). If they all have the same IP *network* number (i.e. the number is the same after applying the netmask), then Linux will only use one of them. In other words, you can only have one route for each subnet.

By the way, if you want Linux to forward packets between the interfaces, then ensure you enable forwarding (echo 1 > /proc/sys/net/ipv4/ip_forward).

Also, you could by-pass all this IP stuff and do things at the ethernet level (using a RAW socket?). Cheers!

								Murray...

--
Murray Jensen, CSIRO Manufacturing Sci & Tech, Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853
Internet: [email protected] (old address was [email protected])

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

#2 lore raw
Quoted 7 lines · Murray Jensen
Quoted 2 lines · Brad Bonkoski

Essentailly, I have them all set up on the same
network: 192.168.0.X.

Use different IP network numbers for each ethernet interface. e.g.

Quoted 9 lines

FCC1 - eth0 - 192.168.1.x
FCC2 - eth1 - 192.168.2.x
FCC3 - eth2 - 192.168.3.x

(assuming a netmask of 255.255.255.0). If they all have the same IP *network* number (i.e. the number is the same after applying the netmask), then Linux will only use one of them. In other words, you can only have one route for each subnet.

Does Linux _really_ do this? Shouldn't it route at the host layer before the network layer? Like it I ping 192.168.0.1 it should return the ping on that interface regardless of if another network device lives on this network! Or, do I have to explicitly set up host routes in the routing table? I guess what is the point of having multiple interfaces on one board live on the same network, but even so, I would still think it should choose the host route before the network route. Any thoughts on this?

Quoted 6 lines

By the way, if you want Linux to forward packets between the interfaces, then ensure you enable forwarding (echo 1 > /proc/sys/net/ipv4/ip_forward).

Also, you could by-pass all this IP stuff and do things at the ethernet level (using a RAW socket?). Cheers!

This is a good idea, but I would like to keep it simple, as they say simplicity is the 'key' to High availability.

Regards,
Brad

                                                          Murray...
Quoted 7 lines

--
Murray Jensen, CSIRO Manufacturing Sci & Tech, Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853
Internet: [email protected] (old address was [email protected])

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

#3 lore raw
In reply to a message not in the archive
Quoted 2 lines · Brad Bonkoski

Does Linux _really_ do this? Shouldn't it route at the host layer before the network layer?

I think it does look for host routes before matching network routes, but there needs to be one in your routing table. I believe when you configure the interface the driver installs the network route only. i.e. by default they will clash.

Quoted 4 lines

Like it I ping 192.168.0.1 it should return
the ping on that interface regardless of if another network device lives on this network! Or, do I have to explicitly set up host routes in the routing table?

Yes, I believe you need to explicitly add them to the routing tables.

Quoted 4 lines

I guess what is the point of having multiple interfaces
on one board live on the same network, but even so, I would still think it should choose the host route before the network route. Any thoughts on this?

You are correct, but you have to set it up manually. Or maybe it depends on what net-tools package you use - the one I use doesn't add the host routes.

Quoted 2 lines

This is a good idea, but I would like to keep it simple, as they say simplicity is the 'key' to High availability.

What could be more simple than removing all that really complicated IP protocol overhead? :-) Cheers!

								Murray...

--
Murray Jensen, CSIRO Manufacturing Sci & Tech, Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853
Internet: [email protected] (old address was [email protected])

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

#4 lore raw

Thanks for the recoomendations, look like things are on thier way!

One further question, is it possible for a detection of a loss of the actual Ethernet cable at the kernel level? Are there any pointers to docs I could read on this?
Thanks again!
Regards,
Brad

Quoted 28 lines · Murray Jensen
Quoted 2 lines · Brad Bonkoski

Does Linux _really_ do this? Shouldn't it route at the host layer before the network layer?

I think it does look for host routes before matching network routes, but there needs to be one in your routing table. I believe when you configure the interface the driver installs the network route only. i.e. by default they will clash.

Quoted 4 lines

Like it I ping 192.168.0.1 it should return
the ping on that interface regardless of if another network device lives on this network! Or, do I have to explicitly set up host routes in the routing table?

Yes, I believe you need to explicitly add them to the routing tables.

Quoted 4 lines

I guess what is the point of having multiple interfaces
on one board live on the same network, but even so, I would still think it should choose the host route before the network route. Any thoughts on this?

You are correct, but you have to set it up manually. Or maybe it depends on what net-tools package you use - the one I use doesn't add the host routes.

Quoted 2 lines

This is a good idea, but I would like to keep it simple, as they say simplicity is the 'key' to High availability.

Quoted 10 lines

What could be more simple than removing all that really complicated IP protocol overhead? :-) Cheers!

                                                              Murray...

--
Murray Jensen, CSIRO Manufacturing Sci & Tech, Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853
Internet: [email protected] (old address was [email protected])

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

#5 lore raw
In reply to a message not in the archive
Quoted 2 lines · Brad Bonkoski

One further question, is it possible for a detection of a loss of the actual Ethernet cable at the kernel level?

Depends on your board design - only the PHY knows this info and you communicate with the PHY via the MII. But the 8260 has no specific support for the management communication as defined by the MII spec (MDC/MDIO - very similar to an i2c interface) - you implement this using I/O port pins, twiddling bits to send clocked serial data to the PHY.

The first board design dependent thing is which port pins you choose to connect to the PHY MDC/MDIO pins. The second is which interrupt input(s) (port C pins?) you connect the PHY interrupt output(s) to. There will be others - probably dependent on the PHY you choose, or even the RJ45 connector itself! e.g. on our board, there is a bi-colour LED on the RJ45 socket which we connect to our FPGA so that with the appropriate FPGA code loaded we can interpret the PHY state outputs and display the appropriate colours - rather than dedicate I/O port pins on the 8260 to this function i.e. input the PHY state, output the LED state - wastes a lot of pins. Other board designs might use I/O port pins. LEDs aren't so critical, but you get the idea.

Based on previous postings, I believe Dan Malek will (eventually) be patching the FCC driver to provide interrupt driven MII/PHY support, but you will have to hack it for your PHY etc. although most PHYs are pretty similar so that all you might need to do is recognise your vendor ID number.

Quoted 2 lines

Are there any pointers to
docs I could read on this?

Your PHY manual, your board design manual, and section 30.3 of the 8260 UM. Cheers!

								Murray...

--
Murray Jensen, CSIRO Manufacturing Sci & Tech, Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853
Internet: [email protected] (old address was [email protected])

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/