Weird routing/subnet question

[WStoffel1]

If you have the subnet 24.48.75.0/24 giving you a host range of 24.48.75.1 - 254 defined on an interface

and you then have a static route statement:

ip route 24.48.75.64 255.255.255.224 X.X.X.X

Have you effectively lost 2 addresses?

Meaning, even though it's just a static route, does 24.48.75.64 become a network number and 24.48.75.95 a broadcast, and consequently unusable as host addresses? 

Thanks.

PS, I'm not looking for best practices type info, it's just hypothetical as I try to work out an possible issue...and wanted to know if my thinking was correct.

[cadet alain]

Hi,

you're just configuring a network static route and this subnet you are routing to still has a broadcast and subnet id and so these can't be configured as source address on any node.

Regards

Alain

Don't forget to rate helpful posts.

[Richard Burts · Accepted solution]

We tend to think of routing in terms of networks and subnets and I think that Alain's response is based on the assumption that you are routing to a subnet. But that is not necessarily the case. So let me take a slightly different approach in answering the question.

I would start from the assertion that a route statement is just a direction about how to get to some range of addresses and that any address in the range is potentially valid. And I would especially say that from a routing perspective if you have a route such as ip route 24.48.75.64 255.255.255.224 X.X.X.X then the addresses 24.48.75.64 and 24.48.75.95 are potentially valid addresses. You can not determine whether 24.48.75.64 is a subnet address or a host address until you get to the place where those addresses are deployed.

Let me suggest a scenario that may illustrate my point. Let us think of router A where the route is being configured, router B and router C which each provide a connection to router D where subnet 24.48.75.0/24 is configured. Let us assume that router A has a route for the /24 that points through router B. And let us assume that for some reason (perhaps load balancing, perhaps some security concern based on the type of server in the particular address range) that it wants to router 24.48.75.64 through 24.48.75.95 through router C. So you configure ip route 24.48.75.64 255.255.255.224 X.X.X.X (where X.X.X.X is on router C) and the result is that this particular address range is routed differently. And clearly .64 and .95 are still valid host addresses.

So I would answer the original question that no you have not necessarily lost 2 addresses.

HTH

Rick

[Peter Paluch]

Rick,

Very nice and insightful answer.

Best regards,

Peter

[WStoffel1]

Yes very insightful.  My inclination was towards cadet alain's response.  My thinking is the router will look at 24.48.75.95 as a legitimate broadcast and cause some sort of issue in trying to reach that host, but couldn't put my finger on it.

However your example stands up.  Thank you.  I'll have to mull this over.

[Peter Paluch]

Hi,

My thinking is the router will look at 24.48.75.95 as a legitimate broadcast and cause some sort of issue in trying to reach that host, but couldn't put my finger on it.

It won't. The broadcast is really a concept that is relevant only to a router directly connected to the network whose broadcast address you are referring to. Other routers do not care at all. As long as the destination IP address of a packet ANDed with the netmask produces the network address in the respective row of the routing table, the packet is destined for that network so let's forward it there.

After all, that is the foundation of a directed broadcast that is still being used in certain scenarios.

Best regards,

Peter

[Richard Burts]

Peter

Thank you.

Interestingly I started to say something about the relationship with directed broadcast in my first response and then decided to try to keep my response shorter and more focused. So let me add this to the discussion.

In forwarding a packet (and in configuring a static route) the originating router has no way to know whether a destination is a broadcast address or not. So a router will always forward traffic toward the destination and only the router for which the destination is locally connected can determine whether it is broadcast or not.

For example consider this - ip helper-address 172.16.2.255

Will this produce a directed broadcast or not? (is 172.16.2.255 a broadcast address or not?)

If the subnet is 172.16.2.0 255.255.255.0 then the answer is yes.

If the subnet is 172.16.2.0 255.255.254.0 then the answer is no.

Who can tell the difference and accurately know if it is a broadcast or not - only the router where that subnet is connected. All other routers will just forward the traffic and not care whether it is a broadcast or not.

HTH

Rick

[WStoffel1]

Well ok, but in this example you're clearly defining a subnet, 172.16.2.0/24 vs 172.16.2.0/23, the latter with 172.16.2.255 being a host address.  And 172.16.3.0 one as well.

But take the following snippet of a config where an ip block is given to a customer from an isp:

IP block: 70.11.120.0/22

The customer then goes and carves it up as needed.

interface GigabitEthernet0/2

ip address 70.11.120.10 255.255.255.252

!

interface GigabitEthernet0/3

ip address 70.11.121.3 255.255.255.0 secondary

ip address 70.11.120.62 255.255.255.224 secondary

ip address 70.11.123.152 255.255.255.192 secondary

ip address 70.11.120.2 255.255.255.248

!

!

!

ip route 70.11.120.64 255.255.255.192 GigabitEthernet0/3

ip route 70.11.120.128 255.255.255.128 70.11.120.4

ip route 70.11.122.0 255.255.255.0 GigabitEthernet0/3

ip route 70.11.123.0 255.255.255.128 70.11.120.4

ip route 70.11.123.192 255.255.255.192 70.11.120.4

Is 70.11.120.64 a valid host address or is it a network number?

Thanks by the way for all the help so far..

[Richard Burts]

Based on that you have posted it is impossible to know whether 70.11.120.64 is a host or a network number. This is because we do not see the router interface where that address is locally connected.

Based on your highlighted secondary subnet on gig0/3 which has subnet 70.11.120.32/27 configured we would think it likely that 70.11.120.64 might be a subnet. But what if 70.11.120.64 is assigned to a loopback interface with mask 255.255.255.255? Then it is a legitimate host address and not a network.

I would hope that by now it should be becoming obvious that until you see the interface where the address is locally connected you can not tell whether it is a host address or a network address.

HTH

Rick

[WStoffel1]

yes is helps immensely.  thank you.

i was sort of leading somewhere as i have this very odd customer problem.

the router above (call it routerA) with the info i bolded, has a primary gig 0/3 address of :

ip address 70.11.120.2 255.255.255.248

and that route which sends it out Gig0/3:

ip route 70.11.120.64 255.255.255.192 GigabitEthernet0/3

Gig0/3 is connnected to Gig0/1 on this router (routerB):

interface GigabitEthernet0/1

ip address 70.11.120.4 255.255.255.248

!

interface GigabitEthernet0/2

ip address 70.11.120.153 255.255.255.252

!

interface GigabitEthernet0/3

ip address 70.11.120.185 255.255.255.252

!

!

ip route 0.0.0.0 0.0.0.0 70.11.120.5

ip route 70.11.120.172 255.255.255.252 70.11.120.142

ip route 70.11.123.0 255.255.255.248 70.11.120.134

ip route 70.11.123.8 255.255.255.248 70.11.120.138

ip route 70.11.123.16 255.255.255.248 70.11.120.142

ip route 70.11.123.24 255.255.255.248 70.11.120.146

ip route 70.11.123.40 255.255.255.248 70.11.120.154

ip route 70.11.123.48 255.255.255.248 70.11.120.158

ip route 70.11.123.64 255.255.255.248 70.11.120.166

ip route 70.11.123.72 255.255.255.248 70.11.120.170

ip route 70.11.123.96 255.255.255.248 70.11.120.186

ip route 70.11.123.104 255.255.255.248 70.11.120.182

!

!

From RouterB:

sh ip route 70.11.120.64 255.255.255.192

% Network not in table

So naturally uses the default route and sends it to 70.11.120.5.

My problem is 70.11.120.5 is a glbp ip address on RouterA.

So i guess my question becomes do i have a routing loop or am I not grasping a config issue with glbp?

[Richard Burts]

I do not see how glbp would become a factor here. My impression is that there is some misconfiguration which results in a routing loop or some problem.

It is difficult for me to come up with a scenario where they would on purpose route from router A to router B in order to get back to router A.

And I find the static route on router A to be slightly an issue, though it may give us some clue about things. In general it is not good to have a static route that points just to the outbound interface when that interface is Ethernet (as this static route does). There are several reasons why this is not good and one of them is that it forces router A to ARP for any destination address reached through that route. So router A must ARP for 70.11.120.64 or whatever address within that range it is attempting to forward. It might be useful to do show arp on router A and look for any entries for addresses that are within that subnet. We expect that the MAC for those addresses would be the MAC from router B but it might be good to verify that.

Do you know if the customer has allocated the address 70.11.120.64 (and perhaps with a mask different from 255.255.255.192) and if so where that subnet is actually located?

HTH

Rick

[WStoffel1]

No there are no currently allocated addresses in that range.  In fact the whole reason I started looking at this was because there's another range in the full /22 block that is dedicated to a specific purpose, 70.11.122.64 /26 coincedentally, in which someone assigned 70.11.122.127 to a host and had issues.  There's no other issues in that range, 127 being the broadcast, i changed it to 95 which was available and it all worked.  That snowballed into me looking at how this subnet had originally been broken up.  And i'm finding many problems like this that don't make sense.

If I show arp on RouterA i actually see

Internet  70.11.120.76           0   Incomplete      ARPA

Internet  70.11.120.111          0   Incomplete      ARPA

Internet  70.11.120.83          0   Incomplete      ARPA

Those addresses as far as I know have never been used.

Oh it appears if i keep showing arp tables those addresses above change.  But that range is always incomplete hardware addresses.

I have not been able to find anything else with those specific addresses either with that mask or another, or defined on any other device.  Perhaps sometime previously that block was going to be utilized for something, they got as far as defining the route and never went further, and just didn't clean it up.

[Richard Burts · Accepted solution]

Thanks for the additional information. It does help to explain a bit about what is going on.

If that range is not allocated/assigned anywhere then I certainly would suggest removing the static route.

The situation is pretty interesting. What you have is really not a loop. And this is because of the way that the static route was configured. The best practice for static routes going out an Ethernet interface is to put the next hop address into the static route. If the static route had been configured that way it would, in fact, have produced a loop. But because it just points to the exit interface then the router must ARP for each destination address. The incomplete entries that you are seeing in the arp table are where some packet has come to the router with that destination address. The router has issued an ARP request, and creating the incomplete entry is part of sending the ARP request (it is a placeholder while the router waits for a response and then will have a place to put the MAC address). So the router is getting these packets, is sending the ARP request, creates the incomplete entry, does not receive an ARP response (because the device does not exist), drops the packet, and removes the incomplete entry. So there is no loop in this particular situation.

It has been a very interesting discussion and I am glad that we finally have pretty much got to the bottom of the issue.

HTH

Rick

[WStoffel1]

Yes, and thank you very much for hanging in there.  What sometimes could be a two minute converstation tends to get rather lengthy when troubleshooting this way.

[Richard Burts]

You are very welcome. It has been a very interesting conversation and I am glad that we finally got a good understanding of the issue. You are right that sometimes a direct conversation can find a solution pretty quickly and that working the issue through the forum can take a bit longer, especially since the most relevant details take a bit longer to discover. The good news is that we did figure out what is the underlying issue here. And it is another example of the value of the forum in finding solutions for problems that members are facing.

HTH

Rick