Ip packing mikrotik что это

Manual:IP/Packing

Contents

Overview

IP Packing provides packet packaging service on network links. It allows simple packet aggregation into larger packets and compression of contents of packets.

Requirements

Packet packing is part of system package and has to have discovery protocol enabled on interface.

Configuration

It required to have configuration in two places, both routers should be set up symmetrically:

  • ip packing — to enable packet aggregation and/or compression on interface
  • /ip neighbor discovery— to enable discovery protocol on the interface

Packing configuration

Property Description
aggregated-size (20 .. 16384 default:1500) size of aggregated packet that packing will try to achieve before sending packet over network
disabled (yes|no) state of packing rule, if value is yes it will be ignored and will not be part of active configuration
interface (interface name) packing will try to aggregate and/or compress packets from this interface
packing (simple|compress-all|compress-headers|none) action it should perform when packet is leaving interface packing rule is configured on.
  • simple — do just aggregation of packets
  • compress-all — do aggregation and attempt to compress headers and payload of packet
  • compress-headers — do aggregation and attempt to compress headers and leaving payload of packet as is
  • none — send packets as is
unpacking (simple|compress-all|compress-headers|none) action it should perform when packet is received on interface packing rule is configured on.
  • simple — unpack received packets from aggregated packet received from interface
  • compress-all — unpack aggregated packet and uncompress headers and payload of packet
  • compress-headers — unpack aggregated packet and decompress headers of packet
  • none — do nothing with received packet

Warning: Router should be seen as neighbour of router over interface you want to enable packing on. If in neighbour list there are no entry indicating packing, packing is not working!

Note: Packing may increase latency on the link it is configured on!

Example

Router-A and Router-B are connected with cable with interface ether1 on Router-A and ether3 on Router-B. This example will aggregate packets coming from Router-A, but will leave packets from Router-B intact On Router-A:

  • make sure discovery is enabled
  • add packing rule for the interface
  • make sure discovery is enabled
  • add packing rule for the interface

Источник

IP packing

IP Packing provides packet packaging service on network links. It allows simple packet aggregation into larger packets and compression of contents of packets.

Packet packing is part of the system package and has to have discovery protocol enabled on an interface.

Configuration

It required to have a configuration in two places, both routers should be set up symmetrically:

  • ip packing — to enable packet aggregation and/or compression on an interface
  • /ip neighbor discovery— to enable discovery protocol on the interface

Packing configuration

Property Description
aggregated-size (20 .. 16384 default:1500) size of an aggregated packet that packing will try to achieve before sending a packet over the network
disabled (yes|no) state of packing rule, if a value is yes it will be ignored and will not be part of the active configuration
interface (interface name) packing will try to aggregate and/or compress packets from this interface
packing (simple|compress-all|compress-headers|none) the action it should perform when a packet is leaving the interface packing rule is configured:
  • simple — do just aggregate packets
  • compress-all — do aggregation and attempt to compress headers and payload of a packet
  • compress-headers — do aggregation and attempt to compress headers and leave payload of a packet as is
  • none — send packets as is
unpacking (simple|compress-all|compress-headers|none) the action should perform when a packet is received on the interface packing rule is configured on:
  • simple — unpack received packets from aggregated packets received from the interface
  • compress-all — unpack aggregated packet and uncompress headers and payload of a packet
  • compress-headers — unpack aggregated packets and decompress headers of a packet
  • none — do nothing with a received packet

The router should be seen as a neighbor of the router over the interface you want to enable packing on. If in the neighbor list there is no entry indicating packing, packing is not working!

Packing may increase latency on the link it is configured on.

Example

Router-A and Router-B are connected with cable with interface ether1 on Router-A and ether3 on Router-B. This example will aggregate packets coming from Router-A, but will leave packets from Router-B intact On Router-A:

Источник

Mikrotik IP Packing

Mikrotik has, since at least version 2.8, a protocol built into ROS that will allow you to aggregate packets as well as do come compression. I had installed version 5 on a test machine and was poking around when I happened across this.

From what I understand this may or may not work across all tunnel types, so buyer beware. This is supposed to work properly with standard ethernet interfaces.

In effect, what you do is specify an aggregate size. The router will then collect packets until it has enough to fill that aggregate size before it will send. I assume that it will send after X amount of time if it hasn’t collected enough packets, though I’m not sure what that time is.

Packing is what you do to packets as they leave and unpacking is what is done to packets as they arrive.

Packing options:
Simple : Just do packet aggregation
Compress-all : Aggregate packets, compress payload and header
Compress-headers : Aggregate packets, compress header only
None : Send packets unchanged

As an interesting side note, ip neighbors is used for communication of this protocol and must be enabled on all participating interfaces. The wiki article also cautions that this will cause latency, which I hope you could have gleaned from the aggregation explination 😉

Источник

Ip packing mikrotik что это

Thu May 05, 2011 7:14 pm

Anyone have any real world compression ratios for ip packing? I’m trying to compress data on a PTP T1 link and I’m barely getting any increase in speed. Here’s my setup —

Computer — Switch — RB433AH — Cisco 1720 — T1 — Cisco 1720 — RB433AH — Computer

I’m running ROS 5.1 and I’m transferring a 15MB excel spreadsheet at 160kB/s w/o packing turned on and about 170kB/s with compress-all enabled. I can RAR the spreadsheet to 2.6MB so it’s a pretty compressible file and I understand I’m not going to get that great of a compression ratio across the line but I was hoping to get more than that.

Anyone have any thoughts? I’m thinking about bringing the remote unit back to test it directly connected but it’s a two hour drive in each direction to retrieve the hardware.

Re: IP Packing

Thu May 05, 2011 8:36 pm

Re: IP Packing

Thu May 05, 2011 10:41 pm

Anyone have any real world compression ratios for ip packing? I’m trying to compress data on a PTP T1 link and I’m barely getting any increase in speed. Here’s my setup —

Читайте также:  Ресивер tiger t2 iptv lan инструкция

Computer — Switch — RB433AH — Cisco 1720 — T1 — Cisco 1720 — RB433AH — Computer

I’m running ROS 5.1 and I’m transferring a 15MB excel spreadsheet at 160kB/s w/o packing turned on and about 170kB/s with compress-all enabled. I can RAR the spreadsheet to 2.6MB so it’s a pretty compressible file and I understand I’m not going to get that great of a compression ratio across the line but I was hoping to get more than that.

Anyone have any thoughts? I’m thinking about bringing the remote unit back to test it directly connected but it’s a two hour drive in each direction to retrieve the hardware.

This sounds to me like a fallacy test.

My understanding of IP Packets is that it packs multiple ip paackts into a larger one to transmit them in one frame on the lower level. This basically targets, if i understand correctly, wireless lan.

Your test is flawed in this context by two scenarios. One, you have no wireless in the game where the time slice is critical.

But MORE relevant: you transfer a file. These are BIG ip packets on the transfer side where basically packing is not possible becaust you dont have packets small enough to pack them.

Packing would pack the answers and small system packets, but not the data apackets which will be on the maximum transfer size anyway.

Источник

Packet Flow in RouterOS

More advanced firewall setups, or complicated tasks, such as traffic prioritization, routing policies, where it is necessary to utilize more than one RouterOS facility, require knowledge: How do these facilities work together? What happens when and why?

RouterOS packet flow diagram and flow examples will try to answer these questions.

It would be very complicated to represent what is going on with the packet in one diagram, therefore a packet flow diagram is divided into three parts:

  • overall diagram;
  • detailed bridging, routing, and MPLS flow diagram;
  • a diagram that shows what facilities and in what order are included in prerouting, input, forward, output, and postrouting.

Overall Packetflow Diagram

Let’s look at the overall diagram. It looks complicated at first, but after we go through the diagram with examples it will become much clearer.

There are 4 boxes in the center of the diagram: Bridging, Routing, Mpls decisions, and local router processes. So for example, if the packet needs to be routed over the router, a packet will flow as illustrated in the image below. Without looking deeper into each facility, the packet enters the in-interface, the router determines that it is IP traffic and needs to be routed, the packet goes through all routing processes and exits the out-interface.

Let’s take a look at another example that will illustrate what happens if the packet’s destination is a router. For example, the in-interface receives ICMP (ping) packet, its destination is the router itself, so the packet will go for local-in processing. After the packet is processed ICMP (ping) reply is generated inside the router (local-out processing) and will be sent out over the out-interface.

A simple explanation of each box before we go further with examples:

  • physical in-interface — the starting point of the packet received by the router;
  • logical in-interface — the starting point of the decapsulated packet (from tunnels, IPsec, etc);
  • local in — the last point of a packet destined to router itself;
  • interface HTB (Hierarchical Token Bucket) — interface queue;
  • physical out-interface — last point of the packet before it is actually sent out;
  • logical out-interface — last point of the packet before encapsulation (to tunnels, IPsec, etc);
  • local out — the starting point of a packet generated by the router;

Now it is time to take a deeper look at what is happening inside bridging, MPLS, and routing flows.

A simple explanation of each box before we go further with examples:

  • routing decision — go through routes in the routing table to find a match for the destination IP address of the packet. When a match is found — the packet will be processed further, in case of no match — the packet will be discarded.;
  • mpls decision — what to do with the packet based on MPLS forwarding tables;
  • bridging decision — bridge goes through the MAC address table to find a match for the destination MAC address of the packet. When a match is found — the packet will be processed further, in case of no match — multiple copies of the packet will be created and packets will be flooded (sent out via all bridge ports). A single packet copy will also reach a bridge input chain as the bridge interface itself is one of the many destinations. When using vlan-filtering=yes , packets that are not allowed due to the «/interface bridge vlan» table, will be dropped at this stage.
  • use-ip-firewall — whether a ‘use-ip-firewall’ option is enabled in bridge settings;
  • ipsec-policy — whether a packet matches any of configured IPsec policies;

Chains

RouterOS consist of a few default chains. These chains allow you to filter packets at various points:

  • The PREROUTING chain: Rules in this chain apply to packets as they just arrive on the network interface. This chain is present in the nat, mangle and raw tables.
  • The INPUT chain: Rules in this chain apply to packets just before they’re given to a local process. This chain is present in the mangle and filter tables.
  • The OUTPUT chain: The rules here apply to packets just after they’ve been produced by a process. This chain is present in the raw, mangle, nat, and filter tables.
  • The FORWARD chain: The rules here apply to any packets that are routed through the current host. This chain is only present in the mangle and filter tables.
  • The POSTROUTING chain: The rules in this chain apply to packets as they just leave the network interface. This chain is present in the nat and mangle tables.

Each of the prerouting, input, forward, output, and postrouting blocks contains even more facilities, which are illustrated in the third part of the packet flow diagram:

A simple explanation of each box before we go further with examples:

  • Hotspot-in — allows to capture traffic that otherwise would be discarded by connection tracking — this way our Hotspot feature is able to provide connectivity even if networks settings are an incomplete mess ;
  • RAW Prerouting — RAW table prerouting chain;
  • Connection tracking — packet is processed by connection tracking;
  • Mangle Prerouting — Mangle prerouting chain;
  • Mangle Input — Mangle input chain;
  • Filter Input — Firewall filter input chain;
  • HTB Global — Queue tree;
  • Simple Queues — ;
  • TTL — indicates an exact place where the Time To Live (TTL) of the routed packet is reduced by 1 if TTL becomes 0, a packet will be discarded;
  • Mangle Forward — Mangle forward chain;
  • Filter Forward — Filter forward chain;
  • Accounting — Authentication, Authorization, and Accounting feature processing;
  • RAW Output — RAW table output chain;
  • Mangle Output — Mangle output chain;
  • Filter Output — Firewall filter output chain;
  • Routing Adjustment — this is a workaround that allows to set up policy routing in mangle chain output (routing-mark) ;
  • Mangle Postrouting — Mangle postrouting chain;
  • Src Nat — Network Address Translation srcnat chain;
  • Dst Nat — Network Address Translation dstnat chain;
  • Hotspot-out — undo all that was done by hotspot-in for the packets that are going back to the client;
Читайте также:  1 мбит трафика это сколько

Flow of Routed Packet

Forward

Now, let’s take our first example where the packet gets routed over the router and look deeper through what facilities packet goes:

We already learned that packet goes into the in-interface, the router determines that it is an IP packet and needs to be routed, and here starts the complicated process:

  1. The packet enters prerouting processing:
    1. check if there is a hotspot and modify the packet for hotspot use
    2. process packet through RAW prerouting chain;
    3. send the packet through connection tracking;
    4. process packet through Mangle prerouting chain;
    5. process packet through NATs dst-nat chain;
  2. Run packet through routing table to make routing decision;
  3. The packet enters the forward process;
    1. check TTL value;
    2. process packet through Mangle forward chain;
    3. process packet through the Filter forward chain;
    4. send the packet to accounting processes;
  4. A packet enters postrouting process;
    1. process packet through Mangle postrouting chain;
    2. process packet through NATs src-nat chain;
    3. if there is a hotspot undo any modifications made in hotspot-in;
    4. process packet through queue tree (HTB Global);
    5. process packet through simple queues;
  5. Check if there is IPsec and then process through IPsec policies;

Input

We already learned that packet goes into the in-interface, the router determines that it is an IP packet and needs to be routed, and here starts the complicated process:

  1. A very similar process happens when a packet’s destination is a router (routing input): Packet enters prerouting processing:
    1. — check if there is a hotspot and modify the packet for hotspot use;
    2. — process packet through RAW prerouting chain;
    3. — send a packet through connection tracking;
    4. — process packet through Mangle prerouting chain;
    5. — process packet through NATs dst-nat chain;

Run packet through routing table to make routing decision;

  • A Packet enters the input process;
    1. — process packet through Mangle input chain;
    2. — p rocess packet through Filter input chain;
    3. — process packet through queue tree (HTB Global);
    4. — process packet through simple queues;
  • Check if there is IPsec and then process through IPsec policies.
  • Output

    Or when a packet is originated from the router (routing output):

    1. The packet is originated from the router itself
      1. the packet goes through the routing table to make a routing decision
  • A packet enters the output process
    1. process packet through the Bridge decision;
    2. send the packet through connection tracking;
    3. process packet through the Mangle output chain;
    4. process packet through the Filter output chain;
    5. send the packet to routing adjustment ( policy routing)
  • The packet enters postrouting process;
    1. — process packet through Mangle postrouting chain;
    2. — process packet through NATs src-nat chain;
    3. — if there is a hotspot undo any modifications made in hotspot-in;
    4. — process packet through queue tree (HTB Global);
    5. — process packet through simple queues;
  • Check if there is IPsec and then process through IPsec policies;
  • Flow of Bridged Packet

    Below is discussed a general bridging process in RouterOS. Most of the packets will always follow the same processing path, but in certain configurations (e.g. with enabled VLAN filtering, horizon, STP, DHCP, or IGMP snooping) some packets can be treated differently. Please visit the bridging manual for more specific information.

    Bridge Forward

    Bridge forward is a process that takes place when a packet is forwarded from one bridge port to another, essentially connecting multiple devices on the same network. After receiving a packet on the in-interface, the device determines that the in-interface is a bridge port, so it gets passed through the bridging process:

    1. A packet goes through the bridge NAT dst-nat chain, where MAC destination and priority can be changed, apart from that, a packet can be simply accepted, dropped, or marked;
    2. Checks whether the use-ip-firewall option is enabled in the bridge settings;
    3. Run packet through the bridge host table to make a forwarding decision. A packet that ends up being flooded (e.g. broadcast, multicast, unknown unicast traffic), gets multiplied per bridge port and then processed further in the bridge forward chain. When using vlan-filtering=yes , packets that are not allowed due to the «/interface bridge vlan» table, will be dropped at this stage.
    4. A packet goes through the bridge filter forward chain, where priority can be changed or the packet can be simply accepted, dropped, or marked;
    5. Checks whether the use-ip-firewall option is enabled in the bridge settings;
    6. A packet goes through the bridge NAT src-nat chain, where MAC source and priority can be changed, apart from that, a packet can be simply accepted, dropped, or marked;
    7. Checks whether the use-ip-firewall option is enabled in the bridge settings;

    When bridge vlan-filtering is enabled, received untagged packets might get encapsulated into the VLAN header before the «DST-NAT» block, which means these packets can be filtered using the mac-protocol=vlan and vlan-encap settings. Encapsulation can happen if frame-types is set to admit-all or admit-only-untagged-and-priority-tagged .

    Tagged packets might get decapsulated on the «BRIDGING DECISION» block, which means these packets will no longer match the mac-protocol=vlan and vlan-encap settings. Decapsulation can happen if the packet’s VLAN ID matches the port’s untagged VLAN membership.

    Bridge Input

    Bridge input is a process that takes place when a packet is destined for the bridge interface. Most commonly this happens when you need to reach some services that are running on the bridge interface (e.g. a DHCP server) or you need to route traffic to other networks. The very first steps are similar to the bridge forward process — after receiving a packet on the in-interface, the device determines that the in-interface is a bridge port, so it gets passed through the bridging process:

    1. A packet goes through the bridge NAT dst-nat chain, where MAC destination and priority can be changed, apart from that, a packet can be simply accepted, dropped, or marked;
    2. Checks whether the use-ip-firewall option is enabled in the bridge settings;
    3. Run packet through the bridge host table to make a forwarding decision. A packet where the destination MAC address matches the bridge MAC address will be passed to the bridge input chain. A packet that ends up being flooded (e.g. broadcast, multicast, unknown unicast traffic), also reaches the bridge input chain as the bridge interface itself is one of the many destinations;
    4. A packet goes through the bridge filter input chain, where priority can be changed or the packet can be simply accepted, dropped, or marked;

    Bridge Output

    Bridge output is a process that takes place when a packet should exit the device through one or multiple bridge ports. Most commonly this happens when a bridge interface itself tries to reach a device connected to a certain bridge port (e.g. when a DHCP server running on a bridge interface is responding to a DHCP client). After a packet is processed on other higher-level RouterOS processes and the device finally determines that the output interface is a bridge, the packet gets passed through the bridging process:

    1. Run packet through the bridge host table to make a forwarding decision. A packet that ends up being flooded (e.g. broadcast, multicast, unknown unicast traffic), gets multiplied per bridge port and then processed further in the bridge output chain.
    2. A packet goes through the bridge filter output chain, where priority can be changed or the packet can be simply accepted, dropped, or marked;
    3. A packet goes through the bridge NAT src-nat chain, where MAC source and priority can be changed, apart from that, a packet can be simply accepted, dropped, or marked;
    4. Checks whether the use-ip-firewall option is enabled in the bridge settings;
    Читайте также:  Что делает впн мастер

    Forward With Firewall Enabled

    In certain network configurations, you might need to enable additional processing on routing chains for bridged traffic, for example, to use simple queues or an IP firewall. This can be done when the use-ip-firewall is enabled under the bridge settings. Note that additional processing will consume more CPU resources to handle these packets. All the steps were already discussed in previous points, below is a recap:

    1. A packet goes through the bridge NAT dst-nat chain;
    2. With the use-ip-firewall option enabled, the packet will be further processed in the prerouting chain;
    3. A packet enters prerouting processing;
    4. Run packet through the bridge host table to make forwarding decision;
    5. A packet goes through the bridge filter forward chain;
    6. With the use-ip-firewall option enabled, the packet will be further processed in the routing forward chain;
    7. A packet enters routing forward processing;
    8. A packet goes through the bridge NAT src-nat chain;
    9. With the use-ip-firewall option enabled, the packet will be further processed in the postrouting chain;
    10. A packet enters prerouting processing;

    Flow of Hardware Offloaded Packet

    On the previous topic, we solely discussed a software bridging that requires the main CPU processing to forward packets through the correct bridge port. Most of the MikroTik devices are equipped with dedicated switching hardware, the so-called switch chip or switch ASIC. This allows us to offload some of the bridging functions, like packet forwarding between bridge ports or packet filtering, to this specialized hardware chip without consuming any CPU resources. In RouterOS, we have named this function Bridge Hardware (HW) Offloading. Different MikroTik devices might have different switch chips and each chip has a different set of features available, so make sure to visit this article to get more details — Bridge Hardware Offloading.

    Interface HTB will not work correctly when the out-interface is hardware offloaded and the bridge Fast Path is not active.

    • switching decision — widely depends on the switch model. This block controls all the switching-related tasks, like host learning, packet forwarding, filtering, rate-limiting, VLAN tagging/untagging, mirroring, etc. Certain switch configurations can alter the packet flow;
    • switch-cpu port — a special purpose switch port for communication between the main CPU and other switch ports. Note that the switch-cpu port does not show up anywhere on RouterOS except for the switch menu, none of the software-related configurations (e.g. interface-list) can be applied to this port. Packets that reach the CPU are automatically associated with the physical in-interface.

    The hardware offloading, however, does not restrict a device to only hardware limited features, rather it is possible to take advantage of the hardware and software processing at the same time. This does require a profound understanding of how packets travel through the switch chip and when exactly they are passed to the main CPU.

    Switch Forward

    We will further discuss a packet flow when bridge hardware offloading is enabled and a packet is forwarded between two switched ports on a single switch chip. This is the most common and also the simplest example:

    1. The switch checks whether the in-interface is a hardware offloaded interface;
    2. Run a packet through the switch host table to make a forwarding decision. If the switch finds a match for the destination MAC address, the packet is sent out through the physical interface. A packet that ends up being flooded (e.g. broadcast, multicast, unknown unicast traffic) gets multiplied and sent out to every hardware offloaded switch port.

    Switch to CPU Input

    This process takes place when a packet is received on a physical interface and it is destined to switch-cpu port for further software processing. There are two paths to the switch-cpu. One where hardware offloading and switching is not even used (e.g. a standalone interface for routing or a bridged interface but with deliberately disabled HW offloading), so the packet is simply passed further for software processing. Another path is taken when hardware offloading is active on the in-interface. This will cause the packet to pass through the switching decision and there are various reasons why the switch might forward the packet to the switch-cpu port:

    • a packet’s destination MAC address match with a local MAC address, e.g. when a packet is destined to a local bridge interface;
    • a packet might get flooded to all switch ports including the switch-cpu port, e.g. when broadcast, multicast, or unknown unicast traffic is received;
    • a switch might have learned that some hosts can only be reached through the CPU (switch-cpu port learning is discussed in the next section), e.g. when a bridge contains HW and non-HW offloaded interfaces, such as wireless, EoIP, and even Ethernet interfaces;
    • a packet is intentionally copied to the switch-cpu, e.g. for a packet inspection;
    • a packet is triggered by the switch configuration and should be processed in software, e.g. a DHCP or IGMP snooping.

    See the packet walkthrough when an in-interface is hardware offloaded:

    1. The switch checks whether the in-interface is a hardware offloaded interface;
    2. Run a packet through the switch host table to make a forwarding decision. In case any of the above-mentioned points are true, the packet gets forwarded to the switch-cpu port.
    3. The packet exits through the switch-cpu port and it will be further processed by the RouterOS packet flow.

    Any received packet that was flooded by the switch chip will not get flooded again by the software bridge to the same HW offloaded switch group. This prevents the formation of duplicate packets.

    CPU Output to Switch

    This process takes place when a packet exits the RouterOS software processing and is received on the switch-cpu port. Again, there are two paths the packet can take. One where hardware offloading and switching are not even used (e.g. a standalone interface for routing or a bridged interface but with deliberately disabled HW offloading), so the packet is simply sent out through the physical out-interface. Another path is taken when hardware offloading is active on the out-interface. This will cause the packet to pass through the switching decision. Just like any other switch port, the switch will learn the source MAC addresses from packets that are received on the switch-cpu port. This does come in handy when a bridge contains HW and non-HW offloaded interfaces, so the switch can learn which frames should be forwarded to the CPU. See the packet walkthrough when an out-interface is hardware offloaded:

    1. A packet that exits the RouterOS software processing is received on the switch-cpu port;
    2. The switch checks whether the out-interface is a hardware offloaded interface;
    3. Run a packet through the switch host table to make a forwarding decision. If the switch finds a match for the destination MAC address, the packet is sent out through the physical interface. A packet that ends up being flooded (e.g. broadcast, multicast, unknown unicast traffic) gets multiplied and sent out to every hardware offloaded switch port.

    A software bridge that sends a flooded packet through HW offloaded interfaces, will only send a single packet copy per HW offloaded switch group rather than per HW offloaded interface. The actual flooding will be done by the switch chip, this prevents the formation of duplicate packets.

    Источник

    Ip packing mikrotik что это

    Manual:IP/Packing

    Contents

    Overview

    IP Packing provides packet packaging service on network links. It allows simple packet aggregation into larger packets and compression of contents of packets.

    Requirements

    Packet packing is part of system package and has to have discovery protocol enabled on interface.

    Configuration

    It required to have configuration in two places, both routers should be set up symmetrically:

    • ip packing — to enable packet aggregation and/or compression on interface
    • /ip neighbor discovery— to enable discovery protocol on the interface

    Packing configuration

    Property Description
    aggregated-size (20 .. 16384 default:1500) size of aggregated packet that packing will try to achieve before sending packet over network
    disabled (yes|no) state of packing rule, if value is yes it will be ignored and will not be part of active configuration
    interface (interface name) packing will try to aggregate and/or compress packets from this interface
    packing (simple|compress-all|compress-headers|none) action it should perform when packet is leaving interface packing rule is configured on.
    • simple — do just aggregation of packets
    • compress-all — do aggregation and attempt to compress headers and payload of packet
    • compress-headers — do aggregation and attempt to compress headers and leaving payload of packet as is
    • none — send packets as is
    unpacking (simple|compress-all|compress-headers|none) action it should perform when packet is received on interface packing rule is configured on.
    • simple — unpack received packets from aggregated packet received from interface
    • compress-all — unpack aggregated packet and uncompress headers and payload of packet
    • compress-headers — unpack aggregated packet and decompress headers of packet
    • none — do nothing with received packet
    Читайте также:  Xiaomi yi 1080p car wifi dvr обзор

    Warning: Router should be seen as neighbour of router over interface you want to enable packing on. If in neighbour list there are no entry indicating packing, packing is not working!

    Note: Packing may increase latency on the link it is configured on!

    Example

    Router-A and Router-B are connected with cable with interface ether1 on Router-A and ether3 on Router-B. This example will aggregate packets coming from Router-A, but will leave packets from Router-B intact On Router-A:

    • make sure discovery is enabled
    • add packing rule for the interface
    • make sure discovery is enabled
    • add packing rule for the interface

    Источник

    IP packing

    IP Packing provides packet packaging service on network links. It allows simple packet aggregation into larger packets and compression of contents of packets.

    Packet packing is part of the system package and has to have discovery protocol enabled on an interface.

    Configuration

    It required to have a configuration in two places, both routers should be set up symmetrically:

    • ip packing — to enable packet aggregation and/or compression on an interface
    • /ip neighbor discovery— to enable discovery protocol on the interface

    Packing configuration

    Property Description
    aggregated-size (20 .. 16384 default:1500) size of an aggregated packet that packing will try to achieve before sending a packet over the network
    disabled (yes|no) state of packing rule, if a value is yes it will be ignored and will not be part of the active configuration
    interface (interface name) packing will try to aggregate and/or compress packets from this interface
    packing (simple|compress-all|compress-headers|none) the action it should perform when a packet is leaving the interface packing rule is configured:
    • simple — do just aggregate packets
    • compress-all — do aggregation and attempt to compress headers and payload of a packet
    • compress-headers — do aggregation and attempt to compress headers and leave payload of a packet as is
    • none — send packets as is
    unpacking (simple|compress-all|compress-headers|none) the action should perform when a packet is received on the interface packing rule is configured on:
    • simple — unpack received packets from aggregated packets received from the interface
    • compress-all — unpack aggregated packet and uncompress headers and payload of a packet
    • compress-headers — unpack aggregated packets and decompress headers of a packet
    • none — do nothing with a received packet
    Читайте также:  Почему не раздается вайфай с ноутбука

    The router should be seen as a neighbor of the router over the interface you want to enable packing on. If in the neighbor list there is no entry indicating packing, packing is not working!

    Packing may increase latency on the link it is configured on.

    Example

    Router-A and Router-B are connected with cable with interface ether1 on Router-A and ether3 on Router-B. This example will aggregate packets coming from Router-A, but will leave packets from Router-B intact On Router-A:

    Источник