Anyone want a contract to help IP routing?

[robertm]

Is there anyone out there who has enough experience with configuring StarOS to help (for hire) me with assigning my class C block to the clients on my system.
Basic configuration is working with 5mb of thruput on private addressing.
Backhaul = WRAP 2c with 2@CM9 5.8 > ethernet to > WRAP 2c with 2@Senao 2.4 to clients I have 5 of these repeaterAPs on line now.
I am hoping to hire someone to help me figure this out. I need to get this working yesterday.
Please pass this on if you know someone who could take on this project with me.
Robert

[rvi-ip]

I will help with what I can, but I will not accept money. All I request is that all info is posted for all to see so the whole forum can benefit.

[ninedd]

I will help with what I can, but I will not accept money. All I request is that all info is posted for all to see so the whole forum can benefit.OK, I'll take you up on that then. :) A recurring theme is idoits like us who start small, do a simple bridge of their public IP's and then end up in the stuck in the ditch without a shovel... A recurring question is ''how to I convert my bridged/broken network to a routed/working network?"

1st) Can EZEE and DHCP be used at the same time on the same interface?

Reason: We have clients setup with static / public IP's right now, and want to move to routed and private. Ideally, we'd want to EZEE so that customers keep working, even with their now-broken TCP/IP setup, until we can call them all and tell them to DHCP.

2nd) We have a corporate customer that needs their StaticIP for their VPN and they are at the very end of our network. The farthest customer, 8 hops away, and of course, they can have zero down time. :) So, once we're routed, we'll need to.... imap? them the same address they have now.

This is the primary reason we've delayed. They are a large, expensive customer and while we know it's broken, it's very risky to try to fix it unless we are certain we know exactly how much downtime there will be....

So, RVI, have at it. All help will be great appreciated by me, and other idiots.

- Thanx
Todd

[lonnie]

eeZee and DHCP-AutoAuth work extremely well together. Just assign them to different chunks of the subnet and they coordinate and eeZee only handles units that do not have a DHCP assignment. You can also use eeZee static arp to assign some customers to known IP so that you can still monitor them.

VDS will get the remote client using the proper IP. IPMAP might do it, but some VPN systems do not like any sort of nat and IPMAP is using bidirectional nat.

Good luck guys. For anybody else just starting out -- watch this thread and read all you can about the trouble that people get into by not building their network the proper way from the very beginning. My question has always been --> If you cannot afford the time to do it right, when will you have the time to do it a second time? And make no mistake, if you are going to continue in this business you absolutely MUST have a properly designed network. Sure there are "successful" guys who are doing it quick and dirty, but just watch their posts to the lists and you'll see they are constantly battling issues. Their network just never seems to run the way it should.

You rarely see issues from guys with routed solutions, except when software fails. That is easily fixable with an update. Fixing a cobbled together bridged network can take days and have you visiting most customers to change their system to DHCP since you likely also did not take the time to use DHCP when you started, and those static, hard coded assignments have to go as the first phase of the redesign.

[ninedd]

Well, a good place to start would be the story of how we got here, so you may see some simularities on your situation and know what to avoid...

You know, it's ironic in a way. The guy's who have a DSL connection with one Static IP that use a StarOS machine on their garage to sell it to the block, and then end up putting up another hop to sell it to the next block... those are the guys that end up having a properly designed network from the get-go, mainly because they have no choice and they have only one real IP.

The guy's I see in the most trouble, are the "Real ISP's" like us, who have a real class-C and who's first 10 machines (Cisco Router, DNS, Mail, Host, Dialup Modem Pool, etc...) are all just assigned IP's from that group. Everything plugged into our switch was always flat, so when we plugged in the first AP (Zcomax 2mbit in 1997) it was also assigned an IP. Of course, their point-to-point solutions did real bridging, so our first AP was assigned an IP, and then next and the next. Of course, their AP's crashed once or twice a day, so it really limited the growth of the network - it was a full time job running to sites to power cycle.

Then we switched to StarOS and two things happend. First, we started running month's at a time without reboots. We actually had a power outtage at a building top that needed a visit one time, and we couldn't remember where we had the keys. Before StarOS, we were there twice a day and had the keys basically around our necks!

The second thing that happened was that we went from a point-to-point bridge to a AP-Client bridge. At that time, it didn't seem significant, but it was. Actually, StarOS used to have a StarLink protocal, but that was obsoleted at some point - I'm not sure when exactly.

In any case, that was also the start of a network that worked for us and didn't crash twice a day, and as a result, we actually started connecting customers at a fast pace, and that was when our network problems started to grow as well. That's why it's important to do it correctly, from the get-go, REGARDLESS of if you have a Class-C at your disposal or not.

The other issue is that we liked to be able to sit and ping any IP on our network, from anywhere on our network, and we liked to be able to plug in our laptop, at any site, at any AP, into any switch and be able to have it's Public Static IP available from anywhere. We figured big and flat was the only way to do all that. If we went to 192.168.1.x for one AP, and 192.168.2.x for another AP, we figured we've have to have a 255.255.0.0 netmask to be able to see it all - but that's really big/flat thinking again. As Lonnie pointed out, anyone can ping www.cbs.com right now, and they are not within your netmask range at all. The whole internet is IP routed, and everything is pingable / reachable / administerable / configurable / monitorable from anywhere else on the internet, without having to have it all flat and bridged. Duh!

So, you're totally correct, and it would be great to have a step by step instruction on how to do this for the novice, from the get-go and that's what we'll try to do here. As well, we'll try to have step-by-step help on how to fix a broken-bridged-flat mess into a working-routed network. If we can accomplish good enough instructions for those two things, we should be able to 1) have new networks grow properly and 2) fix broken networks out there.

Any contributions or advice would be greatly appreciated.

- Thanx,
Todd

[ninedd]

OK, let's assume I'm a new user (and I pretty much am, if I'm building a new network from scratch, and doing it right this time!)

I have two machines, the first with an Ethernet card and a Radio card in AP Mode. The Ethernet is wired to our switch, and the Radio is in AP mode linking to our first POP, a nearby tower.

The second machine is on the tower with three radio cards in it. The first radio card is in Client mode, connecting back to machine 1, the second is in AP Mode, connected to an Omni, DHCPing for end user clients, and the third is in AP mode connected to a grid that will hop to a future, third machine.

So, I put a static, public IP on machine 1's, Ethernet. Something from our class C - (let's say 207.xxx.xx.50) and on the AP card, I put 10.10.1.1 as the IP. I don't put anything into the bridge (0) of course (that's what we're trying to avoid!!) and I put a default route of 0.0.0.0 going to.... 207.xxx.xx.254, which is the gateway connected to the Internet, right.

[lonnie]

What you need to do is assign a subnet for EACH physical connection. If an Ethernet plugs into a switch it gets an IP from the subnet you have assigned to that segment.

Each segment has a subnet and each subnet has a default gateway --> meaning one machine on each subnet has the task of carrying traffic from that segment to the Internet or at least to another machine that might be able to handle the task.

I know it means a lot of numbers but in time you will get used to it and believe me it works.

Each AP is the gateway for the subnet that clients hookup to. If you use RIP on everything then it is quite easy to assign a new IP and it gets sent through your LAN with 30 seconds typically, and you do not have to even enter any subnets.

If you want something better then you need to learn OSPF. It will actually deal with parallel connections and route around a problem if you have points in your LAN that are interconnected.

[ninedd]

OK, here's what I've done...

Machine 1 - rip turned on
Ether1 - 207.xxx.xx.63 (physically wired to switch)
wlan1 - 10.10.4.1/24
Static Default Route - 0.0.0.0/0 - 207.xxx.xx.254 on ether1
(that is our existing gateway that everything points to)
wlan1 in AP mode, channel 1, SSID of 'Test'

Machine 2 - rip turned on
wlan1 - 10.10.4.254/24 in client mode, SSID of 'Test' connecting back to machine 1
wpci1 - 10.10.5.1/24 in AP mode, Channel 11, SSID of 'Test2'
Static Default Route - 0.0.0.0/0 - 10.10.4.1 on wlan1
wpci1 - Auto-auth settings
gw - 10.10.5.1
sub - 255.255.255.0
pri - 10.10.5.1
sec - 207.195.43.254
Range - 10.10.5.100 - 199

My laptop, linked wirelessly to the AP card (Test2) in Machine 2.

It gets' DHCP Number good, assigned 10.10.5.100, subnet 255.255.255.0, gw of 10.10.5.1 which I think is all correct?

Now, on the laptop, I can ping 10.10.5.100 (itself) as expected, 10.10.5.1 (AP card) as expected, 10.10.4.254 (good, routing...), 10.10.4.1 (great, routing over the wireless link back to machine 1) and 207.xxx.xx.63 (the Ethernet side of Machine 1 that's physically connected to our switch) All good I think - it looks like routing is working OK.

Our gateway router at 207.xxx.xx.254 is a Mikrotik machine, and I've turned RIP on in that, and I can now ping from my 10.10.5.100 laptop, all the way to 207.xxx.xx.254 gateway. Great, routing is working well so far.

However, I can't ping from the laptop all the way to the internet. I can if I log into 207.xxx.xx.63 - from there I can ping both the public 207.x.x.x network, and anywhere on my routed 10.10.x.x network, but not beyond that.

Now, I know don't have any MASQ / NAT on machine1, but I don't think that should be an issue is it. We MASQ/NAT right now on that MT box, the 207.xxx.xx.254 machine as our gateway, so I think that should be fine, shouldn't it? I don't also have to MASQ on that StarOS machine do I?

Thanx,
Todd

I'm getting darn close here, but stumped at this last step.... :)

- Thanx
Todd

[lonnie]

The MT machine is not masq'ing for the entire range of IP addresses. If you can get to the box but not beyond to the net, it is not masq'ing, plain and simple.

[ninedd]

Yea, the MT machine has been using to transparently sending data to/from our Squid Proxy, but let's leave MT out of the equasion - forget I mentiond it. :)

As far as the rest of the above diagram, that looks OK? Each machine simple has one default route 0.0.0.0/0 to the IP of the device that is closer to the internet - for lack of a better description. This all looks right to you?

If so, on my StarOS machine1 then, which has it's Ethernet as 207.xxx.xx.63/24 and it's wireless card as 10.10.4.1/24, I'll need to Masq the private IP's to a public IP so that they can be encasalated and transit the public internet.

So, should the masq statement on machine1 be...

masq from 10.10.4.0/24 to dev ether1

or

masq from 10.10.0.0/16 to dev ether1

We'll of course have many 10.10.x.x subnets, since each AP card will have it's own subnet for it's own set of clients, but I'm not sure if we just need to masq the 10.10.4.0 packets once they are at that machine. I know we don't want to masq on other places on the net, but help on the proper masq would be great. :)

[ninedd]

Lonnie or anyone;

How does this look for routing. Is this the correct way to do it with StarOS?

Machine 1 - rip turned on
Ether1 - 207.xxx.xx.63 (Public IP - Physically wired to our switch)
wlan1 - 10.10.4.1/24
One Static Default Route - 0.0.0.0/0 - 207.xxx.xx.254 on ether1
(IP of existing Ciso router that everything else points to)
wlan1 card is in AP mode, channel 1, SSID of 'Test'

Machine 2 - rip turned on
wlan1 - 10.10.4.254/24 in client mode, connecting back to machine 1
wpci1 - 10.10.5.1/24 in AP mode, Channel 11, SSID of 'Test2'
One Static Default Route - 0.0.0.0/0 - 10.10.4.1 on wlan1

Machine 2's wpci1 card in AP mode
Auto-auth settings:
gw - 10.10.5.1
sub - 255.255.255.0
pri - 10.10.5.1
sec - 207.195.43.254
Range - 10.10.5.100 - 199

Client computer, linked wirelessly to the AP card (Test2) in Machine 2.
End users get assigned 10.10.5.100, subnet 255.255.255.0, gw of 10.10.5.1 which I think is all correct?

If so, on my StarOS machine1 then, which has it's Ethernet as 207.xxx.xx.63/24 and it's wireless card as 10.10.4.1/24, I'll need to Masq the private IP's to a public IP so that they can be encasalated and transit the public internet.

Question 1) What should the masq statement on machine1 be?

'masq from 10.10.4.0/24 to dev ether1' or 'masq from 10.10.0.0/16 to dev ether1' or what?

Question 2) from a public machine on our network (a 207.xxx.xxx.xxx machine) I can ping the first StarOS machine (10.10.4.1), but not 10.10.5.1 or 10.10.5.100, which I should be able to do, correct?

I'm think I'm getting pretty close to this working here....

- Thanx
Todd

[boyonfish]

Hi Todd,

I'm new to the forum but have some experience in setting up and configuring long range links and hotspots (and both from the same AP) - so if you haven't already figured out the process I can probably assist.

Stephen

[boyonfish]

Sorry, and the correct "masq" script needs to be from your wireless interface to your ethernet interface, so

"masq from 10.10.5.0/24 to dev ether1"

[ninedd]

Hi Todd,I'm new to the forum but have some experience in setting up and configuring long range links and hotspots (and both from the same AP) - so if you haven't already figured out the process I can probably assist.StephenThanx. I've got a 45Km link going for about a year, so no problems there. I've never figured out HotSpots, and never really gave it too much of a try since there isn't an accounting / verification / account creation / billing component. If you have a solution for this, I'd be VERY pleased to get it working. :)