Ip command Manual (IV)

Ip command Manual (IV)

10. IP mroute-Multicast Route Cache Management

10. 1. Abbreviations

Mroute, Mr

10. 2. Object

The operation object of this command is the Multicast Route cache entry, which is played by a user space
A route monitoring process (such as pimd or mrouted) is created.

Currently, due to restrictions on multicast routing engine interfaces, you cannot use IP commands to modify Multicast Routing
So we can only view.

10. 3. Command

Show or list

10.4.ip mroute show -- list Multicast Route cache entries

Abbreviations: Show, list, sh, ls, l

Parameters

To prefix (default) the destination multicast address is prefix.
Network Interface for IIF name to receive multicast data packets
From prefix Prefix: select the IP Source Address of the Multicast Route

Output Format

Kuznet @ AMBER :~ $ IP mroute ls
(193.232.127.6, 224.0.1.39) IIF: unresolved
(193.232.244.34, 224.0.1.40) IIF: unresolved
(193.233.7.65, 224.66.66.66) IIF: eth0 oifs: pimreg
Kuznet @ AMBER :~ $

The cache entries of multicast routes are in the form of (S, g), S is the source address, and G is the multicast group. IIF is the number of multicast packets received.
Network Interface of the data packet. If the device name is unresolved, it indicates that the route monitoring process cannot be parsed.
The keyword next to this entry is OIF, which is followed by some output network interfaces.
Cells are separated.

Statistics

Using the-Statistics option, we can get more detailed output information, including:
Number, the number of bytes forwarded through this route, and the number of packets that reach the error interface (if any ).

Kuznet @ AMBER :~ $ IP-s Mr ls 224.66/16
(193.233.7.65, 224.66.66.66) IIF: eth0 oifs: pimreg
9383 packets, 300256 bytes
Kuznet @ AMBER :~ $

11. IP Tunnel-Channel Configuration

11. 1. Abbreviations

Tunnel and tunl

11. 2. Object

The operation object of the IP Tunnel command is the network tunnel ). Tunnel refers
The data packet is encapsulated into an IPv4 packet and sent using the IP protocol. For more information about the channel, see
The iproute documentation tunnels over IP in Linux-2.2.

11. 3. Command

Add, delete, change, show, or list

11.4.ip tunnel add -- Add a new channel
IP Tunnel change -- modify existing channel
IP Tunnel Delete -- delete a channel

Abbreviations: add, A; change, chg; delete, Del, d

Parameters

Name (default) select Channel Device Name
Mode mode sets the channel mode. Valid modes include ipip, sit, and GRE.
Remote address
The local address is the fixed local address of the data packet entering the channel. It must be another interface on the local machine.
.
Ttl n is set to N for the incoming channel data packet. N is a number between 1 and. 0 is a special
Value, indicating that the TTL value of this data packet is inherited (inherit. The default value of TTL is "inherit.

The tos t or dsfield T is set to enter the TOS domain of the channel data packet. The default value is inherit.
Dev name binds the channel to the device name so that data packets entering the channel can only be routed through the name Device
When the peer end changes, the encapsulation cannot be unwrapped on another device.
In this channel, nopmtudisc prohibits path MTU discovery ). Mo
This function is enabled. Note: This option is incompatible with the fixed TTL.
With a fixed TTL parameter, the system will enable path MTU discovery
Yes.
Key K, ikey K, and okey K are only applicable to GRE channels, and key of keyed GRE channel is set. K or
A sequence of numbers or IP addresses. The parameter key is used in both directions of the channel, and the Ikey And okey are inputs.
Set different keys for input and output.
Csum, icsum, and ocsum are only used for the GRE channel and calculate the packet checksum of the incoming channel. Ocsum indicates only
The calculated packet checksum; icsum indicates that only the incoming packet checksum is calculated; csum and so on
In icsum ocsum.
Seq, iseq, and oseq are only applicable to GRE channels and send/receive packets sequentially. Oseq outbound data packets
Sequential transmission; iseq requires that all incoming data packets are in order; seq is equal to iseq oseq.

Example

Create a point-to-point channel with a maximum TTL of 32
Netadm @ AMBER :~ # IP Tunnel add Cisco mode sit remote 192.31.7.104
Local 192.203.80.1 TTL
32

11.4.ip tunnel show -- Some channels appear in the column

Abbreviations: Show, list, sh, ls, l

Parameters

None

Output Format

Kuznet @ AMBER :~ $ IP Tunnel ls Cisco
Cisco: IPv6/IP remote 192.31.7.104 local 192.203.80.142 TTL 32
Kuznet @ AMBER :~ $

The first part of the output is the device name of the channel, followed by the channel mode. The following figure shows
Parameters.

Statistics

Kuznet @ AMBER :~ $ IP-s tunl ls Cisco
Cisco: IPv6/IP remote 192.31.7.104 local 192.203.80.142 TTL 32
RX: Packets bytes errors csumerrs outofseq mcasts
12566 1707516 0 0 0 0
TX: Packets bytes errors deadloop noroute nobufs
13445 1879677 0 0 0 0
Kuznet @ AMBER :~ $

The numbers in the above output results are the same as those in the IP-s link show output, but each
The flag is specific to the channel.

Csumerrs indicates the GRE channel for enabling the checksum test. This number is dropped due to a checksum error.
Number of data packets.
The number of data packets discarded by outofseg due to an incorrect sequence in the GRE channel that enables the sequence function.
The number of multicast packets received by mcasts on the GRE channel.
Deadloop does not transmit the number of data packets because the channel is directed to itself.
Noroute does not transmit the number of data packets because there is no route to the peer end.
Nobufs does not transmit the number of data packets because the kernel cannot allocate a buffer.

12. IP monitor and rtmon -- Status Monitoring

IP commands can be used to continuously monitor the status of devices, addresses, and routes. The command options are in the format
The command option is called Monitor, followed by the operation object:

IP monitor [file] [All | object-list]

Object-list is some monitored objects, including link, address, and route. If
If the file parameter is not provided, the ip command will enable rtnetlink, listen on it, and output the status change.
To the standard output device.

If the file parameter is used, the ip command does not listen on rtnetlink, but opens the file parameter.
The number of specified binary files that contain rtnetlink information. The resolution result is displayed. This historical document
Parts can be generated by tools. This tool has a command line similar to the IP monitor command syntax. Ideal
In this case, run the rtmon command before the network configuration command starts. (Of course, you can start the command at any time.
Rtmon, which records the status changes from startup ). You can insert the following command line in the startup script:

Rtmon file/var/log/rtmon. Log

If we execute the following command:

[Root @ nixe0n root] IP Route add Dev eth0 to 61.133.4.7 via 211.99.114.
65
[Root @ nixe0n root] IP Route del Dev eth0 to 61.133.4.7

Then, we use the IP monitor command to analyze/var/log/rtmon. log and we will get the following output results:
:

[Root @ nixe0n root] IP monitor file/var/log/rtmon. log R
Timestamp: Wed NOV 6 20:25:54 2002 733331 us
1: Lo: MTU 16436 qdisc noqueue
Link/loopback 00: 00: 00: 00: 00: 00 BRD 00: 00: 00: 00: 00: 00
2: eth0: MTU 1500 qdisc pfifo_fast
Link/ether 00: 01: 4f: 00: 15: F1 brd ff: FF
Timestamp: Wed NOV 6 20:25:58 2002 33700 us
61.133.4.7 via 211.99.114.65 Dev eth0
Timestamp: Wed NOV 6 20:25:59 2002 924124 us
Deleted 61.133.4.7 via 211.99.114.65 Dev eth0
[Root @ nixe0n root]

13. rtacct-route range and Policy Propagation

On a router using OSPF or BGP, the route table may be large. If we need
To classify or compute data packets passing through each route, you need to keep a lot of information. Worse,
If we need to distinguish not only the destination addresses of data packets, but also their source addresses, this task
It is even more complicated and almost cannot be solved.

For this problem, Cisco IOS release 12.0 Quality of Service Solutions
Configuration Guide: Processing ing QoS policy propagation via border
Gateway protocol proposes a solution to migrate a policy from the routing protocol to the forwarding engine.
Basically, Cisco policy propagation via BGP is based on
In this way, the router retains all the rib (Routing)
Information base, routing information library), so that policy routing rules can monitor all routing attributes,
Includes aspath information and group strings.

Linux divides this information into a routing Infomation
Base, rib), and the kernel-layer forwarding information library (forwarding infomation base, FIB ).

This is lucky because there are other solutions that allow more flexible policies.
And richer semantics.

In other words, you can classify routes in the user space according to their attributes. For example
Aspath, group (community); OSPF route label and their range. The Administrator manually adds a path
You also know their attributes. Number of sets divided by this standard (we call them realm)
Therefore, you can perform full classification based on the source address and destination address of the route.

Therefore, each route can be allocated to a realm. Generally, this is the result of Route Monitoring.
But for Static Routing, you can also use the IP route command for manual processing.

In some cases (for example, the routing monitoring process does not understand realm), for convenience, the missing realm can
Supplemented by routing policy rules.

The kernel uses the following algorithm to calculate the source range (realm) and destination range (realm) of each data packet ):

If route has a realm, destination realm of the packet is set to it.
If rule has a source realm, source realm of the packet is set to it.
If destination realm was not get from route and rule has destination
Realm, it is also set.
If at least one of realms is still unknown, kernel finds reversed
Route to the source of the packet.
If source realm is still unknown, get it from reversed route.
If one of realms is still unknown, swap realms of Reversed routes and
Apply Step 2 again.

After this process is completed, we know the source range and target range of the data packet. If some
It will be set to 0 (realm unknown)

　　

The range (realm) is mainly controlled by the TC (Traffic) route type (route
Classifier), we can use the routing class to allocate data packets to different traffic classes.
(Trafffic class) for Data Packet Count and for them to develop scheduling policies.

Compared with TC, it is much easier to use realm to count incoming packets, but this is a very useful
. The kernel collects summary data packet statistics based on realm. In user space, we can
Use the rtacct tool to view the information. For example:

Kuznet @ AMBER :~ $ Rtacct Russia
Realm bytesto pktsto bytesfrom pktsfrom
Russia 20576778 169176 47080168 153805
Kuznet @ AMBER :~ $

The result indicates that the vro receives 153805 data packets from the Russia region and
Russia forwards 169176 packets. Russia ranges from aspath (path Autonomous System) to vro in Russia.
Composed.

15. Reference

T. narten, E. nordmark, W. Simpson. ''Neighbor Discovery for IP
Version 6 (IPv6) '', RFC-2461.
S. Thomson, T. narten. ''ipv6 Stateless Address autoconfigur '',
RFC-2462.
F. Baker. ''requirements for IP version 4 routers '', RFC-1812.
R. T. Braden. ''requirements for Internet hosts -- Communication
Layers', RFC-1122.
''Cisco IOS release 12.0 network protocols command reference, Part 1''
And ''cisco IOS release 12.0 Quality of Service Solutions
Configuration Guide: logging ing policy-based routing '',
Http://www.cisco.com/univercd/cc/td/doc/product/software/ios120.

A. N. Kuznetsov. ''tunnels over IP in Linux-2.2 '',
In: ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz.

A. N. Kuznetsov. ''tc command reference '',
In: ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz.

''Cisco IOS release 12.0 Quality of Service Solutions Configuration
Guide: Permission ing QoS policy propagation via Border Gateway Protocol '',

Http://www.cisco.com/univercd/cc/td/doc/product/software/ios120.

R. droms. ''dynamic Host Configuration Protocol. '', RFC-2131