net: remove policy-routing.txt documentation
authorVincent Bernat <vincent@bernat.im>
Tue, 27 Jun 2017 13:42:57 +0000 (15:42 +0200)
committerDavid S. Miller <davem@davemloft.net>
Tue, 27 Jun 2017 18:38:17 +0000 (14:38 -0400)
It dates back from 2.1.16 and is obsolete since 2.1.68 when the current
rule system has been introduced.

Signed-off-by: Vincent Bernat <vincent@bernat.im>
Signed-off-by: David S. Miller <davem@davemloft.net>
Documentation/networking/policy-routing.txt [deleted file]

diff --git a/Documentation/networking/policy-routing.txt b/Documentation/networking/policy-routing.txt
deleted file mode 100644 (file)
index 36f6936..0000000
+++ /dev/null
@@ -1,150 +0,0 @@
-Classes
--------
-
-       "Class" is a complete routing table in common sense.
-       I.e. it is tree of nodes (destination prefix, tos, metric)
-       with attached information: gateway, device etc.
-       This tree is looked up as specified in RFC1812 5.2.4.3
-       1. Basic match
-       2. Longest match
-       3. Weak TOS.
-       4. Metric. (should not be in kernel space, but they are)
-       5. Additional pruning rules. (not in kernel space).
-       
-       We have two special type of nodes:
-       REJECT - abort route lookup and return an error value.
-       THROW  - abort route lookup in this class.
-
-
-       Currently the number of classes is limited to 255
-       (0 is reserved for "not specified class")
-
-       Three classes are builtin:
-
-       RT_CLASS_LOCAL=255 - local interface addresses,
-       broadcasts, nat addresses.
-
-       RT_CLASS_MAIN=254  - all normal routes are put there
-       by default.
-
-       RT_CLASS_DEFAULT=253 - if ip_fib_model==1, then
-       normal default routes are put there, if ip_fib_model==2
-       all gateway routes are put there.
-
-
-Rules
------
-       Rule is a record of (src prefix, src interface, tos, dst prefix)
-       with attached information.
-
-       Rule types:
-       RTP_ROUTE - lookup in attached class
-       RTP_NAT   - lookup in attached class and if a match is found,
-                   translate packet source address.
-       RTP_MASQUERADE - lookup in attached class and if a match is found,
-                   masquerade packet as sourced by us.
-       RTP_DROP   - silently drop the packet.
-       RTP_REJECT - drop the packet and send ICMP NET UNREACHABLE.
-       RTP_PROHIBIT - drop the packet and send ICMP COMM. ADM. PROHIBITED.
-
-       Rule flags:
-       RTRF_LOG - log route creations.
-       RTRF_VALVE - One way route (used with masquerading)
-
-Default setup:
-
-root@amber:/pub/ip-routing # iproute -r
-Kernel routing policy rules
-Pref Source             Destination        TOS Iface   Cl
-   0 default            default            00  *       255
- 254 default            default            00  *       254
- 255 default            default            00  *       253
-
-
-Lookup algorithm
-----------------
-
-       We scan rules list, and if a rule is matched, apply it.
-       If a route is found, return it.
-       If it is not found or a THROW node was matched, continue
-       to scan rules.
-
-Applications
-------------
-
-1.     Just ignore classes. All the routes are put into MAIN class
-       (and/or into DEFAULT class).
-
-       HOWTO:  iproute add PREFIX [ tos TOS ] [ gw GW ] [ dev DEV ]
-               [ metric METRIC ] [ reject ] ... (look at iproute utility)
-
-               or use route utility from current net-tools.
-               
-2.     Opposite case. Just forget all that you know about routing
-       tables. Every rule is supplied with its own gateway, device
-       info. record. This approach is not appropriate for automated
-       route maintenance, but it is ideal for manual configuration.
-
-       HOWTO:  iproute addrule [ from PREFIX ] [ to PREFIX ] [ tos TOS ]
-               [ dev INPUTDEV] [ pref PREFERENCE ] route [ gw GATEWAY ]
-               [ dev OUTDEV ] .....
-
-       Warning: As of now the size of the routing table in this
-       approach is limited to 256. If someone likes this model, I'll
-       relax this limitation.
-
-3.     OSPF classes (see RFC1583, RFC1812 E.3.3)
-       Very clean, stable and robust algorithm for OSPF routing
-       domains. Unfortunately, it is not widely used in the Internet.
-
-       Proposed setup:
-       255 local addresses
-       254 interface routes
-       253 ASE routes with external metric
-       252 ASE routes with internal metric
-       251 inter-area routes
-       250 intra-area routes for 1st area
-       249 intra-area routes for 2nd area
-       etc.
-       
-       Rules:
-       iproute addrule class 253
-       iproute addrule class 252
-       iproute addrule class 251
-       iproute addrule to a-prefix-for-1st-area class 250
-       iproute addrule to another-prefix-for-1st-area class 250
-       ...
-       iproute addrule to a-prefix-for-2nd-area class 249
-       ...
-
-       Area classes must be terminated with reject record.
-       iproute add default reject class 250
-       iproute add default reject class 249
-       ...
-
-4.     The Variant Router Requirements Algorithm (RFC1812 E.3.2)
-       Create 16 classes for different TOS values.
-       It is a funny, but pretty useless algorithm.
-       I listed it just to show the power of new routing code.
-
-5.     All the variety of combinations......
-
-
-GATED
------
-
-       Gated does not understand classes, but it will work
-       happily in MAIN+DEFAULT. All policy routes can be set
-       and maintained manually.
-
-IMPORTANT NOTE
---------------
-       route.c has a compilation time switch CONFIG_IP_LOCAL_RT_POLICY.
-       If it is set, locally originated packets are routed
-       using all the policy list. This is not very convenient and
-       pretty ambiguous when used with NAT and masquerading.
-       I set it to FALSE by default.
-
-
-Alexey Kuznetov
-kuznet@ms2.inr.ac.ru