On 08/22/17 at 05:55pm, Baoquan He wrote:
> > > I am not sure, but most likely we can not simplify it.
"ip route" is based on routing table.
> > > While "ip neigh" is based on neighbor's discovery
protocol(L2 protocol), which means the peer should be on the switch.
> > > As for link-local addr, there is no subnet fields, I can not figure out
how it is go through routing table.
> > > Versa vice, the problem based on routing-table can not be resolved by L2
info.
> >
> > Since link local is only local addresses, do we really need these ip
> > route callback? Maybe we can skip them?
> >
> > For the static route issue, is it a problem for link local?
> >
> > Baoquan, do you have idea?
>
> I talked with Pingfan before about link lock, it should be the address
> inside a local net which are connected by bridge. At least it's similar
> in principal. Involve Leo and Xin Long to this thread, they are network
> experts.
>
> In bridge peers broadcast arp and get the related mac info and ip addr
> and build the arp table, also named as neighbour table. In fact we seems
> to haven't consider that either for ipv4 in the current kexec-tools scripts.
> And as you said, up to now, no customers really dump to target within a local
> network. For bridge, namely the layer two area, internally they don't
> have route, just arp table and mac table. They only use route when they
> need to communicate with outer area.
>
> I think we can leave it as is for now. If really there are weirdos who
> just want to deploy kdump inside a local area, we can reconsider them.
OK, forget about what I said, I was wrong about ipv6 link local address.
Yesterday I talked with Xin Long about it on the phone, he explained the
detailes about ipv6 link local, let me try to conclude it here:
Basically ipv6 is the same as ipv4, however link local is an exception,
it's an layer 3 address. In ipv4, we have layer 2 address, namely MAC
address; and layer 3 address, namely ip address. However for ipv6, it
has mac address, and two kinds of layer 3 address, namely link local
address and global address.
For global address, we can think it's the counterpart of ipv4 address in
ipv6. We configure a global ipv6 address on an interface, system will
generate a subnet route for it, e.g we configure 2000::1 for eth1, the
generated route will be like:
2000::/64 dev eth1 proto kernel metric 256
And we also can configure a route for it manually, like:
ip -6 route add 2000::1/64 dev eth1 via 2000::254
While ipv6 link local address is not configured by people, it's
generated by system. The rule is the prefix fe80 following '::', plus
the latter part which is made based on MAC address. E.g you have a
netdev which mac address is 52:54:00:c4:53:7e, then its link local
address is:
fe80::5254:00c4:537e
Can you see that, it's set by system, and system also generates a route
for this layer 3 address, like this:
fe80::/64 dev eth0 proto kernel metric 256
If you have multiple netdev in one system, you will have multiple
routes, like
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth1 proto kernel metric 256
fe80::/64 dev eth2 proto kernel metric 256
You are surprised by them, right? You must be. Because if you want to
ping the ipv6 link local of your peer, it must fail, system doesn't know
which netdev interface it will go through.
If you really want to ping, how can we be allowed to do? Like this:
ping6 fe80::713e:a426:d167:aaaa -I eth2
We need specify interface. But how can we do ssh since ssh doesn't have
option to provide us to specify interface? like this:
ssh -6 fe80::21b:21ff:fe22:e865%eth1
And you can ping with above syntax:
ping6 fe80::713e:a426:d167:aaaa%eth2
And other application protocol too, with fe80::xx:xx:xx%ethX syntax.
As Xin Long told, above only works between two direct connected systems.
If in a ipv6 area, such as there are several subnet in this area, can we
ping remote link local address across subnet, Xin Long said no.
>
> Checked again, we have kdump_setup_bridge(), but that seems to use that
> bridge interface as an output interface. In theory, a bridge, the whole
> can be seen as a layer 3 interface. In linux, by default, all netdev
> will be a l3 interface. I am not sure if we can make the dump work
> inside bridge, means machine A and B which are all inside bridge C, then
> A dump to B. We may not support this kind of scenario. While inside
> bridge C, A and B communicate by local link in ipv4 term possibly, if
> what I understand is correct.
> >
> >
> > Thanks
> > Baoquan
> > > >
> > > > > dracut-module-setup.sh: _gateway=$(ip $_ipv6_flag route
list dev
> > > > > $_netdev | \
> > > > > dracut-module-setup.sh: /sbin/ip $_ipv6_flag route show | grep
-v default
> > > > > | grep ".*via.* $_netdev " |\
> > > > > dracut-module-setup.sh:get_ip_route_field()
> > > > > dracut-module-setup.sh: _route=`/sbin/ip -o route get to
$_server 2>&1`
> > > > > dracut-module-setup.sh: _srcaddr=$(get_ip_route_field
"$_route" "src")
> > > > > dracut-module-setup.sh: _netdev=$(get_ip_route_field
"$_route" "dev")
> > > > > dracut-module-setup.sh: netdev=$(/sbin/ip route get to
${tgt_ipaddr} | \
> > > > >
> > > > >
> > > > [...]
> > >
> > > Thanks
> > > Dave