4

suppose we have two networks net1 = 192.24.0.0/18 and net2 = 192.24.12.0/22 and if we have a packet with destination IP as 192.24.12.8. So, according to longest prefix matching rule, we send this packet to net2. Now I have a doubt that all the packets which match with both networks are sent only to net2, instead, it might be possible that some actually belong to net1. So isn't this incorrect because we are not sending to the actual destination?

  • 2
    The first part of your question is correct, but the second part of your question isn't clear what you're asking. If a packet matches two entries in the routing table, the longest match wins. – Ron Trunk Jun 5 '18 at 11:23
  • The problem is that 192.24.12.0/22 is part of 192.24.0.0/18, and not a separate network at all. – Ron Maupin Jun 5 '18 at 14:55
  • @RonMaupin Can't we have two such networks located separately? – Vishal Rana Jun 5 '18 at 15:13
  • 1
    No. That would imply you could have two hosts with the same address. For example, two hosts addressed as 192.24.12.33, one on each network. Addressing must be unique unless you have some kludge like NAT, but then one router would not have both networks. – Ron Maupin Jun 5 '18 at 15:22
  • Routers route between networks, and routing must be deterministic. A router cannot have interfaces with overlapping networks because the router could use the wrong interface for traffic. Remember that IP packets only have IP addresses, not masks, for the the destination. – Ron Maupin Jun 5 '18 at 15:25
4

So, according to longest prefix matching rule, we send this packet to net2.

That is correct.

Now I have a doubt that all the packets which match with both networks are sent only to net2, instead, it might be possible that some actually belong to net1.

This isn't possible unless you have another, even more specific (longer) routing table entry. In any case, this problem indicates overlapping subnets which are a general design error.

So isn't this incorrect because we are not sending to the actual destination?

A router always forwards according to its routing table (or routing policy when policy-based). There is no might be.

  • thanks for such a nice answer. But till now I was thinking that we can have two such physical networks attached to a router due to which I got this doubt. So I am thinking incorrect right?. But I have a doubt, is it not possible on the Internet to have two such networks which are at a different geographical location? Otherwise, we would have to look for all prefixes on Internet before creating a new one. – Vishal Rana Jun 5 '18 at 15:09
  • 1
    Routers generally don't allow that kind of setup (interfaces can't overlap), but it is technically a valid, if out dated, setup. As far as the /18 is concerned, the /22 is "on the wire" and the router will proxy-arp for the /22 hosts making them appear to be still be in the /18. This is Very Old School Bridging(tm). – Ricky Beam Jun 5 '18 at 20:17
  • @RickyBeam Interface-wise this isn't possible (not even technically), but with an aggregated route it is, ie. as seen from afar. Locally, overlapping networks can't work without serious trickery (proxy ARP and such). – Zac67 Jun 6 '18 at 10:54
0

If you do need to provice simultaneous access from overlapping networks (including the special case: two distinct but equal networks), for example to connect two RFC1918 networks, you will need policy based routing with stateful firewall. With stateful fw you mark connections originating from these networks based on interface, which received packets. With PBR you send responses to that interface (to be specific: you create a rule to direct marked packets to the appropriate routing table, as each routing table needs to be unambiguous).

According to the connectivity you require, i.e. - if you only want to provide access from the overlapping networks to the services you provide, or if you need also backward connectivity, you might need NAT as well - just map one of the networks out of the overlapping range; stateless NAT might be enough for some cases. Of course from your perspective one of the networks would be accessible under different IPs than actually assigned locally.

  • There are several ways to work your way around getting this to work, not necessarily using policy-based routing and a stateful firewall (you'd also need to take care of "local" ARP). All of these should be avoided though since sooner or later they drop on your feet. – Zac67 Jun 6 '18 at 11:04
  • ARP tables are per-interface, but indeed, querying the appropriate interface needs some attention when these networks are directly attached. As for the several ways - you might want to elaborate them. – Tomasz Pala Jun 6 '18 at 11:42
  • Sorry, no.This isn't anything that any serious engineer should want to work with. The several ways were referring to the approaches to handle the general ARP problem (proxy ARP, static ARP). – Zac67 Jun 6 '18 at 12:13
  • Serious engineer sometimes simply needs to join two (or more...) networks with colliding address spaces, both administered by someone else. I myself had to provide interconnectibility between 3 (yes, three) separate networks working in single company (sic!). With one uncooperative administrator, second incompetent and third unknown (entirely missing). Their networks used entire 192.168/16 and 10/8 ranges, with no central host management. In such situation you can't do anything more than NAT into 172.16/12 space to get this working ...and leave the problem of 4 networks to someone else. – Tomasz Pala Jun 6 '18 at 12:52
0

(my comment merits expansion)

IOS -- at least versions you'll find today -- don't allow interfaces to overlap:

rtr1841(config)#int loopback 10
rtr1841(config-if)#ip address 192.24.0.1 255.255.192.0
rtr1841(config-if)#int loopback 11                    
rtr1841(config-if)#ip address 192.24.12.1 255.255.252.0
% 192.24.12.0 overlaps with Loopback10

Linux -- and systems like it (*BSD, Solaris, etc.) -- will allow it:

root@r610-b8:~# ip -4 addr
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet 192.168.51.20/24 brd 192.168.51.255 scope global eno1
3: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet 192.168.51.129/28 scope global eno2

With ip-forwarding and proxy-arp enabled, this setup does actually work. The machine acts like a router (ip-forwarding) while bridging the two segments (proxy-arp). Nodes within the smaller segment use 129 as their router. Nodes within the larger segment will ARP for addresses across the entire /24, because the netmask says it's on-the-wire local; .20 will answer those requests with its own MAC and forward traffic into the /28, so long as it has a MAC for the destination.

This is a Highly Undesirable Setup™. It's a 1970's era legacy construct. It's just bad practice to divide and stack networks like this. I did it out of simplicity and address sanity for openstack development. (dev environments can be messy)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.