So even though .10 and .20 are on a different subnet then .30, .20 and .30 shares a common .16 network bit between the 2 subnets allowing them to reach each other. At least that's how my brain made sence of it. Right?

10.1.1.0/27 is addresses 10.1.1.0 to 10.1.1.31 with .0 being the network address and .31 being the subnet broadcast address.

Edit***

I should have read your original post about the problem. I don't think this has anything to do with the issue at hand. I'm not following your logic on what's going on... It sounds to me like there's a config error somewhere.

If you have 10.1.1.30/28 configured as the address/mask on switch 3 then that's the problem. It needs to be a /27.

Infinite wrote:.10 .20 and .30 are all on the same network with a /27 mask.

10.1.1.0/27 is addresses 10.1.1.0 to 10.1.1.31 with .0 being the network address and .31 being the subnet broadcast address.

Edit***

I should have read your original post about the problem. I don't think this has anything to do with the issue at hand. I'm not following your logic on what's going on... It sounds to me like there's a config error somewhere.

If you have 10.1.1.30/28 configured as the address/mask on switch 3 then that's the problem. It needs to be a /27.

This was a troubleshooting situation I had last night. They are all on the /27 now, my question is why the switches were even communicating between /27 and /28 subnet masking..

It's a weird scenario, I don't fully understand the problem, this is just what I can work out is happening.

I replicated the issue this morning by erasing the NVRAM on all 3 switches, and no configuration exist outside of just the vlan1 ip address/subnetting.

3 switches physical connected to each other, switch 1 & 2 on the /27 subnet and switch 3 on the /28 subnet.

host 10.1.1.10 /27 has a network address bit of .0, host bits of .1 - .31, and broadcast of 32.host 10.1.1.20 /27 has a network address bit of .0, host bits of .1 - .31, and broadcast of 32.host 10.1.1.30 /28 has a network address bit of .16, host bits of .17 - 30, and broadcast address of .31.

- When 10.1.1.10 /27 & 10.1.1.30 /28 try to communicate they can't because the don't share the same network bit - When 10.1.1.10 /27 & 10.1.1.20 /27 everything works as expected - When 10.1.1.20 /27 and 10.1.10.30 /28 try to communicate they can because .20 and .30 share the same .16 network bit on the /28 network. That's the only conclusion I can come to.

scottsee wrote:This was a troubleshooting situation I had last night. They are all on the /27 now, my question is why the switches were even communicating between /27 and /28 subnet masking..

I'm confused. If all the interfaces have a /27 mask where are you getting a /28 from? Or did you have them different last night but you've now corrected it?

scottsee wrote:It's a weird scenario, I don't fully understand the problem, this is just what I can work out is happening.

I replicated the issue this morning by erasing the NVRAM on all 3 switches, and no configuration exist outside of just the vlan1 ip address/subnetting.

3 switches physical connected to each other, switch 1 & 2 on the /27 subnet and switch 3 on the /28 subnet.

host 10.1.1.10 /27 has a network address bit of .0, host bits of .1 - .31, and broadcast of 32.host 10.1.1.20 /27 has a network address bit of .0, host bits of .1 - .31, and broadcast of 32.host 10.1.1.30 /28 has a network address bit of .16, host bits of .17 - 30, and broadcast address of .31.

A little error here. .31 is the broadcast on a /27. .32 is going to be the network address of the next subnet.

And if I may nitpick, your use of terminology is a bit awkward here. I would say "the subnetwork bits are all set to 0" as opposed to saying "the network bit is set to .0". In this case, using the class c private range, you have a network of the first 24 bits, a subnet of 3 bits (due to the /27) and a 5 host bits.

Of course, that's assuming things are classful, which they are not, so it's all wrong anyway. Now it's just 27 bits for the network, and 5 for the host. There is no such thing a classes anymore and referring to them is incorrect.

scottsee wrote: - When 10.1.1.10 /27 & 10.1.1.30 /28 try to communicate they can't because the don't share the same network bit - When 10.1.1.10 /27 & 10.1.1.20 /27 everything works as expected - When 10.1.1.20 /27 and 10.1.10.30 /28 try to communicate they can because .20 and .30 share the same .16 network bit on the /28 network. That's the only conclusion I can come to.

I think that's right, right?

After reading this a few times, and changing my reply... I think you might have the right idea, you're just expressing it the wrong way.

It's not that they share the same "network bit", it's the switch 3 thinks that switch 2 is in the same subnet and that switch 1 is in a remote subnet.

switch 3 - 10.1.1.30/28 which means that switch 3 thinks that addresses 10.1.1.17 - 10.1.1.30 are valid host addresses in its local subnet.

When hosts are communicating on their local subnet they will ARP to get the layer two address, and then send the packet. If a host wants to communicate with another host that is not on its local subnet it needs to use its default gateway. If you have not configured a default gateway on switch 3 then it it needs to send a packet to a host not on its local subnet (it will think 10.1.1.10 is NOT local) then it will drop the packet because it has no way to reach it.

10.1.1.10/27 is the 10.1.1.0 subnet, which has a range from 1 to 30 and broadcast of 31, from it's perspective .30 is in the same subnet. Traffic from 1.10 can reach 1.30, but when 1.30 needs to send a reply this is what happens:

10.1.1.30/28 is the 10.1.1.16 subnet, which means .10 is not in the same subnet, this means you need routing for .30 to know how to reach back to .10.

10.1.1.20/27 is the 10.1.1.0 subnet, .30 is in the same subnet from .20 perspective.10.1.1.30/28 is as mentioned before the 10.1.1.16 subnet which means .20 is a valid host.

So what you are seeing is expected behaviour. You are on the right track with your thinking but you probably need to practice some more subnetting and get the terminology right, but thats what the scholarship is for right?

Sorry for the confusion. I literally just started studying a couple nights ago. It's frustrating not having the vocabulary and terminology down. I'll put a lot more effort into making things more clear.

I'm unable to get the interfaces to come up. I've built the lab on physical routers. I'm using T1 cables to connect the routers. Am I doing something wrong building this lab out on physical and not on GNS3.

I'm unable to get the interfaces to come up. I've built the lab on physical routers. I'm using T1 cables to connect the routers. Am I doing something wrong building this lab out on physical and not on GNS3.

Both T1 and Synchronous Serial interfaces will show up with "Serial" interface names.

If it really is T1 on an integrated CSU/DSU card (eg WIC-1DSU-T1), with a T1 crossover cable, then "clock rate" won't apply, because the T1 interface specifies a specific clock rate.

If it's a synch serial interface, then I'm not sure. My first thought is that you're not entering the command on a DCE interface (show controllers serial 0/0), but I'm pretty sure that if you mistakenly type the command on a DTE interface, it will complain about it not being a valid command for DCE interfaces.