Egy fizikai link rekord (phs_links_table) mentésekor, az adatbázisban automatikusan létrejön a logikai link rekord (log_links_table) is, ha a fizikai linkek lánca végponttól végpontig tart. Ez megosztások esetén hibás lehet, ha a két végponton nem azonosak a rögzített megosztások. Pl. ha az egyik oldalon nincs megosztás, a másikon pedig két megosztás is van két végponttal, akkor hibásan mindkét portra megkísérli a logikai link rekordot létrehozni, ami viszont ütközik, így sikertelen. A logikai linkek létrehozásánál az átjárhatóságot vizsgálja, nem pedig azt, hogy egy ethernet csatlakozás kapcsolódik-e. Az megosztás hiánya az egyik oldalon, a másik oldalon az A és B megosztás felé is átjárható, viszont hálózati kapcsolat csak az A felé lesz. Az API-ban van olyan függvény ami ezt kezeli, de az SQL-ben csak olyan ami az átjárhatóságot vizsgálja.
Ha figyelünk erre a sajátosságra, akkor ez a hiba elkerülhető. Sajnos a megosztások kezelése igen összetett kérdés, így javítás egyhamar nem várható.
Egy fizikai link rekord (phs_links_table) mentésekor, az adatbázisban automatikusan létrejön a logikai link rekord (log_links_table) is, ha a fizikai linkek lánca végponttól végpontig tart. Ez megosztások esetén hibás lehet, ha a két végponton nem azonosak a rögzített megosztások. Pl. ha az egyik oldalon nincs megosztás, a másikon pedig két megosztás is van két végponttal, akkor hibásan mindkét portra megkísérli a logikai link rekordot létrehozni, ami viszont ütközik, így sikertelen. A logikai linkek létrehozásánál az átjárhatóságot vizsgálja, nem pedig azt, hogy egy ethernet csatlakozás kapcsolódik-e. Az megosztás hiánya az egyik oldalon, a másik oldalon az A és B megosztás felé is átjárható, viszont hálózati kapcsolat csak az A felé lesz. Az API-ban van olyan függvény ami ezt kezeli, de az SQL-ben csak olyan ami az átjárhatóságot vizsgálja. Ha figyelünk erre a sajátosságra, akkor ez a hiba elkerülhető. Sajnos a megosztások kezelése igen összetett kérdés, így javítás egyhamar nem várható.