HOWTO: 'routed' on an Xserve

[awingnut]

I have a dual homed Xserve and am trying to set it up with a lab network on the PCI adapter. However, I cannot get routing to work. Although I am knowledgable about 'routed' on Unix (maybe that is a handicap ) so much of that is hidden from the OS X administrator I cannot figure out what is wrong. I set up the 2 interfaces using "System Preferences" setting the primary interface with a route entry for my ISP router and the secondary interface route entry is blank. Unfortunately, 'routed' is not being started and starting it manually (I cheated and used 'sudo') doesn't seem to help. What am I missing? TIA.

 

[xtrooper]

greetings

vi /etc/hostconfig
IPFORWARDING=-YES-


routed is not what you want. You need to use ' route '
see man route
set the default route to your ISP
and then add routes to all internal subnets. by default your xserve will see the internal subnet but nothing beyond that.

example:

root# route -n flush
root# route -n add default 192.168.1.1 -ifp en0
root# route -n add 192.199.0.0 192.50.1.1 -ifp en1
root# route -n add 192.200.0.0 192.50.1.1 -ifp en1

192.199.0.0/16 and 192.200.0.0/16 are two different subnets on an internal lan behind a firewall. These statements basically say all traffic not local go to 192.168.1.1 via en0 , if your looking for my internal subnets go through en1.

hope this helps.
( you would need to create a startup item to have theses entries active after each restart ).

--x

 

[awingnut]

Thanks for the reply. I'm a Unix admin so I'm a little confused. 'Route' is a command not the the routing daemon ('routed'). What process handles the routing protocols? I was trying to set up '/etc/gateways' and starting 'routed' which is the standard routing process when 'gated' is not implemented.

 

[awingnut]

Thanks for the reply but I'm still not having much luck. IPFORWARDING is now on (what about ICMP redirect?) and I don't think I need to really set any static routes if this thing does its job right.

I have 2 networks, the primary LAN which has a router to the internet (default router) at ppp.ppp.ppp.129 (mask 255.255.255.128) and the Xserve interface (en0) at ppp.ppp.ppp.141. The other interface (en1) is on the secondary LAN at sss.sss.sss.1 (mask 255.255.255.192). The Xserve can get to either LAN but nodes on the secondary LAN can only get as far as ppp.ppp.ppp.141 and nodes on the primary LAN can only get as far as sss.sss.sss.1.

That implies to me that IPFORWARDING is not working.

 

[xtrooper]

bjeez,..all your ppp's ans sss's are screwing me up

let me see if i can break this out:

( inet gateway )-- en0 [ xserve ] en1-- ( internal )

en0=p.p.p.141/128
upstream router = p.p.p.129/128

en1=s.s.s.1/192

clients on the ' S ' network can only see through the xserve to the ' P' network but not beyond.
Can the client (net S) ping interface "?" p.p.p.129 on the primary gateway?
Answer i suspect is no. The Primary gateway needs to have a return route to find the internal clients *( the "s" network ).

If the primaary gateway/router is a cisco box. Turn on ICMp packet debugging and watch for the reply's

debug ip icmp
term mon

from the ' S ' client. Ping p.p.p.129
If no reply is seen. Place a computer on the "p" network and ping it.

static routes may be useful at this point even for debugging.

Remember Ip forwarding isn't like turing on RIP or OSPF. It just allows packets to be passed between interfaces. If no routes are specified the packets will no go beyond the the two interfaces.

--x

 

[awingnut]

Thanks again for the reply. I will examine the problem from the standpoint of it being the return path. I set the static route (on 129) for that network but maybe something else is wrong. I'll get back to you.

 

[awingnut]

I'm pretty sure the return path is not the issue. I saw my cisco router issue the ICMP redirect for the 's' network to the pinging 'p' host.

When pinging from the 's' network the router never saw anything so I have to conclude that the xserve is not routing.

About your comments on needing to issue routes. I am sure I don't issue a 'route -n' for the directly connected networks. I did issue a 'route -n' for the default route but there are no other routes to set. If I do:

route -n add sss.sss.sss.0 sss.sss.sss.1 255.255.255.192 -ifp en1

I get an error (which I expect).

 

[awingnut]

As I was pondering this it noticed that there seems to be something wrong with the addresses I was given. I have reqested clarification from the ISP. It seems to me if the subnet mask is 255.255.255.192, then the address range should be sss.sss.sss.129-159 but if the range is sss.sss.sss.1-31 then the subnet mask is 255.255.255.224.

Either way I don't think this is the problem I'm seeing with the xserve, at least until I try to access something on the other side of the ISP router (cisco). Thoughts?

 

[xtrooper]

yes .1-.31 is a 224/27

here is your range for the 192
255.255.255.192/26

.0 net
.1 - .62
.63 broadcast

.64 net
.65 - .126
.127 broadcast

.128 net
.129 - .190
.191 broadcast

.192 net
.193 - .254
.255 broadcast


between the cisco ( gateway to the internet ) and your xserve. Place a machine on that wire with a mini hub or something. Set that machines default gateway to the xserve. And ping the xserve. You should get replys. And now visa versa, xserve shoudl she client.
Now, from the inside network, have a machine ping through the xserve to the new machine you just placed in between the router and the xserve.

this will tell you if your packets are being passed through the box.

If you don't own the Internet router. and don't have the ability to configure the return routes, you may want to look into doing some Network Address Translation (NAT) on the xserve. That way the upstream router will not need any "new" routes.

-x

 

[awingnut]

I got it straightened out with the ISP. They actually assigned us 64 addresses not 32 so the 192 mask is correct.

I did the pings a few posts ago but maybe I wasn't complete enough.

From the secondary network machine (sss.sss.sss.2, which has a default route of sss.sss.sss.1):

ping sss.sss.sss.1 successful
ping ppp.ppp.ppp.141 successful
ping ppp.ppp.ppp.<anything else> fails

From the primary network machine (ppp.ppp.ppp.130, which has a default route of ppp.ppp.ppp.129):

ping ppp.ppp.ppp.141 successful
ping sss.sss.sss.<anything> fails

Recall that I earlier set debug on, per your suggestion, the primary default router (129) and confirmed the ICMP redirect, sending packets for the secondary network to the Xserve (141).

I find it interesting (although unrevealing, to me) that the Xserve responds to the ping on the opposite interface from one side but not the other. In any case I think the evidence clearly points to a problem on the Xserve but damfino what it is.