In our LAN we have several keepalived clasters (used different virtual_router_id of course) - all operating on multicast.
The issue is that before installing and running keepalived on particular host I cannot sniff vrrp traffic by tcpdump:
when I started keepalived - I see ALL vrrp multicast of this LAN
when I stopped keepalived - tcpdump shows nothing in vrrp
Already checked firewalld, iptabels and sysctl net.ipv4.ip_nonlocal_bind - everything is OK.
OS - RHEL 8.0
The need to see vrrp traffic before running keepalived is because we want to generate unique virtual_router_id before installing and running keepalived by checking what ids are already taken.
Related
I am getting the connection time out when running the command in bootstrap.
Any configuration suggestions on networking part if I am missing
It’s says kubernetes api calling time out
This is obviously very hard to debug without having access to your environment. Some tips to debug the OKD installation:
Before starting the installation, make sure your environment meets all the prerequisites. Often, the problem lies with a faulty DNS / DHCP / networking setup. Potentially deploy a separate VM into the network to check if everything works as expected.
The bootstrap node and the Master Nodes are deployed with the SSH key you specify, so in vCenter, get the IP of the machines that are already deployed and use SSH to connect to them. Once on the machine, use sudo crictl ps and sudo crictl logs <container-id> to review the logs for the running containers, focussing on the components:
kube-apiserver
etcd
machine-controller
In your case, the API is not coming up, so reviewing the logs of the above components will likely show the root cause.
It appears my GCP Compute Engine service/instance/whatever-you-call-it is refusing connections from my machine at times. I was just trying to set up an SFTP connection through a desktop app and probably failed a password too many times.
But I don't have Fail2Ban installed, and I don't see any Firewall Rules in the GCP interface blocking my IP. During what I perceive as the block, I can't even ping the machine. As soon as I switch to my cellphone's hotspot - I can ping it again. See screenshot below - I switched to the hotspot mid-way in that ping.
Does anyone know where I can look to control this setting and/or see what's being done here?
lastb output reflects regular attempts to get into my machine so I don't understand why something is being so harsh on me while this level of spam is flowing to the Linux level at least.
Found the answer - it's sshguard running on linux.
in /var/log/auth.log
Apr 19 01:43:05 x-x sshguard[696]: Blocking "-.-.-.-/32" for 122880 secs (3 attacks in 1 secs, after 11 abuses over 3268716 secs.)
I have a GCE instance that uses older mysql connection type and in order to connect to a Google Cloud SQL instance, I open an SSH connection through the browser on the GCE instance and run the following:
> cd /
> ./cloud_sql_proxy -dir=/cloudsql -instances=my-gce-instance-name:us-east1:my-sql-instance-name &./cloud_sql_proxy -dir=/cloudsql -
And then it is open for connections. The problem is, when I close the browser window (or even sign into Google with a different user), the connection is lost. Is there any way to persistently run this Unix socket with Google Cloud Engine?
Generally, you can run a command in the background by appending a & to the end of the command. This will start a background process for the proxy. You can stop the proxy with killall cloud_sql_proxy.
Another solution would be to run the proxy as a service. How to do this wildly varies by distro and version. Ubuntu 16 is typically bundled with systemd.
Question: How do I get CDK to work on the corporate laptop using virtualbox without running into the 'could not find mathcing ip for mac' issue?
environment: Windows7, CDK 3.2.0, Virtualbox 5.0.x/5.1.x various versions tried. Key callout, corporate machine has VPN software (cisco anyconnect) while home pc does not, home pc works fine. Issue happens regardless if using VPN or not. Virtualbox (all versions) proven to work using vagrant.
Key finding:
minishift ssh -> functions, doing an ifconfig returns eth0 with a 10.0.*
network, instead of the expected 192.168.99.* network segments configured
for virtualbox network host adapters. Explicitly using minishift config set
host-only-cidr 192.168.99.1/24 with matching virtualbox host adapters
doesn't change outcome
Details:
c:\devrh\cdk\bin>minishift version
minishift v1.7.0+204ce19 CDK v3.2.0-1
c:\devrh\cdk\bin>minishift start --vm-driver=virtualbox -- Starting local
OpenShift cluster using 'virtualbox'
hypervisor ... -- Starting Minishift VM ............................ FAIL
E1108 10:27:05.991687 3128 start.go:356] Error starting the VM: Error
configuring authorization on host: Could not find matching IP for MAC
address 0800279fa156. Retrying. Error starting
the VM: Error configuring authorization on host: Could not find matching IP
for MAC address 0800279fa156
corporate workstation has the issue, home PC does not.
Minishift delete and restart, same issue (different MAC address, but same issue).
Virtualbox remove all host adapters, minishift delete, restart (which auto-creates new host adapters), same issue.
Minishift --profile approach, same issue.
Uninstalled virtualbox, installed the version from the RHDevSuite installer with the CDK from the installer, all steps tested with that combination as well, same issue.
Additional notes, Virtualbox is working fine with vagrant (static IP’s in vagrant files), virtualbox/vagrant combo works on both corporate and home machine without issues.
I started several GCE instances and was unable to connect to even 1 of them using ssh. For debian wheezy instances the ssh server appeared to be not running ("nc IP 22" times out). Even though I enabled ICMP in default network, debian instances did not respond to ping.
CentOS instances responds to ping and I was able to get an ssh banner using nc intermittently. But connecting using ssh command repeatedly timed out.
I suspected a network outage but "gcutil listzones" showed that all the zones I was using, were UP (us-cental)
From https://groups.google.com/d/msg/gce-operations/coBWszq91j4/dRPq5_gJ3t4J:
We're investigating an issue with network connectivity to new Google Compute Engine instances. Currently-running instances are not affected. We will provide more information shortly.