Re: problem with ixl(4) and vlans

[Daniel]

Hi Santi,


yes that was one of the first things i tried, disabling all the VLAN_HW* 
options on the interface, unfortunately without any change in the behavior.


The pf module is loaded and some filters are active on another interface 
but no filtering happens on ixl3, ixl3.15 or bridge0. That was also one 
of the reasons why I crosschecked my setup with an USB nic so I can make 
sure its not the firewall by accident.



Thanks & Best

Daniel


On 1/25/24 22:10, Santiago Martinez wrote:

Hi Daniel,

have you try disabling hardware vlan filtering?

Also I guess there is not ipfw or pf modules loaded right?

Best
Santi


On 25 Jan 2024, at 10:07, Daniel  wrote:



Hi,

thanks for your suggestion. Turns out, when i unplug the vlan 
interface from the bridge and put the ip address on the vlan 
interface, as you suggested, things start to work, e.g. arp resolves.


as soon as i put the ip and the vlan interface back on the bridge, 
things stop again. so where does this lead me? the problem is not in 
the vlan handling, but on the bridge?


I started playing with the net.link.bridge sysctls and indeed, when i 
set



# sysctl net.link.bridge.inherit_mac=1


and then recreate the bridge


# ifconfig bridge0 deletem ixl3.15 deletem vnet0.1
# ifconfig bridge0 addm ixl3.15 addm vnet0.1


with the ip address still on bridge0 and ixl3, ixl3.15 and bridge0 
all sharing the same mac address, arp starts resolving. but only for 
requests sent from the bridge0 interface. inside of the jail things 
still don't work (as the vnet interface again has another mac address).



# ifconfig ixl3
ixl3: flags=28963 
metric 0 mtu 1500

options=4a500b9
    ether a4:bf:01:76:ef:9d
    media: Ethernet autoselect (10Gbase-SR )
    status: active
    nd6 options=29
# ifconfig ixl3.15
ixl3.15: flags=8943 
metric 0 mtu 1500

    options=421
    ether a4:bf:01:76:ef:9d
    groups: vlan
    vlan: 15 vlanproto: 802.1q vlanpcp: 0 parent interface: ixl3
    media: Ethernet autoselect (10Gbase-SR )
    status: active
    nd6 options=29
# ifconfig bridge0
bridge0: flags=8843 metric 0 
mtu 1500

    ether a4:bf:01:76:ef:9d
    inet 192.168.55.20 netmask 0xff00 broadcast 192.168.55.255
    id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
    maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
    root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
    member: vnet0.1 flags=143
    ifmaxaddr 0 port 9 priority 128 path cost 2000
    member: ixl3.15 flags=143
    ifmaxaddr 0 port 8 priority 128 path cost 2000
    groups: bridge
    nd6 options=9
# ping 192.168.55.1
PING 192.168.55.1 (192.168.55.1): 56 data bytes
^C
--- 192.168.55.1 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss

[! yes, the host does not answer on ICMP, but that is to be expected !]

# arp -an
? (192.168.55.20) at a4:bf:01:76:ef:9d on bridge0 permanent [bridge]
? (192.168.55.1) at b8:27:eb:47:8f:43 on bridge0 expires in 1197 
seconds [bridge]

[...]

[! into the jail !]

JAIL # ifconfig epair0b
epair0b: flags=8863 metric 0 
mtu 1500

    options=8
    ether ac:16:2d:bd:b7:34
    hwaddr 02:51:73:d1:33:0b
    inet 192.168.55.10 netmask 0xff00 broadcast 192.168.55.255
    inet6 fe80::ae16:2dff:febd:b734%epair0b prefixlen 64 scopeid 0x2
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T )
    status: active
    nd6 options=21
JAIL # ping 192.168.55.1
PING 192.168.55.1 (192.168.55.1): 56 data bytes
^C
--- 192.168.55.1 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
JAIL # arp -an
? (192.168.55.10) at ac:16:2d:bd:b7:34 on epair0b permanent [ethernet]
? (192.168.55.1) at (incomplete) on epair0b expired [ethernet]


I conclude that there must be some mac address filtering going on in 
the data path, whether its on ixl or the bridge.


In dmesg I also see:

>> bridge0: can't disable some capabilities on ixl3.15: 0x400

but as of /usr/src/sys/net/if.h:233 this maps to IFCAP_LRO which 
afaik should not have any influence on L2 filtering.



Have to say, I'm out of ideas again. Never had something like this. 
So far just 'throwing interfaces on a bridge' worked in the past. Any 
ideas where to look next?



Thanks a lot & best


Daniel


On 1/25/24 08:22, Zhenlei Huang wrote:




On Jan 23, 2024, at 11:03 PM, Daniel  wrote:

Hi List,


just recently I discovered a problem with the ixl(4) driver. 
Hopefully someone here can help me. my setup is as follows:



Network - ixl3 interface - ixl3.15 vlan interface - 
bridge0 - vnet0.1 to jail



the problem now is that the jail can send data out (arp requests), 
i do see the responses on the ixl3 interface of the host, but they 
never make their way up to the ixl3.15 vlan interface (even though 
they are tagged correctly). To rule out that my config or the 
network is the cruel pit i did 

Re: problem with ixl(4) and vlans

[Santiago Martinez]

Hi Daniel, have you try disabling hardware vlan filtering?Also I guess there is not ipfw or pf modules loaded right?Best SantiOn 25 Jan 2024, at 10:07, Daniel  wrote:

  

  
  
Hi,
thanks for your suggestion. Turns out, when i unplug the vlan
  interface from the bridge and put the ip address on the vlan
  interface, as you suggested, things start to work, e.g. arp
  resolves.
as soon as i put the ip and the vlan interface back on the
  bridge, things stop again. so where does this lead me? the problem
  is not in the vlan handling, but on the bridge? 

I started playing with the net.link.bridge sysctls and indeed,
  when i set 



# sysctl net.link.bridge.inherit_mac=1


and then recreate the bridge


# ifconfig bridge0 deletem ixl3.15 deletem vnet0.1
  # ifconfig bridge0 addm ixl3.15 addm vnet0.1


with the ip address still on bridge0 and ixl3, ixl3.15 and
  bridge0 all sharing the same mac address, arp starts resolving.
  but only for requests sent from the bridge0 interface. inside of
  the jail things still don't work (as the vnet interface again has
  another mac address).


# ifconfig ixl3 
  ixl3:
  flags=28963
  metric 0 mtu 1500
     
options=4a500b9
      ether a4:bf:01:76:ef:9d
      media: Ethernet autoselect (10Gbase-SR
  )
      status: active
      nd6 options=29
  # ifconfig ixl3.15
  ixl3.15:
  flags=8943
  metric 0 mtu 1500
      options=421
      ether a4:bf:01:76:ef:9d
      groups: vlan
      vlan: 15 vlanproto: 802.1q vlanpcp: 0 parent interface:
  ixl3
      media: Ethernet autoselect (10Gbase-SR
  )
      status: active
      nd6 options=29
  # ifconfig bridge0
  bridge0: flags=8843
  metric 0 mtu 1500
      ether a4:bf:01:76:ef:9d
      inet 192.168.55.20 netmask 0xff00 broadcast
  192.168.55.255
      id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay
  15
      maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
      root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
      member: vnet0.1
  flags=143
      ifmaxaddr 0 port 9 priority 128 path cost 2000
      member: ixl3.15
  flags=143
      ifmaxaddr 0 port 8 priority 128 path cost 2000
      groups: bridge
      nd6 options=9
  # ping 192.168.55.1
  PING 192.168.55.1 (192.168.55.1): 56 data bytes
  ^C
  --- 192.168.55.1 ping statistics ---
  2 packets transmitted, 0 packets received, 100.0% packet loss

[! yes, the host does not answer on ICMP, but that is to be
  expected !]

# arp -an
  ? (192.168.55.20) at a4:bf:01:76:ef:9d on bridge0 permanent
  [bridge]
  ? (192.168.55.1) at b8:27:eb:47:8f:43 on bridge0 expires in 1197
  seconds [bridge]
  [...]

  [! into the jail !]

JAIL # ifconfig epair0b
  epair0b: flags=8863
  metric 0 mtu 1500
      options=8
      ether ac:16:2d:bd:b7:34
      hwaddr 02:51:73:d1:33:0b
      inet 192.168.55.10 netmask 0xff00 broadcast
  192.168.55.255
      inet6 fe80::ae16:2dff:febd:b734%epair0b prefixlen 64
  scopeid 0x2
      groups: epair
      media: Ethernet 10Gbase-T (10Gbase-T )
      status: active
      nd6 options=21
  JAIL # ping 192.168.55.1
  PING 192.168.55.1 (192.168.55.1): 56 data bytes
  ^C
  --- 192.168.55.1 ping statistics ---
  1 packets transmitted, 0 packets received, 100.0% packet loss
  JAIL # arp -an
  ? (192.168.55.10) at ac:16:2d:bd:b7:34 on epair0b permanent
  [ethernet]
  ? (192.168.55.1) at (incomplete) on epair0b expired [ethernet]
  



I conclude that there must be some mac address filtering going on
  in the data path, whether its on ixl or the bridge.
In dmesg I also see:
>> bridge0: can't disable some capabilities on ixl3.15:
  0x400
but as of /usr/src/sys/net/if.h:233 this maps to IFCAP_LRO which
  afaik should not have any influence on L2 filtering.



Have to say, I'm out of ideas again. Never had something like
  this. So far just 'throwing interfaces on a bridge' worked in the
  past. Any ideas where to look next?


Thanks a lot & best


Daniel



On 1/25/24 08:22, Zhenlei Huang wrote:


  

  On Jan 23, 2024, at 11:03 PM, Daniel 
wrote:
  
  

  Hi List, 


just recently I discovered a problem with the ixl(4)
driver. Hopefully someone here can help me. my setup is

Re: problem with ixl(4) and vlans

[Daniel]

Hi,

thanks for your suggestion. Turns out, when i unplug the vlan interface 
from the bridge and put the ip address on the vlan interface, as you 
suggested, things start to work, e.g. arp resolves.


as soon as i put the ip and the vlan interface back on the bridge, 
things stop again. so where does this lead me? the problem is not in the 
vlan handling, but on the bridge?


I started playing with the net.link.bridge sysctls and indeed, when i set


# sysctl net.link.bridge.inherit_mac=1


and then recreate the bridge


# ifconfig bridge0 deletem ixl3.15 deletem vnet0.1
# ifconfig bridge0 addm ixl3.15 addm vnet0.1


with the ip address still on bridge0 and ixl3, ixl3.15 and bridge0 all 
sharing the same mac address, arp starts resolving. but only for 
requests sent from the bridge0 interface. inside of the jail things 
still don't work (as the vnet interface again has another mac address).



# ifconfig ixl3
ixl3: flags=28963 metric 
0 mtu 1500

options=4a500b9
    ether a4:bf:01:76:ef:9d
    media: Ethernet autoselect (10Gbase-SR )
    status: active
    nd6 options=29
# ifconfig ixl3.15
ixl3.15: flags=8943 
metric 0 mtu 1500

    options=421
    ether a4:bf:01:76:ef:9d
    groups: vlan
    vlan: 15 vlanproto: 802.1q vlanpcp: 0 parent interface: ixl3
    media: Ethernet autoselect (10Gbase-SR )
    status: active
    nd6 options=29
# ifconfig bridge0
bridge0: flags=8843 metric 0 mtu 
1500

    ether a4:bf:01:76:ef:9d
    inet 192.168.55.20 netmask 0xff00 broadcast 192.168.55.255
    id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
    maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
    root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
    member: vnet0.1 flags=143
    ifmaxaddr 0 port 9 priority 128 path cost 2000
    member: ixl3.15 flags=143
    ifmaxaddr 0 port 8 priority 128 path cost 2000
    groups: bridge
    nd6 options=9
# ping 192.168.55.1
PING 192.168.55.1 (192.168.55.1): 56 data bytes
^C
--- 192.168.55.1 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss

[! yes, the host does not answer on ICMP, but that is to be expected !]

# arp -an
? (192.168.55.20) at a4:bf:01:76:ef:9d on bridge0 permanent [bridge]
? (192.168.55.1) at b8:27:eb:47:8f:43 on bridge0 expires in 1197 seconds 
[bridge]

[...]

[! into the jail !]

JAIL # ifconfig epair0b
epair0b: flags=8863 metric 0 mtu 
1500

    options=8
    ether ac:16:2d:bd:b7:34
    hwaddr 02:51:73:d1:33:0b
    inet 192.168.55.10 netmask 0xff00 broadcast 192.168.55.255
    inet6 fe80::ae16:2dff:febd:b734%epair0b prefixlen 64 scopeid 0x2
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T )
    status: active
    nd6 options=21
JAIL # ping 192.168.55.1
PING 192.168.55.1 (192.168.55.1): 56 data bytes
^C
--- 192.168.55.1 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
JAIL # arp -an
? (192.168.55.10) at ac:16:2d:bd:b7:34 on epair0b permanent [ethernet]
? (192.168.55.1) at (incomplete) on epair0b expired [ethernet]


I conclude that there must be some mac address filtering going on in the 
data path, whether its on ixl or the bridge.


In dmesg I also see:

>> bridge0: can't disable some capabilities on ixl3.15: 0x400

but as of /usr/src/sys/net/if.h:233 this maps to IFCAP_LRO which afaik 
should not have any influence on L2 filtering.



Have to say, I'm out of ideas again. Never had something like this. So 
far just 'throwing interfaces on a bridge' worked in the past. Any ideas 
where to look next?



Thanks a lot & best


Daniel


On 1/25/24 08:22, Zhenlei Huang wrote:




On Jan 23, 2024, at 11:03 PM, Daniel  wrote:

Hi List,


just recently I discovered a problem with the ixl(4) driver. 
Hopefully someone here can help me. my setup is as follows:



Network - ixl3 interface - ixl3.15 vlan interface - 
bridge0 - vnet0.1 to jail



the problem now is that the jail can send data out (arp requests), i 
do see the responses on the ixl3 interface of the host, but they 
never make their way up to the ixl3.15 vlan interface (even though 
they are tagged correctly). To rule out that my config or the network 
is the cruel pit i did test the same setup with a cheap usb-ethernet 
adapter and there everything works as expected. I'm on FreeBSD 
13.2-RELEASE-p8 and I did test both, the in kernel driver and the 
driver from ports intel-ixl-kmod-1.13.4_1.


I would encourage you to do plain VLAN tests, i.e. plug ixl3.15 out 
from bridge0


```
# ifconfig bridge0 deletem ixl3.15
# ifconfig bridge0 inet 192.168.55.20/24 delete ### to prevent confusion
# ifconfig ixl3.15 inet 192.168.55.x/24
# ping -c1 192.168.55.1
```



Here is a bit of information on my environment:

# uname -a
FreeBSD mimir 13.2-RELEASE-p8 FreeBSD 13.2-RELEASE-p8 GENERIC amd64

# pciconf -lBbcevV pci0:25:0:3
ixl3@pci0:25:0:3:   

Re: problem with ixl(4) and vlans

[Zhenlei Huang]

> On Jan 23, 2024, at 11:03 PM, Daniel  wrote:
> 
> Hi List, 
> 
> 
> just recently I discovered a problem with the ixl(4) driver. Hopefully 
> someone here can help me. my setup is as follows: 
> 
> 
> Network - ixl3 interface - ixl3.15 vlan interface - bridge0 - 
> vnet0.1 to jail 
> 
> 
> the problem now is that the jail can send data out (arp requests), i do see 
> the responses on the ixl3 interface of the host, but they never make their 
> way up to the ixl3.15 vlan interface (even though they are tagged correctly). 
> To rule out that my config or the network is the cruel pit i did test the 
> same setup with a cheap usb-ethernet adapter and there everything works as 
> expected. I'm on FreeBSD 13.2-RELEASE-p8 and I did test both, the in kernel 
> driver and the driver from ports intel-ixl-kmod-1.13.4_1. 
> 
I would encourage you to do plain VLAN tests, i.e. plug ixl3.15 out from bridge0

```
# ifconfig bridge0 deletem ixl3.15
# ifconfig bridge0 inet 192.168.55.20/24 delete ### to prevent confusion
# ifconfig ixl3.15 inet 192.168.55.x/24
# ping -c1 192.168.55.1
``` 

> 
> Here is a bit of information on my environment: 
> 
> # uname -a 
> FreeBSD mimir 13.2-RELEASE-p8 FreeBSD 13.2-RELEASE-p8 GENERIC amd64 
> 
> # pciconf -lBbcevV pci0:25:0:3 
> ixl3@pci0:25:0:3:   class=0x02 rev=0x09 hdr=0x00 vendor=0x8086 
> device=0x37d3 subvendor=0x8086 subdevice=0x35d5 
> vendor = 'Intel Corporation' 
> device = 'Ethernet Connection X722 for 10GbE SFP+' 
> class  = network 
> subclass   = ethernet 
> bar   [10] = type Prefetchable Memory, range 64, base 0xb000, size 
> 16777216, enabled 
> bar   [1c] = type Prefetchable Memory, range 64, base 0xb500, size 
> 32768, enabled 
> cap 01[40] = powerspec 3  supports D0 D3  current D0 
> cap 05[50] = MSI supports 1 message, 64 bit, vector masks 
> cap 11[70] = MSI-X supports 129 messages, enabled 
>  Table in map 0x1c[0x0], PBA in map 0x1c[0x1000] 
> cap 10[a0] = PCI-Express 2 endpoint max data 256(512) FLR RO 
>  max read 512 
>  link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) 
> cap 03[e0] = VPD 
> ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected 
> ecap 0003[140] = Serial 1 9aef7601bfa4 
> ecap 000e[150] = ARI 1 
> ecap 0010[160] = SR-IOV 1 IOV disabled, Memory Space disabled, ARI 
> disabled 
>  0 VFs configured out of 32 supported 
>  First VF RID Offset 0x006d, VF RID Stride 0x0001 
>  VF Device ID 0x37cd 
>  Page Sizes: 4096 (enabled), 8192, 65536, 262144, 
> 1048576, 4194304 
> ecap 0017[1a0] = TPH Requester 1 
> ecap 000d[1b0] = ACS 1 Source Validation unavailable, Translation 
> Blocking unavailable 
>  P2P Req Redirect unavailable, P2P Cmpl Redirect 
> unavailable 
>  P2P Upstream Forwarding unavailable, P2P Egress Control 
> unavailable 
>  P2P Direct Translated unavailable, Enhanced Capability 
> unavailable 
>   PCI-e errors = Correctable Error Detected 
>  Unsupported Request Detected 
>  Corrected = Advisory Non-Fatal Error 
> VPD ident  = 'Example VPD' 
> 
> # ifconfig
> [...]
> ixl3: flags=8963 metric 0 mtu 
> 1500
> 
> options=4a500b9
> ether a4:bf:01:76:ef:9d
> media: Ethernet autoselect (10Gbase-SR )
> status: active
> nd6 options=29
> ixl3.15: flags=8942 metric 0 mtu 
> 1500
> options=421
> ether a4:bf:01:76:ef:9d
> groups: vlan
> vlan: 15 vlanproto: 802.1q vlanpcp: 0 parent interface: ixl3
> media: Ethernet autoselect (10Gbase-SR )
> status: active
> nd6 options=29
> bridge0: flags=8843 metric 0 mtu 1500
> ether 58:9c:fc:10:dd:05
> inet 192.168.55.20 netmask 0xff00 broadcast 192.168.55.255
> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
> member: vnet0.1 flags=143
> ifmaxaddr 0 port 9 priority 128 path cost 2000
> member: ixl3.15 flags=143
> ifmaxaddr 0 port 8 priority 128 path cost 55
> groups: bridge
> nd6 options=9
> [...]
> 
> 
> 
> 
> # cat /etc/rc.conf 
> [...] 
> ifconfig_ixl3="up" 
> vlans_ixl3="15" 
> cloned_interfaces="bridge0" 
> ifconfig_bridge0="addm ixl3.15 up" 
> [...]
> 
> 
> 
> # dmesg | grep ixl 
> ixl0:  mem 
> 0xb300-0xb3ff,0xb5018000-0xb501 at device 0.0 numa-domain 0 on 
> pci6 
> ixl0: fw 3.1.55727 api 1.5 nvm 3.31 etid 8d32 oem 1.262.0 
> ixl0: PF-ID[0]: VFs 32, MSI-X 129, VF MSI-X 5, QPs 384, MDIO shared 
> ixl0: Using 1024 TX descriptors and 1024 RX descriptors 
> ixl0: Using 12 RX queues 12 TX queues 
> ixl0: Using MSI-X interrupts with 13 

Re: problem with ixl(4) and vlans

[Daniel]

Hi List,


because i've been asked, yes, the ixl3.15 interface is also UP (even my 
output in the last mail showed different, result of my desperate tries 
to make it work.


One thing I didn't mention, this is an onboard ixl on a Intel S2600STB 
Board, is has this wired config, were the first two interfaces are 10g 
base-t and the other two are sfp+ ports. While looking around further I 
noticed that only one of the sfp+ ports shows information on the sfp+ 
module correctly (both modules are genuine intel and have been cycled):



# ifconfig -v ixl2
ixl2: flags=8863 metric 0 mtu 9184
options=4e507bb
    ether a4:bf:01:76:ef:9c
    inet [...]
    media: Ethernet autoselect (10Gbase-SR )
    status: active
    nd6 options=23
    plugged: GBIC 100G AOC (Active Optical Cable (SC)
    vendor:  PN:  SN:  DATE: 20--


does not show the correct information (100G AOC, i'd wish ;) even thou 
it has the same kind of sfp+ as ixl3 here:



# ifconfig -v ixl3
ixl3: flags=8963 metric 
0 mtu 1500

options=4a500b9
    ether a4:bf:01:76:ef:9d
    media: Ethernet autoselect (10Gbase-SR )
    status: active
    nd6 options=29
    plugged: SFP/SFP+/SFP28 10G Base-SR (LC)
    vendor: Intel Corp PN: FTLX8571D3BCV-IT SN: MHT27ZB DATE: 
2018-11-09

    module temperature: 43.24 C voltage: 3.32 Volts
    lane 1: RX power: 0.57 mW (-2.41 dBm) TX bias: 8.20 mA

this made me thinking; is this 'wired' base-t and sfp+ configuration 
properly supported by the driver?


Any ideas from the list?


thanks & best


Daniel


On 1/23/24 16:03, Daniel wrote:


Hi List,


just recently I discovered a problem with the ixl(4) driver. Hopefully 
someone here can help me. my setup is as follows:



Network - ixl3 interface - ixl3.15 vlan interface - 
bridge0 - vnet0.1 to jail



the problem now is that the jail can send data out (arp requests), i 
do see the responses on the ixl3 interface of the host, but they never 
make their way up to the ixl3.15 vlan interface (even though they are 
tagged correctly). To rule out that my config or the network is the 
cruel pit i did test the same setup with a cheap usb-ethernet adapter 
and there everything works as expected. I'm on FreeBSD 13.2-RELEASE-p8 
and I did test both, the in kernel driver and the driver from ports 
intel-ixl-kmod-1.13.4_1.


Here is a bit of information on my environment:

# uname -a
FreeBSD mimir 13.2-RELEASE-p8 FreeBSD 13.2-RELEASE-p8 GENERIC amd64

# pciconf -lBbcevV pci0:25:0:3
ixl3@pci0:25:0:3:   class=0x02 rev=0x09 hdr=0x00 vendor=0x8086 
device=0x37d3 subvendor=0x8086 subdevice=0x35d5

    vendor = 'Intel Corporation'
    device = 'Ethernet Connection X722 for 10GbE SFP+'
    class  = network
    subclass   = ethernet
    bar   [10] = type Prefetchable Memory, range 64, base 0xb000, 
size 16777216, enabled
    bar   [1c] = type Prefetchable Memory, range 64, base 0xb500, 
size 32768, enabled

    cap 01[40] = powerspec 3  supports D0 D3  current D0
    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
    cap 11[70] = MSI-X supports 129 messages, enabled
 Table in map 0x1c[0x0], PBA in map 0x1c[0x1000]
    cap 10[a0] = PCI-Express 2 endpoint max data 256(512) FLR RO
 max read 512
 link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1)
    cap 03[e0] = VPD
    ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected
    ecap 0003[140] = Serial 1 9aef7601bfa4
    ecap 000e[150] = ARI 1
    ecap 0010[160] = SR-IOV 1 IOV disabled, Memory Space disabled, ARI 
disabled

 0 VFs configured out of 32 supported
 First VF RID Offset 0x006d, VF RID Stride 0x0001
 VF Device ID 0x37cd
 Page Sizes: 4096 (enabled), 8192, 65536, 262144, 
1048576, 4194304

    ecap 0017[1a0] = TPH Requester 1
    ecap 000d[1b0] = ACS 1 Source Validation unavailable, Translation 
Blocking unavailable
 P2P Req Redirect unavailable, P2P Cmpl Redirect 
unavailable
 P2P Upstream Forwarding unavailable, P2P Egress 
Control unavailable
 P2P Direct Translated unavailable, Enhanced 
Capability unavailable

  PCI-e errors = Correctable Error Detected
 Unsupported Request Detected
 Corrected = Advisory Non-Fatal Error
    VPD ident  = 'Example VPD'

# ifconfig
[...]
ixl3: flags=8963 
metric 0 mtu 1500

options=4a500b9
    ether a4:bf:01:76:ef:9d
    media: Ethernet autoselect (10Gbase-SR )
    status: active
    nd6 options=29
ixl3.15: flags=8942 
metric 0 mtu 1500

    options=421
    ether a4:bf:01:76:ef:9d
    groups: vlan
    vlan: 15 vlanproto: 802.1q vlanpcp: 0 parent interface: ixl3
    media: Ethernet autoselect (10Gbase-SR )
    status: active
    nd6 options=29
bridge0: flags=8843 metric 0 
mtu 1500

    ether 58:9c:fc:10:dd:05
    inet