How to check the network interfaces

• using dmidecode

• Using ip monitor command

• Using lspci and dmesg

uuidgen eth0

speed 10GB no auto neg

echo 'ETHTOOL_OPTS=“speed 10000 duplex full autoneg off”' » /etc/sysconfig/network-scripts/ifcfg-eth1

You need add this parameter to the NM_CONTROLLED=no to the connfiguration file

GUIDE: Oracle VM VirtualBox and Oracle Linux NIC bonding Guide fail_over_mac=1

Attempts to connect to a server with ssh and/or sftp results in time-outs or a delayed response.

When the network load goes high, there are high number of network retransmits observed.

Connection using SSH to a Host Not in DNS/hosts Stalls for Some Time at Connection Initiation (Doc ID 1066024.1) Scp Transfer 'stall' Between Oracle Linux Servers (Doc ID 1997673.1).

• VALIDAR CUANDO NO FUNCIONA EL RSYN O SCP NO PERMITEN PASAR ARCHIVOS MAYORES A 1M

rp_filter - INTEGER

0 - No source validation.

1 - Strict mode as defined in RFC3704 Strict Reverse Path Each incoming packet is tested against the FIB and if the interface is not the best reverse path the packet check will fail. By default failed packets are discarded.

2 - Loose mode as defined in RFC3704 Loose Reverse Path Each incoming packet's source address is also tested against the FIB and if the source address is not reachable via any interface the packet check will fail.

The maximum number of packets that kernel can handle on a NAPI interrupt, it's a Per-CPU variable. For drivers that support LRO or GRO_HW, a hardware aggregated packet is counted as one packet in this context. Default: 64

Generic Receive Offload (GRO) is a widely used SW-based offloading technique to reduce per-packet processing overheads. By reassembling small packets into larger ones, GRO enables applications to process fewer large packets directly, thus reducing the number of packets to be processed. To benefit DPDK-based applications, like Open vSwitch, DPDK also provides own GRO implementation. In DPDK, GRO is implemented as a standalone library. Applications explicitly use the GRO library to reassemble packets.

PURPOSE This troubleshooting note aims to identify the theoretical network throughput between a Protected Database system and a Zero Data Loss Recovery Appliance, or between two Zero Data Loss Recovery Appliances in a replication configuration.

TROUBLESHOOTING STEPS Assumptions This script uses the QPERF utility that is provided as part of an Exadata Engineered System as well as part of the Zero Data Loss Recovery Appliance.

This script may be executed from any Linux server with a BASH shell, and requires trusted SSH to be established between the execution node and the two sets of nodes that are being tested.

The Execution node may be one of the nodes being tested.

The O/S user used for trusted SSH is the O/S user running the script. There is no support for the script to use a different O/S user for logging into the nodes being tested.

Installation

If not already available under /opt/oracle.RecoveryAppliance/client then download the script attached to this MOS Note and copy it to the desired location.