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?
3 Answers
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. Jun 5, 2018 at 15:09
-
1Routers 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).– RickyJun 5, 2018 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, 2018 at 10:54
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, 2018 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. Jun 6, 2018 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, 2018 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. Jun 6, 2018 at 12:52
(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)
192.24.12.0/22is part of192.24.0.0/18, and not a separate network at all.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.