Lines Matching defs:and
52 ``network unreachable'' and after this I found a strange direct route
74 that between \verb|route add| and \verb|route del| host 193.233.7.65 is
78 Q: In 2.0.36 I used to load \verb|tunnel| device module and \verb|ipip| module.
82 and for all IPIP tunnel devices.
93 and you are not afraid of
102 \paragraph{Summary of differences between 2.2 and 2.0.}
107 and got set of 4 devices \verb|tunl0| ... \verb|tunl3| or,
108 alternatively, compile it as module and load new module
113 tunnel device \verb|tunl0| and another tunnels may be created with command
133 kinds and gateway is required to be directly reachable via this tunnel,
170 \verb|ipip|, \verb|sit| and \verb|gre|.
183 Both \verb|remote| and \verb|local| may be omitted. In this case we
185 have the same \verb|remote| and \verb|local|. Particularly it means
190 have some not wildcard \verb|remote| address and deliver all the packets
191 to this destination, and {\bf NBMA} (i.e. Non-Broadcast Multi-Access) tunnels,
200 routing infrastructure and simultaneously create new virtual links,
209 and add routes with \verb|route| utility.
244 tunneled packets will be routed only via this device and will
253 \verb|ipip| and \verb|sit| tunnels have no more options. \verb|gre|
266 work. At least, I did not test it, did not debug it and
267 even do not understand, how it is supposed to work and for what
274 Actually, these GRE options can be set separately for input and
277 packets with correct checksum and \verb|ocsum| means, that
278 our host will calculate and send checksum.
305 \section{Differences 2.2 and 2.0 tunnels revisited.}
308 and 2.2.
314 tunnel device and packet looks as received on this. F.e.\ if host
320 1 & \verb|remote| is \verb|D| and \verb|local| is \verb|S| \\
321 2 & \verb|remote| is \verb|D| and \verb|local| is wildcard \\
322 3 & \verb|remote| is wildcard and \verb|local| is \verb|S| \\
333 and to enable reversed path filter (\verb|rp_filter| sysctl option) on
336 \item In 2.2 you can monitor and debug tunnels with \verb|tcpdump|.
338 which kernel output, via tunnel \verb|Cisco| and the packets received on it
344 \section{Linux and Cisco IOS tunnels.}
346 Among another tunnels Cisco IOS supports IPIP and GRE.
369 \section{Interaction IPIP tunnels and DVMRP.}
374 From kernel and user viewpoints there are no differences between
375 tunnels, created in this way, and tunnels created by \verb|ip tunnel|.
380 tunnel with the same local and remote addresses.
397 This tunnel is true broadcast network and broadcast packets are
399 to resolve both IP and IPv6 addresses via ARP/NDISC, so that
401 will find one another automatically and will form virtual Ethernet-like
408 and to add required information to ARP tables manually:
413 and sent to 128.6.190.2. It is possible to facilitate address resolution
421 it is really flexible, scalable and easily managable, so that
423 hack with NBMA mode and \verb|onlink| modifier. Unfortunately,
432 applies to them. The simplest (and the most useful in practice)
439 and queuing not more than 10K.
442 implemented in software and true queue management is impossible for them
444 on real physical interfaces and to map tunneled packets to them.
449 and you need to setup corresponding classes only on it.
454 specially for tunnel \verb|Cisco| with endpoints \verb|S| and \verb|D|.
455 Now you can select IPIP packets with addresses \verb|S| and \verb|D|
456 with some classifier and map them to class \verb|1:ABC|. F.e.\
466 rooted at \verb|1:ABC| and attach to subroot set of rules parsing