Networking [Документация VAS Experts]

Networking

Does STP transparently pass?

Yes.

Will your solution design allow the following implementation scheme: the server has one 10G network interface. Is it possible to pass traffic through the SSG by organizing two VLANs on this interface (input and output)?

No. No future support is planned.

We connected an internal LAN to try it out, the ping time did not change. Is there supposed to be a delay?

If the equipment complies with our recommendations, the delay on the device does not exceed 30 µs (microseconds) or 0.03 ms (milliseconds). Ping measurements start at 1ms. To measure this kind of delay you need special software and equipment. We use counters in nanoseconds, which are supported by modern network cards.

If you implement mirroring, and traffic with different tags will come to in_dev=dna1:dna2, can the Stingray Service Gateway remove the tag on out_dev=dnaX output?

The SSG sends a response with the original packet tag if no VLAN translation is configured.

What is the Stingray Service Gateway? A router, a NAT, a transparent proxy? Or is it transparent to network devices?

Stingray Service Gateway is a DPI device, analogous to the Cisco SCE. It works as a bridge, without assigning IP addresses, meaning it is not visible in the network. Latency is not more than 30 microseconds (according to tests it is 16 microseconds), so it is almost indistinguishable from direct connection.
See SSG connection diagrams for more details.

How is aggregated traffic sent? Can ports be grouped via LACP?

Yes, you can use LACP, LAGG for traffic aggregation.
See SSG connection diagrams for more details.

At what point should the complex be connected, before termination or after termination on BRAS (in other words, on L2 or L3)?

It depends on the task: if the platform is connected as a DPI, it is implemented after the termination point; if you need BRAS and NAT functionality, - then the Stingray platform performs traffic termination directly.
See SSG connection diagrams for more details.

The WEB server network stack optimization

# The WEB server network stack optimization

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

Why does one BGP session connects and another does not?

Look at tcpdump
And on the client's interface there is mtu 9000
In one session, we see mss 1480
in sync, and in the second session we see mss 8500
This means that one peer's mtu on the interface is standard 1500, the other is overdrawn.
The session that has an mss higher than 1480 (there's also an ip header)
we're setting it up in the MX.

neighbor 95.167.18.57 {
traceoptions {                      
file as12389.log size 1m files 3;
}
 description "-= RT AS12389 Upload =-";
 import [ bogus-reject MM-IN ];
 export REJECT-ALL;
  peer-as 12389;
  tcp-mss 1460;
}
 tcp-mss 1460;

Administration issues