Subnetting, private networks & default routes

When you use network mask 255.255.0.0, you're telling all those machines that all 172.16.x.y addresses are on the same network. So the

172.16.1.y machines try to talk directly to the 172.16.130.y machines, rather than sending to the router. You need to change their masks to 255.255.255.0 so that they'll understand that they need to go through the router for 172.16.x.y addresses where x isn't the same as their address.

There are 3 or 4 172.16.x networks that are all connected to the same switch (e.g. 172.16.1, 172 .16.10, 172.16.11) but there's also a handful of 172.16.x networks that are in remote locations and thus connected by routers. Which is why I get confused..! :-\\

Then there is the 172.16.30 net which is a DMZ, physically in the same location as 172.16.1 etc but logically separate. That's probably just confusing the issue though...

I guess my question is, which machines do I need to change netmasks on? All of them?

Chris

Well, that's just bad design. You need to configure the address ranges to match the network topology. Different subnets should be connected by routers, same subnets should be connected by switches.

You also need to rearrange the addressing. The remote networks shouldn't be 172.16.x.

However, you can probably get what you have to work by configuring proxy-arp on all the routers.

You should be able to route traffic between subnets with different mask. For example172.16.x.x/16 in the core and 172.30.x.x/24 in DMZ or remote locations. You can also divide 172.16.x.x into subnets and assign different masks. However, you cant have 172.16.x.x/16 and 172.16.x.x/24 in the same network. This will cause routing issues. If you are looking for a quick fix, NAT at remote locations may be a solution. For example NAT 172.16.64.x/24 to 10.10.10.x/24 should work.

Good luck

That's where I get confused though, I'm not real sure of the best practise in this case. Seeing as I just inherited it and all...

I would be happy with 172.16 being location A, and 172.17 being location B; but unfortunately (at the moment) .16 is a mix of several locations. I don't see what's so bad, though, if 172.16.1 and 172.16.2 are in different locations?

Okay

I'll need to look this up. :) I know what ARP is, but haven't c> You should be able to route traffic between subnets with different mask. For

But if I want the two nets to communicate, shouldn't the two masks be the same? In a perfect world, anyway.

Ah-ha. What kind of routing issues? I think this is exactly what is happening now...

Given the size of this network & it's importance, I'd really rather get it done once and done right.

Chris

Barry's first reply has the answer to this questions. You can have 172.16.1 abd 172.16.2 in different locations so long as they have same subnet mask.

So long as you have well defined subnet boundaries, you can subnet your network in a variety of ways.

I guess what I need to do is figure out how to apply his advise to my network. I've tried to break it down like this:

172.16.1, .10 and .11 have masks of /16 and are local 172.16.120, 172.16.130 have masks of /24 and are different remotes 172.16.25, .26, .27 and .28 have masks of /24 and are different remotes 172.16.4 has a mask of /16 and is local 172.16.5 has a mask of /24 and is bridged to 172.16.4 172.20.1, .2, .3, .4 and .5 have masks of /24 and are different remotes 172.30.1 has a mask of /24 and is the local dmz

Without wanting to sound like a fool *g* I guess that I'm missing the fundamental point; in so far as I'm not sure how I'm supposed to be defining & bounding them. So, if you could sum it up in a nutshell, I'd be all ears!

Essentially I want every net to be able to talk to the other nets with the least amount of trouble.

Chris

Without knowing the details about the network it is impossible to suggest a IP scheme. That said, here are some suggestions

1- The problem is with the 172.16.x.x addresses.

2- One solution is to change the subnet mask of networks 172.16.1, .4, .10 and .11 to /24.

3- Another solution is to move 172.16.120, .130, .25, .26, .27, .28 to a different network for example change the devices in remote network 172.16.130.x/24 to 172.17.130.x. You should be able to test the connectivity by pinging from both ends

If I go with solution 2, and change every 172.16.1 device's subnet from /16 to /24, is there any potential for breakage? It would be nice if I could use your second suggestion and move the remote networks out of the 172.16 range, but I'm not sure if that will be practical :-\\

If the subnet mask is 255.255.0.0, then they will not send to a router to communicate with each other, because they think they're on the same subnet.

Proxy-arp means that the router will respond to ARP requests for any remote subnets. So if a machine on the LAN has its subnet mask too large, and thinks that remote subnets are local, the router will make up for the mistake.

Different networks can certainly have different subnet masks.

172.16.x.x/16 means that all 172.16.*.* addresses are on the local subnet, so 172.30.x.* are remote. 172.30.x.y/24 means all 172.30.x.* addresses are on the local subnet, so 172.16.*.* are remote.

It sounds like you really need to read a tutorial on how subnet masks are used.

A /16 subnet mask means that all addresses with the same first two octets as yourself are on your own subnet. So machines on the 172.16.1 subnet think that the 172.16.120 machines can be reached directly, without going through a router.

Okay, and therefore some of the packets will be dropped because some of the 172.16s are actually remote... right?

Yep, I found it in the IOS manual on Cisco's site. Seeing as it requires zero configuration it actually looks like it might be a good fix, albeit a temporary one. Provided it does't break anything in the process, of course...

Right, I know that normally that's the case; but in this case where some of them happen to be remote -- which is why I get confused. :-)

It does. And, I did look up a bunch; but they were either quite too basic or /way/ too complicated. Counting out network addresses into binary does not interest me 8-)

Okay. So in my case, some of the 172.16s are remote; and therefore reachable only by routers. Which means I get the three options: proxy-arp as a temporary fix, moving the networks around as a permanent fix (no thanks), or changing subnets masks to /24. Correct?

Chris

In order to assist you _someone_ will have to.

If you don't want to understand IP addressing (a perfectly reasonable position to have in life) then you need to hire someone who does if you want your network to work.

Making such architecural changes as you have indicated without fully understanging the operation of the network and the systems that use it is very likely to result in further problems.

For example the 172.16 machines may actually be in the same broadcast domain and changing the mask to /24 from /16 could break existing function.

It is also very odd that you have pings working one way and not the other. Ping requires bi-directional comms in order to work at all, irrespective of which end the request originated from.

Maybe there is some sort of policy routing configured? ACLs?

If your reports are sufficiently detailed and complete then the existing problems are present due to a faiulre to understand IP addressing and routing. It is going to be hard to fix them without fixing the understanding first.

Good luck.

I was mostly being facetious about the counting in binary, I do want to obtain a deeper understanding of classless subnetting & routing than I already do; I just find it amusing that understanding subnet masks comes down (in part) to counting in binary. :-)

Yes, it is possible; however in order to troubleshoot the existing network problems I need to at least make changes somewhere. Perhaps using proxy-arp on some of the routers to alleviate problems temporarily whilst I try and understand this better...

How would I be able to investigate that, though? Being on the same broadcast domain

I'm also trying to discern that as I go, but there's nothing immediately obvious -- yet.

At the moment I only have symptoms of problems (e.g. passing pings in one direction); and I wasn't clear on having two subnet masks for the same network range so I posted here. But, yes, I would like to understand it more. If you have any resources you'd like to point me to...

Chris

Which is precisely the problem. You're telling the machines they're local, but they're actually remote. When you lie to computers, they believe you and usually don't work properly.

Another solution is to change all the subnet masks to /24. You'll need to give the local routers additional addresses on all the subnets, and change the machines' default gateways accordingly. This means that some local traffic will go through the router when it doesn't need to.

Exactly, so I can't blame them when they're not working correctly. Like everyone, I just want the best solution that provides the minimum possiblity for breakage.

That isn't a bad idea, either. Here is an example of a problem I'm trying to deal with:

I have a local 2516 router which goes to a frame relay cloud for a remote site. Eth0 is 172.16.101.195/16 and Ser0 is 192.168.1.1/24. The remote site has a 1721 router, Eth0 is 172.16.130.191/24 and Ser0 is

192.168.1.13/24. The remote router can ping the local router, but it cannot ping any farther -- i.e. it cannot ping machines inside the core network which is local to me, it can only ping the 2516 router. So, would proxy-arp on the 1721 solve that problem temporarily?

Also, I don't see why the Serial interfaces are on a completely different private network either; but that's an argument for another day.

2516 config:

! ip subnet-zero no ip domain-lookup ! interface Ethernet0 ip address 172.16.101.195 255.255.0.0 ! interface Serial0 ip address 192.168.1.1 255.255.255.0 encapsulation frame-relay bandwidth 384 no fair-queue frame-relay lmi-type ansi frame-relay map ip 192.168.1.13 28 ! ip classless ip route 0.0.0.0 0.0.0.0 172.16.1.181 ip route 172.16.130.0 255.255.255.0 192.168.1.13 ! line con 0 line aux 0 transport input all line vty 0 4 password 7 *** login end

1721 config:

ip subnet-zero no ip domain-lookup ip domain-name ***.com ! ! ! ! interface FastEthernet0 ip address 172.16.130.191 255.255.255.0 speed auto ! interface Serial0 ip address 192.168.1.13 255.255.255.0 encapsulation frame-relay no fair-queue service-module t1 timeslots 1-6 ! ip classless ip route 0.0.0.0 0.0.0.0 192.168.1.1 no ip http server ! ! dialer-list 1 protocol ip permit dialer-list 1 protocol ipx permit ! line con 0 line aux 0 line vty 0 4 password ****** login ! no scheduler allocate end

You need proxy-arp on the 2516's Eth0, not the 1721, since the problem is with the machines on the local network. They have their network mask set to /16, so they think the remote site is local, and they need the

2516 to grab the packets automatically.

The designer apparently decided to use 172.x networks for offices, and

192.168 networks for links between, to make it easier to see the difference. The networks used for the links are pretty much irrelevant.

Okay -- I got that one wrong. I'll give that a try, thanks!

Yah, I just didn't see why he didn't put them in the 172.x nets and just subnet them suitably.

Thanks again for the help!

Chris

The last thing -- what impact will proxy-arp have on the broadcast domain? Will it extend it to the remote network?

Chris