On 08/23/17 at 01:48pm, Dave Young wrote:
On 08/23/17 at 09:35am, Baoquan He wrote:
> 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.
Thanks for the details.
According to this understanding, any comments about my previous questions about
ip route handling in kdump scripts and how should we handle them?
Ask customer to specify fe80::713e:a426:d167:aaaa%eth2 when they want to
dump to target with link local address. And we can handle them easy too.
Surely with a detailed description about ipv6 link local address.
>
> Thanks
> Dave
> _______________________________________________
> kexec mailing list -- kexec(a)lists.fedoraproject.org
> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org