Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First ping results #14

Open
CdavM opened this issue May 3, 2015 · 8 comments
Open

First ping results #14

CdavM opened this issue May 3, 2015 · 8 comments

Comments

@CdavM
Copy link
Member

CdavM commented May 3, 2015

I discovered some interesting facts:

After replacing the patch cable in Afro, I'm able to connect to Sherman-Castro (Great success!).

Pinging Wilde-Loth from Sherman-Castro did not work. I could not reach a single antenna, not even Loth-Wilde from Wilde-Loth.

I could, however, ping my desktop (located in Wilde) from Sherman-Castro. Attaching the results:
sherman-wilde-ping-results

The connections look awesome. Any thoughts on this, @mitar?

@mitar
Copy link
Member

mitar commented May 3, 2015

After replacing the patch cable in Afro, I'm able to connect to Sherman-Castro (Great success!).

That is great to hear. I am not sure if it was really the patch cable, or just that we restart the link between antennas by unplugging and plugging back.

Any thoughts on this

Yes, this is normal. We do not yet have routers which would allow you to route between different IP segments. Currently, we do not yet have that and have just a bridged L2 network with multiple IP segments on it. So antennas cannot really talk to each other over IP (or ICMP).

When you connect to Sherman-Castro, then your put your local computer into its IP segment, so that is why you can ping yourself. But other antennas are outside that IP segment, so you cannot do anything.

You have to use arping to ping on L2, what we have now. Read the wiki page, they explain a bit about L2 vs L3 pinging.

One option would be that we put the whole BSC mesh network under the same big subnet (10.20/16) and do not really segment the backbone devices into house sugnets. House would still keep their own subnets as planned. Only instead of using /22 on antenna devices, we would use /16 there. Not sure what we would use for a gateway on antennas though. Currently we set house gateway which is inside the /22. I do not know if it works?

Anyway, that antennas are directly connected to each other and that you have even issues talking between them on L2 is just for now, because we do not have routers which would get each antenna connection and route between them, but we daisy-chained all antennas together with LAN port of one going to the LAN port of the other.

So, the questions are:

  • should all mesh devices (antennas and routers) have /16 subnet?
  • wan port on routers and house network would still use house's /22 subnet?
  • currently IPs of antennas and routers are part of the house IP pool, and not a separate IP pool, is this OK?
  • do we even have to care about this pinging, if we will have to have routers anyway? but in wlan slovenija network we do have a common /16 subnet for whole network, and then for clients each node gets its own /27 subnet?
  • but in wlan slovenija we have a gateway inside /16, outside client subnets, and here each house has its own gateway?

Maybe @kostko can help here.

@mitar
Copy link
Member

mitar commented May 3, 2015

Probably for debugging purposes like this one is good backbone/mesh devices share the same IP subnet because it is easier to work? Even if we have L3 routing later on?

@mitar
Copy link
Member

mitar commented May 4, 2015

This is also the reason why speed test did not work between antennas when were trying yesterday. For the same reason ping is not working for you now. Antennas are not in the same IP segment/subnet.

@CdavM
Copy link
Member Author

CdavM commented May 4, 2015

No, I think there was an actual problem with the patch cable. We couldn't even connect to the antennas, and I don't remember rebooting the antennas - changing the patch cable doesn't turn them off..

If the houses keep their own subnets, administered by house routers, then we'll have the same problem. We might be able to ping antennas, but can we reach house servers?

So I guess the main question is: Can we route between different IP segments and subnets with the new routers?

Then the house router would have to be connected to the mesh router, correct? Which router would serve as a DHCP server? Also, how do we prevent double NAT-ing / other problems with two routers in series?

@mitar
Copy link
Member

mitar commented May 4, 2015

I don't remember rebooting the antennas - changing the patch cable doesn't turn them off.

But it does restart the interface. So I think that might be what fixed it.

If the houses keep their own subnets, administered by house routers, then we'll have the same problem. We might be able to ping antennas, but can we reach house servers?

This is why we will have house mesh routers to route traffic. Currently we do not have mesh routers, but are working on bridging.

Can we route between different IP segments and subnets with the new routers?

That's what a routing protocol on house mesh routers will be taking care of.

Then the house router would have to be connected to the mesh router, correct?

Yes. And there are multiple ways to do it. One is that mesh router is behind house router. Another is that it is in front.

Which router would serve as a DHCP server?

House router. Or house could decide that it is a mesh router. They could also replace house router with mesh router.

More complicated question is how to configure DNS if we would like to have a global DNS for all houses.

Also, how do we prevent double NAT-ing / other problems with two routers in series?

That is why we are using separate IP segments. We do not have to do NAT between them. You have to do NAT between public IPs and private IPs. We are already inside private IPs, so multiple routers do not have this issues. The whole mesh networks consist of multiple routers.

@kostko
Copy link

kostko commented May 4, 2015

should all mesh devices (antennas and routers) have /16 subnet?

This is irrelevant as far as a L3 routing protocol is concerned, as the routing protocol will usually announce all connected subnets and also direct host routes to all routers. The only question is how you will be allocating IP addresses to "antennas" (if there are any). You should allocate one address per interface and if you will be using L3 routing everywhere, you may assign /32 to each interface.

Also, in wlan slovenija, with nodewatcher v3, we are no longer using any /16 netmasks, instead all interfaces where addresses are assigned for L3 routing are configured a /32 from the "Router ID" allocations.

wan port on routers and house network would still use house's /22 subnet?

Probably yes. And then you may redistribute the /22 into the L3 routing protocol.

currently IPs of antennas and routers are part of the house IP pool, and not a separate IP pool, is this OK?

This doesn't matter as more specific routes always take precedence over the less specific ones. So you will have one /22 redistributed on all edge routers, and the routers themselves will also redistribute their own addresses (/32?).

do we even have to care about this pinging, if we will have to have routers anyway? but in wlan slovenija network we do have a common /16 subnet for whole network, and then for clients each node gets its own /27 subnet?

This "common" subnet is like this only when you look at the aggregated view of the network. There are actually only two things - router IP addresses used for identifying nodes in the L3 routing protocol (Router IDs) and client subnets whose routes are redistributed into the routing protocol as stub networks (networks without any other routers). And there is no reason that those should come from the same /16.

but in wlan slovenija we have a gateway inside /16, outside client subnets, and here each house has its own gateway?

Well, the question is if you even want to redistribute the default route? So if one gateway fails, do you want traffic to be redirected to other houses? In case you want that, then you may redistribute all default gateways and this will work in an anycast fashion where the best gateway (based on calculated cost) will be chosen by the routers.

@mitar
Copy link
Member

mitar commented May 4, 2015

So we have the following devices in our network with current plan:

  • antennas, Ubiquiti AirOS in bridge mode between WiFi and LAN, has a static IP assigned from the house IP range, no routing protocol running
  • house mesh router, TPLink, running OpenWrt with Babel, its LAN ports are connected to antennas, its WAN port to house router
  • existing house router, run whatever it has, hopefully it can have support for static routes, directing mesh /16 subnet to the house mesh router, each house gets /22

We for now do not want to redistribute the default route. Each house would keep its default route on house router. Mesh router would work only for /16 subnet.

So, the question is, currently, each antenna has set its netmask to /22. But probably we could set it to /16, so that we can talk to neighboring antennas without having to go through the router on the other side. But I think this is just an edge case and also just a problem now, because we do not yet have mesh routers in the network, so there is nothing yet which routes anything, so it feels that using /16 would allow us to at least communicate for now. But I think we should just let it on /22 and work on adding mesh routers next.

@kostko
Copy link

kostko commented May 4, 2015

Ah, so you have a different topology where antennas do not perform routing. So I assume that you are just bridging all the antennas to the house mesh router?

So in this case I think that it would be cleaner to consider the antennas part of the house subnet as they only act as a L2 bridge for the mesh router. So no need for /16.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants