GrigoriyMikhalkin
commented
2 years ago @networkop I guess 3.7.0 kernel is based on 4.1.0. So indeed, lack of VRF support(and, looking at loaded modules, probably bunch of other stuff) must be the reason. Here's list of loaded modules and kernel version:
cumulus@vagrant-leaf01:mgmt-vrf:~$ lsmod
Module Size Used by
nf_conntrack_netlink 36864 0
nfnetlink 16384 2 nf_conntrack_netlink
xfrm_user 36864 1
xt_conntrack 16384 1
ipt_MASQUERADE 16384 2
nf_nat_masquerade_ipv4 16384 1 ipt_MASQUERADE
iptable_nat 16384 1
nf_conntrack_ipv4 20480 2
nf_defrag_ipv4 16384 1 nf_conntrack_ipv4
nf_nat_ipv4 16384 1 iptable_nat
nf_nat 24576 2 nf_nat_ipv4,nf_nat_masquerade_ipv4
nf_conntrack 94208 6 nf_nat,nf_nat_ipv4,xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_netlink,nf_conntrack_ipv4
8021q 28672 0
garp 16384 1 8021q
mrp 20480 1 8021q
vxlan 45056 0
ip6_udp_tunnel 16384 1 vxlan
udp_tunnel 16384 1 vxlan
tcp_diag 16384 0
inet_diag 20480 1 tcp_diag
vrf 24576 0
ebt_police 16384 8
ebt_setclass 16384 7
xt_POLICE 16384 41
xt_SETCLASS 16384 19
ebtable_filter 16384 1
ebtables 36864 1 ebtable_filter
ip6table_raw 16384 0
ip6table_mangle 16384 0
ip6table_filter 16384 1
ip6_tables 28672 3 ip6table_filter,ip6table_mangle,ip6table_raw
kvm_intel 155648 0
kvm 438272 1 kvm_intel
aesni_intel 172032 0
aes_x86_64 20480 1 aesni_intel
glue_helper 16384 1 aesni_intel
lrw 16384 1 aesni_intel
gf128mul 16384 1 lrw
ablk_helper 16384 1 aesni_intel
cryptd 20480 2 aesni_intel,ablk_helper
virtio_rng 16384 0
rng_core 16384 1 virtio_rng
acpi_cpufreq 20480 0
softdog 16384 1
cumulus_vx_platform 20480 0
hwmon 16384 1 cumulus_vx_platform
mpls_iptunnel 16384 0
mpls_router 28672 1 mpls_iptunnel
at24 16384 0
eeprom_class 16384 2 at24,cumulus_vx_platform
tun 28672 0
br_netfilter 24576 0
bridge 147456 1 br_netfilter
stp 16384 2 garp,bridge
llc 16384 3 stp,garp,bridge
bonding 139264 0
loop 28672 0
autofs4 36864 2
btrfs 937984 1
xor 24576 1 btrfs
raid6_pq 106496 1 btrfs
dm_mod 102400 0
crc32c_intel 24576 1
virtio_net 32768 0
i2c_piix4 24576 0
i2c_core 49152 2 at24,i2c_piix4
uhci_hcd 45056 0
cumulus@vagrant-leaf01:mgmt-vrf:~$ uname -r
4.1.0-cl-7-amd64Regarding packaging kernel into container image, i will try) Will let you know when i have some results.
networkop
reported by @GrigoriyMikhalkin looking at what happens there, it looks like the ifupdown get stuck trying to dhcp eth0.
This looks like the VRF support did not exist in upstream kernel and was added via a patch.
I don't have access to 3.7.x system, maybe @GrigoriyMikhalkin you can compare the kernel version and loaded modules? This is how it looks inside ignite:
The reason for this is most likely that 3.7.0 code is running on a kernel built from 4.3.0.
This is the process I haven't really documented anywhere, probably worth adding a guide for it later. The process of building a kernel image. It's fairly simple -- you need to unpack the /boot/vmlinuz into a vmlinux and get a copy of /lib/modules from an existing CL image. Package it up in an container image, vmlinux goes to /boot/ and /lib/modules go to /lib/modules.
The final step would be to update https://github.com/srl-labs/containerlab/blob/master/nodes/cvx/cvx.go to use a different image kernel depending on the version , similar to how it's done with RAM today.
Do you think you can do this @GrigoriyMikhalkin ? I'll be happy to write up some documentation and makefiles for this.