On 08/07/14 at 04:35pm, Vivek Goyal wrote:
On Thu, Aug 07, 2014 at 05:46:17PM +0800, Baoquan He wrote:
> In static route handling, one corner case is ignored. That is 2 machines
> are directly connected while IPs configured are in the different subnet.
> Say the IP of NIC1 on machine A is 192.168.10.1/24, the IP of NIC2 on
> machine B is 192.168.20.1/24. Then on machine A, a route need be specified:
> 192.168.20.0/24 dev NIC1
> On machine B:
> 192.168.10.0/24 dev NIC2
>
> Without these routes connection from NIC1 to NIC2 can't be setup.
>
> So if in machine A the dump target is set as machine B, route
> "192.168.20.0/24 dev NIC1" has to be added in kdump kernel. But this is
ignored
> in previous handling since we use below patch to find all routes:
>
> /sbin/ip route show | grep -v default | grep "^[[:digit:]].*via.* $_netdev
"
>
> Now in this patch use "/sbin/ip route get to $_target" to get the exact
route
> to the target.
You need to explain why are you switching from "ip route show" to "ip
route get to".
This is the original idea which I wanted to take to solve the static
route. For any specific target we want to connect to in kdump kernel, a
exact route is saved and added in 2nd kernel.
However exact route idea is denied by Marc in rhel6. Since in mkdumprd
of rhel6.6, the handlenetdev() will check if a net dev has been
added per $handlednetdevices. If added, it won't add it again. This is
why we have to add all routes which go through a certain net dev, and
exact route can't be used. Marc's idea is gorgeous in rhel6.6, we
needn't change $handlednetdevices stuff.
In fedora/rhel7, it's different. fedora doesn't have this limitation.
Any time you want to add a network configuration related to a net dev,
you just add it. If use the the same way as rhel6.6 does, a problem
emerged. That is if routes to several different targets all go through
the same net dev, this will add all routes which go through this net dev
several times. Duplicate routes exist in route-static, adding them will
cause warning of adding route repeatedly.
So it may be better to take exact route back.
>
> sh> ip route get to 192.168.20.2
> 192.168.20.2 via 192.168.10.2 dev ens10 src 192.168.10.1
> 192.168.10.1 -> 192.168.20.2 -> 192.168.20.1 -> 192.168.20.2
So this is the actual output of "ip route get to". What is this second
line?
Who has ip addr 192.168.20.2 and 192.168.10.2 respectively? I thought
machine A had ip addr 192.168.10.1 and machine B had ip addr 192.168.20.1.
OK, here the example I took maybe misled. Here assume a network top:
A 1 <---> 1 R 2 <---> 2 B
A1 interface: 192.168.10.1
R1 interface: 192.168.10.2
R2 interface: 192.168.20.1
B2 interface: 192.168.20.2
In this case, R is route between A and B. If A want to dump to B, the
ip route "192.168.20.2 via 192.168.10.1 dev A1" can be added, surely
this is a exact route. The subnet route "192.168.20.0/24 via 192.168.10.1
dev A1" can also works. But here "ip route get to 192.168.20.2"
returns this exact route, it's enough.
>
> or
> sh> ip route get to 192.168.20.2
> 192.168.20.2 dev ens10 src 192.168.10.1
> 192.168.10.1 -> 192.168.20.2
What's this alternative output. So output of "ip route get to" changes
now?
Here assume a network top:
A 1<--->1 B
A1 interface: 192.168.10.1
B1 interface: 192.168.20.1
In this case, A1 and B1 is connected by a cable directly. If A want to
dump to B, a exact route "192.168.20.2 dev A1" need be added, or a
subnet route "192.168.20.0/24 dev A1".
>
> And write the static route to config file only if static ip address configured
> on this network interface.
What's the relation between an interface having static ip and it having
static routes. Can't an interface having dhcp still have some static
routes going through it?
I am not very familiar with the different complex network deployment,
just know a little how route tables work in kernel stack. Here you are
right, an interface having dhcp can have static routes going through it.
For this we need add that kind of route if needed.
>
> Signed-off-by: Baoquan He <bhe(a)redhat.com>
> ---
> dracut-module-setup.sh | 25 +++++++++++++++++--------
> 1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> index 8fa59ca..3de2008 100755
> --- a/dracut-module-setup.sh
> +++ b/dracut-module-setup.sh
> @@ -75,15 +75,24 @@ kdump_static_ip() {
> local _ipaddr=$(ip addr show dev $_netdev permanent | \
> awk "/ $_srcaddr\/.* $_netdev\$/{print \$2}")
> if [ -n "$_ipaddr" ]; then
> - _netmask=$(ipcalc -m $_ipaddr | cut -d'=' -f2)
> - _gateway=$(ip route list dev $_netdev | awk '/^default /{print
$3}')
> - echo -n "${_srcaddr}::${_gateway}:${_netmask}::"
> + _netmask=$(ipcalc -m $_ipaddr | cut -d'=' -f2)
> + _gateway=$(ip route list dev $_netdev | awk '/^default /{print
$3}')
> + echo -n "${_srcaddr}::${_gateway}:${_netmask}::"
> +
> +
Same question here. This function kdump_static_ip() seems to be doing
multiple things. It determines whether interface has static ip or not
and also saves static routes going through that function in a file. I
am wondering what's the correlation between two. Should these not be
in separate functions.
Yeah, I need think about this.
Thanks
Vivek
> + local _route
> + _route=`/sbin/ip route get to $_target 2>&1`
> + if [ -n "`echo $_route | grep via`" ]
> + then
> + # route going to a different subnet via a router
> + echo $_route | awk '{printf("rd.route=%s:%s:%s\n", $1,
$3, $5)}' \
> + >> ${initdir}/etc/cmdline.d/45route-static.conf
> + else
> + # route going to a different subnet though directly connected
> + echo $_route | awk '{printf("rd.route=%s::%s\n", $1,
$3)}' \
> + >> ${initdir}/etc/cmdline.d/45route-static.conf
> + fi
> fi
> -
> - /sbin/ip route show | grep -v default | grep "^[[:digit:]].*via.* $_netdev
" |\
> - while read line; do
> - echo $line | awk '{printf("rd.route=%s:%s:%s\n", $1, $3,
$5)}'
> - done >> ${initdir}/etc/cmdline.d/45route-static.conf
> }
>
> kdump_get_mac_addr() {
> --
> 1.9.0
_______________________________________________
kexec mailing list
kexec(a)lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/kexec