Op 08-10-2025 om 10:10 schreef Paul Procacci:
On Wed, Oct 8, 2025 at 4:04 AM Paul Procacci <[email protected]> wrote:

On Wed, Oct 8, 2025 at 3:59 AM Lexi Winter <[email protected]> wrote:

Paul Procacci wrote in 
<cafbbpuhilswcjbvd9f_rh+q+5b2bzcanlk2h3aqijjkcokx...@mail.gmail.com>:
 From hosts' perspective:
-----------------------------------------------------------
root@host:~ # tcpdump -ni epair0a
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on epair0a, link-type EN10MB (Ethernet), snapshot length 262144 bytes

 From Jail 1's perspective:
-----------------------------------------------------------
root@Jail1:/ # tcpdump -ni epair0b.60
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on epair0b.60, link-type EN10MB (Ethernet), snapshot length
262144 bytes
07:52:03.722196 ARP, Request who-has 192.168.60.2 tell 192.168.60.1, length 28
07:52:04.785635 ARP, Request who-has 192.168.60.2 tell 192.168.60.1, length 28

this seems like the packets are not making it out of the vlan(4)
interface for some reason.  could you please re-run this with
tcpdump -ve (it doesn't show .1q tags otherwise) and include
the output for both epair0b.60 and epair0b in the jail?

also for my reference, please include the ifconfig output for
epair0b.60, epair0b and epair0a (i think you already showed this,
it's just easier to have it all together, if you don't mind).

Sure.  This isn't a problem and I think you're onto something:

root@fw:/ # tcpdump -nvi epair0b -e
tcpdump: listening on epair0b, link-type EN10MB (Ethernet), snapshot
length 262144 bytes
^C
root@Jail 1:/ # tcpdump -nvi epair0b.60 -e
tcpdump: listening on epair0b.60, link-type EN10MB (Ethernet),
snapshot length 262144 bytes
08:00:29.095183 58:9c:fc:10:bb:b7 > ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.60.2 tell 192.168.60.1, length 28
08:00:30.158598 58:9c:fc:10:bb:b7 > ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.60.2 tell 192.168.60.1, length 28


.... and the output of the interfaces ....
root@Host:~ # ifconfig epair0a
epair0a: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP>
metric 0 mtu 1500
         options=60000b<RXCSUM,TXCSUM,VLAN_MTU,RXCSUM_IPV6,TXCSUM_IPV6>
         ether 58:9c:fc:10:8b:0f
         groups: epair
         media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
         status: active
         nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>


root@Jail 1:/ # ifconfig epair0b; ifconfig epair0b.60
epair0b: flags=1008942<BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP>
metric 0 mtu 1500
         options=60000b<RXCSUM,TXCSUM,VLAN_MTU,RXCSUM_IPV6,TXCSUM_IPV6>
         ether 58:9c:fc:10:bb:b7
         groups: epair
         media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
         status: active
         nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
epair0b.60: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP>
metric 0 mtu 1500
         options=0
         ether 58:9c:fc:10:bb:b7
         inet 192.168.60.1 netmask 0xffffff00 broadcast 192.168.60.255
         groups: vlan
         vlan: 60 vlanproto: 802.1q vlanpcp: 0 parent interface: epair0b
         media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
         status: active
         nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

Let me know if you want anything more.

~Paul
--
__________________

:(){ :|:& };:

Problem fixed.  I feel so ashamed.
While epair0b.60 was up ... epair0b wasn't.
A stupid stupid oversight.

Thanks again for all the help and attention.  And sorry for the noise.
I owe ya'll a beer if we ever cross paths.

~Paul


Oh, I've been bitten by this so many times. Would be nice if ifconfig would 
show interface that are down in blinking bold red. :-)

Thinking out loud. With these layered interfaces, I can't think of a reason why 
you would have epair0b.60 up, but epair0b down. Why wouldn't we bring up both 
if you ifconfig up one of them or at least when you bring up the top one? 
Similar thinking could be done for epair0a and epair0b. I have never been in a 
situation in which I want one side of the pair up and the other down.

What would hold us back from implementing this?

Ronald.


Reply via email to