Re: [Xen-users] Usage of ifconfig in /etc/xen/scripts/vif-route

[Gerdriaan Mulder <hello@xxxxxxxxxxxxxxxxx>]

Hi,

On 31/03/2019 18:14, Hans van Kranenburg wrote:
> A git log --follow, or tig --follow or any other way to follow renames,
> reveils the code is from 2005.

Ah, I've only looked at the last modification, but this is also useful
to know.

>> Since ifconfig has been deprecated in a couple of major
>> distributions[0][1] some 8-10 years ago, I was wondering whether there
>> is an equivalent iproute2 command for creating the vif in
>> /etc/xen/scripts/vif-route. Currently it is: ifconfig ${dev} ${main_ip}
>> netmask 255.255.255.255 up
> I did not test this, but I think it would be:
> 
> ip link set up dev ${dev}
> ip addr add ${main_ip}/32 dev ${dev}

I've modified vif-route per your suggestion (after pasting the relevant
lines somewhat below here). That works as intended.

> However, I'm wondering why it would use /32. I never used vif-route,
> only vif-bridge in the past and vif-openvswitch for a long time now.

Interestingly enough, it appears adding the address is not necessary. In
vif-route, after verifying your suggestion worked, I've left out adding
the address and started the domU. To my surprise, this also worked. I
must note that the current setup uses NAT from vif* to eno1, but I can
test it without that if necessary.

> What do relevant lines in output of ip a and ip r look like after doing
> it with the current script (with net-tools installed)?

# ip a
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
    link/ether 44:37:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.252/24 brd 192.168.0.255 scope global eno1
       valid_lft forever preferred_lft forever
    inet6 2001:470:1f15:55f:xx/64 scope global mngtmpaddr dynamic
       valid_lft 3585sec preferred_lft 3585sec
    inet6 fe80::xx:/64 scope link
       valid_lft forever preferred_lft forever
3: vif1.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
group default qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.252/32 brd 192.168.0.255 scope global vif1.0
       valid_lft forever preferred_lft forever
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
# ip r
default via 192.168.0.1 dev eno1
192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.252
198.51.100.42 dev vif1.0 scope link src 192.168.0.252

> ...and then it will also end up in Debian, but that will be in Buster+1.
> In the meantime we might be able to bring back the dependency on
> net-tools piggy-backing on a stable/security update. It's important
> functionality (I mean, who starts a domU without networking?) and is
> broken by default if the user has no other packages that accidentally
> drag in net-tools. (In my case that's munin-plugins-core everywhere I
> think).

(for what it's worth: `apt-cache rdepends net-tools`, the only
connection with xen is "dtc-xen").

> So, summarizing:
> 1) Can you test the above suggested alternative?

[x] done

> 2) We should create a Debian bug about this (add missing dependency)
> against src:xen.

> 3) If you can test vif-route, then I know someone on IRC who uses
> vif-bridge, which I can ask, and if someone else wants to test vif-nat,
> then I don't mind formatting and sending a proper patch with the
> changes. I only currently don't have spare time to set up different
> networking scenarios in a test environment to trigger all usage scenarios.

As mentioned, I've shortly tested vif-route, although dom0 uses NAT to
provide access to other networks for now. I'll test it with a proper
routed setup later this week.

-- Gerdriaan

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-users