Home | History | Annotate | Download | only in doc

Lines Matching refs:FROM

25 from the \verb|iproute2| package. It is not a tutorial or user's guide.
72 the protocol family is guessed from other arguments. If the rest of the command
111 --- read commands from provided file or standart input and invoke them.
124 or from standart input:
207 \verb|ip| failed to compile a kernel request from the arguments
231 from the context of the command.
403 unique at every given moment. However, the interface may disappear from the
431 from other nodes on the network.
442 and all packets received by us came from this single peer.
471 \item \verb|NOARP| --- this flag is different from the other ones. It has
475 without any help from the protocol stacks.
697 --- deletes the loopback address from the loopback device.
842 \paragraph{Example:} Delete all the addresses from the private network
859 acquired by the host from stateless address autoconfiguration
964 The deleted neighbour entry will not disappear from the tables
1047 may remove the entry from the neighbour table.
1159 from transport protocols to select a working router, so the order
1226 tables identified by a number in the range from 1 to 255 or by
1227 name from the file \verb|/etc/iproute2/rt_tables|. By default all normal
1271 number or an identifier from {\tt /etc/iproute2/rt\_dsfield}.
1281 \verb|TABLEID| may be a number or a string from the file
1307 \verb|REALMID| may be a number or a string from the file
1350 Linux uses a default value calculated from the first hop device MTU.
1395 \verb|SCOPE_VAL| may be a number or a string from the file
1405 \verb|RTPROTO| may be a number or a string from the file
1534 --- only select routes from the given range of destinations. \verb|SELECTOR|
1553 --- show the routes from this table(s). The default setting is to show
1567 --- list cloned routes i.e.\ routes which were dynamically forked from
1571 \item \verb|from SELECTOR|
1574 rather than destinations. Note that the \verb|from| option only works with
1647 193.233.7.82 from 193.233.7.82 dev eth0 src 193.233.7.65 \
1657 it is a path from 193.233.7.82 back to 193.233.82? Well, you will
1782 gatewayed routes from the main table (f.e.\ after a routing daemon crash).
1789 from BSD, but was never implemented in Linux.
1850 \item \verb|from ADDRESS|
1860 --- the device from which this packet is expected to arrive.
1868 --- if no source address (option \verb|from|) was given, relookup
1869 the route with the source set to the preferred address received from the first lookup.
1883 that a packet arrived from this interface and searches for
1900 from 193.233.7.82 and destined for 193.233.7.82:
1902 kuznet@amber:~ $ ip r g 193.233.7.82 from 193.233.7.82 iif eth0
1903 193.233.7.82 from 193.233.7.82 dev eth0 src 193.233.7.65 \
1910 This is the command that created the funny route from 193.233.7.82
1916 from host 193.233.7.82 and destined for multicast group 224.2.127.254
1920 kuznet@amber:~ $ ip r g 224.2.127.254 from 193.233.7.82 iif eth0
1921 multicast 224.2.127.254 from 193.233.7.82 dev lo \
1926 This route differs from the ones seen before. It contains a ``normal'' part
1949 PING 193.233.7.98 (193.233.7.98) from 193.233.7.90 : 56 data bytes
1950 From 193.233.7.254: Redirect Host(New nexthop: 193.233.7.98)
1951 64 bytes from 193.233.7.98: icmp_seq=0 ttl=255 time=3.5 ms
1952 From 193.233.7.254: Redirect Host(New nexthop: 193.233.7.98)
1953 64 bytes from 193.233.7.98: icmp_seq=1 ttl=255 time=2.2 ms
1954 64 bytes from 193.233.7.98: icmp_seq=2 ttl=255 time=0.4 ms
1955 64 bytes from 193.233.7.98: icmp_seq=3 ttl=255 time=0.4 ms
1956 64 bytes from 193.233.7.98: icmp_seq=4 ttl=255 time=0.4 ms
2037 a route from these tables according to the classic longest match algorithm.
2119 \item \verb|from PREFIX|
2130 the rule only matches packets originating from this host. This means that you
2163 \item \verb|realms FROM/TO|
2188 \item Route packets with source addresses from 192.203.80/24
2191 ip ru add from 192.203.80.0/24 table inr.ruhep prio 220
2197 ip ru add from 193.233.7.83 nat 192.203.80.144 table 1 prio 320
2221 0: from all lookup local
2222 200: from 192.203.80.0/24 to 193.233.7.0/24 lookup main
2223 210: from 192.203.80.0/24 to 192.203.80.0/24 lookup main
2224 220: from 192.203.80.0/24 lookup inr.ruhep realms inr.ruhep/radio-msu
2225 300: from 193.233.7.83 to 193.233.7.0/24 lookup main
2226 310: from 193.233.7.83 to 192.203.80.0/24 lookup main
2227 320: from 193.233.7.83 lookup inr.ruhep map-to 192.203.80.144
2228 32766: from all lookup main
2359 \paragraph{Example:} Let us continue with the example from the previous subsection.
2421 \item \verb|from PREFIX|
2666 One approach to propagating the policy from routing protocols
2708 If the destination realm was not inherited from the route and the rule has a destination realm,
2712 \item If the source realm is still unknown, get it from the reversed route.
2718 arrived from and the realm where it is going to propagate to.
2736 This shows that this router received 153805 packets from
2903 to the destination goes back via the interface from which the solicitation
2933 several servers with NAT. This is a mistake. All you get from this
2989 ip rule add prio 320 from 193.233.7.83 nat 192.203.80.144
3010 example from sec.\ref{IP-RULE-SHOW} (p.\pageref{IP-RULE-SHOW}).
3012 300: from 193.233.7.83 to 193.233.7.0/24 lookup main
3013 310: from 193.233.7.83 to 192.203.80.0/24 lookup main
3014 320: from 193.233.7.83 lookup inr.ruhep map-to 192.203.80.144
3017 packets from 193.233.7.83 do not leave networks 193.233.7/24
3020 domain owning addresses from 192.203.80/24 is dead), no translation
3027 Suppose you did and all the packets from 193.233.7.83
3031 320: from 193.233.7.83 fwmark 1234 lookup main map-to 192.203.80.144
3053 It also refers to a DHCP client, \verb|dhcpcd|. I should refrain from