I’m trying to understand the best way to subnet my network.
We have a subnet : 66.227.18.0/23
What I am thinking about doing is putting a router on each side of our primary BackHaul. This will of course require its own subnet, which will only need a /29 giving me 6 addresses for the router interfaces and the backhauls.
The question is there a non-wastefull way to keep the other addresses contiguous?
As I understand it this forces me to break up all the rest of my addressess into a bunch of subnets, being :
66.227.19.0/24
66.227.18.128/25
66.227.18.64/26
and so on…
is there a way to simply do a route summerization that excludes the /29 created for the backhaul link?
Inet — Router1 — BH1 ---- BH2 ---- Router2 ---- internal
From the internet to router1 would be summarized at 66.227.18.0/23
And the link from router1 to 2 makes sense… but from router to our internal network, is there a way to have the rest of the addresses as a single subnet, or will i have to create several subinterfaces with all of the broken down subnets?
tlsarles wrote: We have a subnet : 66.227.18.0/23
This is going to get messy. Assuming everything in your network is capable of VLSM (variable length subnet masks), then you can have mixed blocks, although this may be rather confusing for you.
Personally for 512 addresses (maximum) I would just put everything on a flat subnet and not bother with routing.... We have nearly 512 customers on a single AP site (on a single subnet) with no problems.
That said, if you really want to do this, here is a not so short, but also not comprehensive description on how to break up your subnets:
The only rule you really need to know is to subsequently divide the subnets in half. So let's say you need 3 blocks of 32 addresses, 1 block of 64 addresses, and 5 blocks of 4 addresses for "point to point" links:
Divide 66.227.18.0/23 into 18.0/24 and 19.0/24 (We're going to drop the first two octects to make this easier at this point)
Take 18.0/24 and divide it into 18.0/25 and 18.128/25 (blocks of 128)
Take 18.0/25 and divide it into 18.0/26 and 18.64/26 (Blocks of 64)
Take 18.128/25 and divide it into 18.128/26 and 18.192/26 (Blocks of 64)
Take 18.128/26 and divide it into 18.128/27 and 18.160/27 (blocks of 32)
Take 18.192/26 and divide it into 18.192/27 and 18.224/27 (blocks of 32).
Pausing for a minute, you now have:
18.0/26 (block of 64)
18.64/26 (block of 64)
18.128/27 (block of 32)
18.160/27 (block of 32)
18.192/27 (block of 32)
18.224/27 (block of 32)
19.0/24 (block of 256)
It looks like we have plenty of blocks except for the blocks of 4 for the point to point links. I would probably split up 18.0/26 further for this purpose:
18.0/26 into 18.0/27 and 18.32/27
18.0/27 into 18.0/28 and 18.16/28
18.0/28 into 18.0/29 and 18.8/29
and subsequently into 18.0/30, 18.4/30, 18.8/30 and 18.12/30
18.16/28 into 18.16/29 and 18.24/29
18.16/29 into 18.16/30 and 18.20/30
So, in summary:
18.0/30, 18.4/30, 18.8/30, 18.12/30, 18.16/30, 18.20/30 - blocks of 4
18.24/29 - block of 8
18.32/27 - block of 32
18.64/26 (block of 64)
18.128/27 (block of 32)
18.160/27 (block of 32)
18.192/27 (block of 32)
18.224/27 (block of 32)
19.0/24 (block of 256)
You will notice that the address of each block is evenly divisible by the block size, and that there is no overlap in addressing. This shows you have divided up your block correctly.
Now you just assign the blocks to each segment and number accordingly. You will also need to add routing tables to each router and/or turn on ospf or similar on your network to make this work.
-forrest
I just re-read your message again, and I’m not sure I addressed your specific concern…
tlsarles wrote:
The question is there a non-wastefull way to keep the other addresses contiguous?
Not really, if you’re really routing you will need to split them…which means that you will have to add each block separately to each interface where they should “appear”.
If your entire network really consists of a flat network attached to a BH attached to the internet, then there really isn’t much to gain with adding the routers… The BH’s already filter out traffic which isn’t destined for the internet router, so you aren’t consuming BH capacity with your LAN traffic, other than perhaps a bit of broadcast traffic.
Even worse is the necessity that each machine inside your has to have a subnet mask and gateway specific to the address assigned to it. Plus traffic between machines on different subnets (even if they are on the same wire), generally have to travel to the router and back in order to get where they are going. In short, doubling your network traffic.
About the only other thing I could think of is to ask your upstream for a couple of small /30’s for this purpose. Depending on your upstream, they may or may not be willing to give you this small of a chunk.
What are you hoping to accomplish with the routers?
-forrest
Well, you answered my question; which is that I will have to break it up in to many separate blocks, just to take out a small section. This is what i figured, but was hoping there was some trick… What we want to do is two things potentially.
If we have a cisco on each end of our backhauls we can then compress traffic between them giving us a little extra bandwith over the backhaul.
but the main reason is to limit broadcast traffic over the backhaul, so that only stuff intended to leave the segment wastes out backhaul bandwidth.
Tony,
I’m with Forrest on this. It’s going to be a lot of hardware, management and potential IP conflicts for little gain. I’d run it flat.
In the SM block
- PPPoE
- SMB
- SNMP
- BootP Client
- BootP Server
Doing this, we see < 4pps of multicast traffic on our router interface.
tlsarles wrote: If we have a cisco on each end of our backhauls we can then compress traffic between them giving us a little extra bandwith over the backhaul. but the main reason is to limit broadcast traffic over the backhaul, so that only stuff intended to leave the segment wastes out backhaul bandwidth.
1) Compression is overrated, but I believe you can compress across a bridged link... You may just want to bridge the ethernet ports together on the ciscos and compress in the middle.
Compression adds latency and latency is in many applications the most important factor in apparent throughput, not bandwidth... Even 20-30 ms can make a drastic difference in performance. I think you'll find that compression seems to slow things down just because of the added latency.
Plus, much of the internet is already compressed today. Images are .jpeg compressed (or containg .GIF compression), many web servers are configured to compress the html on the fly. Files are typically already compressed with .zip or another application-specific compression (.mp3). And once compressed, it is really hard to apply another compression and get any meaningful compression ratio out of it.
2) There should be very little broadcast traffic in your network. If there is a lot, then you should figure out why and fix the problem. And by very little I really mean very little. There are other ways to filter broadcasts as well... all you really need is ARP broadcasts, and they should only occur when traffic is first directed to a machine.
For example, on a segment with well over 300 customers, the number of broadcasts in my network are around 1 per second. And they're small, typically under 100 bytes. Inside a network, there are a few more, but again, the total quantity is minimal.
Really, I wouldn't bother.
Thanks to all of you guys for the interesting discussion!
I have some more to ask you…
1) What could be the practical limit permitting to have a flat layer 2 network? 500 SM? maybe more?
Even if they are distributed over many different APs connected by backhauls?
2) What could be the best practice in the following situation:
internet — router1+AP+BH — BH+AP+BH — BH+AP+router2 — internet
So, it’s a symmetrical topology and the path is composed by sequential segments.
I have 2 internet upstreams and would like router1 acts like MAIN router and router2 as BACKUP in case of failure.
Which is the simplest way to do a sort of automatic failover?
Is really needed routing in this case or I can use any layer 2 technology? Do I need layer3 switches?
Thank you again
Massimo
I didn’t even think about the latency as an issue, so given that I aggree, that this might not be worth it… just speculating any ways to optimize our network…
As far as I understand the multiple WAN connections as purposed by trumpet; I’m not the expert, but I think your going to need a router that will run BGP. Whoever is going to sell you your bandwidth might be the best person to answer the spesifics
Hello Forrest,
Could you please tell me how your IP is addressing looks like?
We have been using 10.10.10.x for all our equipment, form routers to backhauls to AP to SM. We also reserved a block of 20 IP to be assigned by DHCP at our office.
I’m afraid we’ll run out of addresses soon.
Thanks,
Chavex wrote: Could you please tell me how your IP is addressing looks like?
The only answer is really a long, convoluted one. The only way to shorten it is to say that we are an Internet Service provider with lots and lots of real addresses which we can assign as needed.
-forrest