The attachment is logic topo, Server has 2 NICs.
the server has running a http server and listening on 0.0.0.0:80
When client call the http server, I can capture the TCP SYN on NIC of Vlan20 and nothing response.
I also tried capturing on NIC of Vlan10, but got nothing.
I can't understand why this is the phenomenon.
NIC forwarding question
NIC forwarding question
- Attachments
-
- WechatIMG15.png (12.57 KiB) Viewed 4604 times
Re: NIC forwarding question
First, What do you have/see in ip ro
Second, you have VLAN's. Which links are tagged and which untagged?
Second, you have VLAN's. Which links are tagged and which untagged?
Re: NIC forwarding question
Hi Jlehtone,
Thanks your reply.
The output of "ip route":
default via 10.1.2.254 dev eth0
10.1.2.0/24 dev eth0 proto kernel scope link src 10.1.2.1
10.1.1.0/24 dev eth1 proto kernel scope link sec 10.1.1.1
All of interfaces on switch is untagged, and call url is "http://10.1.2.1"
Thanks your reply.
The output of "ip route":
default via 10.1.2.254 dev eth0
10.1.2.0/24 dev eth0 proto kernel scope link src 10.1.2.1
10.1.1.0/24 dev eth1 proto kernel scope link sec 10.1.1.1
All of interfaces on switch is untagged, and call url is "http://10.1.2.1"
Re: NIC forwarding question
You show that your server has addresses 10.1.2.1 and 10.1.1.1
but your picture shows addresses 10.1.2.1 and 10.1.1.2
Your picture shows a client, that has the 10.1.1.1
You say that "call" is to 10.1.2.1. Is it the client in 10.1.1.0/24 that makes that call?
What route does the client use to reach subnet 10.1.2.0/24?
Lets assume that a packet arrives at the server eth0 with SRC=10.1.1.x DST=10.1.2.1
Where should the reply go to? DST=10.1.1.x is quite obvious.
However, packages to 10.1.1.0/24 should leave via eth1 with SRC=10.1.1.1.
That means that while client did send a packet to 10.1.2.1, it would receive (and drop) "unrelated" reply from 10.1.1.1.
Default config in CentOS does not send replies like that. It can be enabled, but as said, the client would not cope with that.
but your picture shows addresses 10.1.2.1 and 10.1.1.2
Your picture shows a client, that has the 10.1.1.1
You say that "call" is to 10.1.2.1. Is it the client in 10.1.1.0/24 that makes that call?
What route does the client use to reach subnet 10.1.2.0/24?
Lets assume that a packet arrives at the server eth0 with SRC=10.1.1.x DST=10.1.2.1
Where should the reply go to? DST=10.1.1.x is quite obvious.
However, packages to 10.1.1.0/24 should leave via eth1 with SRC=10.1.1.1.
That means that while client did send a packet to 10.1.2.1, it would receive (and drop) "unrelated" reply from 10.1.1.1.
Default config in CentOS does not send replies like that. It can be enabled, but as said, the client would not cope with that.
Re: NIC forwarding question
Sorry, the IP on eth1 should be 10.1.1.2
Yes, the call from 10.1.1.0/24 subnet and goes to 10.1.2.0/24 subnet, the L3 switch responsible for routing.
Client use the default gateway 10.1.1.254(config on L3 switch vlan 10) to reach the other subnet
Yes, the call from 10.1.1.0/24 subnet and goes to 10.1.2.0/24 subnet, the L3 switch responsible for routing.
Client use the default gateway 10.1.1.254(config on L3 switch vlan 10) to reach the other subnet
How can I config this? Is it "ipv4_forwarding"?Default config in CentOS does not send replies like that. It can be enabled.
Re: NIC forwarding question
No.
The thing that drops packets is Strict Reverse Path Forwarding filter
See https://access.redhat.com/solutions/53031
It also says:
https://sites.google.com/site/syscookbo ... te-traffic shows bit of the logic.
That packets matching iif eth0 or from 10.1.2.1 should use a custom routing table that sends via eth0.
However, the latter document does not show how to create persistent configuration.
Red Hat has public documentation about policy based routing with NetworkManager.service: https://access.redhat.com/documentation ... ive-routes
The thing that drops packets is Strict Reverse Path Forwarding filter
See https://access.redhat.com/solutions/53031
It also says:
and has link to https://access.redhat.com/solutions/19596to configure a system to function with rp_filter in strict mode is to set up policy based routing
https://sites.google.com/site/syscookbo ... te-traffic shows bit of the logic.
That packets matching iif eth0 or from 10.1.2.1 should use a custom routing table that sends via eth0.
However, the latter document does not show how to create persistent configuration.
Red Hat has public documentation about policy based routing with NetworkManager.service: https://access.redhat.com/documentation ... ive-routes