Messages

Pardon me for my ignorance, but isn't all of that besides the point?

If indeed two devices in the same broadcast domain do have the same MAC for whatever reason, you will be out of luck anyway, because both will use the same ethernet header and that is independent of IPv4 with ARP or IPv6 with NDP.

Sure. Obviously you can replace the PC and move that dupe PC to another network or tell the OS to use a diff MAC. The point here was the when running SLAAC the end user may not know how to correct the dupe IP.

I must be the only one here who's seen many dupe macs on laptops and pc's.

I'm a network engineer for more than three decades and I have never seen a single duplicate MAC address. 🤷�♂️

Four decades here, sounds super old... I have seen it as recent as in last 10yrs with the same manufacturer with diff NICs one on a laptop and other on a PC. Dupe MACs are here to happen is a fact. Reliance on them as an IPv6 is a crap shoot that I will not recommend losing job over. :D

To elaborate, the IPv6 should include at least the vlanID .

I must be the only one here who's seen many dupe macs on laptops and pc's. This is relevant in million VLAN architecture but an absolute nightmare in IPv6. Anywho, please move along nothing to see here...

lol

Ah... You forgot to read... No worries! Please re read the thread all the way to this post. :)

nice!

https://www.youtube.com/watch?v=FgtTVzYFEF0

Patrick,
   Nice Presentation bud!!! Thanks a lot for all the hard work!

I highly recommend testing strict IPv6 case once deployed. Meaning remove all existence of IPv4 and test to make sure ALL is working as expected which if correctly performed all sites regardless of IPv4 only should work flawlessly. Otherwise, it's not properly set, period.

This would make Patrick's link moot point since there should not be a case where dual stack would be needed. 

Dual Stack is a like speaking Tunisian, half French, half Arabic. Who know which half is what... </joking>

If you really are trying to learn the "ula made useless" is not really important. :) Since the ultimate goal is Site wide IPv6 only.

otherwise, there's no point in deploying IPv6 other than after midnight stress of why google link sends me to my fav pR0n site troubleshooting. :D

[### Why]

Let me GROK that for you:

If you're seeing `OUT_BYTES` and `OUT_PACKETS` as always zero in the NetFlow v9 flow records from OPNsense, despite these fields being defined in the templates, there are several potential reasons for this behavior. Below, I'll explain why this might be happening and why these fields are still included in the templates, along with steps to diagnose and potentially resolve the issue.
### Why `OUT_BYTES` and `OUT_PACKETS` Are Always Zero
1. **NetFlow Configuration in OPNsense**:
  - OPNsense's NetFlow exporter, based on the `ng_netflow` module in FreeBSD, can be configured to capture either ingress, egress, or both directions of traffic. If your configuration is set to capture only **ingress** traffic (default in many setups), the `OUT_BYTES` and `OUT_PACKETS` fields will be zero because no egress data is being collected.
  - Check the NetFlow settings in OPNsense under **Reporting > NetFlow**. Look at the interface settings to see if egress capturing is enabled. If only ingress is selected, the exporter will not populate `OUT_BYTES` and `OUT_PACKETS`.
2. **Traffic Direction and NAT**:
  - In OPNsense, Network Address Translation (NAT) can affect how flows are recorded. If traffic is being NAT'd (e.g., from LAN to WAN), the firewall may only record flows in one direction (typically ingress) to avoid double-counting traffic. This is a common optimization in NetFlow setups, as noted in OPNsense documentation, where capturing both directions can lead to duplicate data for NAT'd flows.
  - If your setup involves NAT, the exporter might intentionally omit egress data to simplify analysis, resulting in `OUT_BYTES` and `OUT_PACKETS` being zero.
3. **Interface Monitoring**:
  - The fields `OUT_BYTES` and `OUT_PACKETS` are populated based on the traffic leaving the monitored interface. If the monitored interfaces (e.g., LAN or WAN) are not seeing outbound traffic or if the exporter is not configured to monitor the interfaces where outbound traffic occurs, these fields will remain zero.
  - Verify which interfaces are being monitored in the NetFlow settings. For example, if you're only monitoring the LAN interface for ingress traffic, outbound traffic (e.g., to WAN) may not be captured.
4. **Collector or Template Misinterpretation**:
  - Some NetFlow collectors may misinterpret or fail to properly parse the flow records, leading to `OUT_BYTES` and `OUT_PACKETS` appearing as zero. Ensure your collector (e.g., nfdump, SolarWinds, or OPNsense's Insight) is fully compatible with NetFlow v9 and correctly processes the templates sent by OPNsense.
  - Check the collector's logs for any errors about missing or unprocessed templates, as this can cause data to be misreported.
5. **NetFlow v9 Template Behavior**:
  - In NetFlow v9, templates are sent periodically to describe the structure of flow records, and they may include fields like `OUT_BYTES` and `OUT_PACKETS` even if no data is currently being reported for those fields. This is standard behavior, as the template defines the *potential* data that can be sent, not necessarily what is always populated. If egress data is not being captured due to configuration, these fields will remain zero but are still included in the template for compatibility and future use.
### Why Are `OUT_BYTES` and `OUT_PACKETS` Included in Templates?
- **Template Design**: NetFlow v9 templates are designed to be flexible and reusable. OPNsense includes `OUT_BYTES` and `OUT_PACKETS` in the templates to support scenarios where egress traffic is monitored. Even if your current configuration doesn't populate these fields, the template is structured to accommodate both ingress and egress data, ensuring compatibility with collectors that expect these fields.
- **Future-Proofing**: Including these fields allows you to enable egress capturing later without changing the template structure, avoiding disruptions to the collector. If you reconfigure OPNsense to capture egress traffic, the same template can be used, and `OUT_BYTES`/`OUT_PACKETS` will start being populated.
- **Standard Compliance**: The `OUT_BYTES` and `OUT_PACKETS` fields (Field IDs 23 and 24 in NetFlow v9) are part of the standard NetFlow v9 specification. Including them in the template aligns with best practices and ensures interoperability with various collectors.
- **Bidirectional Analysis**: Many network monitoring use cases require bidirectional flow data to analyze traffic patterns fully. Including these fields in the template supports such use cases, even if they're not currently active in your setup.
### Steps to Diagnose and Resolve
1. **Verify NetFlow Configuration**:
  - Go to **Reporting > NetFlow** in the OPNsense web interface.
  - Check the **Interfaces** setting to see if egress capturing is enabled. You may need to explicitly enable "Export flows from this interface" for egress on the relevant interfaces (e.g., WAN or LAN).
  - Ensure the "Direction" setting includes both ingress and egress if you want bidirectional data.
2. **Check Interface Traffic**:
  - Confirm that the interfaces being monitored have outbound traffic. For example, if you're monitoring the LAN interface, ensure it's seeing traffic leaving the interface (e.g., to the WAN or another network).
  - Use OPNsense's traffic graphs or packet captures to verify outbound traffic on the monitored interfaces.
3. **Inspect Flow Records**:
  - Use a tool like `nfdump` or Wireshark to capture and inspect the raw NetFlow packets from OPNsense. Look at the flow records to confirm whether `OUT_BYTES` and `OUT_PACKETS` are indeed zero or if the collector is misinterpreting the data.
  - Example `nfdump` command to view flows:
    ```bash
    nfdump -r <flow-file> -o extended
    ```
    Check for non-zero values in the `out bytes` and `out packets` columns.
4. **Test Egress Traffic**:
  - Generate test traffic (e.g., using `ping`, `wget`, or file transfers) to ensure outbound traffic is flowing through the monitored interface. Then check if `OUT_BYTES` and `OUT_PACKETS` are populated in the flow records.
5. **Collector Compatibility**:
  - Verify that your NetFlow collector supports NetFlow v9 and bidirectional flows. Some older collectors may not handle `OUT_BYTES`/`OUT_PACKETS` correctly.
  - Update the collector to the latest version or test with a different collector (e.g., nfdump or FlowViewer) to rule out collector issues.
6. **Consider Disabling NAT Optimization**:
  - If NAT is causing OPNsense to suppress egress data to avoid double-counting, you can experiment with disabling this optimization. In the NetFlow settings, look for options like "Disable NAT" or adjust the flow capture to include egress explicitly. Be cautious, as this may lead to double-counting in some scenarios.
7. **Consult OPNsense Documentation or Community**:
  - Check the OPNsense documentation for NetFlow (available under **Reporting** in the official docs) or the OPNsense forum for similar issues. Users have reported cases where egress data wasn't captured due to specific interface or NAT configurations.
### Additional Notes
- **Performance Impact**: Capturing both ingress and egress flows increases the load on the OPNsense system and the volume of flow data sent to the collector. If egress data isn't critical for your use case, keeping it disabled (resulting in zero `OUT_BYTES`/`OUT_PACKETS`) can reduce resource usage.
- **Alternative Tools**: If bidirectional data is critical, consider using other OPNsense features like the Traffic Insight tool or external collectors like nProbe, which can provide more granular control over flow data.
If you'd like, I can guide you through specific configuration changes in OPNsense or help analyze flow data from your collector. Could you share:
- Which interfaces are configured for NetFlow?
- Whether you've enabled ingress, egress, or both in the settings?
- The NetFlow collector you're using?
This will help pinpoint the issue further.

Mac is already able to and no need to run OPNsense... use either Murus and/or LittleSnitch
https://www.murusfirewall.com/murus/

Mac is already able to and no need to run OPNsense... use either Murus and/or LittleSnitch
https://www.murusfirewall.com/murus/

Are there instructions as to how to replace them and upload the new OPNsense? possibly a YT vid?

So, Oracle example was was from "A Company" and "Multicore" perspective regardless of what product performs.

Now back to ZA, I agree with you @Seimus on all counts but to be the devil's advocate here...
what's it for a company to buy a DECISO's BEEFY box and throw in the ZA and run with it for free... Yeah, I do understand the Mom'n'Pops shops should be considered home users as the restrictions in budgets'n all... 

BUT! ZA has to make moola! So, from that perspective they could Cap the multi to a session rate or what not so that the grandma in Norway with 400Gbps pipe would have to cough up USD to satisfy her 8K TV. ROFL!

Hi,
  Disable Nut and you are done. :)

Quite easy if you follow the directions

it states:
-build port dotnet8

Code Select Expand

cd /usr/ports/
mkdir packages
opnsense-code tools src ports
cd lang/dotnet8
make package


Just look how much Oracle charges per core... ROFLMAO...