Topics

Moin zusammen,

ich sitze seit einiger Zeit vor einem seltsamen Problem. Mein Setup sieht wie folgt aus:
OPNsense virtuell auf einem Debian Unterbau (openmediavault um genau zu sein). Host hat 2 NICs, eine davon Intel, diese ist durchgereicht. Interface in OPNsense ist em0.
Auf diesem Interface habe ich nun alle VLANs getagged vorliegen, d.h. untagged wird gar nicht verwendet. Tagged VLAN 5 ist das Glasfasermodem vom ISP, und darauf wird wiederum PPPoE gesprochen. Soweit so gut, PPPoE funktioniert, IPv4 funktioniert, IPv6 funktioniert - ich erhalte eine IP auf dem Interface sowie ein /56 Präfix. Meine LAN Clients bekommen eines der Netze aus dem delegierten Präfix.

Wenn da nicht das eine "kleine" Problem wäre: OPNsense hat manchmal schlicht und ergreifend keine IPv6 Default Route. Ich verstehe nicht wie es dazu kommt. Früher lief das und ich meine, dass die Probleme mit 24.1 begonnen haben. Ist aber schwierig zu sagen, da im gleichen Zeitraum mein ISP an den Settings geschraubt hat - ursprünglich bekam ich nur ein IPv6 Präfix ohne IP auf dem Interface, dann zweitweise nur ein /64 Präfix und mittlerweile eine Adresse fürs Interface sowie ein /56 Präfix, wie es ja an und für sich auch schön ist.

Was mir noch auffällt ist, dass beim Boot "Configuring LAN Interface" sehr lange hängt, die anderen Interfaces flutschen durch. Nehme ich die IPv6 Config als Track Interface vom LAN Interface runter, geht es auch da schnell. Das WAN Interface wird nach dem LAN Interface konfiguriert - da erscheint mir die Verzögerung logisch. Kann es hier möglicherweise ein Problem mit der Reihenfolge der Initialisierung der Interfaces geben, das auch gleichzeitig die fehlende IPv6 Route erklärt?
Ansonsten bin ich für jeden Hinweis dankbar was ich noch probieren könnte

/e: wichtig zu erwähnen ist, dass die Route manchmal fehlt, und manchmal geht es. Gerade hatte ich sie nicht, habe OPNsense rebooted, jetzt ist sie da. Das schreit doch auch irgendwie Race Condition, oder?

/e2: Es scheint als würde das Problem speziell bei PPPoE auf VLAN auftreten. Ich habe auf eine Proxmox VM migriert und für jedes VLAN ein eigenes vtnet Interface an die OPNsense VM angehängt, anstatt ein Device durchzureichen und die VLANs in OPNsense direkt anzulegen. Damit sind die Probleme scheinbar weg - Boot geht gewohnt flott und Default Route ist auch da. Ich beobachte noch ein paar Tage...

/e3: Leider war das doch kein permanenter Fix - auch mit dedizierten Interfaces pro VLAN fehlt ab und an die Route. Aktueller Fix, der nun seit 2 Tagen hält, ist eine statische Route mit ::/0 und dem entsprechenden Gateway anzulegen. Nicht schön aber wenn das die Lösung ist, soll es so sein

Hey comm,

so i tried to put in some effort recently to make the FRR plugin more of a first-class citizen. First thing i did was (try to) get rid of the dependency on lodash on the diagnostics pages. It's not that hard to do, all the components are basically there anyway.
The thing is, it takes time, a lot of it. This may be in part because i don't do that much coding, especially frontend stuff. But still, i spent a whole day just reworking the BGP page.
I did put in quite a bit of time and effort to attempt to make a generic, extensible Diagnostics template that can be re-used for the other pages, which i would now hope are a breeze to implement. And i also learned a lot about the nifty internals of Bootgrid.

But still, i had to introduce some fiddly JS code to convert the API output into something Bootgrid can understand. Then some other stuff that all in all is not that much - but everytime i spend an evening or a few hours working on these pages i ask myself "Wouldn't it be better to just present FRR's textual output to the user and not think about it anymore"?
It would for sure be a lot less code. Less code, less bugs, more time to spend working on other improvements. I see no big impact on usability from an admin's perspective, at least personally i don't mind reading text vs having the same information prettified in HTML.

Then again, i'm not sure if this is in line with the vision of OPNsense as a whole, and i do believe that routing protocol support is going to become increasingly important for more users in the future. So i'd like to open this thread for a discussion around the plugin and where to go with it. Specifically the diagnostics section.


On another note, and somewhat related, is the topic of the API implementation. Right now it passes through whatever FRR produces which, on the one hand, is a bit annoying when you deal with Bootgrid for example. On the other hand, it can potentially make people with existing tooling very happy because they can just continue using whatever scripts they have for FRR already. Plus whatever code snippets may be out there on stackoverflow or Github will also just work.
So my Q is, is it better to move the complexity of restructuring FRR's JSON output into the Backend and try to make the API output more uniform? Or is that best left in the frontend? Again i can see arguments for both sides...

/discuss


(edit: if you'd like to see my WIP to understand what i'm talking about, here's the branch on my fork: https://github.com/marcquark/plugins/tree/diagnostics-overhaul)

Hi Community,

for those of you who didn't know, the Netbox commmunity maintains a library of device types from multiple vendors so you don't have to click through everything yourself. There's also a Python script that allows you to conveniently import either the whole collection, or specific vendors, into your own Netbox.
You can now take advantage of this library for your OPNsense appliances. All network interfaces aswell as the console and power port are included for every model.

I hope that's useful for some of you. Enjoy!

Hey there,

i'd like to suggest a small improvement to the forum's CSS. There are two tweaks that would make it a lot more widescreen-friendly.

1)

Code Select Expand

.wrapper {
width:100%;
max-width:990px; <<<<<<<<<<<<<<<<<< Change this line to the line below
max-width:90%;
margin:0 auto;
position:relative
}
2)

Code Select Expand

#footer {
text-align:left;
background:#333;
color:#ebebec;
padding:40px; <<<<<<<<<<<<<<<<<< Remove this line, add the two lines below
padding-top:40px;
padding-bottom:40px;
font-size:12px;
overflow-x:hidden;
overflow-y:hidden;
box-shadow:0 0 5px rgba(0,0,0,.15)
}

The second one just makes sure the footer is properly aligned, otherwise it looks weird. Screenshots attached.

upgraded my lab boxes to 20.7.5 a couple of days ago, now i noticed i can't change the settings on any of my VTI interface. i.e. i cannot add or delete a description, cannot change the enabled state. then i tried unassigning the interface but that doesn't work either. i also can't make any changes to related gateways that i had created.

while i don't recall testing this specifically, i do remember playing around with VTI interfaces quite a bit on 20.7.4 before and never ran into such an issue. does anybody else observe this behaviour? could it be caused by a failed migration? i currently don't have the time to create a clean test setup to check that