User Netdoc: Switchports anzeigen

Aktuell filtern wir auf DD, allerdings gibt es Anwendungsfälle auch Switchports zu sehen (z.B. im Rechenzentrum/Kanaleinbauswitche/...)

Beispielnetz: kastel-dsn-server

UPDATE: Es ist jetzt eine Übergangslösung implementiert; erst mit ou2p_port wird es eine gute Lösung für das Problem geben. (s.a. #726 (closed) wg. interimsloesung / leserechte mtc, mt, m f. oe-betreuer)

changed milestone to %Pre 4.1 NETVS Development

added Good first issue NETVS labels

Das ist gar nicht so trivial hier einen sinnvollen Filter zu bauen, der genau die p_ports findet, die ein "Access" Port für den User sind. Im allgemeinen eben Datendosen, aber eben auch Switche im Datacenter an denen dann der Server hängt. Allerdings will man wiederum nicht irgendwelche anderen Switche auf dem Verbindungsweg bekommen. Da ist mir gerade noch keine Metrik klar, wie man das am sinnvollsten darstellen kann.

@rainer.steinmueller hast du da eine Idee?

me. geht das nur mit der angedachten p_port2ou-abbildung.

Hmm. Dachte ich mir schon. Habe jetzt eben mal rumprobiert, mit is_edge_node=true und is_connected=false kommt man hier erstmal schon recht weit; habe bisher bei mir nur eine BCD gefunden, wo man hier zu viele Module sieht.

changed the description

removed Good first issue label

added API postponed labels

removed milestone %Pre 4.1 NETVS Development

changed milestone to %Pre 4.2 NETVS Development

assigned to @rainer.steinmueller, @julian-hiwi, and @janis.streib

ich habe mal eine ersterfassung bzw. aufstellung gemacht. es gibt demnach insgesamt 75464 pp-oe-zuordnungen. die aufstellung erfolgt nach den kriterien:

1. switchports in aktiven modulen, die accessports sind (nicht verbunden, via l2p-port - vlan (egress oder ingress) - bcd - oe ). darunter fallen:
   • kanal-einbauswitche
   • switche im datacenter, an denen server haengen
2. dd-ports, die verbunden sind (via dest-port, der zu einem aktiven modul gehoert, von dort aus weiter wie switchports). also nur anschlussdosen via mtc 'DD'.

das koennte man zunaechst mal relativ einfach als neue relation z.b. nd.p_port2ou (pp2ou) einfuehren und als neuen OT in die webapi stellen.

sql:

with dd as (

  select pp.key_nr, oe.key_nr
  from nd_p_port pp
    JOIN nd_mdl m ON pp.nd_mdl_key_nr = m.key_nr
    JOIN nd_mdl rm ON m.nd_root_mdl_key_nr = rm.key_nr
    JOIN nd_l2p_port l2p ON pp.key_nr = l2p.nd_p_port_key_nr
    JOIN nd_l_port lp ON lp.key_nr = l2p.nd_l_port_key_nr
    JOIN nd_vlan_egress ve ON ve.nd_l_port_key_nr = lp.key_nr
    JOIN nd_vlan v ON ve.nd_vlan_key_nr = v.key_nr
    JOIN nd_bcd bcd ON v.nd_bcd_key_nr = bcd.key_nr
    JOIN nd_bcd2oe b2oe ON b2oe.nd_bcd_key_nr = bcd.key_nr
    JOIN vw_oe oe ON b2oe.vw_oe_key_nr = oe.key_nr
  where rm.is_active
  and pp.key_nr = pp.nd_p_port_key_nr
  and lp.adm_state = 1 -- up/down/undef: 1/2/0
  and v.name != 'unused'

UNION

  select ddpp.key_nr, oe.key_nr
  from nd_p_port ddpp
    JOIN nd_mdl ddm ON ddpp.nd_mdl_key_nr = ddm.key_nr
    JOIN nd_mdl_typ ddmt ON ddm.nd_mdl_typ_key_nr = ddmt.key_nr
    JOIN nd_mdl_typ_class ddmtc ON ddmt.nd_mdl_typ_class_key_nr = ddmtc.key_nr
    JOIN nd_p_port pp ON ddpp.key_nr = pp.nd_dest_p_port_key_nr AND ddpp.key_nr != pp.key_nr
    JOIN nd_mdl m ON pp.nd_mdl_key_nr = m.key_nr
    JOIN nd_mdl rm ON m.nd_root_mdl_key_nr = rm.key_nr
    JOIN nd_l2p_port l2p ON pp.key_nr = l2p.nd_p_port_key_nr
    JOIN nd_l_port lp ON lp.key_nr = l2p.nd_l_port_key_nr
    JOIN nd_vlan_egress ve ON ve.nd_l_port_key_nr = lp.key_nr
    JOIN nd_vlan v ON ve.nd_vlan_key_nr = v.key_nr
    JOIN nd_bcd bcd ON v.nd_bcd_key_nr = bcd.key_nr
    JOIN nd_bcd2oe b2oe ON b2oe.nd_bcd_key_nr = bcd.key_nr
    JOIN vw_oe oe ON b2oe.vw_oe_key_nr = oe.key_nr
  where rm.is_active
  and ddmtc.short_name = 'DD'
  and lp.adm_state = 1 -- up/down/undef: 1/2/0
  and v.name != 'unused'

)
select count(*) from dd
;

die frage der weiteren datenpflege ist damit allerdings noch voellig offen...

• also z.b. was passiert, wenn vlans@device umkonfiguriert werden. pp2ou in devimport integrieren? damit waeren die ports, die vlan-zuordbar sind, erledigt.
• parallel dazu koennen pp2ou auch direkt per api-fkt. eingetragen/geloescht werden, um z.b. ports zuzuordnen, die keinen vlan-aufschluss haben. damit koennen aber durchaus widersprueche entstehen.

Das ist in der Tat nicht so einfach. Man sollte sich das grundsätzlich nochmal genau überlegen, wie die Datenpflege in Zukunft aussehen soll. Vom Gefühl her sollte das in einer idealen Welt so aussehen, dass man beim Umzug eines Instituts einmal Raumweise die Ports einer neuer OU assignen muss. (Allerdings mit einer ref_params Konstruktion auch nur die wieder zuweisen, die der alten vorher gehört haben; ggf gibt es in dem Raum ja sowas wie Access Points etc). Das sollte mMn nach auch direkt beim Umzug passieren und nicht erst beim ersten Patchen (sonst muss ja das patchen noch immer händisch erfolgen, was wir ja eigentlich minimieren wollen). Aktuell wo es noch keinen Prozess gibt, wie wir Umzüge sinnvoll mitbekommen und bearbeiten könnte man wie du vorgeschlagen hast im Import die Zuordnungen machen, dann hätte man zumindest schonmal eine Datenbasis die initial einen größeren Teil abdeckt. Mit relativ wenig scripten sollte man da daraus dann eine raumweise Zuordnung erzeugen können.

Wenn wir diese erste Zuordnung haben könnte man auch mal im Handling von der Patch-Request mitspeichern, ob eine durchgeführte Patch-Request mit unserer Datenbasis von pp2ou funktioniert hätte und welche Fälle problematischer sind. Das ist vielleicht sogar eine der spannendsten Informationen um zukünftigen Aufwand und Anforderungen abschätzen zu können.

Denkbar wäre auch, dass man zusätzlich zu pp2ou auch ein (in Zukunft automatisiertes) **Un**patchen von eigenen BCDs erlaubt (auch wenn einem selbst der Port nicht gehört).

Das Problem ist aber auf jeden Fall etwas über das man ggf nochmal nächste Woche reden könnte; da sollte man nochmal in Person ein bisschen brainstormen, ob es da Sonderfälle gibt die häufiger auftreten oder ob bestimmte Ideen wie man das umsetzen kann evtl doch Probleme haben.

auf jeden fall im direkten gespraech fortsetzen und die anforderungen festmachen. in erster linie aus unserer sicht, in zweiter linie mit den leuten, die den betrieb CS/CN machen (manfred/ingo, benjamin/andreas/markus). moeglichst trennung/unterteilung der anforderungen in die beiden ebenen

• api/netdb (als basismaessige datenablage)
• anwendungsebene (netvs) bzw. betriebsprozesse/arbeitsablaeufe, die deutlich komplexer sind als die blosse basisdatenhaltung.

punktesammlung bisher:

• unterscheidung, ob pp2ou-rows durch automatismen (wie z.b. devimport) behandelt werden oder nicht
• ausschlusskriterien fuer eine neuerfassung eines ports in pp2ou (automatisch oder direkt)
• ausschlusskriterien fuer eine loeschung eines ports in pp2ou (automatisch oder direkt)
• sind diese punkte auch noch ou-seitig erforderlich?

marked this issue as blocking #135

mentioned in issue #726 (closed)

marked this issue as related to #726 (closed)

changed the description

removed milestone %Pre 4.2 NETVS Development