On 9/5/25 2:33 PM, Ilya Maximets wrote: > On 9/5/25 2:13 PM, Dumitru Ceara wrote: >> Hi Ilya, >> >> On 9/5/25 1:41 PM, Ilya Maximets wrote: >>> On 9/5/25 9:16 AM, Surya Seetharaman via dev wrote: >>>> >>>> Also a side question for anyone who can answer (no need to derail the >>>> original intent >>>> of the thread), in real world routers how do things work? Is there a >>>> reliable link someone >>>> can provide pointing to a correct source page around this that I can read >>>> just for my own understanding? >>> >>> I'm not an expert on how router appliances work, but I know a bit how >>> routing >>> works in linux and so in linux-based routers. From my understanding, all >>> routing in linux is pretty much policy-based routing. There is a set of >>> policy rules (ip rule) that performs packet matching using different >>> criteria >>> including the input port or source address. And this is pretty much the >>> only place where you can do source based decision. Rules have priorities >>> and the actions. Priorities make the logic transparent, i.e. it's obvious >>> which rule will be evaluated first. Typical action is 'lookup ID' that >>> performs a route lookup in the corresponding routing table. If there is no >>> route, then the next priority policy rule is evaluated. Inside the routing >>> table, the match is dst-only, so there is no problem there. >>> >> >> What happens if there's a route match in the corresponding routing >> table? I'm assuming the packet is just forwarded according to the next >> hop of the route. > > Yes, if there is a match it just gets routed according to the match. > >> >> In OVN (leaving aside source ip based routing) one can configure: >> 1. a static route, e.g., dst=42.42.42.0/24 via 1.1.1.1 >> 2. a router policy (evaluated in the next stage, after static routes): >> if dst == 42.42.42.42 reroute 1.1.1.2 > > This policy just overrides the routing decision entirely. Why it needs > to be a policy and not just another route? It has a larger prefix, so > it will have higher priority. Or you can also keep it as a policy rule > that matches on 42.42.42.42 destination and performs a lookup in a > table with the only route being 1.1.1.2 default route. >
Sorry, I over-simplified. Let me try again with a different type of config: 1. a static route, e.g., dst=42.42.42.0/24 via 1.1.1.1 2. a router policy: if tcp.dst == 80 && dst == 42.0.0.0/8 reroute 1.1.1.2 Note the larger subnet in the policy. I'm not sure ovn-k8s has something like this configured but I'm pretty sure OVN would support it just fine today. >> >> Essentially changing the routing decision (1) for a subset of the >> traffic (dst 42.42.42.42). >> >> I'm trying to figure out how that would be configured in linux but i'm >> having a hard time figuring it out. >> >> I'm asking because this is something commonly used in ovn-kubernetes today. >> >>> And there are sane defaults for the policy rules: >>> >>> $ ip rule >>> 0: from all lookup local >>> 32766: from all lookup main >>> 32767: from all lookup default >>> >>> AFAIU, every router appliance manufacturer has their own logic on how policy >>> based routing interacts with routing tables and in which order the source >>> and destination matches are evaluated, so there is no standard there. >>> But mixing the source and the destination during the prefix-based lookup >>> seems unique to OVN and kind of strange indeed. >>> >>> For me it seems like what the linux kernel does is fairly flexible and less >>> ambiguous. There is single entry point (policy rules), clear priorities >>> and no mixing of src and dst during prefix lookups, as there is just no >>> prefix lookup for src. So, maybe that's the architecture OVN should >>> consider >>> moving towards. >>> >> >> It might be but, I guess, we need to make sure we're also flexible >> enough to easily support all the use cases CMS currently have. >> >>> Best regards, Ilya Maximets. >>> >> >> Regards, >> Dumitru >> > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
