General Discussion
  >> Fibre Broadband


Register (or login) on our website and you will not see this ad.


Pages in this thread: 1 | 2 | 3 | [4] | (show all)   Print Thread
Standard User XGS_Is_On
(experienced) Sun 19-Jul-26 17:08:24
Print Post

Re: Zzoomm Static IP query


[re: XGS_Is_On] [link to this post]
 
In reply to a post by XGS_Is_On:
In reply to a post by candlerb:
It *should* work. A standards-compliant router does longest-prefix match: if it has a static route to 84.18.228.42/32 and a connected route to 84.18.228.0/22, the former will be followed when the destination address of a datagram is .42

It will then see the next-hop of .1, which it can resolve via the connected route.


I just realised what you're saying. Networks don't work like this, sorry. Directly connected routes are not treated in the same manner as unconnected ones. On basic kit metrics or whatever they call it are a thing with directly connected always taking precedence, on more complex equipment admin distances. These end up in the RIB as route preference. Prefix length is further down the decision tree to differentiate routes with the same route preference. I'm not aware of any equipment or OS that assigns the same preference to directly connected as static. Cisco, Juniper, Fortinet, PAN, Aruba, Checkpoint, Linux, BSD, Windows all prefer connected over static, prefix length comparison never done as doesn't matter.


I have no idea why I wrote this. It's nonsense and I need to not post while, yeah never mind. You get the idea given the time of day. *Sigh* LPM wins, admin distance is later in the tree and I'm going to go hide somewhere.to rethink my life choices. The reason it may not work like that here is the behaviour of the switch chip in the router being used for hardware forwarding and how it's been programmed. I need to go relearn the basics it seems and perhaps see a doctor. This is incredibly fundamental stuff. Sorry OP/candlerb.

Edited by XGS_Is_On (Sun 19-Jul-26 17:09:58)

Standard User candlerb
(knowledge is power) Sun 19-Jul-26 19:35:23
Print Post

Re: Zzoomm Static IP query


[re: XGS_Is_On] [link to this post]
 
In reply to a post by XGS_Is_On:
I just realised what you're saying. Networks don't work like this, sorry. Directly connected routes are not treated in the same manner as unconnected ones. On basic kit metrics or whatever they call it are a thing with directly connected always taking precedence, on more complex equipment admin distances. These end up in the RIB as route preference. Prefix length is further down the decision tree to differentiate routes with the same route preference.

Sorry, but I have to disagree.

Routes from the various RIBs (e.g. static routes, connected routes, OSPF routes, BGP routes) are fed into the global RIB. If two *identical* routes (same prefix and prefix length) come from two different RIBs, then the admin distance is used to decide between them.

But two different routes (different prefix and/or length) will both find their way into the global RIB, which in turn is used to build the forwarding information base (FIB). And once in the FIB, it's longest-prefix match wins - always. In any case, the admin distances are lost by the time the routes get into the global RIB.

It's easy enough to demonstrate. For a living, I build classes for this sort of stuff using IOU, but you can check using Linux if you prefer. Here you go:

Text
1
23
45
67
89
10
root@nuc3:~# ip -4 a l dev incusbr0
12: incusbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000    inet 10.12.13.1/24 brd 10.12.13.255 scope global incusbr0
       valid_lft forever preferred_lft foreverroot@nuc3:~# ip route add 10.12.13.14/32 via 10.12.13.2
root@nuc3:~# ping 10.12.13.14PING 10.12.13.14 (10.12.13.14) 56(84) bytes of data.
^C--- 10.12.13.14 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1036ms


Meanwhile, in another window, I'm running tcpdump -i incusbr0 -nn:

Text
1
23
45
6
root@nuc3:~# tcpdump -i incusbr0 -nn
tcpdump: verbose output suppressed, use -v[v]... for full protocol decodelistening on incusbr0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:32:54.633806 ARP, Request who-has 10.12.13.2 tell 10.12.13.1, length 2818:32:55.669476 ARP, Request who-has 10.12.13.2 tell 10.12.13.1, length 28
18:32:56.693535 ARP, Request who-has 10.12.13.2 tell 10.12.13.1, length 28


You can see that it has followed the static route, and is ARPing for the next-hop of the static route (10.12.13.2), not for the address in the connected subnet (10.12.13.14)
Pages in this thread: 1 | 2 | 3 | [4] | (show all)   Print Thread

Jump to