Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| en:dpi:faq:fastdpi:net_points:start [2024/07/29 15:13] – elena.krasnobryzh | en:dpi:faq:fastdpi:net_points:start [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Network Interaction ====== | ||
| - | {{indexmenu_n> | ||
| - | < | ||
| - | < | ||
| - | Yes. | ||
| - | </ | ||
| - | |||
| - | < | ||
| - | No. This is not planned for future support. | ||
| - | </ | ||
| - | |||
| - | < | ||
| - | Yes, this is possible. [[en: | ||
| - | </ | ||
| - | |||
| - | < | ||
| - | The delay on the device, if the hardware meets our recommendations, | ||
| - | </ | ||
| - | |||
| - | < | ||
| - | SSG will send a response with the original packet tag if VLAN [[en: | ||
| - | </ | ||
| - | |||
| - | < | ||
| - | SSG is a DPI device, similar to Cisco SCE. It operates as a bridge, without IP addressing, and is invisible on the network.\\ | ||
| - | The delay when using it is no more than 30 microseconds (based on tests, 16 µs), which is virtually indistinguishable from a direct connection.\\ | ||
| - | [[en: | ||
| - | </ | ||
| - | |||
| - | < | ||
| - | Yes, you can use LACP and LAG for traffic aggregation.\\ | ||
| - | [[en: | ||
| - | </ | ||
| - | |||
| - | < | ||
| - | It depends on the task: if the platform connects as a DPI, then after the termination point; if BRAS, NAT functionality is required, then the SSG platform performs traffic termination directly.\\ | ||
| - | [[en: | ||
| - | </ | ||
| - | |||
| - | < | ||
| - | Apply the following settings: | ||
| - | <code bash> | ||
| - | net.core.netdev_max_backlog=10000 | ||
| - | net.core.somaxconn=262144 | ||
| - | net.ipv4.tcp_syncookies=1 | ||
| - | net.ipv4.tcp_max_syn_backlog = 262144 | ||
| - | net.ipv4.tcp_max_tw_buckets = 720000 | ||
| - | net.ipv4.tcp_tw_recycle = 1 | ||
| - | net.ipv4.tcp_timestamps = 1 | ||
| - | net.ipv4.tcp_tw_reuse = 1 | ||
| - | net.ipv4.tcp_fin_timeout = 30 | ||
| - | net.ipv4.tcp_keepalive_time = 1800 | ||
| - | net.ipv4.tcp_keepalive_probes = 7 | ||
| - | net.ipv4.tcp_keepalive_intvl = 30 | ||
| - | net.core.wmem_max = 33554432 | ||
| - | net.core.rmem_max = 33554432 | ||
| - | net.core.rmem_default = 8388608 | ||
| - | net.core.wmem_default = 4194394 | ||
| - | net.ipv4.tcp_rmem = 4096 8388608 16777216 | ||
| - | net.ipv4.tcp_wmem = 4096 4194394 16777216 | ||
| - | </ | ||
| - | </ | ||
| - | |||
| - | < | ||
| - | Example: | ||
| - | * Check '' | ||
| - | * On one session, mss = 1480 during sync, while on the other, mss = 8500.\\ This indicates that one peer has a standard mtu of 1500, while the other has an increased mtu. \\ | ||
| - | * On sessions where mss is higher than 1480 and there is an IP header, set the settings in MX: | ||
| - | <code bash> | ||
| - | traceoptions { | ||
| - | file as12389.log size 1m files 3; | ||
| - | } | ||
| - | | ||
| - | | ||
| - | | ||
| - | peer-as 12389; | ||
| - | tcp-mss 1460; | ||
| - | } | ||
| - | | ||
| - | |||
| - | [[en: | ||
| - | </ | ||
| - | </ | ||