shukko·Configure two network cards in a different subnet on RHEL 6, RHEL 7, CentOS 6 and CentOS 7 için yorumlar kapalı
The goal is to become symmetric routing:
Each interface on the server should have it’s own default gateway, which allows that interface to reply itself to incoming packets from other networks.
A normal routing table can only have one default gateway. This is quite logical since it’s the place where to send packets that do not match anything else in the rest of the table. To be able to have two default gateways, one for each interface, you need to setup policy based routing.
Policy based routing allows you to have multiple routing tables. Which table is used, depends on a set of rules.
To setup policy based routing for our example case, we will use two policy based tables. While it is possible to give a nice name to the tables (in /etc/iproute2/rt_tables), it’s not really when you only plan to have a few. Without a name, the tables are automatically created when you’re adding something to them.
Let’s start with adding a route for the network itself (link) and one for the default gateway for each interface. ens192 (192.168.0.10) will use table 1, ens224 (192.168.1.10) will use table 2.
[jensd@server ~]$ sudo ip route add 192.168.0.0/24 dev ens192 tab 1
[jensd@server ~]$ sudo ip route add 192.168.1.0/24 dev ens224 tab 2
[jensd@server ~]$ sudo ip route add default via 192.168.0.1 dev ens192 tab 1
[jensd@server ~]$ sudo ip route add default via 192.168.1.1 dev ens224 tab 2
To define when table 1 or 2 will be used, we’ll add a rule, based on the source of the packet to the policy and refresh the policy based routing:
[jensd@server ~]$ sudo ip rule add from 192.168.0.10/32 tab 1 priority 100
[jensd@server ~]$ sudo ip rule add from 192.168.1.10/32 tab 2 priority 200
[jensd@server ~]$ sudo ip route flush cache
To check if we did everything correctly, let’s list the tables and the rules:
[jensd@server ~]$ ip route show tab 1
default via 192.168.0.1 dev ens192
192.168.0.0/24 dev ens192 scope link
[jensd@server ~]$ ip route show tab 2
default via 192.168.1.1 dev ens224
192.168.1.0/24 dev ens224 scope link
[jensd@server ~]$ ip rule show
0: from all lookup local
100: from 192.168.0.10 lookup 1
200: from 192.168.1.10 lookup 2
32766: from all lookup main
32767: from all lookup default
[jensd@server ~]$ ip route
default via 192.168.0.10 dev ens192
169.254.0.0/16 dev ens192 scope link metric 1002
169.254.0.0/16 dev ens224 scope link metric 1003
192.168.1.0/24 dev ens224 proto kernel scope link src 192.168.1.10
192.168.0.0/24 dev ens192 proto kernel scope link src 192.168.0.10
As you can see in the output from ip rule show, our policy based tables have a higher priority than the main table, which can be viewed with ip route. Nevertheless it’s import to still have a default route in the main table since packets leaving the machine itself can have a source IP of 0.0.0.0 and would not match any of the rules in our policy.
Make the changes permanent Up to now, the changes would get lost after a reboot or restart of the networking. To make the changes permanent, create a route and rule file for every interface. For the above example, the contents would look like this:
[jensd@server ~]$ cat /etc/sysconfig/network-scripts/route-ens192
192.168.0.0/24 dev ens192 tab 1
default via 192.168.0.1 dev ens192 tab 1
[jensd@server ~]$ cat /etc/sysconfig/network-scripts/route-ens224
192.168.1.0/24 dev ens224 tab 2
default via 192.168.1.1 dev ens224 tab 2
[jensd@server ~]$ cat /etc/sysconfig/network-scripts/rule-ens192
from 192.168.0.10/32 tab 1 priority 100
[jensd@server ~]$ cat /etc/sysconfig/network-scripts/rule-ens224
from 192.168.1.10/32 tab 2 priority 200
Now your configuration should be persistent.
Some people pointed out in the comments that, in order for the routers to be persistent, you need to first perform the following actions:
While this solution is slightly more work than changing the value for rp_filter, it isn’t that hard and has a lot of advantages over the other solution.
TAKEN FROM: https://jensd.be/468/linux/two-network-cards-rp_filter
If the output is zero then go to bios settings and enable VT-x (Virtualization Technology Extension) for Intel processor and AMD-V for AMD processor. Install QEMU and Virtual Machine Manager
titus@debian:~$ sudo systemctl status libvirtd.service
Start Default Network for Networking
VIRSH is a command to directly interact with our VMs from terminal. We use it to list networks, vm-status and various other tools when we need to make tweaks. Here is how we start the default and make it auto-start after reboot.
titus@debian:~$ sudo virsh net-start default
Network default started
titus@debian:~$ sudo virsh net-autostart default
Network default marked as autostarted
Check status with:
titus@debian:~$ sudo virsh net-list --all
Name State Autostart Persistent
----------------------------------------------
default active yes yes
Add User to libvirt to Allow Access to VMs
titus@debian:~$ sudo adduser titus libvirt
titus@debian:~$ sudo adduser titus libvirt-qemu
Reboot and you are Finished!
Taken from: https://www.christitus.com/vm-setup-in-linux
shukko·routing traffic over wireguard with mikrotik to a specific ip address… için yorumlar kapalı
routing traffic over wireguard with mikrotik to a specific ip address…
Routing traffic for a specific destination over the VPN is definitely much easier. After creating the VPN tunnel between two Mikrotik routers, it was a two-more step process:
Larger subnets than a single ip can be routed through the VPN, and multiple subnets can be routed too. The caveat for this simpler method is that you cannot route “all” traffic (ie. to 0.0.0.0) through the VPN, or else the client Mikrotik itself cannot route its own traffic either.
But also this has got no official updates from AsRock.
Somebody mentioned https://www.asrockrack.com/support/faq.asp?id=40 this solution in that thread , but I also don’t have the luxury to reboot and flash old version of firmware as all these boxes are production boxes with several virtual servers on them.
Anybody using these mainboards have any clue about what to do to regain access to BMC IPMI Web interface?
As I said I can get response using IPMITOOL from command line. And everything seems to be working.
Please help..
SOLUTION:
Updates on this matter:
1- After tons / hours of brain thinkering and google searches I figure out that the most sensible way is to downgrade the bmc firmware to a “working” one.
2- I then needed ASPEED socflash utility v 1.2 linux version – which is very hard to get – Aspeed was providing it from their website but no more – After some google foo I found it. If anybody needs socflash utility v1.2 linux version, you are free to contact me.
3- flashed old bmc firmware with socflash linux utilty
root@r5:~/socflash/SOCFLASH# ./socflash.sh X470D4U_P2.20.00.ima X470D4U_calismayan.ima
ASPEED SOC Flash Utility v.1.20.00
Warning:
SoCflash utility is only for engineers to update the firmware in lab,
it is not a commercialized software product,
ASPEED has not done compatibility/reliability stress test for SoCflash.
Please do not use this utility for any mass production purpose.
Press y to continue if you are agree ....
y
Find ASPEED Device 1a03:2000 on 22:0.0
MMIO Virtual Address: a364e000
Relocate IO Base: f000
Found ASPEED Device 1a03:2500 rev. 41
Static Memory Controller Information:
CS0 Flash Type is SPI
CS1 Flash Type is SPI
CS2 Flash Type is SPI
CS3 Flash Type is NOR
CS4 Flash Type is NOR
Boot CS is 0
Option Information:
CS: 0
Flash Type: SPI
[Warning] Don't AC OFF or Reboot System During BMC Firmware Update!!
[SOCFLASH] Flash ID : 1940ef
Find Flash Chip #1: WinbondW25Q256/257
Backup Flash Chip O.K.
Update Flash Chip #1 O.K.
Update Flash Chip O.K.
root@r5:~/socflash/SOCFLASH#
4- After firmware downgrade:
root@r5:~/socflash/SOCFLASH# ipmitool mc info
Device ID : 32
Device Revision : 1
Firmware Revision : 2.20
IPMI Version : 2.0
Manufacturer ID : 49622
Manufacturer Name : Unknown (0xC1D6)
Product ID : 514 (0x0202)
Product Name : Unknown (0x202)
Device Available : yes
Provides Device SDRs : no
Additional Device Support :
Sensor Device
SDR Repository Device
SEL Device
FRU Inventory Device
IPMB Event Receiver
IPMB Event Generator
Chassis Device
Aux Firmware Rev Info :
0x00
0x00
0x00
0x00
root@r5:~/socflash/SOCFLASH# ipmitool lan print 1
MAC Address : a8:a1:59:86:f3:ec
SNMP Community String : AMI
IP Header : TTL=0x40 Flags=0x40 Precedence=0x00 TOS=0x10
BMC ARP Control : ARP Responses Enabled, Gratuitous ARP Disabled
Gratituous ARP Intrvl : 0.0 seconds
Default Gateway IP : 0.0.0.0
Default Gateway MAC : 00:00:00:00:00:00
Backup Gateway IP : 0.0.0.0
Backup Gateway MAC : 00:00:00:00:00:00
802.1q VLAN ID : Disabled
802.1q VLAN Priority : 0
RMCP+ Cipher Suites : 0,1,2,3,6,7,8,11,12,15,16,17
Cipher Suite Priv Max : caaaaaaaaaaaXXX
: X=Cipher Suite Unused
: c=CALLBACK
: u=USER
: o=OPERATOR
: a=ADMIN
: O=OEM
Bad Password Threshold : 0
Invalid password disable: no
Attempt Count Reset Int.: 0
User Lockout Interval : 0
root@r5:~/socflash/SOCFLASH#
5- Now it’s time to Enter the usual ip address / gateway of the IPMI
LAN Configuration
ipmitool lan set 1 ipsrc static
ipmitool lan set 1 ipaddr 192.168.1.211
ipmitool lan set 1 netmask 255.255.255.0
ipmitool lan set 1 defgw ipaddr 192.168.1.254
ipmitool lan set 1 defgw macaddr 00:0e:0c:aa:8e:13
ipmitool lan set 1 arp respond on
ipmitool lan set 1 auth ADMIN MD5
ipmitool lan set 1 access on
User Configuration
A user will now be setup with admin rights.
ipmitool user set name 2 admin
ipmitool user set password 2
Password for user 2:
Password for user 2:
ipmitool channel setaccess 1 2 link=on ipmi=on callin=on privilege=4
ipmitool user enable 2
6- WEB INTERFACE WORKS NOW!!!
7- Time to upgrade to latest version of BMC firmware now
